Non-XIP Boot to SDRAM with GCC (elftosb and GCC linker script)

[tsantzi]

Hello,

I have adapted the instructions in AN12107 & AN12108 to boot my RT1050-EVK from hyperflash to SDRAM (non-XIP) using GCC/CMake rather than IAR. Everything works fine except one thing: elftosb seems to ignore my .data section, so my globals don't get initialised.

Here's what I've done:

Using hello_world as a base, I've added a global variable foo, which I initialise to a value upon declaration, and then printf it in main.

I've modified MIMXRT1052xxxxx_flexspi_nor.ld as follows:

  m_interrupts          (RX)  : ORIGIN = 0x80002000, LENGTH = 0x00000400
  m_text                (RX)  : ORIGIN = 0x80002400, LENGTH = 0x00020000
  m_data                (RW)  : ORIGIN = 0x81000000, LENGTH = 0x00020000

Building and running readelf -S shows the .data section, as expected:

  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .interrupts       PROGBITS        80002000 002000 000400 00   A  0   0  4
  [ 2] .text             PROGBITS        80002400 002400 002e30 00  AX  0   0  4
  [ 3] .ARM              ARM_EXIDX       80005230 005230 000008 00  AL  2   0  4
  [ 4] .init_array       INIT_ARRAY      80005238 005238 000004 04  WA  0   0  4
  [ 5] .fini_array       FINI_ARRAY      8000523c 00523c 000004 04  WA  0   0  4
  [ 6] .data             PROGBITS        81000000 010000 000074 00  WA  0   0  4
  [ 7] .ncache.init      PROGBITS        81000074 010074 000000 00   W  0   0  1
  [ 8] .ncache           PROGBITS        81000074 010074 000000 00   W  0   0  1
  [ 9] .bss              NOBITS          81000074 010074 000054 00  WA  0   0  4
  [10] .heap             NOBITS          810000c8 010074 000400 00  WA  0   0  1
  [11] .stack            NOBITS          810004c8 010074 000400 00  WA  0   0  1

Indeed, checking the .elf at offset 010000, I can see the initial value of foo.

The command I use to generate the sb is:

elftosb.exe -d -f imx -V -c ../../bd_file/imx10xx/imx-sdram-unsigned-dcd.bd -o imx.bin F:\hello_world.elf

And its output:

positional args:
0: F:\hello_world.elf
source elfFile => extern(0=F:\hello_world.elf)
        Section: 0x0
filtering sections of file: F:\hello_world.elf
creating segment for section .interrupts
creating segment for section .text
creating segment for section .init_array
creating segment for section .fini_array
Entry point is Reset_Handler@0x800024e1 (ARM)
iMX bootable image generated successfully

As can be seen, the .data section doesn't get picked up. At this point (before even generating boot_image.sb), I can confirm that imx.bin lacks the initial values in .data. The const values in .text are retained.

When running the code, I can confirm that main is executing from 0x80002400+, my foo variable is at 0x81000000, and any const variable values (which work fine) are after the code. The startup code's copy-loop fills up foo with whatever is after .fini_array (at __etext), which is, of course, rubbish.

Any clues why this happens?

Thanks in advance,

Nikos

[igorpadykov]

Hi Nikolaos

one can check elftosb documentation on

https://www.nxp.com/docs/en/user-guide/KBLELFTOSBUG.pdf 

also from listing " .data PROGBITS 81000000 010000" offset seems as strange.

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[tsantzi]

Hi Igor,

Thanks for the prompt reply.

I have used the info in the elftosb user manual to modify the .bd file to load the .data section explicitly (by name), but it still doesn't get picked up.

Also, can you please elaborate on why the 10000 offset looks strange? After a bit of experimenting I realised that the gcc linker "aligns" the file offsets with the memory areas - this can be seen with .interrupts, .text, .init_array and .fini_array as well. Do you think this is something that could cause elftosb to skip the .data section?

Trying to confirm that gcc and elftosb play well together, I tried following the steps in section 3.4 of AN12107 (but building with gcc instead of IAR), using unmodified SDK files throughout:

