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

Frank Kaiser frank.kaiser at opensynergy.com
Tue Jun 24 00:55:33 EST 2008


Hello

 

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.

Although the overwriting is not hazardous while the system is running,
since head.spp is only executed ones, it makes it impossible to restart
it w/o reloading it into RAM. And it casts doubt on the MMU
configuration: the successful execution of init_arm_globals() is an
indication that the kernel code (at least the .init section) is not
write-protected by the MMU as I would expect.

Can anyone clarify whether the allocation of the structure arm_globals_t
to the kernel's .init section is intentional, and whether there is an
effective write-protection set up in the MMU for the kernel code?

 

Regards

Frank

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.okl4.org/pipermail/developer/attachments/20080623/f4a3f71f/attachment-0001.htm 


More information about the Developer mailing list