How to load elf directly into SDRAM of STM32H757i-eval board.

[kgardas]

Hello,

I'm curious if there is any way how to load correctly linked elf file into the SDRAM of st32h757i-eval board. By correctly linked elf I mean everything is either linked into SDRAM or to some of the SRAMs. E.g. readelf -S of the elf looks:

There are 35 section headers, starting at offset 0x267c24:
 
Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .start            PROGBITS        d0000000 010000 000458 00  AX  0   0  4
  [ 2] .xbarrier         PROGBITS        d0000458 038698 000000 00   W  0   0  1
  [ 3] .text             PROGBITS        d0000480 010480 010db8 00  AX  0   0 64
  [ 4] .init             PROGBITS        d0011238 021238 00000c 00  AX  0   0  4
  [ 5] .fini             PROGBITS        d0011244 021244 00edbc 00  AX  0   0  4
  [ 6] .robarrier        PROGBITS        d0020000 038698 000000 00   W  0   0  1
  [ 7] .rodata           PROGBITS        d0020000 030000 0040ed 00   A  0   0  8
  [ 8] .ARM.exidx        ARM_EXIDX       d00240f0 0340f0 000008 00  AL  3   0  4
  [ 9] .eh_frame         PROGBITS        d00240f8 0340f8 000004 00   A  0   0  4
  [10] .init_array       INIT_ARRAY      d00240fc 0340fc 000004 04  WA  0   0  4
  [11] .fini_array       FINI_ARRAY      d0024100 034100 000004 04  WA  0   0  4
  [12] .rtemsroset       PROGBITS        d0024104 034104 003efc 00   A  0   0  4
  [13] .rwbarrier        PROGBITS        d0028000 038698 000000 00   W  0   0  1
  [14] .vector           PROGBITS        d0028000 038698 000000 00   W  0   0  1
  [15] .data             PROGBITS        d0028000 038000 000698 00  WA  0   0  8
  [16] .bss              NOBITS          d00286a0 038698 00209c 00  WA  0   0 32
  [17] .rtemsstack       NOBITS          24000000 010000 002008 00  WA  0   0 32
  [18] .work             NOBITS          d002a73c 038698 1fd58c4 00  WA  0   0  1
  [19] .stack            NOBITS          24002008 010000 07dff8 00  WA  0   0  1
  [20] .nocachenoload    NOBITS          30020000 010000 020000 00  WA  0   0  1
  [21] .comment          PROGBITS        00000000 038698 000063 01  MS  0   0  1
  [22] .debug_aranges    PROGBITS        00000000 038700 003810 00      0   0  8
  [23] .debug_info       PROGBITS        00000000 03bf10 13c79e 00      0   0  1
  [24] .debug_abbrev     PROGBITS        00000000 1786ae 02b84f 00      0   0  1
  [25] .debug_line       PROGBITS        00000000 1a3efd 05b6e6 00      0   0  1
  [26] .debug_frame      PROGBITS        00000000 1ff5e4 006e70 00      0   0  4
  [27] .debug_str        PROGBITS        00000000 206454 0167c1 01  MS  0   0  1
  [28] .debug_line_str   PROGBITS        00000000 21cc15 00028f 01  MS  0   0  1
  [29] .debug_loclists   PROGBITS        00000000 21cea4 03350c 00      0   0  1
  [30] .debug_rnglists   PROGBITS        00000000 2503b0 006d79 00      0   0  1
  [31] .ARM.attributes   ARM_ATTRIBUTES  00000000 257129 00002e 00      0   0  1
  [32] .symtab           SYMTAB          00000000 257158 00a910 10     33 2011  4
  [33] .strtab           STRTAB          00000000 261a68 006054 00      0   0  1
  [34] .shstrtab         STRTAB          00000000 267abc 000166 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),
  D (mbind), y (purecode), p (processor specific)

Unfortunately gdb connected to ST-Link gdb server is not able to load even the first section. I'm starting ST-Link gdb server with available external loader with:

./ST-LINK_gdbserver -c config.txt --external-init --extload MT25TL01G_STM32H747I-EVAL.stldr

