Add Wi-Fi firmware partition support for Pico 2 W

[will-v-pi]

This adds the ability to store and load the Wi-Fi firmware for Pico 2 W in a partition. It can be enabled by adding pico_use_wifi_firmware_partition(<exe_name>) to your CMakeLists.txt, which will embed a compatible partition table in the binary, and output two firmware UF2s to use (<exe_name>_firmware.uf2 for regular, and <exe_name>_firmware_tbyb.uf2 for TBYB). You can also create your own partition table and use that.

A Wi-Fi firmware partition is detected as having the ID 0x776966696669726d, and the UF2 family ID for Wi-Fi firmware blobs is 0xe48bff55. The default firmware partition starts at 3500K into the flash - should this be changed to depend on PICO_FLASH_SIZE_BYTES? The default firmware partition is also duplicated with A/B partitions in the same location in flash - this is required to ensure a signature check is performed before loading the Wi-Fi firmware, as there's no way to call the bootrom to check the signature of a single partition (unless chaining into it), you can only call pick_ab_partition.

The Wi-Fi firmware blob is marked in it's image_def as an RP2350 Risc-V executable, and the partition is marked as ignored_during_riscv_boot - this ensures that it can work with TBYB (as TBYB only works for executable image_defs), and that signature checks are performed before loading the firmware when Secure Boot is enabled (because signature checks are performed for all executable image_defs in a partition that is not marked ignored_during_arm_boot). This is slightly clunky, but seems to work robustly.

[lurch]

pinging @peterharperuk as he did a lot of the Wifi-related stuff for Pico 1.

[peterharperuk]

Works nicely. I think we need to fix the Pico W (rp2040) build errors in src/rp2_common/pico_cyw43_driver/cyw43_driver.c
It would be nice if it gave an error if you're a numpty like me and put pico_use_partition_firmware after pico_add_extra_outputs, but that could be improved later?

[will-v-pi]

It would be nice if it gave an error if you're a numpty like me and put pico_use_partition_firmware after pico_add_extra_outputs, but that could be improved later?

Have added in separate PR #2054

[will-v-pi]

I think we need to fix the Pico W (rp2040) build errors in src/rp2_common/pico_cyw43_driver/cyw43_driver.c

I've added a check that it's not RP2040 in the CMake function, so it'll throw a fatal error at that point if you try to build a binary with pico_use_partition_firmware for RP2040

[armandomontanez]

If the Bazel checks are getting in your way, you can add the two new files to a filegroup (which will silence the error) and file an issue+leave a TODO to support this in Bazel and assign it to me.

[peterharperuk]

Tested this and it seems good.

[will-v-pi]

If the Bazel checks are getting in your way, you can add the two new files to a filegroup (which will silence the error) and file an issue+leave a TODO to support this in Bazel and assign it to me.

Thanks, have done - I couldn't actually assign the issue to you, but have tagged you in it

[lurch]

A Wi-Fi firmware partition is detected as having the ID 0x123456789abcdef0, and the UF2 family_is for Wi-Fi firmware blobs is 0x12345678 - these should probably both be changed to something else before merging?

Is that still going to be happening? I guess choosing randomly-generated IDs is much less likely to produce an accidental collision than a "nice" ID like 0x123456789abcdef0 ? And should those IDs be added to a header-file, to allow other UF2s to make use of this Wi-Fi firmware partition?

[will-v-pi]

A Wi-Fi firmware partition is detected as having the ID 0x123456789abcdef0, and the UF2 family_is for Wi-Fi firmware blobs is 0x12345678 - these should probably both be changed to something else before merging?

Is that still going to be happening? I guess choosing randomly-generated IDs is much less likely to produce an accidental collision than a "nice" ID like 0x123456789abcdef0 ? And should those IDs be added to a header-file, to allow other UF2s to make use of this Wi-Fi firmware partition?

Yes - I was looking for ideas. We could go with 0x776966696669726d (hex for wififirm) for the partition ID, and just use the data family_id we already have?

[lurch]

Yes - I was looking for ideas. We could go with 0x776966696669726d (hex for wififirm) for the partition ID, and just use the data family_id we already have?

I've got no opinions on this so it's probably something that you and @peterharperuk ought to decide. Would MicroPython be able to use the same Wifi firmware partition as C-SDK code? (or is that another one of my stupidly naive questions? 😆 )

[will-v-pi]

Note that this now requires a picotool PR as well (raspberrypi/picotool#247) for support of the new family ID

[peterharperuk]

Spent some time playing with this. Seems to work nicely

[lurch]

Looks like parts of your original comment in this PR need updating too? Not that important, but IMHO useful for future reference.

[richard9999999999]

I tried to use the develop branch however getting following error:

[build] [  0%] Linking ASM executable efis_firmware_tbyb.elf
[build] 
[build] ERROR: cyw43-firmware is not a valid family ID
[build] 
[build] SYNOPSIS:
[build]     picotool uf2 convert [--quiet] [--verbose] <infile> [-t <type>] <outfile> [-t <type>] [-o <offset>] [--family
[build]                 <family_id>] [[--abs-block] [<abs_block_loc>]]
[build] 
[build] Use "picotool help uf2 convert" for more info

The build folder was deleted before and the picotool is loaded and built automatically. Does it use correct picotool version? Or did I miss something?

[will-v-pi]

The picotool fix was only merged this morning, so you may need to delete your build folder and try again - raspberrypi/picotool#247

[richard9999999999]

Yes, it works now. Sorry I was too anxious to try the new changes.. :-)