Add initial support for the Raspberry Pi Pico 2

[ajf58]

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

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

cc: @yonsch @soburi

[zephyrbot]

The following west manifest projects have been modified in this Pull Request:

Name	Old Revision	New Revision	Diff

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

[soburi]

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

[soburi]

@ajf58

My suggestion.

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

[nordicjm]

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

[ajf58]

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]

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

[ajf58]

File name fettling has been done. Please note the commit message did (and still does) highlight that in several cases this wasn't required.

Since this is now not going into v4.0, I've also modified the relevant commit so that the documentation updates target v4.1's release notes.

Please note my comment regarding the squashing of rp2350: Define and implement a cpucluster of Cortex-M33s. I'm not going to do that for the reasons I've already outlined above.

[ajf58]

Please can you mark this "conversation" as resolved? I don't think there's any more discussion to be had here.

[soburi]

LGTM

[nordicjm]

Please note my comment regarding the squashing of rp2350: Define and implement a cpucluster of Cortex-M33s. I'm not going to do that for the reasons I've already outlined above.

This is clearly defined in the zephyr contribution guidelines, the exact point of which you have been made aware of earlier https://docs.zephyrproject.org/latest/contribute/guidelines.html#contribution-workflow

If reviewers do request changes to your patch, you can interactively rebase commit(s) to fix review issues. In your development repo:

git rebase -i <offending-commit-id>^

In the interactive rebase editor, replace pick with edit to select a specific commit (if there’s more than one in your pull request), or remove the line to delete a commit entirely. Then edit files to fix the issues in the review.

As before, inspect and test your changes. When ready, continue the patch submission:

git add [file(s)]
git rebase --continue

Update commit comment if needed, and continue:

git push --force origin fix_comment_typo

History has nothing to do with it, you're trying to claim if someone submits a PR with C code changes that do not compile, instead of fixing them in the original commit, they should add a new commit which fixes them on top of it to preserve the history, this makes absolutely no sense.

[nordicjm]

Squash requested changes into original commits

[kartben]

... you're trying to claim if someone submits a PR with C code changes that do not compile

@nordicjm that's not at all what @ajf58 is saying (let alone "claiming"). Please, pretty please, refrain from telling people what they are saying "make no sense", especially if you're going into a straw man argument.

The commit that's left "unsquashed" is transitioning from a working state to another working state, AFAICT, and reflecting changes along the lines of "initial support" --> "slightly improved initial support". That last commit would have likely been a different, follow-up, PR in other circumstances.

[nordicjm]

... you're trying to claim if someone submits a PR with C code changes that do not compile

@nordicjm that's not at all what @ajf58 is saying (let alone "claiming"). Please, pretty please, refrain from telling people what they are saying "make no sense", especially if you're going into a straw man argument.

The C part is applying the same logic here to code instead of a dts file. See #80707 (review)

The commit that's left "unsquashed" is transitioning from a working state to another working state, AFAICT, and reflecting changes along the lines of "initial support" --> "slightly improved initial support". That last commit would have likely been a different, follow-up, PR in other circumstances.

Because we don't rebase history that has been merged, this has not been merged, you submit a clean PR which does what is needed, not add commits that you later fix up in the same PR, and this isn't even a zephyr this, this is a common sense thing with projects and git in general

[fabiobaltieri]

The commit that's left "unsquashed" is transitioning from a working state to another working state, AFAICT, and reflecting changes along the lines of "initial support" --> "slightly improved initial support". That last commit would have likely been a different, follow-up, PR in other circumstances.

That is not how code review works here, or in Linux (which the process is inspired from), or I imagine in any other project with a maintainer structure. Fixups go in the commit that introduced a file, sure in other circumstances it would be fine, but this is not that and the fixup commit makes the stack incredibly hard to review and the whole PR evolution very VERY hard to follow, leading to this being delayed further. There's a reason why that's the process documented in the contribution guidelines.

[soburi]

@ajf58

The commit content should not include the discussion process that led to this point, but rather revise it to a direct commit that reflects the final conclusion and commit it.
Also, please try to avoid making modifications to the same file within a PR as much as possible.

I have sorted it out. Please check it out. (Need to clone the repository)
https://github.com/soburi/zephyr/tree/pr77368_squash

There are some parts in the revision process that use my name,
so please use git format-patch and git am to revise and use it.

[ajf58]

Do Not Merge @soburi 's branch.

@kartben's comment is absolutely correct at #77368 (comment) .

When @fabiobaltieri says:

fixups go in the commit that introduced a file

There is no fixup commit.

Again, kartben is absolutely spot on. This PR could have been merged as-is without the last commit. I don't endorse it, but it has to have my sign off because the "signed off by" process mandates it.

I have sorted it out. Please check it out. (Need to clone the repository)
https://github.com/soburi/zephyr/tree/pr77368_squash

@soburi the branch you've created now really is wrong. At the very least:

1. because you've squashed at least one commit together, but failed to correctly change the commit message, the commit message is wrong.
2. You've messed up the committer and author on at least one commit.
3. You've created commits that will fail the Compliance Checks.

There are some parts in the revision process that use my name,
so please use git format-patch and git am to revise and use it.

No, absolutely not. You cannot take my work, break it, give it back to me, and expect me to fix it.

[nordicjm]

Had a quick look at @soburi's branch and looks ok.

because you've squashed at least one commit together, but failed to correctly change the commit message, the commit message is wrong.

He's correctly squashed requested changes into the base commits

You've messed up the committer and author on at least one commit.

Have you ever actually used git before? This is what happens when you rebase, even if you make no changes, go and rebase and git commit --amend --reset-author to fix.

You've created commits that will fail the Compliance Checks.

Where?

[soburi]

@ajf58

and expect me to fix it.

That's true.
That's why I'm not presenting this in a mergeable form.
But I think it's useful enough to show what I, @nordicjm and @fabiobaltieri expect.
Explaining this in words would be too long, so it's better to show an example, which is what I'm doing here.

[soburi]

@ajf58

Do Not Merge @soburi 's branch.

No one said my branch to merge.
In the first place, how can anyone merge something that isn't even a PR?

No, absolutely not. You cannot take my work, break it, give it back to me, and expect me to fix it.

Ok, of course, I'd welcome you to solve the problem your way.

[soburi]

I share @fabiobaltieri 's concern.
Even if policy changes as the PR branch evolves, the ultimately merged commits should be easy to read and organized based on the final policy.
Because the source code is usually "Write once, read many times."
As pointed out, the guideline's statement that we should rebase and force push also makes it undesirable to have "intermediate states" in a PR, I think.