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_partition_firmware(<exe_name>) to your CMakeLists.txt, which will embed a compatible partition table in the binary, and output lots of firmware UF2s to use (all called <exe_name>_firmware_..._.uf2, eg ..._firmware_w for Wi-Fi only, ..._firmware_wb for Wi-Fi and Bluetooth, ..._firmware_w_tbyb for TBYB). You can also create your own partition table and use that.

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

Supercedes #1850, as it now includes that function in this PR, and shows a use for it.

[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]

That use case will work fine - the embedded partition table in these binaries will be ignored when they’re booted from partitions by the bootloader (as opposed to when they’re booted from slots, see 5.1.12-15 in the datasheet for more details)

Unfortunately in the encrypted bootloader sample like scenario (like my project) the wifi partition in the executable binary seems causes malfunction. So I have to exclude the wifi partition from the executable (by hack of your branch) and add it into the bootloader only.

I've fixed this, so you can now pass NO_EMBEDDED_PT to the function and it will not embed the partition table

[richard9999999999]

I've fixed this, so you can now pass NO_EMBEDDED_PT to the function and it will not embed the partition table

Thank you, I am looking forward to see all those great changes in develop and in new SDK release later..

[kilograham]

i had imagined that we would use a new family-id so we can target specifically (even if it is just for generic wifi firmware)

[will-v-pi]

Would we want to use the next family ID for this then (0xe48bff5c), and add a define into the SDK and picotool for it (WIFI_FIRMWARE_FAMILY_ID)?

[kilograham]

Yes, we can do that since it is well known

[kilograham]

@peterharperuk any suggestions on naming - i assume firmware does and is always likely to include both Wifi and BT (or at least there wouldn't usually be two separates)

[peterharperuk]

any suggestions on naming

Sorry, naming of what?

Unfortunately there are two versions of the firmware w and wb. If you use bluetooth it uses the wb version. This was just done because I didn't want to break wifi when we introduced bluetooth support - if there was an issue. Now we can be fairly confident it's ok, I think we should just use the wb firmware all the time.

[will-v-pi]

Yes, this PR already only uses the wb firmware - the question was the naming of the family ID WIFI_FIRMWARE_FAMILY_ID, or something else as it also contains bluetooth firmware (eg CYW43_FIRMWARE_FAMILY_ID or something)?

[peterharperuk]

ah right. I think CYW43_FIRMWARE_FAMILY_ID might be better - ie. have a reference to cyw in there. I wouldn't mention bluetooth

[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