On Tue, Dec 02, 2025 at 01:14:43AM +0800, Sune Brian wrote: > Tom Rini <[email protected]> 於 2025年12月2日週二 上午1:05寫道： > > > > 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 > > But I am afraid that is the case. You can actually use any one of three > options > to boot. The requirements on Altera Cyclone V or Arria V GEN5 socfpga require > a A2 partition to seek the SPL. So this involved "TYPE" and "PAR NUM". > Then for the complete RAW setup it simply just uses the sector offset. > > > 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 > > That's why I don't even like to count debugging from first place after > 2025.07. > SPL on A2 partition u-boot.img on FAT32 boot very fine and no issue. > You don't even need to consider the u-boot.img offset on top of SPL offset. > Very clean. > Jan proposed to fix the RAW backward support on the old combined > u-boot-with-spl.sfp boot method, which is completely not a must. > > Hope this clears up some confusion.
Yes, thanks. And I think I prefer the way Jan has handled these problems in his series, rather than this approach. -- Tom
signature.asc
Description: PGP signature
