> On Jun 7, 2016, at 10:37 AM, Kevin Townsend <[email protected]> wrote:
> 
> I think I would probably argue as well that the bootloader should be able to 
> run completely independent with no user image flashed, with the ability to 
> flash a first image over serial, but that's just my own opinion and biased 
> expectations in a bootloader.  Obviously, I'm curious to hear what everyone 
> else thinks!
> 
> There should perhaps also be an options for a fail-safe mechanism to boot 
> into 'bootloader only' mode (polling a pin at startup) where no firmware is 
> executed, but you can still talk to the bootloader via the 'newtmgr' tool to 
> flash an image, etc.
> 
> BLE complicates things, but keeping 'serial' as a baseline in the core 
> bootloader image should add a great deal more resilience to mynewt devices, 
> particularly if you're devices cost several hundreds dollars per unit and 
> aren't just say $30 nodes that you can pull out and replace.
> 

IMHO, image upgrade over serial with bootloader only is handy during 
manufacturing.
Not so much during development (JTAG instead), or when devices are in the field.
Users would much rather not deal with cables during update process :)
Therefore, I think making update process as fault proof with hands-off from end 
user
will be key.

There’s options with this; the one that’s present now is built around the 
concept of having
2 bootable images in flash. If one of them fails to boot, system will revert to 
2nd one.
Obvious downside with this one is that it requires you to spend quite a bit of 
your flash space
for the fall-back image.

2nd option would be to have updates happen with bootloader (or 2nd smaller app) 
which
only deals with image update over serial/bluetooth/others. Downsides include 
that the
system will not be doing it’s actual work when update is in process, 
interruptions during
update will yield a system which will not boot and so on. Upside is that there 
should be
more flash available for the actual app.

I think the first approach allows you to build more fault-proof system, but it 
is more
expensive hardware-wise. Therefore, it’s not a one-size-fits-all. We should 
have other
options available.
—
M

Reply via email to