Closed U2654 closed 3 years ago
It is actually strange, because it continues the first section with zero length, and both sections write to the read-only MaskROM. Does this happen with other files as well?
Edit: Especially interesting would be the linker-script.
FIY:
It quite interesting that this effects relates to --gc-sections as I mentioned. This is without:
Program Header:
LOAD off 0x00001000 vaddr 0x20400000 paddr 0x20400000 align 2**12
filesz 0x00000104 memsz 0x00000104 flags r-x
LOAD off 0x00002000 vaddr 0x80000000 paddr 0x20400104 align 2**12
filesz 0x00000000 memsz 0x00000000 flags rw-
NULL off 0x00000000 vaddr 0x80000000 paddr 0x80000000 align 2**0
filesz 0x00000000 memsz 0x00000800 flags rw-
I'll provide the example.
Here is an example.
https://github.com/U2654/embedded/tree/master/workspace/demo_led
There has to be a problem with your linkerscripts.
When building the examples from sifive-hifive1, only sections 0x20400000
and 0x80000000
are present.
Actually, the linker script is from the freedom-bsp except the entry. However, I'll check yours out.
I misinterpreted your output - offs
is not equal to the paddr
.
The Linker produces an empty section (N°2). This is unhandled in the loader, as a zero-length section does not make sense.
OK. I checked the linker script. The only difference is the ENTRY-point. Thus, I wonder if you could reproduce the result?
Actually, the workaround is obvious. Shall I do a pull request?
Using the hifive1 toolchain, I can produce an ELF file (ld script ok and with --gc-sections) with the following header:
I cannot check if this would be a problem with a real hifive1 board (I have only a rev b). However, the ELF loader of the vp throws an error in elf_loader.h:51 (assert fails) as the second LOAD section is a strange entry. I could easily fix this but do not know if the problem would appear on real hardware. Any suggestion?