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

[Marek Vasut]

On 11/27/25 8:42 AM, Jan Kiszka wrote:
> On 25.11.25 13:20, Marek Vasut wrote:
>> On 11/14/25 6:13 PM, Jan Kiszka wrote:
>>> 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
>>> +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;
>> Please add a comment whether this is offset within a partition or within
>> a raw block device.
> 
> Depends on the mode. It is relative to the partition when using any of
> those modes, otherwise relative to base sector. Will add that.

Thank you.

>> Also, I see the long discussion thread, maybe it would be good to point
>> out which commit exactly broken the DE0 board.
> 
> 2a00d73d081a14e7c2ecf23794b6d029268d8ca3 - though it is not completely
> fair to say it broke things because the code paths we took before that
> change were not really consistent and papered over issues which the
> refactoring than surfaced.
I see.