Hi Bob, On 09/05/2014 01:43 PM, Bob Stewart wrote: > > 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.
Are you sure? Can you point me to the relevant information if it's openly available? In the Cortex A8 and AM335x TRM I couldn't find that restriction. I would assume that you don't have to change any memory attributes, as we support Cortex A8 already (although this was error-prone in the past). > > 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. Don't mix things up: the ROM fs dump gives you the physical memory where the boot modules reside in. The program image layout can be seen by e.g.: objdump, or readelf. In this example they are coincidentally nearby. After re-reading your log output (I assume you've added the "void Kernel::Thread::_mmu_exception()" printings?) it seems to me like the init process produces a first page-fault, when executing its first instruction, which is normal, and afterwards continues to run - so the pagefault gets actually resolved, right? After that it gets additional page-faults corresponding to its program flow. So what is the actual weird behaviour? I can't see it given your output. Regards Stefan > > 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 > -- Stefan Kalkowski Genode Labs http://www.genode-labs.com/ ยท http://genode.org/ ------------------------------------------------------------------------------ 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
