entropy: rpi_pico: implement entropy driver for RP2350 #83346

xudongzheng · 2024-12-24T03:37:40Z

Use get_rand_64() from Pico SDK for entropy.

This is somewhat based on #66764.

modules/hal_rpi_pico/CMakeLists.txt

ceolin · 2024-12-29T00:38:23Z

drivers/entropy/entropy_rpi_pico.c

Why this cast ?

Good catch, I took that part from an earlier version of another entropy driver. The cast has been removed.

tomi-font

Do you have any answer to @yonsch's comment in your previous PR #66764 (comment)?

xudongzheng · 2024-12-30T14:37:48Z

Do you have any answer to @yonsch's comment in your previous PR #66764 (comment)?

@yonsch is referring to the fact that RP2040 lacks a hardware random number generator so it uses other sources as seed.

RP2350 has a hardware random number generator and uses that in pico-sdk: https://github.com/raspberrypi/pico-sdk/blob/95ea6acad131124694cda1c162c52cd30e0aece0/src/rp2_common/pico_rand/rand.c#L121

ajf58

I think a few things need addressing here.

ajf58 · 2024-12-31T14:56:39Z

drivers/entropy/entropy_rpi_pico.c

This could be wrapped in a Zephyr spinlock. There would be a slight performance hit because of the Zephyr spinlock + Pico SDK's hardware-based spin_lock (and we're holding a k_spinlock for longer than strictly required), but this would ensure that users get the Zephyr-provided guarantees about spinlocks.

nit: word has overloaded meaning, I'd avoid this variable name.

Variable renamed to value.

modules/hal_rpi_pico/CMakeLists.txt

ajf58 · 2024-12-31T15:05:31Z

modules/hal_rpi_pico/CMakeLists.txt

This needs thinking about, in particular, how this interacts, by default, with Pico SDK's alarm pool. I think PICO_TIME_DEFAULT_ALARM_POOL_DISABLED will need to be set, at least.

In the earlier PR #66764, PICO_TIME_DEFAULT_ALARM_POOL_DISABLED=1 was needed due to building ${common_dir}/pico_time/time.c. However PICO_TIME_DEFAULT_ALARM_POOL_DISABLED doesn't seem to be referenced in either of the two C files added in this PR:

${rp2_common_dir}/hardware_timer/timer.c

${rp2_common_dir}/pico_rand/rand.c

initialise_rand -> capture_additional_rosc_samples -> sleep_until -> add_alarm_at -> alarm_pool_add_alarm_at, and so on, no?

It doesn't seem like PICO_RAND_SEED_ENTROPY_SRC_ROSC or PICO_RAND_ENTROPY_SRC_ROSC are defined so capture_additional_rosc_samples() shouldn't be called.

Function alarm_pool_add_alarm_at() is defined in src/common/pico_time/time.c and that doesn't seem to be added from anywhere in Zephyr.

Looks good to me, thanks for taking the time to walk through the code path here.

ajf58

I don't think my concern about the alarm pool has been addressed.

ajf58 · 2025-01-19T17:05:34Z

drivers/entropy/entropy_rpi_pico.c

Suggested change

uint64_t value = get_rand_64();

K_SPINLOCK(&entropy_lock) {

uint64_t value = get_rand_64();

}

Only the call to get_rand_64() needs wrapping in the spinlock. Reducing the amount of code in the lock is preferable, and use the helper macro to limit the scope of the key.

I've wrapped get_rand_64() with the K_SPINLOCK() macro.

ajf58 · 2025-01-19T17:13:35Z

modules/hal_rpi_pico/CMakeLists.txt

initialise_rand -> capture_additional_rosc_samples -> sleep_until -> add_alarm_at -> alarm_pool_add_alarm_at, and so on, no?

xudongzheng · 2025-01-31T17:51:30Z

PR rebased on top of 03fa6a0 to address merge conflicts.

drivers/entropy/entropy_rpi_pico.c

soburi · 2025-01-31T23:17:50Z

drivers/entropy/entropy_rpi_pico.c

The 3rd arg of memcpy is size_t.

