On Tue, Dec 02, 2025 at 01:01:48AM +0800, Sune Brian wrote: > Tom Rini <[email protected]> 於 2025年12月2日週二 上午12:51寫道： > > > > On Sat, Nov 29, 2025 at 02:48:18PM +0800, Brian Sune wrote: > > > > > Thanks to Jan Kiszka had provided info on > > > u-boot is not able to boot by u-boot-with-spl.sfp. > > > > > > All three TYPE, NUM, OFFSET mode methods > > > are nonfunctional on combined raw boot. > > > > > > The major cause is spl+u-boot structure is > > > defined as 4x[spl+zero_pad] + u-boot.img. > > > Deal to this configuration since GEN5 is used, > > > the spl would require to seek by an offset > > > on top of the spl offset. This means for > > > each spl=0x10000 the offset is 0x40000. > > > > > > However latest u-boot do not consider this > > > major structure on GEN5 socfpga. > > > Meanwhile, the default include file as Jan > > > pointed out is completely wrong syntax and > > > caused issue. > > > > > > Combining both concepts, the minimum fix > > > patch is provide as follows. > > > > > > 1) Offset is control and default set to a > > > proper offset under: > > > SYS_MMCSD_RAW_MODE_U_BOOT_DATA_PART_OFFSET > > > > > > 2) Only GEN5 socfpga will be affected and > > > minimized contamination on other devices. > > > > > > 3) Only one compuatation adjustment is made > > > on spl_mmc_load. And simply introduce the > > > offset adding by the kconfig offset control. > > > It should be 0 by default and gate as well. > > > So no possible harm should be done. > > > > This sounds like a tricky problem to solve in a "nice" looking way. > > > > The first thing that's unclear to me is, which of > > SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR, > > SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION or > > SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION is being used here? > > > > -- > > Tom > > Hi Tom. > > This issue all happened due to the old "u-boot-with-spl.sfp" structure. > The old auto generated u-boot-with-spl.sfp that file itself has spl x4 and > zero padding. then it inserts u-boot.img. > > All are user dependent and have no restriction from the beginning. > SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR any sector with A2 type. > SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION any partition with A2 type. > All are completely dependent on the user SD MMC setup. > So users can even use the last sector aka the most end of the SD MMC. > > That's why it is so tedious. And users even allow to simply use u-boot-spl.sfp > Then manually use dd command to an offset that is in the A2 partition and > load the u-boot.img > > I didn't even like this idea and that's why I changed to the FAT boot method > after 2025.07. > I simply bypassed the inherent issue that Jan was faced with. > > So long story short either completely drop this old compatible boot flow or > do it in a very tedious way aka spl offset on top of u-boot.img offset.
Well, wait, this doesn't make sense. The first thing is you pick which of the three I asked about as to how to find everything else at boot. We don't need to support all three, we need to support one of them. I suspect the first thing is we need a default one-of-those if SYMBOL. This is what we do for MVEBU platforms which have, I suspect at least, a similar odd constraint. -- Tom
signature.asc
Description: PGP signature
