Translation Table Memory Attribute bits

[Stefan Kalkowski]

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
> 

-- 
Stefan Kalkowski
Genode Labs

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