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

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

[Brian Sune]

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.

Signed-off-by: Brian Sune <briansune@gmail.com>
---
 common/spl/Kconfig   |  8 +++++++-
 common/spl/spl_mmc.c | 19 ++++++++++++++-----
 include/part.h       |  4 +++-
 3 files changed, 24 insertions(+), 7 deletions(-)

diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index 8dade2b501e..554509146d8 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -574,6 +574,7 @@ config SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
 config SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE
 	bool "MMC raw mode: by partition type"
 	depends on DOS_PARTITION
+	select SPL_LOAD_BLOCK
 	help
 	  Use partition type for specifying U-Boot partition on MMC/SD in
 	  raw mode. U-Boot will be loaded from the first partition of this
@@ -600,8 +601,13 @@ config SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR
 
 config SYS_MMCSD_RAW_MODE_U_BOOT_DATA_PART_OFFSET
 	hex "U-Boot main hardware partition image offset"
-	depends on SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR
+	depends on SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR || \
+	(SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION && \
+	(TARGET_SOCFPGA_CYCLONE5 || TARGET_SOCFPGA_ARRIA5)) || \
+	(SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE && \
+	(TARGET_SOCFPGA_CYCLONE5 || TARGET_SOCFPGA_ARRIA5))
 	default 0x10 if ARCH_SUNXI
+	default 0x200 if TARGET_SOCFPGA_CYCLONE5 || TARGET_SOCFPGA_ARRIA5
 	default 0x0
 	help
 	  On some platforms SPL location depends on hardware partition. The ROM
diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
index d8ce3a84614..6904ea3edb7 100644
--- a/common/spl/spl_mmc.c
+++ b/common/spl/spl_mmc.c
@@ -5,6 +5,7 @@
  *
  * Aneesh V <aneesh@ti.com>
  */
+
 #include <dm.h>
 #include <log.h>
 #include <part.h>
@@ -28,7 +29,9 @@ static ulong h_spl_load_read(struct spl_load_info *load, ulong off,
 
 static __maybe_unused unsigned long spl_mmc_raw_uboot_offset(int part)
 {
-#if IS_ENABLED(CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR)
+#if IS_ENABLED(CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR) || \
+    IS_ENABLED(CONFIG_TARGET_SOCFPGA_CYCLONE5) || \
+    IS_ENABLED(CONFIG_TARGET_SOCFPGA_ARRIA5)
 	if (part == 0)
 		return CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_DATA_PART_OFFSET;
 #endif
@@ -106,7 +109,9 @@ static int spl_mmc_find_device(struct mmc **mmcp, int mmc_dev)
 	return 0;
 }
 
-#ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
+#if defined(CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION) || \
+    (defined(CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE) && \
+    (defined(CONFIG_TARGET_SOCFPGA_CYCLONE5) || defined(CONFIG_TARGET_SOCFPGA_ARRIA5)))
 static int mmc_load_image_raw_partition(struct spl_image_info *spl_image,
 					struct spl_boot_device *bootdev,
 					struct mmc *mmc, int partition,
@@ -136,7 +141,9 @@ static int mmc_load_image_raw_partition(struct spl_image_info *spl_image,
 		return ret;
 	}
 
-#ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR
+#if defined(CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR) || \
+    defined(CONFIG_TARGET_SOCFPGA_CYCLONE5) || \
+    defined(CONFIG_TARGET_SOCFPGA_ARRIA5)
 	return mmc_load_image_raw_sector(spl_image, bootdev, mmc, info.start + sector);
 #else
 	return mmc_load_image_raw_sector(spl_image, bootdev, mmc, info.start);
@@ -419,10 +426,12 @@ int spl_mmc_load(struct spl_image_info *spl_image,
 
 		raw_sect = spl_mmc_get_uboot_raw_sector(mmc, raw_sect);
 
-#ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
+#if defined(CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION) || \
+    (defined(CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE) && \
+    (defined(CONFIG_TARGET_SOCFPGA_CYCLONE5) || defined(CONFIG_TARGET_SOCFPGA_ARRIA5)))
 		ret = mmc_load_image_raw_partition(spl_image, bootdev,
 						   mmc, raw_part,
-						   raw_sect);
+						   raw_sect + spl_mmc_raw_uboot_offset(part));
 		if (!ret)
 			return 0;
 #endif
diff --git a/include/part.h b/include/part.h
index 6caaa6526aa..91e49012e2f 100644
--- a/include/part.h
+++ b/include/part.h
@@ -461,7 +461,9 @@ ulong disk_blk_erase(struct udevice *dev, lbaint_t start, lbaint_t blkcnt);
 #ifdef CONFIG_XPL_BUILD
 # define part_print_ptr(x)	NULL
 # if defined(CONFIG_SPL_FS_EXT4) || defined(CONFIG_SPL_FS_FAT) || \
-	defined(CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION)
+     defined(CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION) || \
+     (defined(CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE) && \
+     (defined(CONFIG_TARGET_SOCFPGA_CYCLONE5) || defined(CONFIG_TARGET_SOCFPGA_ARRIA5)))
 #  define part_get_info_ptr(x)	x
 # else
 #  define part_get_info_ptr(x)	NULL
-- 
2.34.1

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

[Jan Kiszka]

On 29.11.25 07:48, 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.
> 
> Signed-off-by: Brian Sune <briansune@gmail.com>
> ---
>  common/spl/Kconfig   |  8 +++++++-
>  common/spl/spl_mmc.c | 19 ++++++++++++++-----
>  include/part.h       |  4 +++-
>  3 files changed, 24 insertions(+), 7 deletions(-)
> 
> diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> index 8dade2b501e..554509146d8 100644
> --- a/common/spl/Kconfig
> +++ b/common/spl/Kconfig
> @@ -574,6 +574,7 @@ config SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
>  config SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE
>  	bool "MMC raw mode: by partition type"
>  	depends on DOS_PARTITION
> +	select SPL_LOAD_BLOCK
>  	help
>  	  Use partition type for specifying U-Boot partition on MMC/SD in
>  	  raw mode. U-Boot will be loaded from the first partition of this

Proposed as separate patch in [1] as requested my Marek.

> @@ -600,8 +601,13 @@ config SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR
>  
>  config SYS_MMCSD_RAW_MODE_U_BOOT_DATA_PART_OFFSET
>  	hex "U-Boot main hardware partition image offset"
> -	depends on SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR
> +	depends on SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR || \
> +	(SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION && \
> +	(TARGET_SOCFPGA_CYCLONE5 || TARGET_SOCFPGA_ARRIA5)) || \
> +	(SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE && \
> +	(TARGET_SOCFPGA_CYCLONE5 || TARGET_SOCFPGA_ARRIA5))
>  	default 0x10 if ARCH_SUNXI
> +	default 0x200 if TARGET_SOCFPGA_CYCLONE5 || TARGET_SOCFPGA_ARRIA5
>  	default 0x0
>  	help
>  	  On some platforms SPL location depends on hardware partition. The ROM
> diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
> index d8ce3a84614..6904ea3edb7 100644
> --- a/common/spl/spl_mmc.c
> +++ b/common/spl/spl_mmc.c
> @@ -5,6 +5,7 @@
>   *
>   * Aneesh V <aneesh@ti.com>
>   */
> +
>  #include <dm.h>
>  #include <log.h>
>  #include <part.h>
> @@ -28,7 +29,9 @@ static ulong h_spl_load_read(struct spl_load_info *load, ulong off,
>  
>  static __maybe_unused unsigned long spl_mmc_raw_uboot_offset(int part)
>  {
> -#if IS_ENABLED(CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR)
> +#if IS_ENABLED(CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR) || \
> +    IS_ENABLED(CONFIG_TARGET_SOCFPGA_CYCLONE5) || \
> +    IS_ENABLED(CONFIG_TARGET_SOCFPGA_ARRIA5)
>  	if (part == 0)
>  		return CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_DATA_PART_OFFSET;
>  #endif
> @@ -106,7 +109,9 @@ static int spl_mmc_find_device(struct mmc **mmcp, int mmc_dev)
>  	return 0;
>  }
>  
> -#ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
> +#if defined(CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION) || \
> +    (defined(CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE) && \
> +    (defined(CONFIG_TARGET_SOCFPGA_CYCLONE5) || defined(CONFIG_TARGET_SOCFPGA_ARRIA5)))
>  static int mmc_load_image_raw_partition(struct spl_image_info *spl_image,
>  					struct spl_boot_device *bootdev,
>  					struct mmc *mmc, int partition,
> @@ -136,7 +141,9 @@ static int mmc_load_image_raw_partition(struct spl_image_info *spl_image,
>  		return ret;
>  	}
>  
> -#ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR
> +#if defined(CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR) || \
> +    defined(CONFIG_TARGET_SOCFPGA_CYCLONE5) || \
> +    defined(CONFIG_TARGET_SOCFPGA_ARRIA5)
>  	return mmc_load_image_raw_sector(spl_image, bootdev, mmc, info.start + sector);
>  #else
>  	return mmc_load_image_raw_sector(spl_image, bootdev, mmc, info.start);
> @@ -419,10 +426,12 @@ int spl_mmc_load(struct spl_image_info *spl_image,
>  
>  		raw_sect = spl_mmc_get_uboot_raw_sector(mmc, raw_sect);
>  
> -#ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
> +#if defined(CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION) || \
> +    (defined(CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE) && \
> +    (defined(CONFIG_TARGET_SOCFPGA_CYCLONE5) || defined(CONFIG_TARGET_SOCFPGA_ARRIA5)))
>  		ret = mmc_load_image_raw_partition(spl_image, bootdev,
>  						   mmc, raw_part,
> -						   raw_sect);
> +						   raw_sect + spl_mmc_raw_uboot_offset(part));
>  		if (!ret)
>  			return 0;
>  #endif
> diff --git a/include/part.h b/include/part.h
> index 6caaa6526aa..91e49012e2f 100644
> --- a/include/part.h
> +++ b/include/part.h
> @@ -461,7 +461,9 @@ ulong disk_blk_erase(struct udevice *dev, lbaint_t start, lbaint_t blkcnt);
>  #ifdef CONFIG_XPL_BUILD
>  # define part_print_ptr(x)	NULL
>  # if defined(CONFIG_SPL_FS_EXT4) || defined(CONFIG_SPL_FS_FAT) || \
> -	defined(CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION)
> +     defined(CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION) || \
> +     (defined(CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE) && \
> +     (defined(CONFIG_TARGET_SOCFPGA_CYCLONE5) || defined(CONFIG_TARGET_SOCFPGA_ARRIA5)))
>  #  define part_get_info_ptr(x)	x
>  # else
>  #  define part_get_info_ptr(x)	NULL

Two issues:
 - fixes for CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE mangled
   with socfpga changes
 - a lot if ugly board-specific ifdefs - my approach in [2] does not
   need that

Jan

[1]
https://patchwork.ozlabs.org/project/uboot/patch/db6aa161176dfcc4d2764e9411b4d195c9c3208c.1764574369.git.jan.kiszka@siemens.com/
[2] https://patchwork.ozlabs.org/project/uboot/list/?series=483978

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

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

[Sune Brian]

>  - a lot if ugly board-specific ifdefs - my approach in [2] does not
>    need that
>
> Jan
>
> [1]
Complete unnecessary.

> [2] https://patchwork.ozlabs.org/project/uboot/list/?series=483978

Are you 100% sure modifying as such can kept all u-boot supported device
untouched?
 If not there are no ugly "board specific", btw it is generation
specific on socfpga.
C5 and A5 only. You don't familiar with other brand and family.

Sorry your new patch series are still not able to confirm the compatibility.

And you patch itself also used your claimed ugly board specific method.
So if you really like to take this patch "as yours"
work then move on. I drop mine. But I don't see your original patch is
fixed as such.

+#if (defined(TARGET_SOCFPGA_ARRIA10) || defined(TARGET_SOCFPGA_GEN5)) && \
+    defined(CONFIG_XPL_BUILD)


Brian

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

[Tom Rini]

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

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

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

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

[Sune Brian]

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.

Thanks,
Brian

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

[Tom Rini]

[-- 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 --]

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

[Sune Brian]

Tom Rini <trini@konsulko.com> 於 2025年12月2日週二 上午1:05寫道：
>
> 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

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

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

[Tom Rini]

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

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

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

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

[Sune Brian]

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

No worries. I did not propose this fix from the beginning.
Just drop this patch.

Thanks,
Brian