Thanks for the reply Stefan. For the AM335x processors, the cacheability is required to be set to:
Inner: Write thru, no write allocate Outer: Write back, write allocate. So, in 14 .02 I set the Tex, C, and B bits accordingly and that worked fine. I just transferred those setting to 14.08. With the rework in that tlb area of the kernel for multi-processor support in 14.05 and 14.08, I assumed I was screwing something up in the translation table entry attribute bits. According to the ROM fs dump "Rom: [8113b000,8117aa24) init". it is the .text section of the program image that starts at 0x81000000. I'll dump the contents of the DFSR and see what that tells me later today. I'll also try run/printf as the program image, but the program image I'm using runs fine when built on 14.02. Thanks for the suggestion. Bob On 09/05/2014 03:36 AM, Stefan Kalkowski wrote: > Hi Bob, > > On 09/04/2014 03:33 PM, Bob Stewart wrote: >> I've never been able to get 14.05 or 14.08 working on my AM335X >> processor, which is not a big deal as 14.02 has everything I need for >> the applications I'm using that processor for. But out of curiosity: >> >> The issue on 14.08 may revolve around memory access bit rights in TLB >> table entries. To get 14.08 to initialize the kernel properly the memory >> access bits have to be set as Tex = 0, B = 1, and C = 0. These setting >> seem correct for a shared Device according to the Arm v7 ref manual. >> With those settings in place, the kernel initializes properly and >> eventually init runs. During the kernel initialization process Core_pd >> is called and translations are created for the program image (which >> starts at 0x81000000) and the core-only io memory regions. The >> translation table entries for the program image are of section size plus >> a small page so two entries are inserted in the translation table. The >> access bits and permission bits for the section entry are correct with >> the possible exception of the C bit, which in 14.08 appears never to be >> set and I wondered why that was, when it is used in 14.02. > We reworked a lot regarding ARM caches, shareability etc. within the > last months. Nowadays (release 14.08), on all Arm v7 platforms, > including Cortex A8, we set the following memory region attributes for > normal memory (!not device memory): Tex=0b101, C=0, B=1 > That means: normal, inner- and outer-cacheable memory, with > write-back,write-allocate caching policy. Which works properly on all > our Cortex A8, Cortex A9, and Cortex A15 platforms. > >> Once the init thread runs, any reference to the translation table entry >> for the program image, the section entry mentioned above cause a mmu >> exception as the following partial debug output shows: >> ... >> start thread 3 'entrypoint' in program 1 'core' on processor 0/1 >> start thread 4 'signal' in program 1 'core' on processor 0/1 >> start thread 5 'pager_activation' in program 1 'core' on processor 0/1 >> int main(): --- start init --- >> int main(): transferred 507 MB to init >> start thread 6 'init' in program 1 'core' on processor 0/1 >> thread id is 0x7 >> start thread 7 'init' in program 2 'init' on processor 0/1 >> void Kernel::Thread::_mmu_exception(): f_addr 0x81000000 f_writes 0x0 >> f_pd 0x813ed088 f_signal 0x7f >> label init >> int main(): --- init created, waiting for exit condition --- >> void Kernel::Thread::_mmu_exception(): f_addr 0x81045f60 f_writes 0x1 >> f_pd 0x813ed088 f_signal 0x7f >> label init >> void Kernel::Thread::_mmu_exception(): f_addr 0x8102dab8 f_writes 0x0 >> f_pd 0x813ed088 f_signal 0x7f >> label init >> ... >> >> Setting the C bit as it was set in 14.02 makes no difference, which I >> thought it would and it should be affecting caching behavior. >> >> Any thoughts on this behavoir? > Before thinking about a caching issue, I would investigate whether there > is no other issue. Above output shows that the whole kernel/core are > fully initialized and the init process is started. When the init process > tries to do some "write" operations it fails, right? So there is no > problem with the core's translation tables (Core_pd) at all. > > First of all, you should identify which kind of MMU exception was > triggered by the init process. Therefore, print out the DFSR (data fault > status register) directly after the corresponding faults occur. Does the > init binary also start at 0x81000000? > > Regards > Stefan > >> Thanks, >> Bob >> >> ------------------------------------------------------------------------------ >> Slashdot TV. >> Video for Nerds. Stuff that matters. >> http://tv.slashdot.org/ >> _______________________________________________ >> genode-main mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/genode-main >> ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ genode-main mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/genode-main
