On 14 April 2016 15:18:43 BST, Dirk Hohndel <d...@hohndel.org> wrote:
>
>> On Apr 13, 2016, at 11:48 PM, Robert Helling <hell...@atdotde.de>
>wrote:
>> 
>> Hi,
>> 
>>> On 14.04.2016, at 08:05, Jeroen Massar <jer...@massar.ch
><mailto:jer...@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@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
_______________________________________________
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Reply via email to