Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Explore using MCU boot as the second stage bootloader #2376

Closed
MabezDev opened this issue Oct 21, 2024 · 6 comments
Closed

Explore using MCU boot as the second stage bootloader #2376

MabezDev opened this issue Oct 21, 2024 · 6 comments
Assignees
Milestone

Comments

@MabezDev
Copy link
Member

Related to #1973, we're leaning towards using MCUBOOT, but we need to explore if this is viable before we settle on it. The most important thing we need to know is can we change the ota slot addresses without forcing the user to rebuild the MCU boot project.

@MabezDev MabezDev added this to the 0.22.0 milestone Oct 21, 2024
@jessebraham
Copy link
Member

Don't want to count my chickens before they hatch, so being purposefully a bit cryptic here 😉

Took me a few days to get going on this, unfortunately encountered a number of issues which slowed me down. However, based on some very rudimentary tests I think this should be viable.

I still have some work to do before I'm able to say for sure, but I'm hoping that I can have a better idea by end of day tomorrow. I will update this issue by early-to-mid next week with my findings.

@jessebraham
Copy link
Member

I'm able to build mcuboot and inject arbitrary values in for the required configuration values. These are stored in a contiguous block, and should be easily identifiable by tools e.g. espflash. Therefore, I believe this approach should be viable.

The next steps are:

  • Add the required linker scripts to support mcuboot in esp-hal
  • Update our tooling (i.e. espflash) to support the mcuboot image format

@jessebraham
Copy link
Member

I guess this can probably be closed? The exploration is complete, additional work needs to be done but this involves writing new linker scripts in the HAL (which IMO is outside the scope of this issue) and updating tooling (which isn't in this repository, and has its own tracking issue already).

@MabezDev
Copy link
Member Author

MabezDev commented Nov 7, 2024

I agree, but we still need to track the linker script work - we all know how fun they are :D. Could you open a new issue for that, and perhaps include some details on how to build MCUBOOT etc so whoever works on the linkerscripts can get a head start?

After that we can close this.

@bjoernQ
Copy link
Contributor

bjoernQ commented Nov 7, 2024

BTW here are the changes we had for supporting C3: https://github.com/esp-rs/esp-hal/pull/49/files#diff-f68012054272d7ce1611e965d7c6771a128c2e93fdcb4d8153cbcb9ef691062f

There is also setting up the MMU - I wonder if that was really necessary (I hope not) or not. If it is necessary, I guess ESP32 might add some fun to the task

@jessebraham
Copy link
Member

#2479

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

No branches or pull requests

3 participants