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

soburi · 2023-02-01T03:59:30Z

soc: arm: rpi_pico: Add support RaspberryPi Pico binary info feature

Binary Info embeds program meta information in flash,
which can be viewed with RaspberryPi Pico's picotool.

Metadata is automatically collected from pinctrl.

It can be override by the Kconfig configurations, such as

CONFIG_RPI_PICO_BINARY_INFO_OVERRIDE_PROGRAM_NAME="my program name"

When this feature is enabled, pinctrl groups are restricted to
consisting of pins with a single rpi_pico function.
In other words, SPI's MISO and MOSI can be in the same group,
but I2C's SDA cannot be included in this group.
This is rarely an issue in normal use,
and can be resolved by dividing them into separate groups.

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.

soc/arm/rpi_pico/rp2/binary_info.c

yonsch · 2023-02-02T08:32:25Z

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 · 2023-02-04T14:02:02Z

@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 · 2023-02-05T14:19:48Z

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

MaureenHelm · 2023-03-23T15:18:55Z

dev-review: depends on #54464

github-actions · 2023-05-23T00:29:58Z

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 · 2023-08-02T00:27:11Z

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 · 2023-08-03T15:15:46Z

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

soburi · 2023-08-03T21:40:01Z

@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 · 2023-08-04T10:48:36Z

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

sonarqubecloud · 2025-10-08T21:37:05Z

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

dsseng · 2025-10-09T06:52:25Z

soc/raspberrypi/rpi_pico/common/Kconfig.binary_info

+	  When this feature is enabled, pinctrl groups are restricted to consisting
+	  of pins with a single rpi_pico function.
+	  In other words, SPI's MISO and MOSI can be in the same group, but I2C's
+	  SDA cannot be included in this group. This is rarely an issue in normal use,
+	  and can be resolved by dividing them into separate groups.


Does it now always pack pinctrl data into the binary? Could you please give a binary size comparison, as this seems to increase it for quite a bit

0x00000000100044c8 __binary_info_start = .

(SORT_BY_ALIGNMENT(.binary_info.keep.))
.binary_info.keep.__bi_ptr51
0x00000000100044c8 0x4 zephyr/libzephyr.a(binary_info.c.obj)
.binary_info.keep.__bi_ptr43
0x00000000100044cc 0x4 zephyr/libzephyr.a(binary_info.c.obj)
.binary_info.keep.__bi_ptr38
0x00000000100044d0 0x4 zephyr/libzephyr.a(binary_info.c.obj)
.binary_info.keep.__bi_ptr33
0x00000000100044d4 0x4 zephyr/libzephyr.a(binary_info.c.obj)
.binary_info.keep.__bi_ptr29
0x00000000100044d8 0x4 zephyr/libzephyr.a(binary_info.c.obj)
.binary_info.keep.__bi_ptr25
0x00000000100044dc 0x4 zephyr/libzephyr.a(binary_info.c.obj)
.binary_info.keep.__bi_ptr21
0x00000000100044e0 0x4 zephyr/libzephyr.a(binary_info.c.obj)
.binary_info.keep.__bi_ptr17
0x00000000100044e4 0x4 zephyr/libzephyr.a(binary_info.c.obj)
.binary_info.keep.__bi_ptr13
0x00000000100044e8 0x4 zephyr/libzephyr.a(binary_info.c.obj)
.binary_info.keep.__bi_ptr10
0x00000000100044ec 0x4 zephyr/libzephyr.a(binary_info.c.obj)
.binary_info.keep.__bi_ptr190
0x00000000100044f0 0x4 zephyr/libzephyr.a(binary_info_pins.c.obj)
.binary_info.keep.__bi_ptr156
0x00000000100044f4 0x4 zephyr/libzephyr.a(binary_info_pins.c.obj)
.binary_info.keep.__bi_ptr123
0x00000000100044f8 0x4 zephyr/libzephyr.a(binary_info_pins.c.obj)
.binary_info.keep.__bi_ptr122
0x00000000100044fc 0x4 zephyr/libzephyr.a(binary_info_pins.c.obj)
.binary_info.keep.__bi_ptr88
0x0000000010004500 0x4 zephyr/libzephyr.a(binary_info_pins.c.obj)
.binary_info.keep.__bi_ptr54
0x0000000010004504 0x4 zephyr/libzephyr.a(binary_info_pins.c.obj)
.binary_info.keep.__bi_ptr21
0x0000000010004508 0x4 zephyr/libzephyr.a(binary_info_pins.c.obj)
.binary_info.keep.__bi_ptr20
0x000000001000450c 0x4 zephyr/libzephyr.a(binary_info_pins.c.obj)
(SORT_BY_ALIGNMENT(.binary_info.))
0x0000000010004510 __binary_info_end = .

0x0000000010004510 - 0x00000000100044c8 = 72 (bytes)

Although it's not zero, I don't think it's a large number to concern.
Of course, we can disable it as an option, but we would like to keep it enabled by default to be compatible with the rpi_pico ecosystem.

Great, thanks for clarifying. This is clearly okay :)

The binary info feature references `boot_stage2` and `pico_binary_info`. Add these to include dirs. Signed-off-by: TOKITA Hiroshi <[email protected]>

Use the definition of PICO_NO_BINARY_INFO if it already exists, set it as 1 if not so. Signed-off-by: TOKITA Hiroshi <[email protected]>