And for now, we mostly follow the old habit of "declaring variables at the top of a block", so please do so if possible.

Yes, to_copy should be size_t.

I'm putting a thumbs-down against "declaring variables at the top of a block"
a) Reviewers should not introduce ad-hoc coding styles.
b) It's another throwback to ancient C standards (i.e. C90, which is 4 versions and 30 years too old). Mixing declarations and code is a Good Thing: by reducing a variables scope/lifetime it makes it easier to understand when/where a variable is used. In contrast, sticking all the variable declarations together makes it harder to do this. Some people incorrectly believe they can estimate stack usage by counting number/size of variables declared, and this tacitly encourages such behaviour.

In reality, this habit is still strong
and is frequently pointed out in reviews. #83358 (comment)
Since there is no clear affirmative or negative provision in the terms and conditions, it is up to the discretion of the reviewer or maintainer.
I think that, currently, most cases lean towards this "old habit."

As far as I'm concerned, this habit was abolished in the 2012 MISRA-C regulations,
so I don't intend to block it, but I would probably start by saying, "Do it the way everyone else does."
Even this would probably be a relatively radical stance among maintainers.

ajf58

There's a lot I like about this implementation (it's very well laid out, order of #include s is neat, DTS file changes are nicely in order).

A couple of things need tweaking.

ajf58 · 2025-02-01T09:04:17Z

drivers/entropy/Kconfig.rpi_pico

Suggested change

depends on DT_HAS_RASPBERRYPI_PICO_RNG_ENABLED

depends on DT_HAS_RASPBERRYPI_PICO_RNG_ENABLED

depends on SOC_SERIES_RP2350

Given that *rpi_pico*.c is often used for both RP2040 and RP2350 series SoCs, perhaps the additional constraint will avoid people trying to use this entropy generator on the RP2040, where it would be unsuitable?

Added per suggestion.

ajf58 · 2025-02-01T09:10:29Z

dts/arm/raspberrypi/rpi_pico/rp2350.dtsi

At build-time this is introducing a warning:

zephyr/build/rpi_pico2/rp2350a/m33/hello_world/zephyr/zephyr.dts:408.12-411.5: Warning (simple_bus_reg): /soc/rng: missing or empty reg/ranges property

which this needs looking at.

Ordering should be the other way around (status comes last).

I think the Zephyr convention is meant to be that we don't enable too much stuff by default, with an implicit rationale that we don't want build "hello world" to compile hundreds of files, as that gives a daunting/bad user experience ("I just want to blink and LED, why does that need 130 source files!" kind of response) so this should be disabled by default.

I've added reg = <0x400f0000 DT_SIZE_K(4)> since that corresponds to TRNG_BASE.

I've moved status to the last line to match other entries in the .dtsi file.

I've disabled &rng by default and enabled it from the board since non-wireless microcontrollers seem to follow this pattern.

ajf58 · 2025-02-01T13:28:23Z

dts/arm/raspberrypi/rpi_pico/rp2350.dtsi

It's unclear where this should be (SoC's dtsi vs board's) as the Zephyr codebase is inconsistent. My gut feeling is (in descending order)

Neither; the board doesn't need it to run correctly

In the board file

Here

There is practice in esp32 and nxp, so this is fine.

The majority of uses of zephyr,entropy are in the SOC definitions, so I think this is the right place.

tomi-font · 2025-06-02T09:13:26Z

If I remember correctly, you can't reopen the branch you're pushing if the head of the branch you're pushing to has been changed since it was closed. Changing the head of the branch to a0c870d and push, and try reopen again.

Exactly this.

xudongzheng · 2025-06-04T18:29:24Z

The branch is back at a0c870d, though I don't see a button to reopen the pull request. Perhaps someone with the right permissions can do it now?

sonarqubecloud · 2025-06-06T04:57:09Z

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

github-actions · 2025-08-06T00:43:26Z

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 · 2025-08-15T20:21:40Z

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

xudongzheng · 2025-08-15T21:16:04Z

Previously CI was failing on the following test:

