On 25.11.25 06:02, Chee, Tien Fong wrote: > 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. >
I dislike more magics here. This is surely not board specific, it's rather partition specific (raw vs. fat part) as you pointed out above. Probably the romloader version plays a role as well in supporting one or both, thus the chip generation. Let's encode that into Kconfig, rather than magics. Are there more modes to tell apart? Jan -- Siemens AG, Foundational Technologies Linux Expert Center
