Not flashing: multiple DROM segments
Closed this issue · 3 comments
Something is not being understood by the board - i wonder if its related to this: https://gitlab.com/lightning-signer/validating-lightning-signer/-/blob/main/lightning-signer-core/src/sync.rs#L1
The core2 lib is used as a replacement for core::std::alloc in the no_std version of VLS (as well as rust-bitcoin etc). https://gitlab.com/lightning-signer/validating-lightning-signer/-/blob/main/lightning-signer-core/Cargo.toml#L18
Do we need to create a partial-std fork of each of these? Ignoring std features such as rand, bitcoinconsensus dependecy, and bitcoin_hashes/alloc. But including core::alloc and std::io::{Read, Write, sink}
It seems to me like our binary file indeed has multiple DROM segments as shown below. It is strange because if you look through the references below, you'll see that the DROM segment "carries specific fields describing the application."
######## pwd
/Users/beraf/summer_2022/sphinx-key/sphinx-key/target/riscv32imc-esp-espidf/debug
######## esptool.py --chip esp32c3 image_info sphinx-key.bin
esptool.py v4.1
Image version: 1
Entry point: 40380ba4
8 segments
Segment 1: len 0x7a25c load 0x3c210020 file_offs 0x00000018 [DROM]
Segment 2: len 0x02ec8 load 0x3fc8ee00 file_offs 0x0007a27c [DRAM,BYTE_ACCESSIBLE]
Segment 3: len 0x0d124 load 0x40380000 file_offs 0x0007d14c [IRAM]
Segment 4: len 0x00788 load 0x3c28a280 file_offs 0x0008a278 [DROM]
Segment 5: len 0x01bf8 load 0x4038d124 file_offs 0x0008aa08 [IRAM]
Segment 6: len 0x00010 load 0x50000010 file_offs 0x0008c608 [RTC_IRAM,RTC_DRAM]
Segment 7: len 0x039f0 load 0x00000000 file_offs 0x0008c620 [PADDING]
Segment 8: len 0x206828 load 0x42000020 file_offs 0x00090018 [IROM]
Checksum: 0c (valid)
Validation Hash: 19fba12396e3d059b4ed498885e70080a18db38f06eda7ea888e6ee48f508cd4 (valid)
References:
https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/system/app_image_format.html
https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/memory-types.html
######## hexdump sphinx-key.bin | head
0000000 e9 08 00 00 a4 0b 38 40 ee 00 00 00 05 00 00 00
0000010 00 00 00 00 00 00 00 01 20 00 21 3c 5c a2 07 00
0000020 32 54 cd ab 00 00 00 00 00 00 00 00 00 00 00 00
0000030 31 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000050 6c 69 62 65 73 70 69 64 66 00 00 00 00 00 00 00
0000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000070 31 35 3a 35 32 3a 31 36 00 00 00 00 00 00 00 00
0000080 4a 75 6e 20 31 33 20 32 30 32 32 00 00 00 00 00
0000090 63 35 64 65 62 37 61 00 00 00 00 00 00 00 00 00
########
If you look here:
You'll see #define ESP_APP_DESC_MAGIC_WORD 0xABCD5432
This shows up as 0x3254cdab above at offset 0x20.
Pretty sure this is "the magic word for the esp_app_desc structure" they mention here:
Nonetheless this pattern never shows up again throughout the hexdump. I would have expected it to show up again at 0x008a280 according to the file offsets shown above but nothing of the sort shows up there.
using esp idf 4.3.2 fixed this