west build -p -b rpi_pico2/rp2350a/m33 tests/crypto/mbedtls -T crypto.mbedtls

This should be addressed in the latest push with a __CONCAT definition in modules/hal_rpi_pico/pico/config_autogen.h.

dsseng · 2025-08-16T20:42:43Z

modules/hal_rpi_pico/uninit_data.ld

Why is this required? Maybe SDK functions using this could be avoided?

Pico SDK mixes the TRNG output with uninitialized memory: https://github.com/raspberrypi/pico-sdk/blob/a1438dff1d38bd9c65dbd693f0e5db4b9ae91779/src/rp2_common/pico_rand/rand.c#L365-L374

To work around that, one would have to use capture_additional_trng_samples(), but that's not public API.

dsseng · 2025-08-16T20:44:56Z

drivers/entropy/entropy_rpi_pico.c

+		size_t to_copy = MIN(sizeof(value), len);
+
+		K_SPINLOCK(&entropy_lock) {
+			value = get_rand_64();


Is it idiomatic for an entropy source to actually provide more entropy than it has? It only has a boot-time true random value, while this function is fueled by xoroshiro128 algorithm: https://github.com/raspberrypi/pico-sdk/blob/a1438dff1d38bd9c65dbd693f0e5db4b9ae91779/src/host/pico_rand/rand.c

This is a question to subsys maintainers

Looking at https://github.com/raspberrypi/pico-sdk/blob/a1438dff1d38bd9c65dbd693f0e5db4b9ae91779/src/rp2_common/pico_rand/rand.c#L350-L354, each get_rand_64() invocation calls capture_additional_trng_samples() for additional entropy.

The end result is fed into xoroshiro128 as you mentioned.

Hm, not sure if that matches subsystem expectations, but that sounds good. Please keep this thread open

github-actions · 2025-10-18T00:34:47Z

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.

stef · 2025-10-27T23:22:52Z

hey there, i applied this as a patch to my zephyr ws, and am building it correctly and am using it successfully. am looking forward to not having to patch but seeing this merged. kudos to all involved!

Use get_rand_64() from Pico SDK for entropy. Signed-off-by: Xudong Zheng <[email protected]>

sonarqubecloud · 2025-10-29T18:43:30Z

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

stef · 2025-10-31T23:01:06Z

@xudongzheng how is this mostly sram0 stuff in this diff https://github.com/zephyrproject-rtos/zephyr/compare/29e0630267bd920a5d1087a1aec14f22319487b9..d42a9052d8940c5c5d50dc9964c7397cd1846f80 related to the rng?

xudongzheng · 2025-11-01T12:30:33Z

@xudongzheng how is this mostly sram0 stuff in this diff https://github.com/zephyrproject-rtos/zephyr/compare/29e0630267bd920a5d1087a1aec14f22319487b9..d42a9052d8940c5c5d50dc9964c7397cd1846f80 related to the rng?

@stef Most of that is not part of the PR and just a result of the rebase. A lot of the RP2350 tests were failing in the previous push and I suspected #98363 was necessary.

zephyrbot added area: Crypto / RNG platform: Raspberry Pi Pico Raspberry Pi Pico (RPi Pico) labels Dec 24, 2024

zephyrbot requested review from ceolin, soburi, tomi-font and yonsch December 24, 2024 03:38

zephyrbot assigned ceolin Dec 24, 2024

xudongzheng force-pushed the rp2350-entropy-pr branch 2 times, most recently from df8de81 to be3cfa0 Compare December 24, 2024 03:59

soburi reviewed Dec 25, 2024

View reviewed changes

modules/hal_rpi_pico/CMakeLists.txt Outdated Show resolved Hide resolved

ceolin reviewed Dec 29, 2024

View reviewed changes

tomi-font reviewed Dec 30, 2024

View reviewed changes

xudongzheng force-pushed the rp2350-entropy-pr branch 2 times, most recently from 338dfec to f069b11 Compare December 30, 2024 15:49

ajf58 requested changes Dec 31, 2024

View reviewed changes

xudongzheng force-pushed the rp2350-entropy-pr branch 2 times, most recently from 1edd3e0 to 14d6fb1 Compare January 17, 2025 21:41

ajf58 requested changes Jan 19, 2025

View reviewed changes

soburi mentioned this pull request Jan 28, 2025

TaskList for Supporting RaspberryPi Pico peripherals #53810

Open

57 tasks

xudongzheng force-pushed the rp2350-entropy-pr branch from 14d6fb1 to bb08548 Compare January 31, 2025 17:38

zephyrbot requested a review from ThreeEights January 31, 2025 17:39

xudongzheng force-pushed the rp2350-entropy-pr branch from bb08548 to 1267804 Compare January 31, 2025 17:51

soburi reviewed Jan 31, 2025

View reviewed changes

drivers/entropy/entropy_rpi_pico.c Outdated Show resolved Hide resolved

xudongzheng force-pushed the rp2350-entropy-pr branch from 1267804 to 9bb2f83 Compare January 31, 2025 22:23

soburi reviewed Jan 31, 2025

View reviewed changes

xudongzheng force-pushed the rp2350-entropy-pr branch from 9bb2f83 to 045df69 Compare January 31, 2025 23:33

ajf58 requested changes Feb 1, 2025

View reviewed changes

xudongzheng force-pushed the rp2350-entropy-pr branch from 045df69 to fc54eeb Compare February 4, 2025 13:58

soburi reopened this Jun 4, 2025

github-actions bot removed the Stale label Jun 5, 2025

xudongzheng force-pushed the rp2350-entropy-pr branch from a0c870d to 635722a Compare June 6, 2025 04:33

xudongzheng marked this pull request as draft June 6, 2025 04:33

github-actions bot added the Stale label Aug 6, 2025

xudongzheng force-pushed the rp2350-entropy-pr branch from 635722a to 4c3c8b2 Compare August 15, 2025 20:17

xudongzheng marked this pull request as ready for review August 15, 2025 21:15

github-actions bot removed the Stale label Aug 16, 2025

dsseng reviewed Aug 16, 2025

View reviewed changes

github-actions bot added the Stale label Oct 18, 2025

xudongzheng force-pushed the rp2350-entropy-pr branch from 4c3c8b2 to 29e0630 Compare October 27, 2025 13:27

zephyrbot added area: Devicetree Bindings area: Boards/SoCs labels Oct 27, 2025

dsseng removed the Stale label Oct 27, 2025

dsseng requested review from ajf58 and soburi October 27, 2025 17:26

entropy: rpi_pico: implement entropy driver for RP2350

d42a905

Use get_rand_64() from Pico SDK for entropy. Signed-off-by: Xudong Zheng <[email protected]>

xudongzheng force-pushed the rp2350-entropy-pr branch from 29e0630 to d42a905 Compare October 29, 2025 18:16

ajf58 approved these changes Nov 1, 2025

View reviewed changes

-		uint64_t value = get_rand_64();
+		K_SPINLOCK(&entropy_lock) {
+			uint64_t value = get_rand_64();
+		}

	depends on DT_HAS_RASPBERRYPI_PICO_RNG_ENABLED
	depends on DT_HAS_RASPBERRYPI_PICO_RNG_ENABLED
	depends on SOC_SERIES_RP2350

entropy: rpi_pico: implement entropy driver for RP2350 #83346

Are you sure you want to change the base?

entropy: rpi_pico: implement entropy driver for RP2350 #83346

Uh oh!

Conversation

xudongzheng commented Dec 24, 2024

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tomi-font left a comment

Choose a reason for hiding this comment

Uh oh!

xudongzheng commented Dec 30, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ajf58 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ajf58 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

xudongzheng commented Jan 31, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ajf58 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

xudongzheng Feb 4, 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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tomi-font commented Jun 2, 2025

Uh oh!

xudongzheng commented Jun 4, 2025

Uh oh!

sonarqubecloud bot commented Jun 6, 2025

Quality Gate passed

Uh oh!

xudongzheng commented Dec 30, 2024 •

edited

Loading

xudongzheng Feb 4, 2025 •

edited

Loading