firmware flash: check the partition layout from the image itself, and say what differs - #35
Merged
Merged
Conversation
… and say what differs The layout check took the table it expects from the build directory's partition_table/partition-table.bin, so it silently skipped itself whenever that directory was not there -- which is every flash of a saved .bin with --artifact, not just the ROM-download-port case the issue reported. That is also the flash people reach for when something has already gone wrong. A whole-flash image carries its own table at 0x8000, so take it from there when the build directory is gone. Reading the device's table needed one more thing: esptool was only ever asked with --before default-reset, which is right for a board sitting at a REPL and wrong for one already in ROM download mode, where toggling DTR/RTS can knock it back out. Try no-reset as well. When the tables differ, decode both and name the partition, the field and the two values instead of saying only that they differ. "Enable Erase if the board misbehaves" was the wrong advice for the failure this exists to prevent: the T-Embed's files were intact 64 KB further on, and an erase would have destroyed them. Say what moved, and why flashing anyway leaves a filesystem where the new table does not expect it -- the board then sits in inisetup.fs_corrupted() before USB starts, with no panic and nothing on the bus. Add mpftp firmware ptable <image>, which prints an image's table and diffs it against another image or against an attached board. That is the command that would have found the T-Embed's fault in seconds. Proven on a Waveshare ESP32-S3-Touch-LCD-4.3, with a copy of its own firmware whose vfs entry was moved to 0x390000. Refused on the REPL port and again through the ROM download port after machine.bootloader() (COM73 at 303A:4003 re-enumerated as COM13 at 303A:1001), both times reporting "vfs: offset 0x3a0000 on the device, 0x390000 in the image". The unmodified image flashed through both ports in the same session, reporting "partition layout matches", so the check is not simply refusing everything.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #32.
The hole was wider than reported
The issue says the layout check is skipped when flashing through the ROM
download port. It is also skipped on a perfectly healthy REPL port, for a
commoner reason: the expected table was only ever read from
<artifact dir>/partition_table/partition-table.bin, and that directory doesnot exist beside a saved
.bin. So every--artifactflash skipped thecheck. Measured against the real code before any change:
That is the flash people reach for when something has already gone wrong.
What changed
Take the expected table from the image. A whole-flash image written at 0x0
carries its table at 0x8000 (magic
AA 50), so the check works from the.binalone. The build directory's copy is still preferred when present.
Read the device's table in ROM download mode too. esptool was only asked
with
--before default-reset, which is right for a board at a REPL and wrongfor one already in download mode, where toggling DTR/RTS can knock it back out.
It now tries
no-resetas well.Say what differs. Both tables are decoded and compared partition by
partition.
"enable Erase if the board misbehaves"was the wrong advice for thefailure this exists to prevent — the T-Embed's files were intact 64 KB further
on and an erase would have destroyed them.
New
mpftp firmware ptable <image>— prints an image's table, and diffs itagainst
--compare <other image>or--device <COM>.Proof on hardware
A Waveshare ESP32-S3-Touch-LCD-4.3, and a copy of its own firmware with the
vfsentry moved to 0x390000 — the T-Embed's exact fault.ptable --comparefinds it without touching a board:Refused on the REPL port (COM49) — the case that used to skip:
Refused again through the ROM download port, which is what the issue asked
for.
machine.bootloader()took COM73 (303A:4003) to COM13 (303A:1001),and the flash there was refused with the same sentence.
And the control, because a checker that refuses everything proves nothing — the
unmodified image flashed through both ports in the same session:
The board came back out of ROM mode on its own (COM73 back at
303A:4003, REPLalive,
/libintact) — no button, no replug.Tests
13 new tests in
cli/tests/test_partition_table.py, each planting the fault itis meant to catch, plus an identical-tables control so the differ cannot pass
by always complaining. Full suite: 329 tests, OK.
Image under test:
firmware-s3-bounce.bin, sha25614e683fff2b2c50b37a4e425c55c3023dc56c9f24d920618238679e903f472cb.