Closed t-moe closed 8 months ago
How did you add defmt support? The official template marks the defmt
section as INFO
and therefore shouldn't have the PROGBITS
type.
I also find it a bit strange.
I've added it as suggested by defmt:
here is me .cargo/config.toml
:
[target.xtensa-esp8266-none-elf]
runner = "espflash --monitor"
rustflags = [
"-C", "link-arg=-nostartfiles",
"-C", "link-arg=-Wl,-Tlink.x",
"-C", "link-arg=-Wl,-Tdefmt.x",
]
[build]
target = "xtensa-esp8266-none-elf"
[unstable]
build-std = ["core"]
Is this maybe a problem of the (gcc) linker used with the esp8266? (using xtensa-lx106-elf-gcc (GCC) 10.3.0
here)
Hmm actually it appears .defmt
is marked as a PROGBITS
section. The thing is, espflash should be discarding it because its not in a valid address space for the esp8266. Not sure why it isn't.
Yes it is strange that even if I use the official template .defmt
ends up being marked as PROGBITS
section.
As for the discarding: I think for the esp8266 the address space is not checked?
At that would be it. Sorry its been a long long time since I looked at the esp8266 stuff. Would you mind sending a PR to check the address space when merging sections?
Actually, also on the esp32c3 the .defmt
section ends up with type progbits..
https://github.com/esp-rs/no_std-training/tree/main/intro/hello-world, but with defmt added
readelf -S target/riscv32imc-unknown-none-elf/debug/hello_world
There are 36 section headers, starting at offset 0x589c88:
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .text.dummy NOBITS 42000020 000234 000000 00 A 0 0 1
[ 2] .text_init PROGBITS 42000020 001020 0000f0 00 AX 0 0 4
[ 3] .text PROGBITS 42000110 001110 01fc30 00 AX 0 0 4
[ 4] .text_dummy NOBITS 3c000000 021000 020020 00 AX 0 0 1
[ 5] .rodata PROGBITS 3c020020 021020 005e44 00 AM 0 0 16
[ 6] .rodata.wifi PROGBITS 3c025e64 026e64 000000 00 A 0 0 4
[ 7] .trap PROGBITS 40380000 027000 0007a8 00 AX 0 0 256
[ 8] .rwtext PROGBITS 403807a8 0277a8 0007f8 00 AX 0 0 4
[ 9] .rwtext.wifi PROGBITS 40380fa0 027fa0 000000 00 AX 0 0 1
[10] .rwdata_dummy NOBITS 3fc80000 028000 000fa0 00 AX 0 0 1
[11] .data PROGBITS 3fc80fa0 028000 000000 00 AX 0 0 4
[12] .bss NOBITS 3fc80fa0 028fa0 000010 00 WA 0 0 4
[13] .noinit NOBITS 3fc80fb0 028fa0 000000 00 WA 0 0 4
[14] .data.wifi PROGBITS 3fc80fb0 028fa0 000000 00 WA 0 0 1
[15] .stack_end NOBITS 3fc80fb0 028fa0 000000 00 WA 0 0 4
[16] .rtc_fast.text PROGBITS 50000000 028fa0 000000 00 WA 0 0 1
[17] .rtc_fast.data PROGBITS 50000000 028fa0 000000 00 WA 0 0 1
[18] .rtc_fast.bss NOBITS 50000000 028fa0 000000 00 WA 0 0 1
[19] .rtc_fast.noinit NOBITS 50000000 028fa0 000000 00 WA 0 0 1
[20] .defmt PROGBITS 00000000 028fa0 000003 00 0 0 1
[21] .debug_abbrev PROGBITS 00000000 028fa3 006a7d 00 0 0 1
[22] .debug_info PROGBITS 00000000 02fa20 11bb2e 00 0 0 1
[23] .debug_aranges PROGBITS 00000000 14b54e 00bc20 00 0 0 1
[24] .debug_ranges PROGBITS 00000000 15716e 01c8b8 00 0 0 1
[25] .debug_str PROGBITS 00000000 173a26 13d528 01 MS 0 0 1
[26] .debug_pubnames PROGBITS 00000000 2b0f4e 06320e 00 0 0 1
[27] .debug_pubtypes PROGBITS 00000000 31415c 0a1b89 00 0 0 1
[28] .riscv.attributes RISCV_ATTRIBUTE 00000000 3b5ce5 00002b 00 0 0 1
[29] .debug_frame PROGBITS 00000000 3b5d10 02612c 00 0 0 4
[30] .debug_line PROGBITS 00000000 3dbe3c 0937c8 00 0 0 1
[31] .debug_loc PROGBITS 00000000 46f604 002714 00 0 0 1
[32] .comment PROGBITS 00000000 471d18 000013 01 MS 0 0 1
[33] .symtab SYMTAB 00000000 471d2c 101520 10 35 65131 4
[34] .shstrtab STRTAB 00000000 57324c 000190 00 0 0 1
[35] .strtab STRTAB 00000000 5733dc 0168aa 00 0 0 1
The only difference is, that addr=0 and on the esp8266 addr=1. An addr=0 will cause the segment to be discarded (elf.rs)
Regarding the implementation:
for the esp8266 the addr_is_flash
check is already added. but if addr_is_flash
returns false the segment will simply end up in ram....
How do we fix this?
Hmm, I guess understanding why it's assigned an address of 1, when on every other chip the defmt section has an address of 0, is how we solve this. Of the top of my head though, I don't have any idea why this would be the case :(
We've decided to drop support for the ESP8266 (see #576), so closing this issue.
I'm using the esp8266 with defmt. defmt uses a linker script
defmt.x.in
that adds a custom section:As a result the elf file looks like this (
xtensa-lx106-elf-readelf -S mytarget
):(not sure why the info flag is not set on
.defmt
)The current code of espflash, does not discard that
.defmt
section and instead downloads it. As a result the chip won't boot up.Hacky patch, to get it working: