[PATCH v7 09/11] mach-snapdragon: add board_spl.c and split out common code

[Casey Connolly]

On 12/05/2026 07:08, Sumit Garg wrote:
> + Varda
> 
> Hi Casey,
> 
> On Mon, May 11, 2026 at 04:00:46PM +0200, Casey Connolly wrote:
>>
>>
>> On 11/05/2026 15:55, Michael Srba wrote:
>>>
>>>
>>> On 5/11/26 15:33, Casey Connolly wrote:
>>>> Hi Michael,
>>>>
>>>> On 08/05/2026 23:45, michael.srba at seznam.cz wrote:
>>>>> From: Michael Srba <Michael.Srba at seznam.cz>
>>>>>
>>>>> Code in board.c will now only be compiled into U-Boot proper,
>>>>> and the new board_spl.c will only be built into SPL.
>>>>> Code in board_common.c is common to both phases.
>>>>>
>>>>> Also split out mem_map.c, which is currently common to both
>>>>> phases since it seems to not cause issues in SPL. In the future
>>>>> it should probably behave differenly in SPL, especially if dram
>>>>> initialization is supported.
>>>> Sorry to be a pest with this one, could you rebase this on the SMEM
>>>> series since it also pulls out all the memory mapping stuff.
>>>>
>>>> Since the only thing you left in board_common.c is the board_usb_init(),
>>>> it seems like it's only actually used in db410c at least according to a
>>>> quick grep. Could you just move it over to board/qualcomm/
>>>> dragonboard410c?
>>>>
>>>> Along with the other changes maybe most of the contents of board_spl.c
>>>> should go into some board/qualcomm/sdm845-spl/board.c file or something?
>>> but there's nothing sdm845-specific about it? SPL won't ever be passed
>>> dt by a previous stage, empty board-init is a sensible default even
>>> if someone wants to override it in specific cases, reset-cpu is a stub and
>>> if qcom wants to implement it there's no good reason to use PSCI for that
>>> so it can be universal (though an ifdef for the non-typical case
>>> of late-in-the-chain SPL would probably still be cleaner than multiple
>>> separate board.c files), and fully implemented spl_boot_device should check
>>> what medium the BROM booted from (or at least if it was EDL, which is
>>> in a hw register, not sure if emmc vs ufs vs sdcard vs spi needs awareness
>>> of data passed from PBL), so again can be perfectly shared.
>>> If DFU is not enabled in config then the USB boot branch can even
>>> be ifdef'd away at compile time.
>>
>> Alright, I'm a bit unsure how Qualcomm want to base their stuff on top
>> so I'll defer to you and we can keep this as-is. fwiw the "sdm845-spl"
>> naming is just arbitrary, if you can pick a better name please do.
>>
>> Sumit: any thoughts on how to align these approaches and keep it all
>> maintainable?
> 
> Yeah I earlier asked Michael and Varda to converge on common Qcom SPL
> architecture which can be used across SoCs.
> 
> Basically how I think the way forward here would be to have a common
> Qcom SPL architecture which would then have the platform specific hooks
> for functionality currently supported by that platform. Once more
> platforms try to use the same functionality then we can migrate that to
> common code.
> 
> Looking at Michael's series, I think it's mostly doing the base
> infrastructure SPL setup without much boot functionality added. So we
> should be able to merge that once it's rebased on your SMEM patch-set.
> Then Varda should be able to rebase the IPQ series on top of it. I think
> the QCLIB blob loading for DRAM setup can be a platform specific hook in
> the common SPL code overriden for IPQ platform for now.

Sounds sensible to me!

> 
> Michael, Varda,
> 
> Let us know if there are any concerns to approach mentioned above.
> 
> -Sumit

-- 
// Casey (she/her)