On 13.11.2018 20:53, Simon Glass wrote:
Hi Allan,
On 12 November 2018 at 18:38, Allan Chandler <allan.chand...@dti.com.au> wrote:
Hello, bods.
We're trying to architect a relatively safe solution for updating UBoot in the
field. What we have at the moment is an iMX6-based board with two UBoot
partitions and two system partitions but we only use the first UBoot one.
Switching system partitions is covered well by UBoot since we use what seems
like a fairly standard method involving upgrade_available, bootlimit and
bootcount variables, along with bootcmd/altbootcmd scripts to try and load a
new system partition while falling back if it fails.
However, I'm wondering how people handle the need to update UBoot itself.
Although this will happen FAR less often than normal software updates, these
product have a multi-decade lifespan and it's hard to imagine we'll get through
that without some update being needed. Especially since we need one now (three
years in) due to a bug (with our added stuff, not UBoot baseline). With the
iMX6 boards we have, once we tell it to start using the second UBoot partition,
there's no UBoot/watchdog combo that will revert that change and reprogramming
requires a rather expensive RTB (return to base) to fix via the serial
interface.
What we had hoped to do was to be able to soft-boot an alternate UBoot (i.e.,
without first telling the iMX6 board to commit to the change). The scenario
would go like this:
1/ Have an installer package (it runs under control of the system partition)
that just writes the new UBoot image into the alternate UBoot partition then
soft-boots it somehow (so now running same system partition but started from
the new UBoot image).
2/ While running from the system partition started from that alternate UBoot
partition, have an updater package that tells the iMX6 board to commit to the
changeover. This updater package would only run if it detected that the
bootable UBoot and currently-used UBoot were different.
The advantage of this is that, unless the new UBoot is FULLY capable of running
our system partition (and also running an installer from there), no commit is
possible, hence a simple power cycle would return to the previous working state.
We originally tried kexec from the system partition but it seemed to want to
run a Linux kernel rather than loading and executing some arbitrary boot code.
So we then turned to the UBoot scripts themselves and thought we'd found a way
we could do it.
1/ We changed the mmcboot script by prefixing a special check and introduced a
variable for handling soft-boot:
mmcboot=run check_uboot; <rest of original mmcboot>
other_uboot=0
2/ We extracted the boot image uboot.bootimg from the IMX file by stripping off
the first 0xc00 bytes (we had to put this into the /boot file system since I
don't yet know how to get at raw partition data from UBoot scripts.
3/ We defined check_uboot as:
if test ${other_uboot} -eq 1; then
setenv other_uboot 0
saveenv
ext4load mmc ${mmcdev}:${mmcpart} 0x17800000
/boot/uboot.bootimg
go 0x17800000
fi
The way this should work is that, if alternate boot is flagged, it immediately
unflags it (for recovery if the alternate fails) then loads and executes the
other UBoot image. If it's not flagged, check_uboot will return without trying
to soft-boot the alternate.
4/ After installing the new UBoot to the alternate partition, we set a UBoot
variable (other_uboot) to 1 and rebooted.
Now this seemed to work inasmuch as the alternate UBoot program started pumping
out console messages but, unfortunately, it seemed to hang partway through the
boot process.
I suspect this is because, having already been through a portion of that boot
process in the primary UBoot, it's not keen on having to do it again.
You may need to flush the cache area that you read into, or use
'dcache off' before jumping to the second U-Boot.
So I guess my questions are as follows:
a/ How do people currently handle (if they do) the requirement that UBoot be
safely updatable in the field?
b/ Does anyone have any ideas on how I could achieve this?
I've been told that Google does something like this for Android booting but had
to heavily modify UBoot to do it. I haven't yet investigated this possibility.
Chromium OS and Android verified boot (which is in mainline - see avb)
use an A/B system. You can have SPL chosen whether to boot from A or
B.
I'm actually working on integrating Chromium OS vboot into U-Boot
again. It uses TPL to select the SPL to use, which then boots into
UBoot proper. This is so we can update the SDRAM code. Am hoping to
have something going in January although a lot of the required patches
have been sent.
That sounds interesting, but would it be safe to use TPL from 2019 and
letting it boot a, say, 2025 SPL + U-Boot? I don't have experience with
TPL, can it check signatures for secure boot? I'd suspect Chromium OS
would need that?
Simon
Also, we actually do quite a bit of checking to ensure the image we install is
correctly written to the UBoot partition - it has an MD5 distributed with the
package and a mismatch will prevent activation. It also checks certain other
things like version info and a tag at the end of the partition to ensure the
write was complete. So it may be we're just being too paranoid here. If so, let
me know, I'm sure I could convince the customer with some cogent arguments.
You really need to sign it so you can send updated U-Boot versions and
the device in the field can verified the U-Boot image in the field.
Regards,
Simon
Cheers,
Pax
Allan Chandler | Software Engineer
DTI Group Ltd | Integrated Transit Technologies
31 Affleck Road, Perth Airport, WA 6105, Australia
P +61 8 9373 2905, 182 | F +61 8 9479 1190 |
allan.chand...@dti.com.au<mailto:allan.chand...@dti.com.au>
Visit our website www.dti.com.au<http://www.dti.com.au>
The information contained in this email is confidential. If you receive this
email in error, please inform DTI Group Ltd via the above contact details. If
you are not the intended recipient, you may not use or disclose the information
contained in this email or attachments.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
