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.
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.
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.
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.chandler@dti.com.aumailto:allan.chandler@dti.com.au Visit our website www.dti.com.auhttp://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.