[Buildroot] designing a firmware update mechanism

[Buildroot] designing a firmware update mechanism

[John Stile]

I use buildroot for an embedded project, which has an atmel arm
processor, at91BootStrap on NOR to call uboot (and the reset of the
system) on NAND.

I am trying to devise a brick-safe strategy to update the systems once
created, but I'm making this up as I go for a lack of better ideas.

So far I am trying to split NAND in redundant halves (each with a copy
of uboot + uboot-env + kernel + roofs), and modify at91bootstrap to
choose which uboot to load, based on something inside the uboot-env
areas.

Will I need to compile 2 versions of uboot, differing only in where to
look for the uboot-env, or is there another way?  If so, is there a way
to do this within buildroot, or does uboot need to become an external
project from my buildroot setup?

Could anyone share a firmware update strategy for a project that uses
buildroot, at91bootstrap, and uboot, or is that outside the scope of
this list?

I have not found any built-in mechanisms to handle updates.

[Buildroot] designing a firmware update mechanism

[Jérôme Pouiller]

On Thursday 17 January 2013 14:09:33 John Stile wrote:
[...]
> So far I am trying to split NAND in redundant halves (each with a copy
> of uboot + uboot-env + kernel + roofs), and modify at91bootstrap to
> choose which uboot to load, based on something inside the uboot-env
> areas.
> 
> Will I need to compile 2 versions of uboot, differing only in where to
> look for the uboot-env, or is there another way?  
Two different version of firmware does not looks a good idea. at91bootstrap 
knows which copy of uboot is started/I suggest to find a way to pass this 
information to uboot. With this information, uboot know which uboot-env to 
use.

[...]

-- 
J?r?me Pouiller

[Buildroot] designing a firmware update mechanism

[Peter Korsgaard]

>>>>> "John" == John Stile <john@stilen.com> writes:

Hi,

 John> So far I am trying to split NAND in redundant halves (each with a copy
 John> of uboot + uboot-env + kernel + roofs), and modify at91bootstrap to
 John> choose which uboot to load, based on something inside the uboot-env
 John> areas.

 John> Will I need to compile 2 versions of uboot, differing only in where to
 John> look for the uboot-env, or is there another way?  If so, is there a way
 John> to do this within buildroot, or does uboot need to become an external
 John> project from my buildroot setup?

 John> Could anyone share a firmware update strategy for a project that uses
 John> buildroot, at91bootstrap, and uboot, or is that outside the scope of
 John> this list?

I would suggest you use something simpler than the u-boot environment
(as you would have to extend at91bootstrap to be able to read &
understand it to figure out what u-boot to load).

I have in the past done something similar, just with everything in NOR
flash. At91bootstrap is in the first flash sector and never updated in
the field. Everything after that is doubled, and at91bootstrap figures
out what u-boot to load, which in turn figures out to load the correct
kernel / use the correct rootfs.

As indicator to at91bootstrap about which part it should load (low/high)
I used the unused flash sector in the upper half of the flash
(E.G. where the 2nd copy of at91bootstrap would have been if it would
have been stored double) as that's very simple to read.

A little ascii art probably helps:

flash sector       part
0                  at91bootstrap
1                  u-boot low
..                 u-boot environment low
..                 linux low
..                 rootfs low

n/2                low/high boot marker
n/2 + 1            u-boot high
..                 u-boot environment high
..                 linux high
..                 rootfs high

As an extension, at91bootstrap also starts the watchdog with a long
timeout (~16s on at91). This is used as kind of a 'bootup watchdog' for
extra safety. The software will only kick the watchdog once it is
completely booted, so if the watchdog ever fires we know the system
couldn't boot. It is simple to check for this condition in at91bootstrap
(register in reset controller), and I simply revert to the other half of
the flash in that case.

Finally the choice of what part has been selected is stored somewhere
that U-Boot can easily read it (In my implementation I used GPB3, but a
location in SRAM could be used as well).

U-Boot then reads this value and uses it to select what kernel/rootfs
to use.

The low/high boot marker is simply the first byte in the flash
sector. If it is equal to 0xff (E.G. erased), the low U-boot is used,
otherwise the high one. During upgrade (once the unused part of the
flash has been updated) I simply run something like this before rebooting:

#!/bin/sh
# Toggle high/low boot mode for at91bootstrap (bootstrap_mark erased or not)

set -e

# lookup mtd name and return /dev/mtdX
mtd_name_to_dev()
{
        awk -v FS=: "/\"$1\"\$/ { print \"/dev/\" \$1 }" /proc/mtd
}

dev=$(mtd_name_to_dev "bootstrap_mark")

# partition currently erased?
if dd if=$dev bs=1 count=1 2>/dev/null | hexdump -C | grep -q ff;
then
    dd if=/dev/zero of=$dev bs=2 count=1 2>/dev/null
else
    flash_eraseall -q $dev
fi

-- 
Bye, Peter Korsgaard

[Buildroot] designing a firmware update mechanism

[Arnout Vandecappelle]

On 01/17/13 23:09, John Stile wrote:
> I use buildroot for an embedded project, which has an atmel arm
> processor, at91BootStrap on NOR to call uboot (and the reset of the
> system) on NAND.
>
> I am trying to devise a brick-safe strategy to update the systems once
> created, but I'm making this up as I go for a lack of better ideas.
>
> So far I am trying to split NAND in redundant halves (each with a copy
> of uboot + uboot-env + kernel + roofs), and modify at91bootstrap to
> choose which uboot to load, based on something inside the uboot-env
> areas.

  Do you really need U-Boot itself to be upgradeable? If not, you can put 
U-Boot and its environment in NOR. That gives you U-Boot scripting to 
choose an appropriate kernel+rootfs, it allows you to use a bootcounter 
to fall back on the other kernel when it is resetting all the time (due 
to watchdog), it allows you to detect failed upgrades (CRC check fails), 
it allows you to put everything in UBI volumes (if you need the wear 
levelling and bit scrubbing), etc.

> Will I need to compile 2 versions of uboot, differing only in where to
> look for the uboot-env, or is there another way?  If so, is there a way
> to do this within buildroot, or does uboot need to become an external
> project from my buildroot setup?

  As Peter wrote, you don't need to (but then you have to hack U-Boot). 
If you do want to build two versions of U-Boot, it's not that hard:

make BR2_TARGET_UBOOT_BOARDNAME=myboard_p1 uboot
mv output/images/u-boot.img output/images/u-boot.myboard_p1.img
make BR2_TARGET_UBOOT_BOARDNAME=myboard_p2 uboot
mv output/images/u-boot.img output/images/u-boot.myboard_p2.img


> Could anyone share a firmware update strategy for a project that uses
> buildroot, at91bootstrap, and uboot, or is that outside the scope of
> this list?
>
> I have not found any built-in mechanisms to handle updates.

  I started on a project that collects the best practices of firmware 
updates, but I haven't made much progress up to now :-(

  Regards,
  Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F