boards: Add support for the raspberrypi pico

[yonsch]

This PR provides very basic support for the Raspberry Pi Pico board. It continues #33172 by @ioannisg .
It currently supports the boot process and UART, and is able to run the hello_world sample.
As this is still very premature, it still lacks a few important features, such as spawning the second core or supporting west flash, but it's probably enough so that other people can start using this board with Zephyr and improve this port.
This PR assumes there is a hal_raspberrypi module under zephyrproject-rtos. Since I don't have permissions to create this repository, I will need someone to do so, so that I can push my local changes.

If anyone wants to run this, I used raspberrypi's fork of openocd together with a JLink adapter to flash. If you're using JLink, make sure to checkout to the rp2040_jlink branch of their fork before installing openocd. Flash using this command:

openocd -f interface/jlink.cfg -c 'transport select swd' -f target/rp2040.cfg -c "adapter_khz 2000" -c 'targets rp2040.core0' -c 'program build/zephyr/zephyr.elf verify reset exit'

Closes #33012

[github-actions]

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

Name	Old Revision	New Revision	Diff
hal_rpi_pico	N/A	zephyrproject-rtos/hal_rpi_pico@191f5ba (zephyr)	N/A

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

[yonsch]

Requested here #32193 and here #33012

[petejohanson]

@yonsch Curious to test this with a couple boards I have, but I'm failing to figure out what specifically you did for the modules/hal/raaspberrypi module. Can you share what the zephyr/module.yml in there looks like, and how it works? If I just use the root of the pico-sdk for this, I get errors when the SoC stuff is trying to find some of the core includes.

Thanks!

[yonsch]

@petejohanson I used the src directory from the SDK, but there were a few extra steps that had to be taken to make it work with Zephyr (namely a new cmake file and some auto generated files). I will try to upload it in the coming days.

[petejohanson]

@yonsch cool to see some gpio work now too. Have you had a chance to put together the HAL bits? Would love to contribute, work on other board definitions, etc.

[yonsch]

Thanks @petejohanson , I wanted to make sure the gpio driver works before pushing the hal. You can now find it here: https://github.com/yonsch/hal_rp_demo . It needs some more work, but is good enough for you to play with. Let me know if you have any problem

[petejohanson]

I can confirm that the hello_world works with my initial definition for adafruit_qt_py_rp2040:

[tio 10:49:10] tio v1.32
[tio 10:49:10] Press ctrl-t q to quit
[tio 10:49:10] Connected
*** Booting Zephyr OS build zephyr-v2.5.0-3557-g0bdba34b1ea5  ***
Hello World! adafruit_qt_py_rp2040

@yonsch I made some tweaks locally to define the &flash0 to actually match the flash range, and then using partitions to define a code_partition, etc. to account for the second stage offset, and to create a settings region. Would you like me to PR that to your branch?

[yonsch]

Very cool @petejohanson , that's probably better than what I did. The only problem I can think of is that this will would force every project to enable USE_DT_CODE_PARTITION, which will then require anyone who is not interested in the default partitions to override them. But you can definitely PR this. Thanks!

[petejohanson]

Very cool @petejohanson , that's probably better than what I did. The only problem I can think of is that this will would force every project to enable USE_DT_CODE_PARTITION, which will then require anyone who is not interested in the default partitions to override them. But you can definitely PR this. Thanks!

I played with this a bit more, and I think your intuition there is right, leaving the flash offset as 0x10000100 allows you to skip the partition setup altogether if you don't want it.

I was able to get UF2 flashing working fine here locally too, with some minor tweaks, so I created a PR into your fork here yonsch#1

With this addition it should be easier for folks to test without using forked openocd, etc. since you can just flash over USB.

What areas are you planning on working on next? I want to contribute, but don't want to step on any toes. I'm interested in hacking on USB bits, since I'm aiming for core pieces needed for using this with ZMK firmware.

[yonsch]

@petejohanson Your UF2 branch works with the Pico. Go ahead with the USB - I will probably go with either PWM/I2C/second core. Regarding your PR (of the UF2 and your board) - I'm not really sure what's the best way of doing it. I guess you could PR your changes and I will either rebase or cherry-pick them, signing it off by you of course. If there's any better way, let me know.
BTW, concerning the issue with the flash layout, I found this issue - #27471 which is very similar to our problem. We'll see what they come up with.

[protobits]

Hi, I'm also interested in having support for RP2040 on Zephyr as I would also like to use ZMK with it, so I can definitely help (even though I'm relatively new to Zephyr). I understand this may just take some time but if there's anything I can do, let me know.

