Hi Jacob,
On Sun, Jan 01, 2017 at 11:10:01PM -0700, Jacob Rosenthal wrote:
> On low flash devices like nrf51822 FLASH_AREA_IMAGE_1 equal to
> FLASH_AREA_IMAGE_0 is improbable, which means dual bank is likewise
> improbable and as a result we've talked previously about how to shrink
> FLASH_AREA_IMAGE_1 down to a stub.
>
> However, my current understanding is newtmgr/imagemgr implementation is
> dual bank, wherein the application saves received bytes into
> COREDUMP_FLASH_AREA (ie FLASH_AREA_IMAGE_1) and reboots allowing bootloader
> (apps/boot) to safely make the swap.
Your understanding sounds correct to me. If you don't have enough flash
for a second image slot, then image upgrade isn't possible.
Just a clarification- for a split image, both slots don't need to be
exactly the same size; the slot sizes just need to meet these
requirements:
* Both slots are large enough to accommodate the loader.
* Second slot is large enough to accommodate the app.
In other words, if your app is larger than your loader, you only need to
budget for the extra space in the second slot. Unfortunately, I don't
think this allowance helps in your case. I think the problem you're
facing is that the loader (kernel + BLE stack) is too large.
> I don't believe theres a good way to do a single bank receive from within
> the running application, which would mean this has to be moved into the
> bootloader, which means it need to share access to nimble, which means a
> bootloader fork that includes splitty, nimble, newtmgr, imagemgr.
>
> Im somewhat unclear if the 'loader' app can/should also serve as the
> 'bootloader', or if it was intended that a separate bootloader would also
> be present in addition to loader and application?
>
> Thoughts on this architecture, am I missing anything?
Hmm... I do see what you mean, but that sounds like a pretty fundamental
change to how image management works. I'm also not sure if it would buy
you much extra flash space. The boot loader is already fairly stripped
down, and it doesn't contain much code that could be shared by the image
upgrade mechanism.
I don't want to be dismissive of your idea, but my thinking is that the
best way forward is to try to reduce the size of the BLE stack. This is
something that has been on the radar for quite a while. We haven't
really looked at this at all, so there is probably some easy savings to
be had. I have been meaning to do a quick survey of the BLE host to
determine what is contributing to its code size. That said, if you want
to look at incorporating upgrade functionality into the boot loader,
don't let me stop you :).
Do you know how big your loader is currently?
Thanks,
Chris
