<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 09/08/2014 09:13, Mike Looijmans
wrote:<br>
</div>
<blockquote cite="mid:53E5D844.2050909@topic.nl" type="cite">On
08/07/2014 03:05 PM, Paul Eggleton wrote:
<br>
<blockquote type="cite">On Thursday 07 August 2014 11:13:02 Alex J
Lennon wrote:
<br>
<blockquote type="cite">Historically I, and I suspect others,
have done full image updates of
<br>
the storage medium, onboard flash or whatever but these
images are
<br>
getting so big now that I am trying to move away from that
and into
<br>
using package feeds for updates to embedded targets.
<br>
</blockquote>
<br>
Personally with how fragile package management can end up being,
I'm convinced
<br>
that full-image updates are the way to go for a lot of cases,
but ideally with
<br>
some intelligence so that you only ship the changes (at a
filesystem level
<br>
rather than a package or file level). This ensures that an
upgraded image on
<br>
one device ends up exactly identical to any other device
including a newly
<br>
deployed one. Of course it does assume that you have a read-only
rootfs and
<br>
keep your configuration data / logs / other writeable data on a
separate
<br>
partition or storage medium. However, beyond improvements to
support for
<br>
having a read-only rootfs we haven't really achieved anything in
terms of out-
<br>
of-the-box support for this, mainly due to lack of resources.
<br>
</blockquote>
<br>
Full-image upgrades are probably most seen in "lab" environments,
where the software is being developed.
<br>
<br>
Once deployed to customers, who will not be using a build system,
the system must rely on packages and online updates.
<br>
<br>
Embedded systems look more like desktops these days.
<br>
<br>
- End-users will make changes to the system:
<br>
- "plugins" and other applications.
<br>
- configuration data
<br>
- application data (e.g. loggings, EPG data)
<br>
- There is not enough room in the flash for two full images.
<br>
- There is usually a virtually indestructable bootloader that can
recover even from fully erasing the NAND flash.
<br>
- Flash filesystems are usually NAND. NAND isn't suitable for
read-only root filesystems, you want to wear-level across the
whole flash.
<br>
<br>
</blockquote>
<br>
Agreeing with much you say Mike, I was under the impression that
there are block management layers now which will wear level across
partitions?<br>
<br>
So you could have your read only partition but still wear levelled
across the NAND ?<br>
<br>
<blockquote cite="mid:53E5D844.2050909@topic.nl" type="cite">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.
<br>
<br>
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).
<br>
<br>
<br>
</blockquote>
<br>
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. <br>
<br>
Not a good impression to make with the customers either.<br>
<br>
Whether we're a usual use case I don't know.<br>
<br>
Cheers,<br>
<br>
Alex<br>
<br>
<div class="moz-signature">-- <br>
<div class="preview">
<p style="font-family: Helvetica, Arial, sans-serif; font-size:
10px; line-height: 12px;"><a
href="http://www.dynamicdevices.co.uk/" class="clink"><img
src="cid:part1.01010906.03000201@dynamicdevices.co.uk"
alt="Dynamic Devices Ltd" id="sig-logo" border="0"></a></p>
<p style="font-family: Helvetica, Arial, sans-serif; font-size:
10px; line-height: 12px; color: rgb(153, 153, 153);"><span
id="name-input" style="font-weight: bold;" class="txt">Alex
J Lennon</span> <span id="title-sep">/</span> <span
id="title-input" style="color: #999;" class="txt">Director</span><br>
<span id="address-input" style="color: #999;" class="txt">1
Queensway, Liverpool L22 4RA</span> </p>
<p style="font-family: Helvetica, Arial, sans-serif; font-size:
10px; line-height: 12px;"> <span id="mobile-input"
style="color: #999;" class="txt">mobile: +44 (0)7956 668178</span>
<br>
<br>
</p>
<p style="font-size: 10px; line-height: 12px; font-family:
Helvetica, Arial, sans-serif"> <a id="linkedin-input"
class="social" href="http://www.linkedin.com/in/alexjlennon"><img
src="cid:part3.02030500.03010103@dynamicdevices.co.uk"
alt="Linkedin"></a> <a id="skype-input" class="social"
href="skype:alexjlennon?add"><img
src="cid:part5.09060608.08060800@dynamicdevices.co.uk"
alt="Skype"></a></p>
<p id="disclaimer-input" style="font-family: Helvetica, Arial,
sans-serif; color: rgb(153, 153, 153); font-size: 9px;
line-height: 12px;width: 25%" class="txt">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.</p>
</div>
</div>
</body>
</html>