Re: [PATCH v2] Fix socfpga GEN5 boot by spl+u-boot sfp on RAW

[Tom Rini <trini@konsulko.com>]

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

On Tue, Dec 02, 2025 at 01:01:48AM +0800, Sune Brian wrote:
> Tom Rini <trini@konsulko.com> 於 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

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