where config.txt is nearly vanilla config file which I just edited to correctly specify path to cube programmer. I've also enabled maximal debug there so debug.log contains following interesting info:

[0.008] openDevice():  COM frequency = 24000 kHz
[0.008] openDevice():  Target connection mode: Default
[0.510] readFromTarget():  Reading ROM table for AP 0 @0xe00fefd0
[0.511] reset_hw_wtchpt_module():  Hardware watchpoint supported by the target 
[0.513] initContext():  ST-LINK Firmware version : V3J9M3
[0.513] initContext():  Device ID: 0x450
[0.513] initContext():  PC: 0xfffffffe
[0.514] Device_GetStatus():  ST-LINK device status: HALT_MODE
[0.514] initContext():  ST-LINK detects target voltage = 3.29 V
[0.514] initContext():  ST-LINK device status: HALT_MODE
[0.514] initExternalMemory():  Found external memory initializer at 0x240004e1
[0.514] initExternalMemory():  Writing external memory initializer seg at 0x24000004 (36736 byte)
[0.551] initExternalMemory():  lastAddr = 0x24009080
[0.551] initExternalMemory():  Writing external memory initializer seg at 0x24008f84 (200 byte)
[0.551] initExternalMemory():  lastAddr = 0x2400904c
[0.553] initExternalMemory():  PC: 0x240004e1
[0.553] initExternalMemory():  MSP: 0x24009440
[0.553] initExternalMemory():  LR: 0x2400904c
[0.553] initExternalMemory():  Run external memory initializer
[0.554] Device_GetStatus():  ST-LINK device status: RUN_MODE
[0.554] initExternalMemory():  PC: 0x2400904c; ret: 0
[0.554] initExternalMemory():  Restore after external memory initializer
[0.555] initServerContext():  ST-LINK device initialization OK
[0.555] pollAndNotifyRun():  Stm32Device, pollAndNotify running...
[0.555] Device_GetStatus():  ST-LINK device status: HALT_MODE
[0.556] updateState():  SwvSrv state change: 0 -> 1
[0.556] WaitConnection():  Waiting for connection on port 61235...
[0.556] WaitConnection():  Waiting for connection on port 61234...
[13.980] WaitConnection():  Accepted connection on port 61234...
[13.980] WaitConnection():  Waiting for connection on port 61234...
[13.980] run():  GDB session thread running

so it looks like some external memory is really being initialized. The debug output also contained something which looked as XML memory map dump, so I've also used --memory-map on reported 0x450 device and to my surprise it prints this:

$ ./ST-LINK_gdbserver -c config.txt --memory-map 0x450
<?xml version="1.0"?>
<!DOCTYPE memory-map
          PUBLIC "+//IDN gnu.org//DTD GDB Memory Map V1.0//EN"
                 "http://sourceware.org/gdb/gdb-memory-map.dtd">
<memory-map>
    <memory type="ram" start="0x0" length="0x8000000"/>
    <memory type="flash" start="0x8000000" length="0x200000">
        <property name="blocksize">0x400</property>
    </memory>
    <memory type="ram" start="0x8200000" length="0xf7dfffff"/>
</memory-map>

Honestly this looks completely wrong except the flash parameters. Not sure how gdb or ST-Link gdb server is using that. If they are to enforce memory map on loaded elf, then it would be no wonder this completely fails.

Any help or advice how to use gdb server to load directly into board SDRAM is highly appreciated!

Karel

[Tesla DeLorean · Accepted solution]

Typically you'd need a debugger script capable of bringing up the SDRAM, ie clocks, pins, FMC, and SDRAM itself. Then the SDRAM would load/act like Internal SRAM, and the JTAG/SWD could fill directly

Basically a peek/poke equivalent to code on the STM32 side to initialize the SDRAM.

Could perhaps also do via an External Loader model, or you own loader that brings up memory, clocks, etc then accepts a .HEX via the console.

.ELF really wants random-access file system, where as a .BIN or .HEX can be delivered in a linear end-to-end fashion.

[kgardas]

Thanks a lot for fast reply. Indeed my question was in a realm of "is it supported by the tool chain right out of the box or not?". That's for fastly confirming that it's not and some work needs to be done!