Adding USB capability to secure DFU BLE bootloader

Hi,

The open USB bootloader have everything needed to be a secure bootloader (and in fact by default it do require signature on bootloader updates). The only change that is needed in order to also require signature verification on application and SoftDevice updates is to set NRF_DFU_REQUIRE_SIGNED_APP_UPDATE to 1 in the bootlaoder's sdk_config.h. So if all you need is the USB transport, then take the example and make this change.

If you want to combine USB with BLE, then you should take one of the examples and add includes, configuration, etc from the other, as well as adjust size and start address (there are quite a few things to resolve so it is a bit of work but not a huge task). Essentially all you need to add a transport is to add the required files, and then it will automatically be initialized and work out of the box. You do not need to do anything else to support for the USB CDC, as that is all part of the USB transport implementation.

Hi,

To get a combined USB + BLE DFU secure bootloader, I took the USB example as a baseline and merged sdk_config.h, the Makefile, and the linker script from the BLE example. However, it looks like there are conflicts in the linker script and there's not enough room in Flash:

_build/nrf52840_xxaa.out section `.text' will not fit in region `FLASH'
region FLASH overflowed with .data and user data
section .mbr_params_page VMA [00000000000fe000,00000000000fefff] overlaps section .text VMA [00000000000f4000,00000000000fe077]
section .crypto_data VMA [00000000000fe078,00000000000fe07f] overlaps section .mbr_params_page VMA [00000000000fe000,00000000000fefff]
region `FLASH' overflowed by 284 bytes

Could you advise on how the best way to resolve these issues? What's the best way to attach the resulting sdk_config.h, Makefile, and linker script, so you can better assist?

Hi,

EvDog said:

1. -DMBR_PRESENT is defined in pca10056_usb - does this also need to be defined in pca10056_s140_ble_usb?

 No. For BLE project you should have -DSOFTDEVICE_PRESENT (and the SoftDevice includes the MBR).

EvDog said:

2. How to I work out the adjustments required to the linker script?

For size you should adjust the flash start address of your bootloader down (lower number) and the size up with some pages until it fits. Note that the start address must be a multiple of the page size (0x1000). The easiest way is to move it significantly down (so that it will certainly fit, check the size of the bootloader you built), and then potentially move the start address up again. Note that there should be two unused pages at the end of the flash, after the end of the bootloader, which is used for MBR params and bootloader settings.

Regarding RAM that depends on the SoftDevice configuration. Here the approach is a bit different. If you change the SoftDevice configuration so that it's RAM usage increases, you must increase the RAM start address of the bootloader and decrease the size. See Adjustment of RAM and Flash memory for details.

Hi Einar,

How to I determine the size of the bootloader?  If I adjust the start and length so it builds and links I get

Linking target: _build/nrf52840_xxaa_s140.out
   text    data     bss     dec     hex filename
  41008     200   29404   70612   113d4 _build/nrf52840_xxaa_s140.out

Regarding the two empty pages, is that saying that flash start + length must be at least two pages lower than the total flash available?

So for a nRF52840 the max address is 0x10000 so the bootloader must end at 0xFE000 (0x10000 - 0x2000)? 

MEMORY
{
  FLASH (rx) : ORIGIN = 0xF3000, LENGTH = 0xFE000-0xF3000
  RAM (rwx) :  ORIGIN = 0x20005978, LENGTH = 0x3a688
  uicr_bootloader_start_address (r) : ORIGIN = 0x10001014, LENGTH = 0x4
  bootloader_settings_page (r) : ORIGIN = 0x000FF000, LENGTH = 0x1000
  uicr_mbr_params_page (r) : ORIGIN = 0x10001018, LENGTH = 0x4
  mbr_params_page (r) : ORIGIN = 0x000FE000, LENGTH = 0x1000
}

And regarding RAM, since I have not modified the base BLE example, does this mean RAM is unchanged?

Hi,

EvDog said:

How to I determine the size of the bootloader?

You can often see it by the output of your IDE/toolchain, but the simplest is probably to take the hex file and add it to nRF Connect Programmer. Then you can easily see where it ends. (It might show up a multiple regions, then take the last/highest address of the last/highest region. The sizes is then the end address - start address).

EvDog said:

Regarding the two empty pages, is that saying that flash start + length must be at least two pages lower than the total flash available?

Yes, correct.

EvDog said:

So for a nRF52840 the max address is 0x10000 so the bootloader must end at 0xFE000

Yes, it must end before 0xFE000.

EvDog said:

And regarding RAM, since I have not modified the base BLE example, does this mean RAM is unchanged?

Yes, that is correct. It will not change in this case.

OK thanks.  nRF connect reports 41200 bytes, so if I use

MEMORY
{
  FLASH (rx) : ORIGIN = 0xF3000, LENGTH = 0xA0F0
  RAM (rwx) :  ORIGIN = 0x20005978, LENGTH = 0x3a688
  uicr_bootloader_start_address (r) : ORIGIN = 0x10001014, LENGTH = 0x4
  bootloader_settings_page (r) : ORIGIN = 0x000FF000, LENGTH = 0x1000
  uicr_mbr_params_page (r) : ORIGIN = 0x10001018, LENGTH = 0x4
  mbr_params_page (r) : ORIGIN = 0x000FE000, LENGTH = 0x1000
}

it compiles and links.  I will test tomorrow and provide a finalised patch.

OK thanks.  nRF connect reports 41200 bytes, so if I use

MEMORY
{
  FLASH (rx) : ORIGIN = 0xF3000, LENGTH = 0xA0F0
  RAM (rwx) :  ORIGIN = 0x20005978, LENGTH = 0x3a688
  uicr_bootloader_start_address (r) : ORIGIN = 0x10001014, LENGTH = 0x4
  bootloader_settings_page (r) : ORIGIN = 0x000FF000, LENGTH = 0x1000
  uicr_mbr_params_page (r) : ORIGIN = 0x10001018, LENGTH = 0x4
  mbr_params_page (r) : ORIGIN = 0x000FE000, LENGTH = 0x1000
}

it compiles and links.  I will test tomorrow and provide a finalised patch.