Hi Jan,
On 15/11/2025 1:13 am, Jan Kiszka wrote:
[CAUTION: This email is from outside your organization. Unless you trust the
sender, do not click on links or open attachments as it may be a fraudulent
email attempting to steal your information and/or compromise your computer.]
From: Jan Kiszka <[email protected]>
If U-Boot is located on MMC, SPL and U-Boot proper are glued together.
More precisely, SPL is stored 4 times. Take this and its padding into
account and adjust sector number via board_spl_mmc_get_uboot_raw_sector.
This allows loading from a partition, without the need to hard-code the
offset via SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR
Signed-off-by: Jan Kiszka <[email protected]>
---
arch/arm/mach-socfpga/board.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm/mach-socfpga/board.c b/arch/arm/mach-socfpga/board.c
index 28554b7a109..d756f7381fb 100644
--- a/arch/arm/mach-socfpga/board.c
+++ b/arch/arm/mach-socfpga/board.c
@@ -14,6 +14,7 @@
#include <hang.h>
#include <handoff.h>
#include <image.h>
+#include <spl.h>
#include <usb.h>
#include <usb/dwc2_udc.h>
#include <asm/global_data.h>
@@ -209,3 +210,11 @@ void lmb_arch_add_memory(void)
}
}
#endif
+
+#ifdef CONFIG_SPL
The guard should be CONFIG_XPL_BUILD instead of CONFIG_SPL to correctly
control SPL-specific behavior
+unsigned long board_spl_mmc_get_uboot_raw_sector(struct mmc *mmc,
+ unsigned long raw_sect)
+{
+ return (CONFIG_SPL_PAD_TO * 4) / 512 + raw_sect;
+}
+#endif
Global impact:
Applying board_spl_mmc_get_uboot_raw_sector() to all SoCFPGA boards
could be risky. Older platforms such as Arria 10 and SoC63 devices use
different layouts, and soon U-Boot proper will be moved into FAT32
partitions for cyclone V.
Offset calculation:
(CONFIG_SPL_PAD_TO * 4) / 512 + raw_sect assumes a specific SPL layout.
It may conflict with the default 0x200 sector
(https://github.com/u-boot/u-boot/blob/c5e6d2ab7eba68cbfb600cdc131c0c375ced2ec9/common/spl/Kconfig#L592
which eventually assigned to raw_sect above) used for
SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR on some boards, so this calculation is
not universal.
Suggestion: Consider gating this behind a board-specific Kconfig option,
or limit the change to boards that actually require this offset. This
will avoid potential regressions while supporting existing platforms.
Please let us know your thoughts.
Thanks,
Tien Fong
