1

I need to provide a single update file to a customer in order to update an embedded system via USB. The system is built using Yocto. I'm curious if the plan I have to implement USB updating is viable, or if I'm missing something that should be obvious.

opkg exists on the system, but in order to use opkg update it needs to have a repo to pull from. Since I have no network capabilities I will need to put the entire repo on a USB drive. Since I need to provide a single file to the customer the repo will then need to be a tar file.

Procedure

  1. Plug USB drive in
  2. The udev rule calls a script and pushes it to the background since this will be a long process (see this)
  3. Un-tar the repo update file
  4. opkg update
  5. Notify user they may remove USB drive

At least from a high-level point of view does this sound like it is a good way to update an embedded system via USB? What pitfalls might exist?

Community
  • 1
  • 1
E-rich
  • 9,243
  • 11
  • 48
  • 79
  • create the package (*.ipk) format, instead of *.tar files. Then use `opkg update` – suneet saini Jul 24 '15 at 08:53
  • I have Yocto configured to build `.ipk` packages. What I'm tar'ing is the repository of `.ipk` packages bitbake creates after building an image. The directory I create a `.tar.gz` file of is `tmp/deploy/ipk/` – E-rich Jul 24 '15 at 12:43

3 Answers3

2

Your use case is covered by SWUpdate - it is maybe worth to take a look at my project (github.com/sbabic/swupdate). Upgrading from USB with a single image file is one of the use case, and you can use meta-swupdate (listed on openembedded) to generate the single image with all artifacts.

E-rich
  • 9,243
  • 11
  • 48
  • 79
sbabic
  • 196
  • 1
  • 4
1

Well, regarding what pitfalls might exist, one of the biggest pitfall would likely be a power outage in the middle of the process. How do you recover in that case? (The answer might depend on what type of embedded device your making). (Personally, I'm in favour of complete image based upgrades and not package based upgrades).

Regarding your scenario with the tarball, do you have enough space on your device to unpack out? It might be wiser to instead of distributing a tarball with your opkg repository, to distribute eg a ext2 or squashfs image of the repository. That would allow you to mount it from the USB drive using the loopback device.

Apart from that, as long as you have a good way to communicate work the user, your approach should work. The main issue is what do you do in case of an interrupted upgrade process. That is something you need to think about in advance.

Anders
  • 8,541
  • 1
  • 27
  • 34
0

When deciding on the update format and design there are several things to consider; including what you want to update (e.g. kernel, applications, bootloader); there is a paper on the most popular designs here: https://mender.io/user/pages/04.resources/_white-papers/Software%20Updates.pdf

In your case (no network, lots of storage available on USB) the easiest approach is probably a full rootfs update. I am involved in an open source project Mender.io which does a dual A/B rootfs update and integrates with the Yocto Project to make it easy and fast to enable updates on devices without custom low-level coding.

rduio
  • 36
  • 2