20:32 <dinkelhacker> Hello, I'm trying to load an elf file to a nucleo-h755zi. The elf contains sections in flash and sections in ram. For flash everything seems to be right, however, the ram contents seem to be wrong.

20:33 <dinkelhacker> I'm loading the elf through gdb `load elffile`.

20:34 <dinkelhacker> I tried loading the same file with a gdb server provided by the `st-util` program.

20:35 <dinkelhacker> This one loads the RAM content corretly. Any idea what issue I could be facing?

20:40 <antto> i think openocd might be adding a small "helper firmware" to RAM just to make flashing faster, i wonder if this could be it

20:41 <PaulFertser> dinkelhacker: hm, why does your elf has both flash and ram sections though?

20:41 <PaulFertser> dinkelhacker: are you using "compare-sections" to verify?

20:43 <dinkelhacker> Hm? Code is in Flash, data is in ram? I mean once I am booting from flash I'd need to copy stuff from flash to RAM during startup but as long as I am loading the elf directly this should be fine?

20:44 <PaulFertser> dinkelhacker: if you're doing the regular thing then your ELF should have sections for everything and in the "program header" it should have some sections that have same load address and physical address (execute in place code) and some with different (the RAM contents). The latter is supposed to be copied by startup code, and GDB isn't trying to replicate that process.

20:46 <PaulFertser> Or is it not a regular firmware and you have some OS on the target and that ELF is supposed to be loaded by its loader dynamically or somethitg?

20:47 <PaulFertser> You can see what sections with what addresses you have with "readelf", and only PT_LOAD sections are used when flashing.

20:47 <dinkelhacker> No, not an os. Why should gdb not load the section to RAM? Does it not just load the elf file as is?

20:47 <dinkelhacker> yeah the ram section is PT_LOAD aswell

20:47 <PaulFertser> PT_LOAD sections got copied to target addresses specified. If it's meant to be in flash it's copied to flash.

20:48 <PaulFertser> Then it's expected your startup code will copy it to RAM early.

20:48 <dinkelhacker> So I have PT_LOAD sections that target flash and ram. Why isn't it just copying also the RAM sections to RAM?

20:48 <PaulFertser> Show your header please

20:49 <PaulFertser> The one that lists all PT_LOAD sections.

20:50 <dinkelhacker> one sec

20:51 <dinkelhacker> https://pastebin.com/t1DAigkR

20:51 <dinkelhacker> first 4 are flash addresses, 5th is ram

20:53 <PaulFertser> dinkelhacker: hm, that's unusual. Is it a custom LD script? How do you expect this firmware to run when it's not loaded by GDB?

20:54 <dinkelhacker> yea the ld script is custom. I'm going to do the proper startup code later but right now I wanted to just load it with the debugger.

20:54 <dinkelhacker> gdb also claims that it loads the faulty sections

20:54 <dinkelhacker> Loading section .data._ZN6kernel4arch3arm7armv7em3cpu3irq4NVIC17hb88c5d5ef1033b55E, size 0x8 lma 0x200000f0

20:55 <PaulFertser> dinkelhacker: indeed antto is right, if you want that area to not be kept you might need "$_CHIPNAME.cpu0 configure -work-area-backup 1"

20:55 <PaulFertser> s/not be kept/be kept/

20:56 <antto> my nose strikes again ;P~

20:56 <dinkelhacker> aha so basically it assumes that you don't load anything to RAM, which is why it places the flash driver there?

20:56 <PaulFertser> dinkelhacker: I wonder if GDB loads that section before the others or after?

20:56 <antto> (like that broken clock that's right twice a day)

20:57 <PaulFertser> dinkelhacker: target flash helper part of the driver, yes.

20:57 <dinkelhacker> PaulFertser: It loads it before any flash section

20:57 <PaulFertser> dinkelhacker: ok, that explains it then.

20:57 <PaulFertser> You need -work-area-backup 1 to ask OpenOCD to preserve it.

20:58 <dinkelhacker> antto: impressive nose :P

20:58 <dinkelhacker> PaulFertser: which file do I need to touch? The one of the board, right?

20:59 <PaulFertser> dinkelhacker: I'd say either openocd.cfg of your own or just add -c '$_CHIPNAME.cpu0 configure -work-area-backup 1' to the end of your invocation command line

21:03 <dinkelhacker> Tadaaa, it works!

21:03 <dinkelhacker> Out of curiosity, where does it put the flash helper instead?

21:09 <dinkelhacker> Anyhow, thanks a lot to both of you! Is there a virtual tip char I can use to buy you a coffee?

21:11 <PaulFertser> dinkelhacker: same place it just restores original contents afterwards

21:14 <PaulFertser> Sorry about having to ask you about all those details before telling the solution; your usecase is certainly unusual and xy problem is seen way too often to just answer questions directly right away.

21:15 <PaulFertser> I just use paypal in case you feel like it, fercerpav@gmail.com

21:16 <PaulFertser> But really glad to help either way, it's a joy to see people doing all kinds of interesting things using Free Software.

21:20 <dinkelhacker> Not a problem at all. Again, thanks a lot for your efforts and the fast response. I didn't expect to solve this before going to bed :D

21:22 <dinkelhacker> I'm suprised its not a common usecase. At work I do this all the time in situations where the whole image will be loaded into RAM by a bootloader. Just saves me time flashing and resetting the device all the time.

21:26 <PaulFertser> Usually bootloaders just remap interrupt table address and pass control to the payload running directly from flash. But your usecase makes sense too of course. Especially if firmware is really big and takes long time to flash.

21:30 <PaulFertser> And there's plenty of unused RAM.

21:34 <PaulFertser> Got the tip, happy to help indeed.