Translation Table Memory Attribute bits

[Bob Stewart]

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
>> genode-main at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/genode-main
>>