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