Add initial support for the Raspberry Pi Pico 2 #77368

ajf58 · 2024-08-21T21:22:41Z

https://builds.zephyrproject.io/zephyr/pr/77368/docs/boards/index.html#name=pico+2

This is a PR to add support for the Raspberry Pi Pico 2 board, and the RP2350 SoC. See also the discussion at #77329

~~This should not be merged currently, as it includes changes that will break the clock control driver for the RP2040.~~

Dependencies

west: hal_rpi_pico: Update Pico-SDK to 2.0.0 #76986
Updating hal_rpi_pico incorporate the change for raspberrypi/pico-sdk@0e5ef0f

cc: @yonsch @soburi

zephyrbot · 2024-08-21T21:23:37Z

The following west manifest projects have changed revision in this Pull Request:

Name	Old Revision	New Revision	Diff

✅ All manifest checks OK

Note: This message is automatically posted and updated by the Manifest GitHub Action.

soc/raspberrypi/CMakeLists.txt

dts/arm/rpi_pico/rpi_pico_2_common.dtsi

drivers/clock_control/clock_control_rpi_pico.c

modules/hal_rpi_pico/CMakeLists.txt

soburi · 2024-08-22T07:32:52Z

@ajf58
First, I've listed some points that caught my attention at a glance.
I haven't been able to check it thoroughly yet, so I'll look at it a bit more.

soc/raspberrypi/rp2xxx/Kconfig

soc/raspberrypi/soc.yml

boards/raspberrypi/rpi_pico_2/Kconfig.defconfig

soburi · 2024-08-22T21:28:40Z

@ajf58

My suggestion.

https://github.com/soburi/zephyr/tree/pico2_soc

modules/hal_rpi_pico/CMakeLists.txt

dts/arm/rpi_pico/rpi_pico_2_common.dtsi

soc/raspberrypi/CMakeLists.txt

west.yml

nordicjm

Updates are OK. Though migration guide entry needed for the SoC symbol change

boards/raspberrypi/rpi_pico_2/rpi_pico_2-pinctrl.dtsi

dts/arm/raspberrypi/rpi_pico/rp2350.dtsi

ajf58 · 2024-08-30T14:34:29Z

Updates are OK. Though migration guide entry needed for the SoC symbol change

@nordicjm where should this update go? Is under boards in doc/releases/migration-guide-4.0.rst correct?

nordicjm · 2024-09-02T06:08:27Z

Updates are OK. Though migration guide entry needed for the SoC symbol change

@nordicjm where should this update go? Is under boards in doc/releases/migration-guide-4.0.rst correct?

Yes

kartben · 2024-12-19T10:18:59Z

Who's in to make a drama novel from this PR?

@gmarull do you seriously think this kind of comment is helpful and is what we need at this point?

gmarull · 2024-12-19T10:22:35Z

Who's in to make a drama novel from this PR?

@gmarull do you seriously think this kind of comment is helpful and is what we need at this point?

I doubt it can't get worse TBH. Nevertheless, why doesn't someone just open a PR with a proper rebase, gets approvals, gets merged, and we all move on?

kartben · 2024-12-19T10:49:49Z

Nevertheless, why doesn't someone just open a PR with a proper rebase, gets approvals, gets merged, and we all move on?

I'm working on this

soburi · 2024-12-19T12:15:42Z

Who's in to make a drama novel from this PR?

The dialogue is still ongoing, so please wait.
Whatever the outcome, it won't take long.

Honestly, I understand the desire to say that,
but I think it's a necessary cost for a ridiculously dull yet wonderfully democratic consensus-building system we use.

I doubt it can't get worse TBH. Nevertheless, why doesn't someone just open a PR with a proper rebase, gets approvals, gets merged, and we all move on?

I'm unsure if I caught the exact nuance since it wasn't my native language, but I remember that @carlescufi was cautious about forced updates in a previous Arch-Review. I respect this, and although it's a hassle, I think it's the best way to build trust in the project.

ajf58 · 2024-12-22T23:12:04Z

By having me answer this directly, I am acknowledging the implicit assumption that even if something is written in the documentation, it doesn't have to be followed.
So, I don't need to answer your question.

I'm sorry, I don't understand this reply.
No, you don't need to answer any question a stranger like me asks you on the internet. That said, you are a maintainer and reviewer and if you (or any other reviewer) can't actually give a explanation to articulate why this is required, it doesn't educate/inform/encourage, it just comes across a bit like you don't know why it's needed, and are being deflective/evasive.

Likewise you didn't answer the second question regarding the RP2040. I find this communication style a challenge: if I ask technical questions and the reviewer/maintainers reply "I'm not going to answer" then it feels kinda weird to me.

For anyone following along:

I was a little surprised that @kartben was able to force-push to my branch in my fork[1]. I'm not against @kartben making changes to things, but also need to understand how this will impact my own development work without me having to create my own branch called add-rpi-pico-2-support-the-original or something daft. It's late at night in my timezone, so if anyone has technical contributions to this problem, please post them.

[1] This is a feature of PRs that I didn't know overrode the permissions on the source repo (fork).

soburi · 2024-12-22T23:41:10Z

I am of the opinion that @kartben's actions are within the scope of the terms and conditions agreed to when committing the code and that there is also no moral or ethical problem with them.

soburi · 2024-12-22T23:49:38Z

I'm sorry, I don't understand this reply. No, you don't need to answer any question a stranger like me asks you on the internet. That said, you are a maintainer and reviewer and if you (or any other reviewer) can't actually give a explanation to articulate why this is required, it doesn't educate/inform/encourage, it just comes across a bit like you don't know why it's needed, and are being deflective/evasive.

