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

[Sumit Garg]

+ 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.

Michael, Varda,

Let us know if there are any concerns to approach mentioned above.

-Sumit