[okl4-developer] OKL4 v2.1: ARM startup code overwrites itself

[Frank Kaiser]

Hello, Geoffrey

I see that you have an performance argument to place the location of the
ARM globals at the beginning of the virtual kernel memory. However, it
does not explain my main point, that the way the address of the globals
is maintained, leads to overwriting the startup code in a non-XIP
configuration. Why not define the data properly at C++ level and provide
it with a SECTION attribute so that it can be handled by the linker,
which could assign the expected memory location and prevent overlapping?
Furthermore, I wonder what would happen in a an XIP configuration. Since
the code is kept in NOR Flash, I assume some normally linked kernel data
will appear at the beginning of the virtual kernel memory with which the
ARM globals might interfer.

Regards
Frank
> -----Original Message-----
> From: Geoffrey Lee [mailto:glee at ok-labs.com]
> Sent: Tuesday, June 24, 2008 10:32 AM
> To: Frank Kaiser
> Cc: developer at okl4.org
> Subject: Re: [okl4-developer] OKL4 v2.1: ARM startup code overwrites
itself
> 
> On Mon, Jun 23, 2008 at 04:55:33PM +0200, Frank Kaiser wrote:
> > Hello
> >
> >
> 
> Hello Frank
> 
> >
> > During the ongoing adaption to the ATMEL AT91SAM9263-EK board (which
has
> > a non-XIP configuration) I observed that the initial code located in
> > file head.spp is partly overwritten. In a non-XIP configuration the
> > kernel is linked to the virtual start address of the RAM which maps
to
> > the start address of the physical memory as defined in
> > 'platform/<platform>/tools/machine.py'.
> >
> > Responsible for this behaviour is procedure init_arm_globals() which
is
> > called after the MMU has been switched to virtual addressing mode.
The
> > procedure obtains from function get_arm_globals() a pointer of type
> > arm_globals_t which is a structure holding various variables and
> > pointers the kernel is using. Function get_arm_globals() returns the
> > constant ARM_GLOBAL_BASE as the address of the structure. This
constant
> > is identical with constant VIRT_ADDR_RAM which holds the value
> > 0xF000.0000 to which the kernel code is allocated.
> 
> 
> The ARM architecture normally addresses global variables as such:
> 
> ldr r0, [pc, #offset]
> ldr r0, [r0]
> 
> Using the ARM globals feature, you can do:
> 
> mov r0, #f0000000
> ldr r0, [r0, #offset]
> 
> This is better because it uses less dcahce lines and leads to less
> conflict misses.