It should be possible to provide the cyw43 firmware from the app

[usedbytes]

I've implemented a bootloader for the Pico W allowing code upload via WiFi: picowota; unfortunately this means having a copy of the WiFi firmware in the bootloader code, and another copy in the app code.

It would be good if there were a way to pass a pointer to the firmware binary to the cyw43 library(ies), so that one copy can be stored in the bootloader, and the app code can just refer to that.

This would be less relevant with #909, but may still be worth considering.

[kilograham]

Yes, this has been in the back of my mind and also relates to the implementation of #909 - i.e. it should be possible to pass a block iterator to the driver.

Also a cyw43_driver issue, but this is as good a place as any to track

[kripton]

See also https://github.com/georgerobotics/cyw43-driver/issues/4

[earlephilhower]

@usedbytes , one idea which I think would work now is to make the WiFi BLOB its own region of flash and not part of the actual linked executables. Sort of a WiFi blob partition, if you will.

You'd need to adjust the flash ending address (assuming you put it at the top of flash to make things nice and simple for you) and add PROVIDEs in the .ld linker file to point to the fixed address and any vars you define (i.e. length, etc.) The your OTA could use the same copy as the main app, because both would be using the PROVIDEd address (i.e. it would be as if it were in ROM to the app and OTA shim).

[samveen]

Am I correct in assuming that for the Pico W the BT firmware and the WiFi firmware will be a single BLOB, given #1164? If not, would something similar be possible for the BT firmware BLOB too?

[peterharperuk]

Yes, currently, we have added the bt firmware onto the end of the "wifi" firmware. I guess it's possible things will change before the code is merged but I don't see much sense having it as a separate object.

[rewolff]

Well... for space considerations a wifi-only app or BT-only app could just drop the other one. Maybe by default you just include both, but separating them out at a low level will make it much easier for power-users to shave off a bit of code-storage-space. (the Pico has pretty plenty code-storage: It's a challenge to write a program that exceeds 128k.... until you include WIFI and suddenly it jumps to half a megabyte! The CW43 firmware is a big chunk of that!)

[peterharperuk]

bt goes via wifi, so you need the wifi firmware to use bt. The bt overhead is rather small ~6000 bytes although we might not include this if you're not using bt. We haven't asked for a cut down wifi firmware that doesn't actually do any wifi stuff.

[samveen]

@peterharperuk Actually, given how potentially useful a Pico BT would be, I vote for a WiFi firmware that does no WiFi, and is just a thin wrapper for the BT firmware.

That said, are there any details of how this BT via WiFi interface will work programmatically?

[rewolff]

@samveen I briefly looked at the datasheet for the chip. The way I understand it, for compatibility with older separate wifi/bt chips the chip has separate interafaces to the MCU for BT and WIFI.. But the BT interface has not been hooked up on the pico-W, so bluetooth data needs to be transferred into the chip through the pins meant for WIFI. This means that at least some of the WIFI firmware needs to be present.

That said: IMHO the developers should focus on:

• getting it to work,
• then on getting it to work well,
• tehn on defining a good API,
• then publishing all that

and only THEN does optimization come into play. I'm pretty sure you won't run out of pico-code-space right away.

[peterharperuk]

Wise words.

I vote for a WiFi firrmware that does no WiFi, and is just a thin wrapper for the BT Firmware.

This is unlikely to happen.

[ahasani]

@samveen I briefly looked at the datasheet for the chip. The way I understand it, for compatibility with older separate wifi/bt chips the chip has separate interafaces to the MCU for BT and WIFI.. But the BT interface has not been hooked up on the pico-W, so bluetooth data needs to be transferred into the chip through the pins meant for WIFI. This means that at least some of the WIFI firmware needs to be present.

Pardon for jumping in, as per Pi Pico W datasheet : Pico W has an on-board 2.4GHz wireless interface using an Infineon CYW43439. The antenna is an onboard antenna licensed from ABRACON (formerly ProAnt). The wireless interface is connected via SPI to the RP2040

[rewolff]

Right. The datasheet hints at the SPI being commonly used for the wifi connection and the serial connection (like on raspberry pi 3 and -4) for bluetooth.

[peterharperuk]

This is waiting on the firmware compression work...

[rewolff]

I've been thinking about this. Found a trick to keep things compatible with the current API and make this possible.

Add a new api call that has an argument to the firmware blob. Make the old API call use that.

LTO will remove the normal firmware if you use the new call and provide the firmware in another way.

People doing bootloader stuff can then share the blob between bootloader and app. (e.g. put it in the bootloader, have the app find it)

[mvds00]

I have the setup working where the firmware is in its own section, that is shared between the two builds. With some modifications to the linker scripts, it works fine. With the original linker scripts, it will still work (but each build will contain the firmware blob). The code remains virtually untouched so there is not much to break/test.

Pushing this through first requires adding a section attribute to the firmware blob, then requires some customization of the linker script where ideally picowota linker scripts can be based on them.

As things progress, I will post updates here.

[matsobdev]

I vote for a WiFi firrmware that does no WiFi, and is just a thin wrapper for the BT Firmware.

This is unlikely to happen.

Hmmm. Just removing 20 KB (multiple of 512 B) somewhere at the end (sparing CLM) and Bluetooth works, no errors :D Test program uses Pico W LED, that works as well. Test setup: first Pico W as a Bluetooth dongle btattached to Ubuntu 20.04 LTS, second Pico W hid_mouse_demo.c or hog_keyboard_demo.c. Keyboard and mouse are working bonded to Ubuntu PC, as well with a phone: file transfers up and down and A2DP - PC as a sink.

Further shaving WiFi firmware might reduce weight even more. But requires testing to be sure, BT will work. And don't know it would be accepted as an official BT only WiFi firmware. I'm sure, not.

[rewolff]

Such blindly removing code might seem-to-work, but the developers will have to take it as a "hint there might be seemingly unnecessary code at the end.

No matter how much testing you put this through there might be a weird case that you didn't test that requires that code.

I once debugged a situation where Cisco released a "firewall firmware" that wouldn't handle the case packet-with-data comes in, reply ACK is sent, seen by the firewall, but lost on the return to the client. Under normal TCP the client would resend the data and the transfer would continue. But the firewall would block that as "Someone is trying a replay attach, this is a packet from the past I'm not letting that pass! ". Thus the connection would hang. (According to my client: "for some people, some times of the day on SOME providers, but not on others).

This is apparently such a rare condition that Cisco missed that before releasing that firewall into the market. That code you dropped might activate for "unprotected WIFI networks" or WPA3-protected networks or .... whatever I can come up with you could easily test. It's the things that I cannot come up with that worry me.

The guys with the source can look at their link map and ask themselves: Why did it work for @matsobdev without this code? And then possibly decide: WTF he's right this is "dead code" and can't be reached. Or say: Right, but the standard says we need to support xyz and this is the code to handle that! Yes, it's is not always used, but in some applications it is necessary. And it is logical that @matsobdev didn't hit this code with his simple test.