Translation Table Memory Attribute bits

[Stefan Kalkowski]

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
>>> genode-main at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/genode-main
>>>
> 
> 
> ------------------------------------------------------------------------------
> Slashdot TV.  
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/
> _______________________________________________
> genode-main mailing list
> genode-main at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/genode-main
> 

-- 
Stefan Kalkowski
Genode Labs

http://www.genode-labs.com/ · http://genode.org/