soc: arm: rpi_pico: Add support for binary info feature

[soburi]

Enable embedding binary info to flash.
As a default, information collects from the build configuration.

It can override by the Kconfig configurations, such as

CONFIG_RP2_BINARY_INFO_PROGRAM_NAME_OVERRIDE=y
CONFIG_RP2_BINARY_INFO_PROGRAM_NAME="my program name"

Signed-off-by: TOKITA Hiroshi [email protected]

---

This PR support basic feature of pico's binary info.
It works with picotool (https://github.com/raspberrypi/picotool) to show configuration information.
(by picotool show -a)
Other feature supporting is not yet.

[mbolivar-nordic]

Thank you for your work!

I am not sure about the CMake variable changes here. I'd like @tejlmand to confirm it is OK.

[yonsch]

Before I comment on the changes themselves - I think this feature would be beneficial for all Zephyr users, not only for the pico. Being able to embed strings in a binary where they're accessable outside of the image is very useful. The main use case I can think of is a bootloader and an app being able to read each other's versions. Since this would require some more work I'm not sure it should block this PR for the meantime, but that is something to keep in mind.
I should also note that pico's binary_info can be used to store pin configurations, but I can't think of a use case for that.

[soburi]

@yonsch

Before I comment on the changes themselves - I think this feature would be beneficial for all Zephyr users, not only for the pico. Being able to embed strings in a binary where they're accessable outside of the image is very useful. The main use case I can think of is a bootloader and an app being able to read each other's versions. Since this would require some more work I'm not sure it should block this PR for the meantime, but that is something to keep in mind. I should also note that pico's binary_info can be used to store pin configurations, but I can't think of a use case for that.

The 'self-reference'-ish feature is interresting suggestion.
But I also think there are some difficult point.
In the Pico's scope, the information mainly read it by BOOTSEL mode.
This is probably the same for other MCUs, and I think this function is strongly related to the "recovery mode" specification.
If there are other MCUs with similar functions, it may be possible to define an abstract interface.
If I can draw a big picture, I think it would wonderful if it could define as uf2 meta information. (Create a .uf2meta section with a linker and have the same information there. It can handle with common specification by recovery program and firmware itself!)

[yonsch]

@soburi I've created a quick demonstration of what I was thinking of: #54464

[MaureenHelm]

dev-review: depends on #54464

[github-actions]

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.

[github-actions]

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.

[cfriedt]

@soburi - I assume that once #54464 is merged, work on this will continue

[soburi]

@cfriedt

I assume that once #54464 is merged, work on this will continue

That's right. Perhaps I will have to rethink the design accordingly.

[yonsch]

@soburi Why does this depend on #54464?
Bindesc was supposed to be a standard Zephyr replacement for binary info.
Binary info would still be useful for someone who needs to specifically use the pico format, e.g. if a bootloader expects binary info descriptors.
I think we can treat them as if they are mutually exclusive, as they serve the same purpose, and proceed with this PR regardless of bindesc.
Unless, you somehow see them coexisting somehow, which would require more planning.

[github-actions]

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.

[github-actions]

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.

[sonarqubecloud]

Quality Gate passed

Issues
2 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[github-actions]

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.

[dsseng]

Could this potentially be handled by a linker script like rom_start?

[github-actions]

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud