[U-Boot] UBoot running UBoot - is it possible?

[Simon Glass]

Hi Simon,

On 13 November 2018 at 12:17, Simon Goldschmidt
<simon.k.r.goldschmidt at gmail.com> wrote:
> On 13.11.2018 20:53, Simon Glass wrote:
>>
>> Hi Allan,
>>
>> On 12 November 2018 at 18:38, Allan Chandler <allan.chandler at 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?

This needs to be tested with each build.

The bloblist feature is designed to handle this, although it is update
to individual users to include version info at present. It should land
in the next release.

Regards,
Simon