Re: [yocto] RFC: Improving the developer workflow

[Alex J Lennon <ajlennon@dynamicdevices.co.uk>]

[-- Attachment #1: Type: text/plain, Size: 4351 bytes --]


On 09/08/2014 09:13, Mike Looijmans wrote:
> On 08/07/2014 03:05 PM, Paul Eggleton wrote:
>> On Thursday 07 August 2014 11:13:02 Alex J Lennon wrote:
>>> Historically I, and I suspect others, have done full image updates of
>>> the storage medium,  onboard flash or whatever but these images are
>>> getting so big now that I am trying to  move away from that and into
>>> using package feeds for updates to embedded targets.
>>
>> Personally with how fragile package management can end up being, I'm
>> convinced
>> that full-image updates are the way to go for a lot of cases, but
>> ideally with
>> some intelligence so that you only ship the changes (at a filesystem
>> level
>> rather than a package or file level). This ensures that an upgraded
>> image on
>> one device ends up exactly identical to any other device including a
>> newly
>> deployed one. Of course it does assume that you have a read-only
>> rootfs and
>> keep your configuration data / logs / other writeable data on a separate
>> partition or storage medium. However, beyond improvements to support for
>> having a read-only rootfs we haven't really achieved anything in
>> terms of out-
>> of-the-box support for this, mainly due to lack of resources.
>
> Full-image upgrades are probably most seen in "lab" environments,
> where the software is being developed.
>
> Once deployed to customers, who will not be using a build system, the
> system must rely on packages and online updates.
>
> Embedded systems look more like desktops these days.
>
> - End-users will make changes to the system:
>     - "plugins" and other applications.
>     - configuration data
>     - application data (e.g. loggings, EPG data)
> - There is not enough room in the flash for two full images.
> - There is usually a virtually indestructable bootloader that can
> recover even from fully erasing the NAND flash.
> - Flash filesystems are usually NAND. NAND isn't suitable for
> read-only root filesystems, you want to wear-level across the whole
> flash.
>

Agreeing with much you say Mike, I was under the impression that there
are block management layers now which will wear level across partitions?

So you could have your read only partition but still wear levelled
across the NAND ?

> For the OpenPLi settop boxes we've been using "online upgrades" which
> basically just call "opkg update && opkg upgrade" for many years, and
> there's never been a real disaster. The benefits easily outweigh the
> drawbacks.
>
> When considering system upgrades, too much attention is being spent in
> the "corner cases". It's not really a problem if the box is bricked
> when the power fails during an upgrade. As long as there's a procedure
> the end-user can use to recover the system (on most settop boxes,
> debricking the system is just a matter of inserting a USB stick and
> flipping the power switch).
>
>

For us on this latest project - and indeed the past few projects - it is
a major problem (and cost) if the device is bricked. These devices are
not user-maintainable and we'd be sending engineers out around the world
to fix.

Not a good impression to make with the customers either.

Whether we're a usual use case I don't know.

Cheers,

Alex

-- 

Dynamic Devices Ltd <http://www.dynamicdevices.co.uk/>

Alex J Lennon / Director
1 Queensway, Liverpool L22 4RA

mobile: +44 (0)7956 668178

Linkedin <http://www.linkedin.com/in/alexjlennon> Skype
<skype:alexjlennon?add>

This e-mail message may contain confidential or legally privileged
information and is intended only for the use of the intended
recipient(s). Any unauthorized disclosure, dissemination, distribution,
copying or the taking of any action in reliance on the information
herein is prohibited. E-mails are not secure and cannot be guaranteed to
be error free as they can be intercepted, amended, or contain viruses.
Anyone who communicates with us by e-mail is deemed to have accepted
these risks. Company Name is not responsible for errors or omissions in
this message and denies any responsibility for any damage arising from
the use of e-mail. Any opinion and other statement contained in this
message and any attachment are solely those of the author and do not
necessarily represent those of the company.


[-- Attachment #2.1: Type: text/html, Size: 7581 bytes --]

[-- Attachment #2.2: ddlogo-4.png --]
[-- Type: image/png, Size: 3997 bytes --]

[-- Attachment #2.3: linkedin.png --]
[-- Type: image/png, Size: 631 bytes --]

[-- Attachment #2.4: skype.png --]
[-- Type: image/png, Size: 800 bytes --]