Flash nRF7002 ROM patch via external SPI flash

RE: Flash nRF7002 ROM patch via external SPI flash

AHaug — Fri, 07 Jun 2024 08:51:56 GMT

[quote user="Daniel K"]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.[/quote]

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.

[quote user="Daniel K"]I hope that when NRFJPROG-157 is implemented, it does not interfere with that.[/quote]

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

RE: Flash nRF7002 ROM patch via external SPI flash

Daniel K — Thu, 06 Jun 2024 14:41:47 GMT

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.

RE: Flash nRF7002 ROM patch via external SPI flash

Daniel K — Thu, 06 Jun 2024 14:21:13 GMT

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.

RE: Flash nRF7002 ROM patch via external SPI flash

AHaug — Thu, 06 Jun 2024 13:59:26 GMT

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

[quote user="Daniel K"]Do you know why this option is disabled if that's the way it's supposed to work? Is it broken?[/quote]

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

[quote user="Daniel K"]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.[/quote]

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

RE: Flash nRF7002 ROM patch via external SPI flash

Daniel K — Thu, 06 Jun 2024 13:24:56 GMT

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.

RE: Flash nRF7002 ROM patch via external SPI flash

AHaug — Thu, 06 Jun 2024 13:14:59 GMT

Hi,

[quote user=""]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. [/quote]

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

RE: Flash nRF7002 ROM patch via external SPI flash

Daniel K — Wed, 05 Jun 2024 13:38:01 GMT

My CMakeLists.txt overriding the changes:

# Modifying the library in the sdk at /nrf/drivers/wifi/nrf700x
set(ZEPHYR_CURRENT_LIBRARY ..__nrf__drivers__wifi__nrf700x)

# Add a new source
zephyr_library_sources(nrf70_fw_loader.c)

set(_files_to_remove
    src/fw_load.c
    .*/nrfxlib/nrf_wifi/hw_if/hal/src/hal_fw_patch_loader.c
)

# Remove the old firmware loader source
get_target_property(_nrf_wifi_sources ${ZEPHYR_CURRENT_LIBRARY} SOURCES)
foreach(_filename ${_files_to_remove})
    list_find_regex(_nrf_wifi_sources ${_filename} _found_index)
    if(${_found_index} GREATER -1)
        message(STATUS "Removing ${_filename}")
        list(REMOVE_AT _nrf_wifi_sources ${_found_index})
    else()
        message(FATAL_ERROR "${_filename} not found!")
    endif()
endforeach()
set_target_properties(${ZEPHYR_CURRENT_LIBRARY} PROPERTIES SOURCES "${_nrf_wifi_sources}")

My Kconfig:

# Add a new choice to the built-in choice list

if WIFI_NRF700X

choice NRF_WIFI_PATCHES_EXT_FLASH_SUPPORT
	bool "Store nRF700x FW patches in external flash"

config NRF_WIFI_PATCHES_CUSTOM_EXT_FLASH_DRIVER
    bool "Use custom external flash loader"

endchoice

endif # WIFI_NRF700X