Add binary info to link to additional images #591

New issue

Open

opened 2021-10-06 14:26:23 -05:00 by rhulme · 6 comments

rhulme commented

2021-10-06 14:26:23 -05:00

(Migrated from github.com)

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.

I've implemented a [flashloader](https://github.com/rhulme/pico-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 commented

2021-10-06 16:12:50 -05:00

(Migrated from github.com)

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 commented

2021-10-07 01:31:43 -05:00

(Migrated from github.com)

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.

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 commented

2021-10-07 07:26:04 -05:00

(Migrated from github.com)

GRUB for RP2040? 😉

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

GRUB for RP2040? :wink: EDIT: I've just read through your flashloader README, and it sounds pretty neat :+1: :slightly_smiling_face:

rhulme commented

2021-10-07 15:10:22 -05:00

(Migrated from github.com)

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.

> GRUB for RP2040? :wink: 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 :+1: :slightly_smiling_face: 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 commented

2021-10-20 18:46:03 -05:00

(Migrated from github.com)

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...

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 commented

2023-05-03 14:40:51 -05:00

(Migrated from github.com)