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

[Sune Brian]

Tom Rini <trini at konsulko.com> 於 2025年12月2日週二 上午1:05寫道：
>
> On Tue, Dec 02, 2025 at 01:01:48AM +0800, Sune Brian wrote:
> > Tom Rini <trini at 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

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.

Thanks,
Brian