Running Hubris at a runtime defined flash offset

Hi,
I have posted an initial question in the discussion section but it seems to be dead (https://github.com/oxidecomputer/hubris/discussions/744).

I would be super happy if you could reply in few words - at least if what I write here makes any sense - am I missing something that already allows such a use case or something that is a showstopper here?

I see a huge value for Hubris in the market I come from (IoT devices for healthcare), but in that case the devices are standalone and firmware update often needs to be possible within the same application without any external probe or dongle.
Playing around with Hubris is already a great escape from everyday's work for me so maybe I might do something valuable with it or at least give an idea to somebody else.

Merge viable solution I imagine is a bootloader for Hubris with support from dedicated task:

• bootloader toml file with partition layout and perhaps additional configs for the keys to check if the firmware is properly signed etc
• bootloader that's flashed at the beginning of the flash that decides which partition to boot from
• task that can:
  • flash a new image into the unactive partition and overwrite the bootloader header to try boot from the other partition
  • receive acknowledgement that the new image booted properly and overwrite the bootloader header to make newly booted image a permanent one

There's a long way to that point, but it would enable using Hubris for standalone IoT devices that requires FOTA capabilities, so I want to at least give it a try with a simple POC

I started to investigate what's necessary to make Hubris running from runtime configurable flash offset.
What I already know is that I need to:

• Enable PIC for kernel and tasks
• Pass an image flash offset from a bootloader to main() and then to start_kernel() and add it to some kernel struct
• Use the flash offset for the reinitialize() and apply_memory_protection() and most likely few other places i have not yet spotted
• Make Humility read the runtime image offset and apply for all addr to symbol translation (this gives me a headache, but might be not that bad)

I feel like for the initial work, reusing stage0 for a dummy bootloader might be a good idea since as far as I can see it is included in a Hubris archive and flashed, so less friction from tooling I guess...
It should also be fairly simple to trick Humility to flash bootloader without an offset and the rest with offset applied by additional parametrization of generate_ihex_from_elf()

PS. I understand that you are extremely busy making your first product happen but unfortunately you published the source code and it looks very interesting and partially undocumented, therefore my questions 😄 all the best for the team and thanks for the podcasts!

Start by reading the runtime-offset points named in the issue: main(), start_kernel(), reinitialize(), apply_memory_protection(), and Humility's generate_ihex_from_elf(). Review stage0 and the discussion in #744 before deciding on a proof-of-concept scope. Done would require an agreed design and a working offset-aware boot path, flashing flow, and symbol translation.