failsafe update of bootloader on am335x

[Tom Rini]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20250618/d6962f17/attachment.sig>