Remove bootloader MBR or use UICR

[zilhk]

Hi!

We're using the nRF52810 chip, so we have a very limited amount of flash memory. We're looking at every opportunity to save some space.

We currently run with a modified version of the secure bootloader, SoftDevice S112 and our firmware.


I've noticed that the bootloader is reserving 2 pages of data, one for its settings and one for the MBR parameters (if I understand correctly).

I have a few questions:

1) Is the bootloader MBR parameters page used by the function sd_mbr_command() to store the params member of the sd_mbr_command_t type?

2) If so, is it possible to make it use the UICR since the params use at most 12 bytes? Would this be applicable to the settings page as well? (assuming it can fit in)

3) If we were to decide to never update the SoftDevice and the bootloader, could we configure the bootloader to not have a MBR params page at all? (and saving us 4k of memory)

Thanks in advance for your help!

PS: any other recommendation to save space is welcome :)

[tesc]

Hi,

The MBR params page is used by the Master Boot Record (MBR), which is a small bootloader delivered as part of the SoftDevice. The MBR does not change during DFU, and it is the piece of firmware responsible for copying the DFU bootloader to the final destination during a DFU of the bootloader itself. The MBR does need a flash page for such parameters, in order to function correctly, and writing random data to the MBR params page means either the MBR will erase it, overwrite it, or act (erroneously) based on it.

The MBR params page is used by the bootloader in the sense that the bootloader will write parameters there, instructing the MBR to do flash copy operations.

The MBR params page is also used by the bootloader for backing up the bootloader settings page. This backup is done in a way not interfering with the part of the MBR params page used for communicating operations to the MBR, and not interfering with any other MBR functionality. While possible for the use case of bootloader settings page backup, if done with extreme care and caution, this is not possible for e.g. application data that should be stored for a longer period of time.

The MBR needs to use a full flash page, because flash is erased in full pages only. In order to erase only part of a flash page, it is necessary to first take a backup of all the contents that should be saved (using a second flash page), then erase the fulll flash page, and copy in all the contents that should be saved from the backup. This would involve complexity (that the MBR does not have), and it also means you always need this extra page for storing the backup.

I am afraid that replacing the MBR (and/or its reliance on an MBR params page) is not a trivial task, if at all possible.

Regards,
Terje

[zilhk]

Hi tesc,

Thank you very much for the clarification! Yeah as you say replacing or modifying the MBR is out of reach. Also I now realize that using UICR makes no sense here (still learning about these concepts!).

I'm still seeing some one opportunity to save some space for our use case. Could you give feedback on it?

Assuming we don't need to DFU the bootloader or the SoftDevice but that we still want to keep the ability to DFU the firmware, is it correct to assume that:

* no MBR command will be ever need to be issued
* the bootloader will never try to backup its settings in the MBR params page.

The doc for "sd_mbr_command()" states that if both MBR_PARAM_PAGE_ADDR and MBR_UICR_PARAM_PAGE_ADDR are 0xFFFFFFFF then MBR commands will be unavailable.

Do you think we that setting the MBR param page address to 0xFFFFFFFF would leave us with a working device that can still do DFU of the firmware only?  (note: we use a modify version of the secure bootloader, we could modify it even further if needed to make this work).

Thanks!

[tesc]

Hi,

zilhk said:

is it correct to assume that:

* no MBR command will be ever need to be issued

The MBR parameters page is needed for the SD_MBR_COMMAND_VECTOR_TABLE_BASE_SET (sd_mbr_command_vector_table_base_set_t) and SD_MBR_COMMAND_COPY_BL (sd_mbr_command_copy_bl_t) commands. If you do not use those commands, then having UICR.NRFFW[1] of 0xFFFFFFFF should be fine, yes, and means that you do not need the MBR page for the operation fo the MBR.

zilhk said:

* the bootloader will never try to backup its settings in the MBR params page.

No, that is not correct. The bootloader backs up the settings page whenever it needs to update it, which happens also when changing the application. The bootloader settings page, among other information, stores information such as application version and checksum, which would need to be updated on application update as well.

Before nRF5 SDK v15.2.0, the bootloader did not use the MBR params page for backup. Without the backup, there is a small risk of corrupting the bootloader settings page. Since you are already modifying the bootloader, you could have a look at how this part of the bootloader worked in nRF5 SDK v15.1.0 and earlier, in order to revert the change.

Alternatively (I have not checked) it may be that the bootloader still works when UICR.NRFFW[1] is set to 0xFFFFFFFF, and in this situation does not do the backup. If you are lucky then you don't need to change anything for it to behave the way that you want.

Regards,
Terje