Skip to content

Add binary info to link to additional images #591

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

Open
rhulme opened this issue Oct 6, 2021 · 6 comments
Open

Add binary info to link to additional images #591

rhulme opened this issue Oct 6, 2021 · 6 comments
Assignees
Milestone

Comments

@rhulme
Copy link
Contributor

rhulme commented Oct 6, 2021

I've implemented a flashloader similar to what was suggested in #545 and noticed that using pico-tool to read what's flashed only returns information about the flashloader.

It would be nice if a binary info field could be used to chain from one image to the next so that pico-tool could also show information about the main application (or additional images if appropriate).

From my limited understanding of how the binary info fields work, this could be done by a third-party but it would be nice to have the functionality directly in pico-tool.

@kilograham
Copy link
Contributor

so a "there's another executable at this fixed address" BI type? - and it'd just look within that for a binary info root as it does with the start of flash?

@rhulme
Copy link
Contributor Author

rhulme commented Oct 7, 2021

Yes, exactly. The flashloader knows that the main application should be at 0x1001000, so it could just include that pointer.
If it were a multi-stage flashloader (to allow the flashloader itself to be updated) either the first stage could include pointers to both the second stage and the main application, or just to the second stage and the second stage points to the main application.

In my case, chaining would be sufficient but I could imagine a scenario where, for example, the flashloader (or similar) could decide at boot time which application image to boot (from a selection of fixed addresses). In that case you'd want to be able to list the addresses of all the application images in the flashloader.

@lurch
Copy link
Contributor

lurch commented Oct 7, 2021

GRUB for RP2040? 😉

EDIT: I've just read through your flashloader README, and it sounds pretty neat 👍 🙂

@rhulme
Copy link
Contributor Author

rhulme commented Oct 7, 2021

GRUB for RP2040? 😉

I've no idea whether that's either feasible or practical but I can certainly imagine a multi-stage bootloader/flashloader (since I've been there and done that).

EDIT: I've just read through your flashloader README, and it sounds pretty neat 👍 🙂

Thank you! I've no doubt it could be improved on but I tried to make it as usable as possible. Either directly or as a basis for going in a different direction.

@kilograham kilograham modified the milestones: 1.2.1 bubble, 1.3.0 Oct 8, 2021
@kilograham kilograham self-assigned this Oct 12, 2021
@kilograham kilograham removed this from the 1.3.0 milestone Oct 20, 2021
@kilograham
Copy link
Contributor

Moving this out of the closing 1.3.0 ... need to think some more about use cases.

I did start and added a link to a physical address with flags. those included whether to show the target program ahead of the source in picotool (or whether to hide the source completely).

this would allow you to link to multiple sub images, but we might want more control...

@lurch
Copy link
Contributor

lurch commented May 3, 2023

I guess this links to raspberrypi/picotool#82

@kilograham kilograham added this to the 1.7.0 milestone May 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants