[okl4-developer] [Support.opensynergy] OKL4 v2.1: Building an XIP image
Frank Kaiser
frank.kaiser at opensynergy.com
Thu Aug 28 21:42:52 EST 2008
Hi Nelson
The assumed behaviour of an XIP image is that no code/const/rodata
sections are copied, thus speeding up the power-on procedure. The
bootloader would just pass control to address 0x10020000 in our example.
At some point the kernel would pass control to an IGUANA code section at
a RAM address expecting the code being present there as defined in the
ELF file.
After invoking OBJCOPY on the ELF file any address information is lost,
so neither U-Boot nor the kernel can derive the correct location from
the image itself. One could preprogram U-Boot to copy something from the
NOR flash into RAM (since the kernel cannot do it), but that would not
be XIP anymore. So what should be the benefit of an XIP option which, as
you describe, only places the kernel code into NOR flash?
Our AT91RM9200 platform is deliberately equipped with NOR flash for fast
power-up readiness, but we cannot benefit from this when we are not able
to make the whole image XIP-capable. To achieve this the procedure which
provides the XIP memory layout to the kernel has to be applied to all
other parts of the image. Can you give me a hint which is the
responsible screw to be turned?
Regards
Frank
> -----Original Message-----
> From: Nelson Tam [mailto:nelson at ok-labs.com]
> Sent: Thursday, August 28, 2008 2:27 AM
> To: Frank Kaiser
> Cc: support.opensynergy at portal.ok-labs.com; developer at okl4.org
> Subject: Re: [Support.opensynergy] OKL4 v2.1: Building an XIP image
>
> Hi Frank,
>
> The section headers looks ok to me. My understanding is that XIP only
> puts the kernel code in flash, but not the Iguana code. Have you
> tried executing this binary, if so what results did you see?
>
> You mentioned about the binary (likely) not being runnable because
> iguana won't be in memory when the system boots. But given the layout
> you've shown, doesn't it get loaded into ram by the bootloader? Have
> I missed something?
>
> It doesn't look like you have missed any configuration options to
> enable XIP, so I would go ahead and try running with this image :)
>
> Nelson.
>
> On 28/08/2008, at 12:56 AM, Frank Kaiser wrote:
>
> > Hello
> >
> > Since our AT91RM9200 platform has a NOR-Flash, it would be
> > convenient to use the XIP (eXecution In Place) option of the build
> > system (to get the image started w/o U-Boot's tftpboot). The first
> > thing which surprised me is that it is not sufficient to declare the
> > NOR flash in the machines class with the attribute memory['rom'].
> > This is just ignored as long as one does not specify XIP=1 on the
> > command line. There seems to be no way to specify the XIP option in
> > the machines class: I found nothing in tools/build.py or anywhere
> > that evaluates an XIP-related attribute set by the current machine.
> > However, with the command line option I did not get what I expected.
> > My machine has this memory configuration:
> > memory['virtual'] = [Region(0x90000000L, 0xE0000000L)]
> > memory['physical'] = [Region(0x20000000L, 0x21000000L)]
> > memory['rom'] = [Region(0x10020000L, 0x11000000L)]
> > Readelf lists the following section information of image.boot:
> > Section Headers:
> > [Nr] Name Type Addr Off Size ES
> > Flg Lk Inf Al
> > [ 0] NULL 00000000 000000 000000
> > 00 0 0 0
> > [ 1] kernel.text PROGBITS 10020000 008000 011484 00
> > AX 0 0 16
> > [ 2] kernel.rodata PROGBITS 10031484 019484 00693c 00
> > A 0 0 4
> > [ 3] kernel.kdebug PROGBITS 10037dc0 01fdc0 004690 00
> > AX 0 0 4
> > [ 4] kernel.init PROGBITS 1003c450 024450 001f40 00
> > AX 0 0 4
> > [ 5] kernel.roinit PROGBITS 1003e390 026390 000300 00
> > A 0 0 4
> > [ 6] kernel.data PROGBITS 20000000 028000 001600 00
> > WA 0 0 1024
> > [ 7] kernel.got PROGBITS 20001600 029600 000004 00
> > WA 0 0 4
> > [ 8] kernel.got.plt PROGBITS 20001604 029604 00000c 04
> > WA 0 0 4
> > [ 9] kernel.kdebug-dat PROGBITS 20001610 029610 00041c 00
> > WA 0 0 4
> > [10] kernel.bss NOBITS 20001a2c 029a2c 0036e0 00
> > WA 0 0 8
> > [11] kernel.kspace PROGBITS 20008000 030000 004000 00
> > WA 0 0 16384
> > [12] kernel.traps PROGBITS 2000c000 034000 001000 00
> > WA 0 0 4096
> > [13] kernel.utcb_page PROGBITS 2000d000 035000 001000 00
> > WA 0 0 4096
> > [14] ig_server.text PROGBITS 20068000 038000 00c73c 00
> > AX 0 0 4
> > [15] ig_server.rodata PROGBITS 2007473c 04473c 001873 00
> > A 0 0 4
> > [16] ig_server.data PROGBITS 20007000 047000 000224 00
> > WA 0 0 4
> > [17] ig_server.got PROGBITS 20007224 047224 000010 04
> > WA 0 0 4
> > [18] ig_server.bss NOBITS 20007238 047238 00012c 00
> > WA 0 0 8
> > [19] event.text PROGBITS 20078000 048000 004b7c 00
> > AX 0 0 4
> > [20] event.rodata PROGBITS 2007cb7c 04cb7c 0006f3 00
> > A 0 0 4
> > [21] event.data PROGBITS 20077270 04f270 000108 00
> > WA 0 0 4
> > [22] event.got PROGBITS 20077378 04f378 000010 04
> > WA 0 0 4
> > [23] event.bss NOBITS 20077388 04f388 000120 00
> > WA 0 0 4
> > [24] vostimer.text PROGBITS 200a4000 054000 004f00 00
> > AX 0 0 4
> > [25] vostimer.rodata PROGBITS 200a8f00 058f00 00069f 00
> > A 0 0 4
> > [26] vostimer.data PROGBITS 200a15a0 0595a0 000138 00
> > WA 0 0 4
> > [27] vostimer.got PROGBITS 200a16d8 0596d8 000010 04
> > WA 0 0 4
> > [28] vostimer.bss NOBITS 200a16e8 0596e8 0003d0 00
> > WA 0 0 4
> > [29] bootinfo PROGBITS 200aa000 05a000 002000 00
> > WA 0 0 0
> > [30] .shstrtab STRTAB 00000000 05c000 00019e
> > 00 0 0 1
> > [31] .strtab STRTAB 00000000 05c19e 00dcd1
> > 00 0 0 1
> > [32] .symtab SYMTAB 00000000 069e6f 00cb10
> > 10 31 0 0
> > One can clearly see that only the kernel code and rom data are
> > allocated in the flash memory. IGUANA's code and rom data reside in
> > RAM, and also the bootinfo section. I doubt that the above memory
> > configuration is runnable, since after power-on the IGUANA stuff
> > just won't be there.
> > I checked the gta01_xip build for comparison, and it showed the same
> > memory configuration. Did I miss a command line option to get IGUANA
> > into XIP configuration as well?
> > Another problem is the allocation of the kernel.data section. Its
> > position at the start of the RAM results in a clash with the ARM
> > globals which are hard-wired to the start address of the RAM. I
> > mentioned this a while ago
(http://n2.nabble.com/Re%3A-OKL4-v2.1%3A-ARM-
> startup-code-overwrites-itself-tp219821p219821.html
> > ), and it was said that space will be reserved for the ARM globals.
> > The above list does not give an indication that this is the case.
> >
>
> --
> (nt)
>
> Nelson Tam
More information about the Developer
mailing list