First, I built hello_world using gcc:

cd boards/evkmimxrt1050/demo_apps/hello_world/armgcc
export ARMGCC_DIR="[...]/gcc-arm-none-eabi-6-2017-q2-update/"
./build_flexspi_nor_debug.sh

Then I run readelf -S:

There are 24 section headers, starting at offset 0x30a44:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .interrupts       PROGBITS        60002000 002000 000400 00   A  0   0  4
  [ 2] .text             PROGBITS        60002400 002400 002e68 00  AX  0   0  4
  [ 3] .ARM              ARM_EXIDX       60005268 005268 000008 00  AL  2   0  4
  [ 4] .init_array       INIT_ARRAY      60005270 005270 000004 04  WA  0   0  4
  [ 5] .fini_array       FINI_ARRAY      60005274 005274 000004 04  WA  0   0  4
  [ 6] .data             PROGBITS        20000000 010000 000068 00  WA  0   0  4
  [ 7] .ncache.init      PROGBITS        20000068 010068 000000 00   W  0   0  1
  [ 8] .ncache           PROGBITS        20000068 010068 000000 00   W  0   0  1
  [ 9] .bss              NOBITS          20000068 010068 000054 00  WA  0   0  4
  [10] .heap             NOBITS          200000bc 010068 000404 00  WA  0   0  1
  [11] .stack            NOBITS          200004c0 010068 000400 00  WA  0   0  1
  [12] .ARM.attributes   ARM_ATTRIBUTES  00000000 010068 00002e 00      0   0  1
  [13] .debug_info       PROGBITS        00000000 010096 00d901 00      0   0  1
  [14] .debug_abbrev     PROGBITS        00000000 01d997 001e8d 00      0   0  1
  [15] .debug_aranges    PROGBITS        00000000 01f828 000570 00      0   0  8
  [16] .debug_ranges     PROGBITS        00000000 01fd98 000490 00      0   0  1
  [17] .debug_line       PROGBITS        00000000 020228 005ba9 00      0   0  1
  [18] .debug_str        PROGBITS        00000000 025dd1 004fba 01  MS  0   0  1
  [19] .comment          PROGBITS        00000000 02ad8b 00007f 01  MS  0   0  1
  [20] .debug_frame      PROGBITS        00000000 02ae0c 001490 00      0   0  4
  [21] .symtab           SYMTAB          00000000 02c29c 002760 10     22 324  4
  [22] .strtab           STRTAB          00000000 02e9fc 001f5b 00      0   0  1
  [23] .shstrtab         STRTAB          00000000 030957 0000eb 00      0   0  1

(so .data still gets offset to 010000 in the elf file)

Then I run elftosb, using:

./elftosb -d -V -f imx -V -c ../../../bd_file/imx10xx/imx-flexspinor-normal-unsigned.bd -o ivt_flexspi_nor_hello_world.bin hello_world.elf

The .data section still doesn't get picked up:

positional args:
0: F:\hello_world_pristine.elf
source elfFile => extern(0=F:\hello_world_pristine.elf)
        Section: 0x0
filtering sections of file: F:\hello_world_pristine.elf
creating segment for section .interrupts
creating segment for section .text
creating segment for section .init_array
creating segment for section .fini_array
Entry point is Reset_Handler@0x600024e1 (ARM)
iMX bootable image generated successfully

Can you please confirm that elftosb will work with gcc linked elf files, and advise on how to configure elftosb and/or the gcc linker in the example above so that the .data section gets included in the .sb file?

Thanks,

Nikos

[tsantzi]

It turns out that when I generate a .srec from my .elf and use that instead, it works.

[rshipman]

Similarly I also found that elftosb:

  - Ignores the .data section in a .elf file.

  - Includes the .data section using a .srec file.

NXP can we fix elftosb please!

