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

[Geoffrey Lee]

On Wed, Jul 02, 2008 at 06:02:10PM +0200, Frank Kaiser wrote:
> Hello, Geoffrey

Hi Frank

> 
> 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
> it with a SECTION attribute so that it can be handled by the linker,
> which could assign the expected memory location and prevent overlapping?

In practice this is not an issue, since you'd have to reload the binary
anyway because by the time your code has run on your system the
data and the bss would have been trashed and you would need to reset
them.  The init code is only ever executed once, and since
the kernel is mapped r/w in that instance, that location can be reused
for ARM globals.  Hence, it turns out to be a non-issue even if the
code and the ARM globals data is overlapping.  This allows us to 
save a bit of space using memory that may otherwise be left unused
with not too much effort.

> 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.


In the XIP configuration, the kernel text and data are mapped
separately.  A bit of space is reserved at the start of the
r/w data section of the kernel for the ARM globals data.


> 
> Regards
> Frank

	-gl

> > -----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.
> 
> 

--