05-05-2020, 06:09 AM
(05-04-2020, 11:58 AM)JF002 Wrote: The softdevice is really complex, and, as far as I understand, relies on a MBR located at 0x0. This MBR forwards the IRQ to the softdevice or the applications according to the state of the softdevice. I don't know if it does anything else.
I also don't know how to deal with this in a universal bootloader? Is it possible to chain the MBR with a custom bootloader, the softdevice and the application?
I think the trick needed it to replace the MBR with our own (I called this the vector table in my last post). There a blog post that gives some strong clues about how to do that: https://aykevl.nl/2018/01/mbr-softdevice-internals . For initial development to enable open source BLE stacks I think it can simply update the vector table to adopt mcuboot at the end of internal flash and be done.
Other than that all that is required is to arrange for the softdevice to fit, alongside the application that uses it, within the main application slot so that the softdevice can work when it is copied here.
In other words.
Code:
Internal flash:
0x00000000 FreeMBR 4k
0x00001000 Application slot 492k
0x0007C000 mcuboot 16k
SPI flash:
Update slot 492k
Recovery slot 492k
Scratch 4k (may be better in internal flash before bootloader
File system Rest of SPI flash?A softdevice application would come as a single binary with the SD and application merged together...
PS Above a recovery slot is also proposed. This is used to avoid bricking when both application and update slots do not contain a working application (for example if both crashed before bringing up OTA update suppport due to something recently added to the file system then it would be hard to recover so the recovery slot allows us to have a "simple" BLE OTA update program that can be deployed in emergencies.