Binary Info embeds program meta information in flash, which can be viewed with RaspberryPi Pico's `picotool`. Metadata is automatically collected from pinctrl. It can be override by the Kconfig configurations, such as ``` CONFIG_RPI_PICO_BINARY_INFO_OVERRIDE_PROGRAM_NAME="my program name" ``` When this feature is enabled, pinctrl groups are restricted to consisting of pins with a single rpi_pico function. In other words, SPI's MISO and MOSI can be in the same group, but I2C's SDA cannot be included in this group. This is rarely an issue in normal use, and can be resolved by dividing them into separate groups. Signed-off-by: TOKITA Hiroshi <[email protected]>

Fix indentation to pass CI check. Signed-off-by: TOKITA Hiroshi <[email protected]>

sonarqubecloud · 2025-11-15T10:23:57Z

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

soburi requested review from nashif and yonsch as code owners February 1, 2023 03:59

zephyrbot added the manifest-hal_rpi_pico label Feb 1, 2023

zephyrbot assigned yonsch Feb 1, 2023

soburi force-pushed the pico_binary_info branch 3 times, most recently from 463304d to 93e30d2 Compare February 1, 2023 04:55

soburi changed the title ~~soc: arm: rpi_pico: Add basic support for binary info feature~~ soc: arm: rpi_pico: Add basic support for binary info feature Feb 1, 2023

soburi force-pushed the pico_binary_info branch 2 times, most recently from cdbad46 to 71495bb Compare February 1, 2023 09:26

soburi mentioned this pull request Feb 1, 2023

TaskList for Supporting RaspberryPi Pico peripherals #53810

Open

57 tasks

soburi added the platform: Raspberry Pi Pico Raspberry Pi Pico (RPi Pico) label Feb 1, 2023

soburi force-pushed the pico_binary_info branch from 71495bb to 25a1cc4 Compare February 1, 2023 14:39

mbolivar-nordic reviewed Feb 1, 2023

View reviewed changes

soc/arm/rpi_pico/rp2/binary_info.c Outdated Show resolved Hide resolved

soburi force-pushed the pico_binary_info branch 2 times, most recently from d0736a3 to 480ff02 Compare February 2, 2023 09:31

soburi requested a review from mbolivar-nordic February 4, 2023 14:02

github-actions bot added the Stale label May 23, 2023

mbolivar-nordic removed the Stale label Jun 2, 2023

github-actions bot added the Stale label Aug 2, 2023

github-actions bot removed the Stale label Aug 4, 2023

soburi force-pushed the pico_binary_info branch 13 times, most recently from 3c9082d to e759679 Compare October 8, 2025 15:39

soburi marked this pull request as ready for review October 8, 2025 21:09

zephyrbot added the area: Boards/SoCs label Oct 8, 2025

zephyrbot requested review from ThreeEights and ajf58 October 8, 2025 21:11

soburi force-pushed the pico_binary_info branch from e759679 to 1b204f2 Compare October 8, 2025 21:12

soburi assigned ajf58 Oct 8, 2025

soburi requested a review from dsseng October 9, 2025 01:51

dsseng reviewed Oct 9, 2025

View reviewed changes

soburi requested a review from dsseng October 10, 2025 00:45

soburi added 2 commits November 15, 2025 10:38

modules: hal_rpi_pico: add includes that referenced by binary info

81a0228

The binary info feature references `boot_stage2` and `pico_binary_info`. Add these to include dirs. Signed-off-by: TOKITA Hiroshi <[email protected]>

modules: hal_rpi_pico: Make PICO_NO_BINARY_INFO configurable

c98b707

Use the definition of PICO_NO_BINARY_INFO if it already exists, set it as 1 if not so. Signed-off-by: TOKITA Hiroshi <[email protected]>

soburi force-pushed the pico_binary_info branch from 1b204f2 to e913a22 Compare November 15, 2025 01:39

soburi added 2 commits November 15, 2025 19:19

soc: raspberrypi: rpi_pico: Fix indentation

ab122fa

Fix indentation to pass CI check. Signed-off-by: TOKITA Hiroshi <[email protected]>

soburi force-pushed the pico_binary_info branch from e913a22 to ab122fa Compare November 15, 2025 10:20

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

Are you sure you want to change the base?

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

Conversation

soburi commented Feb 1, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mbolivar-nordic left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

yonsch commented Feb 2, 2023

Uh oh!

soburi commented Feb 4, 2023

Uh oh!

yonsch commented Feb 5, 2023

Uh oh!

MaureenHelm commented Mar 23, 2023

Uh oh!

github-actions bot commented May 23, 2023

Uh oh!

github-actions bot commented Aug 2, 2023

Uh oh!

cfriedt commented Aug 3, 2023

Uh oh!

soburi commented Aug 3, 2023

Uh oh!

yonsch commented Aug 4, 2023

Uh oh!

sonarqubecloud bot commented Oct 8, 2025

Quality Gate passed

Uh oh!

dsseng Oct 9, 2025

Choose a reason for hiding this comment

Uh oh!

soburi Oct 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dsseng Oct 10, 2025

Choose a reason for hiding this comment

Uh oh!

sonarqubecloud bot commented Nov 15, 2025

Quality Gate passed

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

soburi commented Feb 1, 2023 •

edited

Loading

soburi Oct 10, 2025 •

edited

Loading