[protobits]

Any news on this? I see there are now some conflicts to be solved.
@yonsch anything I can do to help?

[tejlmand]

we still haven't concluded on this:
#34835 (comment)

as it seems for now we need to handle this until #40555 is fully in place, I prefer we make it clear that the second stage bootloader is not a Zephyr executable but a stand-alone sample that can be included, similar to the IDF bootloader, and other current multi image builds.

[tejlmand]

Why does this need to be added to the ALL target ?

Aren't some other target depending on the output boot_stage2.S ensuring the custom command below is executed ?

[tejlmand]

actually, why is there a custom target in the first place ?

[yonsch]

What's the alternative?

[tejlmand]

not having a custom target.

When the output from a custom command is used by another build step, then CMake will ensure that command is invoked.

Only if multiple targets depends on the same output from a custom command, then it is required to create a custom target. But in such a case, the CMake code should have a dependency to the custom target, not to the output of the custom command.
This doesn't appear to be what you're doing, cause as far as I can tell, no targets depends on the boot_stage2_asm target.

See more: https://cmake.org/cmake/help/latest/command/add_custom_command.html

[yonsch]

@tejlmand I missed that one, I removed the bootloader_bin custom target successfully, but boot_stage2_asm seems to be needed, as the target that depends on it is in the other file. Is there any way around this, or can I keep that custom target?

[tejlmand]

and I missed the request for changes because you moved the code around 😆

The most correct thing to do here, is to add post build commands to the boot_stage2 target and specify the byproducts.

I'm just giving you the patch set right here:

diff --git a/modules/hal_rpi_pico/bootloader/CMakeLists.txt b/modules/hal_rpi_pico/bootloader/CMakeLists.txt
index 68d080b46f..f582604169 100644
--- a/modules/hal_rpi_pico/bootloader/CMakeLists.txt
+++ b/modules/hal_rpi_pico/bootloader/CMakeLists.txt
@@ -51,15 +51,15 @@ target_link_options(boot_stage2 PRIVATE
 target_compile_definitions(boot_stage2 PRIVATE -DCONFIG_ARM=1)
 
 # Generates a binary file from the compiled bootloader
-add_custom_target(bootloader_bin DEPENDS boot_stage2.bin)
-add_custom_command(OUTPUT boot_stage2.bin
-  DEPENDS boot_stage2
+add_custom_command(TARGET boot_stage2
+  POST_BUILD
+  BYPRODUCTS boot_stage2.bin
   COMMAND ${CMAKE_OBJCOPY} -Obinary $<TARGET_FILE:boot_stage2> boot_stage2.bin
   )
 
 # Checksums the binary, pads it, and generates an assembly file
-add_custom_target(boot_stage2_asm ALL DEPENDS boot_stage2.S)
-add_custom_command(OUTPUT boot_stage2.S
-  DEPENDS boot_stage2.bin
+add_custom_command(TARGET boot_stage2
+  POST_BUILD
+  BYPRODUCTS boot_stage2.S
   COMMAND ${PYTHON_EXECUTABLE} ${boot_stage_dir}/pad_checksum
   -s 0xffffffff boot_stage2.bin boot_stage2.S)

that will give you all you need.

[yonsch]

fixed

[tejlmand]

@yonsch thanks for this update.

Made some comments that will clean up the use of external project.

Also remember to address the earlier comment regarding <TAB> here: #34835 (comment)
There are still a lot of tabs in the CMakeLists.txt files.

[tejlmand]

Looking good, thanks for the effort and patience @yonsch .

One minor observation that you should look at, but approved under the expectation that this will be fixed.

[tejlmand]

Small observation, PYTHON_EXECUTABLE is not passed from main build here:
https://github.com/zephyrproject-rtos/zephyr/blob/adc3cee9264f4b8f2e574bf78819cb3987b16ab9/modules/hal_rpi_pico/CMakeLists.txt#L25-L26

This means that PYTHON_EXECUTABLE is empty, and the script will pickup whatever is present in path.
Such situations has led to non-deterministic behavior in the past and thus confusion, so better fix it in this PR.

From ninja -v, notice the missing Python interpreter before pad_checksum.

[4/4] cd /projects/github/ncs/zephyr/build/bootloader && /projects/github/ncs/modules/hal/rpi_pico/src/rp2_common/boot_stage2/pad_checksum -s 0xffffffff boot_stage2.bin boot_stage2.S

[yonsch]

fixed