On 11/15/2013 03:01 PM, bob wrote:
On 11/15/2013 01:13 PM, Martin Stein wrote:
Hi Bob,
The only purpose of the parameter CACHE_LINE_SIZE_LOG2 is to enable us flushing the level 1 data cache of ARM in base-hw selectively. It controls the granularity of the flushing commands and is set correctly only for the Arndale board by now. The value "2" is the least possible value for ARM and slows flushing in the worst case while a value that would be higher than the correct value might cause data incoherence. Long story short: you can use "2" if you don't find the correct value in the level-1-cache description of your board spec.
Do you know which revision of Cortex-A8 (r1p1..r3p2) your board uses? Maybe there are quirks in your revision that base-hw doesn't support by now.
Have you checked whether the mappings you're adding to core TLB cover the text and BSS segment of the bin/core image?
You can also deactivate caches temporarily by initializing Arm::Cpu::Sctlr::C and Arm::Cpu::Sctlr::I in Arm::Cpu::Sctlr::common with 0 (base-hw/src/core/cpu/arm.h). This would at least limit the candidates.
PS: there is an open issue "base-hw crashes without caches" but as long as you're not above core/init this shouldn't affect you.
Cheers, Martin
On 15.11.2013 18:16, bob wrote:
Hi, Is CACHE_LINE_SIZE_LOG2 the line length in 32 bit words of the L2 Instruction or Data caches? That's the only cache line length I see in the board spec of the am335x in its TRM.
I'm having a problem the initial start of the kernel, which appear to hang when the MMU is switched on in init_virt_kernel function. The tlb should set up correctly as I've defined the boards physical ram and MMIO regions in the Core_tbl class. The CACHE_LINE_SIZE_LOG2 parameter appears to be used as the stride length for walking the tlb. It is currently set at 2 only because that's the value used in the Panda and imx53 boards board_base.h. If that's not the problem, I'm at a loss as to what the issue could be since the CPU object is straight cortex-a8 from the arm_v7 architecture. Any pointers to how to diagnose the issue would be a great help.
Thanks,
Bob Stewart
DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clk...
Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clk...
Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Thanks Martin for the quick response.
The Technical Reference Manual for the Am335X doesn't reference a rev number for the Cortex A8 version, but I'll keep looking at a couple of other manuals. I'll go over all the System Control bit settings and compare them to the current Cortex-A8 manual to see if that tells me anything.
The core tlb I created defines a RAM region that cover the entire RAM available on the board, which covers the .text and .bss sections. Also includes two MMIO regions that cover controls for devices and the devices themselves.
Setting the C and the I bits the System Control register to zero had no effect.
I'll dig deeper into the CPU behavior and see what I can find.
Bob
p.s. I did find out from the Beaglebone community that the Cortex-A8 version is r3p2.