UF2 Image and Bootloader

I am using Windows 11, NCS v2, VSCode extension, under WSL2.

What I want to do is build a UF2 image of my zephyr application and be able to drag/drop it onto a bootloader which supports UF2.

I have looked and I see there are a number of Kconfig parameters which seem to reference this functionality, but I can't figure out what combination of settings and values to use.

I'm familiar that Adafruit has a bootloader (link) which supports UF2, and works on the nrf52840 feather, which I am using.

I can directly flash the Adafruit UF2 bootloader using my jlink programmer.  I can also build zephyr applications and flash them through the vscode extension with jlink.

Specifically what I want to accomplish is:

  • Take an application which I can normally directly flash to the board (any sample or other application)
  • Make changes to the prj.conf file
  • Ultimately end up with a UF2 file I can drag/drop onto the USB drive presented by a UF2 bootloader, adafruit or otherwise, but initially adafruit

A number of Kconfig parameters explicitly name UF2 and Adafruit UF2 bootloaders.  Is the Adafruit UF2 bootloader expected to work for zephyr applications with the right build configuration?

Below I reference a number of the parameters I have seen and played with unsuccessfully, but I may be missing more.  I could really use a working example if there is one.

CONFIG_BUILD_OUTPUT_UF2 - allows automatic building of a zephyr.uf2 file in the build directory.  I enabled this, should I?  I do see zephyr.uf2 produced as part of the build.

CONFIG_BOOTLOADER_BOSSA - Select the Adafruit UF2 variant of the BOSSA bootloader - not sure what this does.  Should I set this?

CONFIG_BOOTLOADER_BOSSA_ADAFRUIT_UF2 - "Select the Adafruit UF2 variant of the BOSSA bootloader"  Not really sure what this does.  Should I set this?

CONFIG_BUILD_OUTPUT_UF2_FAMILY_ID - "UF2 bootloaders only accept UF2 files with a matching family ID"  For the nRF52840, I believe the right value is "0xADA52840".  I think I should set this.

CONFIG_ROM_START_OFFSET - If the application is built for chain-loading by a bootloader this variable is required to be set to value that leaves sufficient space between the beginning of the image and the start of the first section to store an image header or any other metadata. In the particular case of the MCUboot bootloader this reserves enough space to store the image header, which should also meet vector table alignment requirements on most ARM targets, although some targets may require smaller or larger values.  Would I need to set this?  To what?

CONFIG_FLASH_LOAD_OFFSET -  This option specifies the byte offset from the beginning of flash that the kernel should be loaded into. Changing this value from zero will affect the Zephyr image's link, and will decrease the total amount of flash available for use by application code. If unsure, leave at the default value 0.  Should I set this to some offset from 0 to give space to the bootloader?
CONFIG_FLASH_LOAD_SIZE - If non-zero, this option specifies the size, in bytes, of the flash area that the Zephyr image will be allowed to occupy. If zero, the image will be able to occupy from the FLASH_LOAD_OFFSET to the end of the device. If unsure, leave at the default value 0.  I guess set to 0?
CONFIG_BOOTLOADER_MCUBOOT -  This option signifies that the target uses MCUboot as a bootloader, or in other words that the image is to be chain-loaded by MCUboot. This sets several required build system and Device Tree options in order for the image generated to be bootable using the MCUboot open source bootloader. Currently this includes: * Setting ROM_START_OFFSET to a default value that allows space for the MCUboot image header * Activating SW_VECTOR_RELAY_CLIENT on Cortex-M0 (or Armv8-M baseline) targets with no built-in vector relocation mechanisms By default, this option instructs Zephyr to initialize the core architecture HW registers during boot, when this is supported by the application. This removes the need by MCUboot to reset the core registers' state itself.  Should I set this, or no?  Would I need SW_VECTOR_RELAY_CLIENT set if using a UF2 bootloader?
 
I could use a guide or explanation of how this is all meant to work to put this together.
The UF2 bootloaders are clearly the future (the present, really).  This needs to work for any reasonable user-facing product offering with upgradable firmware.

Thanks.