Bootloader overlapping MBR params page, should we worry?

RE: Bootloader overlapping MBR params page, should we worry?

Susheel Nuguru — Wed, 26 Sep 2018 10:23:19 GMT

I do not think that there is much fat to cut there in bootloader templates that we provide.

Yes, you are correct, uECC is needed for secure bootloader to decrypt the signatures.

RE: Bootloader overlapping MBR params page, should we worry?

Susheel Nuguru — Wed, 26 Sep 2018 10:21:12 GMT

Hi Duncan,

I checked the code and to answer your question, it does not erase MBA param page when you are uploading a smaller bootloader (replacing your oversized one). So this should work fine.

RE: Bootloader overlapping MBR params page, should we worry?

dmf3030 — Tue, 25 Sep 2018 20:32:39 GMT

Another related question would be whether the stock 14.2 SDK bootloader has any code that can be cut to reduce the compile size so that I could still squeeze in the extra 2k of code I need to run an oled with my bootloader. In stepping through the memory usage I don't see much fat to cut, we're not using any of the bsp code but mainly I'm seeing the uECC library taking up space and I expect theres not really anything to omit there.

RE: Bootloader overlapping MBR params page, should we worry?

dmf3030 — Tue, 25 Sep 2018 12:28:27 GMT

Aryan, thanks for the help & info!

Seems like our safest course of action is to flash the revised bootloader that correctly fits in the alotted memory. We have done this updated repeatedly over our old "too large" bootloader without any issue. We have then moved along to update the application and found no problems. I did find it odd that flashing the bootloader did not erase our application like I expected. I did not think we had enough free space for a dual bank bootloader update since we have a large chunk reserved for FDS storage. Maybe if those pages are not used yet then they can be used for the update, that or we have a bit more memory than I expected and dual bank is possible. I'm also a bit paranoid here butI feel like the best route is to flash the new bootloader while we have the units in hand and can ensure that everything goes well.

The other option is to let the units get into the wild with the "too large" bootloader which obviously does not have the problem with 0xAA at the magic spot in the MBR page since it works for now. Seems like if the units are currently working theres no reason they should suddenly develop an issue where 0xAA ends up in the wrong spot, but this still makes me nervous and I don't like the idea of the questionable bootloader update ever happening in the wild.

Q: So with the assumption that we will be updating the bootloader to be the correct size, my only question is about what happens to the old bootloader code that overlapped into the MBR. When we flash the smaller bootloader it presumably erases the bootloader memory bank but I would doubt it erases the MBR page, (though if it wrote there then maybe its happy to erase into it too). So after our bootloader update there could still be old bits of code in the MBR, but if I understand correctly the worst thing that can happen is that code eventually causes a bad CRC in the MBR params page which just leads to it getting erased and a system reset. After that we would be all good with no signs of the mistake and a clean MBR page. I'm not sure how the MBR is used for a soft device or bootloader update, could that bad MBR checksum happen after we have sent over a new soft device and cause a bad update? When does the NRF deliberately write that 0xAA value to the MBR params page, seems like the first time that happens we would have a problem unless prior to writing it the page is erased by the NRF.

Thanks!

RE: Bootloader overlapping MBR params page, should we worry?

Susheel Nuguru — Tue, 25 Sep 2018 10:42:42 GMT

Hi Duncan,

1) Your assumptions are correct about when the MBR params page is being used. You app updates would work fine even with the overlap. But I think that BL/SD update will be risky (unpredictable) with an overlapping bootloader into MBR params page. I would caution you with one more thing.

When the system is booting up, the first thing that is run is the MBR reset handler.
In the MBR reset handler, MBR param page is sniffed to see if there is a valid header at ((NRF_UICR->NRFFW[1]) + 5). If this value is 0xAA by coincidence from the overflow of your bootloader then the MBR reset handler would think that this is a valid page and do a CRC check on the rest of the MBR params page. If the CRC check fails, then it would erase the params page and do a system reset. You would not like this as this will erase part of your bootloader. So make sure that the given offset never contains 0xAA.

2) If you try to upload the bootloader first then it would try to reinitialize the MBR param page (which is OK as you do not care about the old bootloader being overwritten) I am still a bit paranoid here, but seems like it should work. Never tried it though