From the document (KBLELFTOSBUG, Kinetis Elftosb User's Guide, Rev. 1, 04/2016):

"ELF file — Using an entire ELF file as a data source causes all sections within the file to be loaded. Not all sections are
loaded; only those sections whose type is SHT_PROGBITS or SHT_NOBITS are considered. All sections from ELF files
have natural locations and sizes."

So .data should be included, see the output below:

> arm-none-eabi-readelf.exe -S sram_app__unencrypted_unsigned.axf

There are 30 section headers, starting at offset 0x1673d4:

Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .text PROGBITS 20002000 002000 0083a0 00 AX 0 0 4
[ 2] .data PROGBITS 2000a3a0 00a3a0 00015c 00 WA 0 0 4
[ 3] .data_RAM2 PROGBITS 00000000 00a4fc 000000 00 W 0 0 4
[ 4] .data_RAM3 PROGBITS 20200000 00a4fc 000000 00 W 0 0 4
[ 5] .data_RAM4 PROGBITS 80000000 00a4fc 000000 00 W 0 0 4
[ 6] .data_RAM5 PROGBITS 81e00000 00a4fc 000000 00 W 0 0 4
[ 7] .bss NOBITS 2000a4fc 00a4fc 000330 00 WA 0 0 4
[ 8] .uninit_RESERVED PROGBITS 2000a3a0 00a4fc 000000 00 W 0 0 4
[ 9] .noinit_RAM2 PROGBITS 00000000 00a4fc 000000 00 W 0 0 4
[10] .noinit_RAM3 PROGBITS 20200000 00a4fc 000000 00 W 0 0 4
[11] .noinit_RAM4 PROGBITS 80000000 00a4fc 000000 00 W 0 0 4
[12] .noinit_RAM5 PROGBITS 81e00000 00a4fc 000000 00 W 0 0 4
[13] .noinit PROGBITS 2000a82c 00a4fc 000000 00 W 0 0 4
[14] .heap NOBITS 2000a82c 00a4fc 000e00 00 WA 0 0 4
[15] .heap2stackfill NOBITS 2000b62c 00a4fc 000e00 00 WA 0 0 1
[16] .stack PROGBITS 2000f200 00a4fc 000000 00 W 0 0 4
[17] .debug_info PROGBITS 00000000 00a4fc 012633 00 0 0 1
[18] .debug_abbrev PROGBITS 00000000 01cb2f 002399 00 0 0 1
[19] .debug_aranges PROGBITS 00000000 01eec8 000ce0 00 0 0 1
[20] .debug_ranges PROGBITS 00000000 01fba8 000c18 00 0 0 1
[21] .debug_macro PROGBITS 00000000 0207c0 0029e1 00 0 0 1
[22] .debug_line PROGBITS 00000000 0231a1 00a4f4 00 0 0 1
[23] .debug_str PROGBITS 00000000 02d695 13032d 01 MS 0 0 1
[24] .comment PROGBITS 00000000 15d9c2 000076 01 MS 0 0 1
[25] .ARM.attributes ARM_ATTRIBUTES 00000000 15da38 000035 00 0 0 1
[26] .debug_frame PROGBITS 00000000 15da70 002d18 00 0 0 4
[27] .symtab SYMTAB 00000000 160788 004100 10 28 606 4
[28] .strtab STRTAB 00000000 164888 002a08 00 0 0 1
[29] .shstrtab STRTAB 00000000 167290 000143 00 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
L (link order), O (extra OS processing required), G (group), T (TLS),
C (compressed), x (unknown), o (OS specific), E (exclude),
y (purecode), p (processor specific)

I have tried two versions of the elftosb - neither include the .data section:

• From the Flashloader_RT1020_1.0_GA release package: elftosb 4.0.0
• From NXP-MCUBootUtility-2.2.0: elftosb 5.1.7

The call:

elftosb.exe -f imx -V -d -c imx-itcm-unsigned.bd -o bootable_app_image_03.bin sram_app__unencrypted_unsigned.axf

The .bd file is very basic:

options {
    flags = 0x00;
    startAddress = 0x20000000;
    ivtOffset = 0x1000;
    initialLoadSize = 0x2000;
}

sources {
     elfFile = extern(0);
}

section (0)
{
}