failsafe update of bootloader on am335x

[Rasmus Villemoes]

On Wed, Jun 18 2025, Tom Rini <trini at konsulko.com> wrote:

> On Wed, Jun 18, 2025 at 02:07:11PM +0200, Rasmus Villemoes wrote:
>> Hi,
>> 
>> I'm looking at the am335x cpu, and have a few questions that I hope the
>> community can answer:
>> 
>> (1) It seems that the ROM code does not support booting from eMMC boot
>> partitions; I can't find anything about it in the reference manual, and
>> this ancient thread suggests that it indeed not supported:
>> 
>>   https://u-boot.denx.narkive.com/S8U7Z3Wr/dra7xx-booting-from-emmc-raw-boot-partition
>
> Correct, the ROM does not know about the eMMC boot partitions.
>
>> (2) The cpu does support looking at a sequence of offsets (0, 128K,
>> 256K, 384K) for a proper header/image, and will read MLO from the first
>> such offset. So it is possible to do a safe update of MLO.
>
> With caveats, yes. A valid header is all that matters and if the
> contents fail it doesn't fall back to another location.
>

True, but that's not really any different from using eMMC boot
partitions. You are safe against power failure causing a subsequent boot
from seeing a partial/broken bootloader, but there's no fallback if the
current active slot is broken. Only in this case one has to somewhat
careful with how one does an update (such as postponing writing the
first sector containing the magic header until everything else is
written).

>> However, it seems that MLO will always load U-Boot proper from some
>> fixed offset (or partition), independent of which offset MLO was loaded
>> from. So in order to implement an update mechanism for the whole
>> bootloader which is safe against power failures, one would need to teach
>> the SPL phase to pick an offset depending on the offset SPL itself was
>> loaded from. But that in turn requires that the ROM code exposes that
>> information. 
>> 
>> Does it?
>> 
>> Poking around the reference manual, it seems there are some "tracing
>> vectors" (0x4030ce40 ..), of which word 2, bits 12-15 are "memory boot
>> trial 0-3". So perhaps those bits can be used to figure out which offset
>> the ROM code eventually ended up using? But is there some more
>> direct/documented approach?
>> 
>> [Alternatively, one would have to build two distinct copies
>> of U-Boot merely differing in their value of
>> CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR, but that's not a very
>> attractive option].
>
> Something, perhaps ad-hoc, would need to be done to support a redundant
> load of which U-Boot to use, perhaps also leveraging the bootcount
> support?

I don't know about bootcount, but poking around a little, it seems to be
easy to provide a spl_mmc_get_uboot_raw_sector() (or a board_ or arch_
one) implementing logic to translate those trace vector bits into an
appropriate offset, with the definition of that function being guarded
by some new config option that should also gate four hex options for
setting those offsets.

I'll have to play around with our bbb to see if those trace vector bits
can actually be relied upon.

Rasmus