[PATCH 3/4] arch: arm: mach-socfpga: Adjust a raw sectors for MMC loading of U-Boot from SPL

[Chee, Tien Fong]

Hi Jan,

On 25/11/2025 2:42 pm, 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.]
>
> 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 <jan.kiszka at siemens.com>
>>>
>>> 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 <jan.kiszka at siemens.com>
>>> ---
>>>    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?

Thanks for your feedback. I’d like to clarify the current status and our 
recent POC regarding SPL and U-Boot proper loading on Cyclone V.


Cyclone V (Gen5 – ROM-based boot) - ROM supports SPL loading in two modes:
   1. Raw mode – from LBA 0
   2. Partition mode (0xA2) – from a dedicated A2 partition

Our POC confirms that this restriction applies to SPL only. Once SPL is 
running from OCRAM, it can load U-Boot proper from FAT32 without issue. 
This reduces OCRAM usage, simplifies the MMC layout, and preserves FAT32 
benefits.

Arria 10
  1. ROM loads SPL from its fixed boot source. SPL already loads U-Boot 
proper from FAT32 today.

SoC64 (Agilex / Agilex 5)
   1. SPL is embedded in the FPGA bitstream and loaded by SDM. SPL is 
never on MMC; only U-Boot proper can be on MMC, and all boards use FAT32.

Conclusion on required modes
   1. ROM loads SPL from raw (Gen5, A10)
   2. ROM loads SPL from A2 partition (Gen5, A10)
   3. SDM loads SPL from bitstream (SoC64 Agilex, Agilex7m, S10 and etc.. )

U-Boot proper loaded from FAT32 — this reflects the standard Altera 
devkit MMC layout. Other boards, partners, or vendors may still use raw 
partitions, so this is not universal.

Implication
   There is no single offset calculation that is portable across all 
generations. Our POC shows that moving U-Boot proper to FAT32 is safe 
for devkits, reduces OCRAM usage, and aligns with long-term MMC layout 
consistency, while older raw modes remain supported where needed.


Please let me know your thoughts on this approach and whether you see 
any corner cases we might have missed.


Thanks,
Tien Fong