Developing and Deploying devices

[David Tillotson]

On 14 April 2016 15:18:43 BST, Dirk Hohndel <dirk at hohndel.org> wrote:
>
>> On Apr 13, 2016, at 11:48 PM, Robert Helling <helling at atdotde.de>
>wrote:
>> 
>> Hi,
>> 
>>> On 14.04.2016, at 08:05, Jeroen Massar <jeroen at massar.ch
><mailto:jeroen at massar.ch>> wrote:
>>> 
>>> Thus in the case of a 'wrong flash', we could have a tool that just
>>> flashes it that way as a way of recovery ;)
>> 
>> I am convinced that “flash the whole thing” should be the default
>upgrade path. The problem is only you cannot do it while running. So
>you need a desktop.
>
>I completely agree, Robert. I want a stateless solution - there is NO
>state kept on the device, no configuration, nothing.
>You want a new version? You flash a new image. Something is wrong, you
>can use the un-brick image from CHIP.
>
>And if we go down the BLE path instead of the wifi hotspot path, I
>believe we can get away with zero state on device...
>
>/D
>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>subsurface mailing list
>subsurface at subsurface-divelog.org
>http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

On a commercial product I worked on in the past, we used a fairly simple solution for field upgrades (although that was an FPGA based system, so it may not be as easy for the likes of the CHIP):
We had 2 effective boot images, a "normal" one, and a "safe" minimal one in the upper half of the address space of the flash store (outside where the system could actually get to normally). The serial interface cable used for upgrades tied the high bit of the flash address high (via a carefully selected resistor - but that's a whole different story).
The "normal" boot image could then be written. The boot image was kept small enough to allow for a config storage at a known address in the upper area of the flash, so that any settings that had been customised were retained.
I'm not entirely sure how easily this could be replicated on these embedded systems - possibly by a simple check for a specific GPIO being tied either high or low, then enabling an "image upgrade" mode.
Unfortunately, I don't have the time for any serious work on this :(
-- 
David Tillotson