Translation Table Memory Attribute bits

Fri Sep 5 19:33:01 CEST 2014

Hi Stefan,
     The TI Sitara Family of processors Starterware contains code 
setting up the translation tables... here's  the relevant snippet--

/*
** Function to setup MMU. This function Maps three regions ( 1. DDR
** 2. OCMC and 3. Device memory) and enables MMU.
*/
void MMUConfigAndEnable(void)
{
/*
** Define DDR memory region of AM335x. DDR can be configured as Normal
** memory with R/W access in user/privileged modes. The cache attributes
** specified here are,
** Inner - Write through, No Write Allocate
** Outer - Write Back, Write Allocate
*/
REGION regionDdr = {
MMU_PGTYPE_SECTION, START_ADDR_DDR, NUM_SECTIONS_DDR,
MMU_MEMTYPE_NORMAL_NON_SHAREABLE(MMU_CACHE_WT_NOWA,
MMU_CACHE_WB_WA),
MMU_REGION_NON_SECURE, MMU_AP_PRV_RW_USR_RW,
(unsigned int*)pageTable
};
/*
** Define OCMC RAM region of AM335x. Same Attributes of DDR region given.
*/
REGION regionOcmc = {
MMU_PGTYPE_SECTION, START_ADDR_OCMC, NUM_SECTIONS_OCMC,
MMU_MEMTYPE_NORMAL_NON_SHAREABLE(MMU_CACHE_WT_NOWA,
MMU_CACHE_WB_WA),
MMU_REGION_NON_SECURE, MMU_AP_PRV_RW_USR_RW,
(unsigned int*)pageTable
};

/*
** Define Device Memory Region. The region between OCMC and DDR is
** configured as device memory, with R/W access in user/privileged modes.
** Also, the region is marked 'Execute Never'.
*/
REGION regionDev = {
MMU_PGTYPE_SECTION, START_ADDR_DEV, NUM_SECTIONS_DEV,
MMU_MEMTYPE_DEVICE_SHAREABLE,
MMU_REGION_NON_SECURE,
MMU_AP_PRV_RW_USR_RW | MMU_SECTION_EXEC_NEVER,
(unsigned int*)pageTable
};

I had to change the memory attributes for device memory to get the 
kernel to complete initialization. If B is not set the kernel silently 
page faults after the mmu is turned on.

The .text address of 0x81000000 come from readelf.

Yes I added a  printk to get at the mmu exception.

I can see one page fault but it appears to be a page fault on every 
access to the section entry for 0x81000000.

Bob

On 09/05/2014 08:30 AM, Stefan Kalkowski wrote:
> 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
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20140905/9c5c1624/attachment.html>