Likewise you didn't answer the second question regarding the RP2040. I find this communication style a challenge: if I ask technical questions and the reviewer/maintainers reply "I'm not going to answer" then it feels kinda weird to me.

All of the questions have been answered.
If my rebuttals were off-point, people here would be making fun of me.

Again, Just working isn't enough. (Absence of technical problems is a necessary but not sufficient condition)
Furthermore, exceptions to the rules are permitted "if there is agreement."
But, there is no reason to permit these exceptions on this issue.

soburi · 2024-12-23T00:36:27Z

@ajf58
If you want to have the discussion you expect, I would recommend creating an issue about the appropriateness of the description in the board porting guide.
I don't think you'll get the answer you are looking for, though.
And no matter what theory you use, it will be impossible to elicit an answer that says you don't have to follow the documentation, I think.

soburi

A resolution has been made in Arch-Review to rebase the commits.

Red-M · 2024-12-23T03:03:48Z

@soburi

All of the questions have been answered. If my rebuttals were off-point, people here would be making fun of me.

Please stop lying. This entire conversation from yourself and pretty much every other maintainer has been disgusting to see.

soburi · 2024-12-23T04:48:43Z

@soburi

All of the questions have been answered. If my rebuttals were off-point, people here would be making fun of me.

Please stop lying. This entire conversation from yourself and pretty much every other maintainer has been disgusting to see.

That statement may have been offensive. I would like to take it back.
However, I did not intend to say anything particularly inappropriate regarding the veracity of the content, and I am simply in a position where I can be criticized. So if there is criticism, I will respond.

carlescufi · 2024-12-23T13:39:46Z

@soburi

All of the questions have been answered. If my rebuttals were off-point, people here would be making fun of me.

Please stop lying. This entire conversation from yourself and pretty much every other maintainer has been disgusting to see.

Please refrain from accusing others of lying in the context of this conversation. As many other comments in this PR, this is not productive to try and get this solved. The maintainers are not perfect, and this PR has clearly uncovered shortcomings in many of our processes, but I have no doubt that @soburi has done his honest best to get this PR merged.

kartben · 2024-12-23T22:47:34Z

@carlescufi , thanks for sharing that interesting voting results. As I've said before, I am not going to do that. Feel free to do with that information as you wish. Perhaps it's time for someone to close this PR.

I've opened #83343 as it seemed like the best way to move forward and not impact @ajf58's branch. Except for squashed commits, the content of the PR is exactly the same as this one.

Thanks, @ajf58, for this awesome contribution, and to everyone else who helped make it finally land.

kartben · 2024-12-23T23:01:39Z

Superseded by #83343

soburi · 2024-12-23T23:19:29Z

Thanks to the main contributor @ajf58, everyone who provided patches helped with the evaluation and spent long hours reviewing this PR and participating in the reviews and discussions. We appreciate it.

Let's us forward to the next step!

The documentation had for a long time a section that specifically recommends to submit "smaller PRs" for review: https://docs.zephyrproject.org/latest/contribute/contributor_expectations.html#defining-smaller-prs Yet submitters keep submitting large PRs on a regular basis, sometimes very large ones. See a couple of very recent examples below. (Reminder: submitting a giant, draft PR for pure _testing_ purposes and NOT for review is a perfectly fine) The "natural" explanation is that submitters optimistically and wrongly believe that dumping a large amount of code at once onto reviewers will be dealt with faster than in smaller chunks. This is most likely a contributing factor but most people should quickly learn from bad experience. Yet we keep seeing large PRs on a regular basis. So there must be other factors too. Based on personal but fairly extensive git support experience, another top reason is likely git usability and some lack of git knowledge (neither the first nor the last time git usability would have a significant impact) To help with this, add to the existing git guide the simple command that lets split a large submission in several, smaller PRs. This can only help demystify and promote smaller PRs while barely growing the size of the documentation. While at it, also add a couple missing benefits of smaller PRs. Recent examples of large PRs: - In the controversial and giant PR zephyrproject-rtos#77368 (comment) the exhausted submitter wrote: > Every time any one person requests a rebase that changes the PR, > unless there's consensus, there's no mechanism (manual/project process > or built into GitHub) to know/prevent a different person from rejecting > the new changes. That PR had 21 commits (18 in the final version), 82 files changed and 400 (!) comments. The sheer size massively increased the likelihood of the problem described. Re-submitting it in smaller chunks would obviously have mitigated that problem. Yet that PR was never split and stayed huge...? - In this second example, a large PR was submitted with different authors. A disagreement emerged about squashing across different authors: zephyrproject-rtos#78795 (comment) If this PR had been split in smaller chunks, then the squashing discussion might have been avoided entirely. Whether squashing is good or bad in this particular case is irrelevant (and already discussed at great in length in zephyrproject-rtos#83117). What matters here is: the submitter lost that chance by submitting a larger PR with different authors. Signed-off-by: Marc Herbert <marc.herbert@intel.com>

kartben · 2025-01-13T11:28:39Z

I'll be more direct: one maintainer did break the CoC. This was determined by the CoC committee. The maintainer was asked to apologize to me. They didn't. They were asked to abstain from interacting with this PR. They didn't.

Just for the record, as I'm only noticing this now, the Code of Conduct team never asked anyone to abstain from interacting with this PR.

zephyrbot added manifest manifest-hal_rpi_pico DNM This PR should not be merged (Do Not Merge) labels Aug 21, 2024

ajf58 force-pushed the add-rpi-pico-2-support branch from 82e6a6f to 161828a Compare August 22, 2024 07:08