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
signature.asc
Description: PGP signature
