Load ELF data directly using probe_rs

[mkeeter]

(staged on #689)

Now that we are using probe-rs for everything, we don't need to convert to IHEX / SREC. This lets us remove a bunch of dependencies. I also switched ProbeCore::load to return a strong error type, while I was poking at it.

This is a building block for a humility flash library.

Bidding a fond farewell to the best docstring in the codebase, describing elf_chunks:

While it may sound like the impetus for an OSHA investigation at the North Pole...

[mkeeter]

I flashed both the SP and RoT on Grapefruit, and everything looks fine.

[mkeeter]

These were unused dependencies that I happened to notice while pruning.

[Copilot]

Pull request overview

This PR updates the flashing workflow to load ELF data directly via probe-rs instead of converting ELF to IHEX/SREC first, reducing dependencies and simplifying the flash pipeline. It also introduces a dedicated LoadError type for ProbeCore::load.

Changes:

• Switch ProbeCore::load to accept in-memory ELF bytes and program flash via probe-rs’s ELF loader/flash loader APIs.
• Remove IHEX/SREC/tempfile-related conversion code and associated dependencies from the flash and rebootleby commands.
• Prune workspace dependencies (ihex, srec, tempfile, path-slash, etc.) and update lockfile accordingly.

Reviewed changes

Copilot reviewed 5 out of 6 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
humility-probes-core/src/probe_rs.rs	Introduces LoadError and changes ProbeCore::load to program ELF bytes directly via probe-rs.
cmd/flash/src/lib.rs	Updates flash command to pass ELF bytes directly to core.load.
cmd/flash/Cargo.toml	Removes now-unneeded dependencies related to ELF→IHEX/SREC conversion.
cmd/rebootleby/Cargo.toml	Removes dependencies no longer used by the command.
Cargo.toml	Removes workspace-level dependencies that are no longer required.
Cargo.lock	Reflects dependency graph changes after removing IHEX/SREC/tempfile/etc.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[mkeeter]

This is deliberate; the progress bar can only fail if it's given an invalid template string, and we won't do that (or will catch it quickly, because it's a loud failure mode).

[labbott]

This makes me a little nervous but I think we're probably okay because our elf is very simple

$ arm-none-eabi-readelf --segments img/final.elf

Elf file type is REL (Relocatable file)
Entry point 0x10181
There is 1 program header, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000054 0x00010000 0x00010000 0x339e8 0x339e8 R   0x20

 Section to Segment mapping:
  Segment Sections...
   00     .sec1 

$ arm-none-eabi-readelf --segments img/final.elf
 
Elf file type is REL (Relocatable file)
Entry point 0x80002e9
There is 1 program header, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000054 0x08000000 0x08000000 0x88100 0x88100 R   0x20

 Section to Segment mapping:
  Segment Sections...
   00     .sec1 

I guess my biggest concern would be if there's any rounding changes. We may also want to take a closer look at the updated DownloadOptions in new probe-rs https://docs.rs/probe-rs/latest/probe_rs/flashing/struct.DownloadOptions.html to make sure we're getting the behavior we want.

[labbott]

This is going to change ever so slightly when we do the probe-rs upgrade https://docs.rs/probe-rs/latest/probe_rs/flashing/struct.FlashLoader.html#method.load_image I think it should still match up okay and we can just use the default ElfOptions https://docs.rs/probe-rs/latest/probe_rs/flashing/struct.ElfOptions.html

[mkeeter]

@labbott Can you say more about what rounding changes would look like, e.g. are you worried about a different erase / write granularity?

[labbott]

@labbott Can you say more about what rounding changes would look like, e.g. are you worried about a different erase / write granularity?

Currently, we're explicitly breaking up the ELF into 32 byte chunks and using that to generate the ihex. I'm concerned if there could be different behavior for the last unaligned block. e.g we had an image of 512+1 bytes in length, that gets converted to (512/32) + 1 chunks in ihex. Block write size is 512. I would expect that that last byte would get handled the same way for both images and that last block should look the same in all cases but I'd want to be sure.