failsafe update of bootloader on am335x

failsafe update of bootloader on am335x

[Rasmus Villemoes]

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

(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.

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].


Rasmus

Re: failsafe update of bootloader on am335x

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2052 bytes --]

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.

> 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?

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: failsafe update of bootloader on am335x

[Rasmus Villemoes]

On Wed, Jun 18 2025, Tom Rini <trini@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