Flash nRF7002 ROM patch via external SPI flash

[Daniel K]

I have been using the nRF7002 DK board; the nRF7002 uses the QSPI bus and the external NOR flash uses SPI.

The nRF WiFi driver's HAL and interface functions all require that the external firmware be accessible via the address bus, which means it can only be loaded from SRAM or over QSPI with XIP enabled.  This eats up >70KB of code space when built internally, and I'd like to free up more.

I would like there to be a method to update the ROM patch via the flash_map API, or via an externally-supplied interface that supplies a read function.

At one point I tried to switch the QSPI and SPI buses, because I think 2 lane QSPI should work, but it did not (probing the signals I may have bricked the SPI flash on one of my boards, and I abandoned attempts at switching the buses after that).

To override this functionality is very difficult, I have to edit the ..__nrf__drivers__wifi__nrf700x library target in CMake:

• Add a new choice option to NRF_WIFI_PATCHES_EXT_FLASH_SUPPORT to avoid having the patch added by the linker
• Remove src/fw_load.c and /nrfxlib/nrf_wifi_hw_if/hal/src/hal_fw_patch_loader.c
• Copy functions hal_fw_patch_chunk_load() and nrf_wifi_hal_fw_patch_boot()
• Supply alternate implementations of nrf_wifi_fw_load() and nrf_wifi_hal_fw_patch_load()

This is not an ideal solution by any means...  I do not like having to dig so deep into Nordic's library to make changes, and I would rather such change be supported by the NCS SDK to avoid breaking on future update.

[AHaug]

Hi,

The nRF WiFi driver's HAL and interface functions all require that the external firmware be accessible via the address bus, which means it can only be loaded from SRAM or over QSPI with XIP enabled. 

You can store the Wifi firmware patch in external flash without QSPI and XiP as well. 

To do so you will need to have your communication with the external flash set up with SPI and use CONFIG_NRF_WIFI_PATCHES_EXT_FLASH_STORE and then use regular flash API to load the patch from the external flash.

https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/device_guides/nrf70/nrf70_fw_patch_update.html. 

Are you certain that this configuration does not fit your use case? It has been created for this exact purpose

Kind regards,
Andreas

[Daniel K]

The Kconfig for this does not work in this case, because it is specifically disallowed for the nRF7002 DK:  This is from menuconfig:

Name: NRF_WIFI_PATCHES_EXT_FLASH_STORE
Prompt: Store nRF700x FW patches in external memory but execute from RAM
Type: bool
Value: n

Direct dependencies (=n):
     !BOARD_NRF7002DK_NRF5340_CPUAPP(undefined/n)  (=y)
  && !BOARD_NRF7002DK_NRF5340_CPUAPP_NS(undefined/n)  (=y)
  && <choice NRF_WIFI_PATCHES_EXT_FLASH_SUPPORT>

Do you know why this option is disabled if that's the way it's supposed to work?  Is it broken?

Also what does it mean in the description by "Execute from RAM"?  At some point I think I looked into this and I saw a virtual flash region was created in RAM, but I don't remember at the moment.  However, I don't want to eat up a whole bunch of RAM for something that only happens once during boot.

[AHaug]

Ah you're right. I will look closer into this, because I was certain that this configuration could be used with SPI and not QSPI, but in practice this means that since the nRF7002DK uses SPI for communication with the external flash it does not work as I thought. Effectively the !nRF7002DK means "it needs QSPI" (as you also say)..

Daniel K said:

Do you know why this option is disabled if that's the way it's supposed to work?  Is it broken?

I did some digging and it is not a bug but it has rather to do with nrfjprog as nrfjprog only has qspi_write and not spi_write. What this means is that you will have to add your own programming scheme that allows for this (I know of other customer who has done this and uses the configuration I mention together with SPI only).

Daniel K said:

Also what does it mean in the description by "Execute from RAM"?  At some point I think I looked into this and I saw a virtual flash region was created in RAM, but I don't remember at the moment.  However, I don't want to eat up a whole bunch of RAM for something that only happens once during boot.

AFAIK this is only done once as it is read from the external flash into RAM and then it is placed on the 7002 through the kernel malloc (see https://github.com/nrfconnect/sdk-nrf/blob/v2.6.1/drivers/wifi/nrf700x/src/fw_load.c#L210). This is done in the same heap that you will use later by the Wifi stack, so it needs to both be big enough to store this firmware patch (1 time only as its usage of RAM is removed after it's been loaded) and to accommodate for your wifi applications.

I will look around to see if there is any incentive from our developers to modify this configuration (most likely it will not be included in the soon to release 2.7.0 of NCS), to support SPI, but as mentioned you can create your own solution for this so it is possible to circumvent it.

Kind regards,
Andreas

[Daniel K]

I am using the external flash for other things related to firmware update, not just the ROM patch.  I hope that when NRFJPROG-157 is implemented, it does not interfere with that.  IMO the help text on this should just state that it requires custom flashing support to write the firmware, or have another config switch to control whether it is automatically flashed.

The NCS SDK is so tightly bound to existing use cases and assumptions made by partition manager in the name of "making it easy on developers" that it actually makes it extremely difficult to customize the system beyond the use cases and designs of the SDK.

For additional context, I am implementing secure boot via a custom b0 and b0n bootloader, with custom image signing tools and update protocol (mcuboot is not used either); an update package is downloaded to external flash and update is done from there, which allows for more code space on the main flash without reserving half of the app code space for a second slot.

[Daniel K]

I think enabling this option is not going to be simple; when I force it on, I get this error:

-- nRF WiFi FW patch binary will be stored in external flash
CMake Error at D:/Projects/nrf_sdk/v2.6.0/nrf/drivers/wifi/nrf700x/CMakeLists.txt:167 (message):
  Unable to find XIP area in dts
  

So this means the build system is still assuming it is a QSPI peripheral with XIP.

[AHaug]

Daniel K said:

IMO the help text on this should just state that it requires custom flashing support to write the firmware, or have another config switch to control whether it is automatically flashed.

Both yes and no. The philosophy is that the configuration documentation should only contain the most necessary information (which it does with !nRF7002DK), and that you should refer to the nRF7002DK regarding why (no QSPI in between external flash and nRF5340). But I agree that it is hard to find out why it is this way (I had to spend some time myself) and that it should be some other help text regarding programming firmware to external flash through spi and not qspi.

Daniel K said:

I hope that when NRFJPROG-157 is implemented, it does not interfere with that.

I've queried the discussion in NRFJPROG-157 for a status regarding it's priority. To my knowledge it should not interfere with this, as it's no problem use an external flash with SPI normally. It is just this part regarding the firmware patch relocation through the linker and programming through nrfjprog that interfers with this.

I'll get back to you with some more information regarding NRFJPROG-157 when I have some more constructive regarding this

Kind regards,
Andreas