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

[Michael Srba]

Hi,

On 5/12/26 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.
>
> Michael, Varda,
>
> Let us know if there are any concerns to approach mentioned above.
Sounds good to me, one thing to mention is that technically the ipq
platform doesn't *need* qclib, so qclib should be a special case path
available for any SoC that Qualcomm releases it for and that doesn't
have proper u-boot dram init support. It looks like the kodiak
QCLib.elf is 500kB and includes stuff other than DDR training,
but it could probably technically be used (even though the non-ddr
part would make more sense to do in u-boot code).

In any case no platform should be locked into assuming it will always
use qclib, someone might RE it and implement a proper ddr init driver.

Speaking of qclib, the license Qualcomm uses seems kinda insane to me,
they reserve the right to terminate it at any time, and the whole license
becomes invalid if any of it's provisions is invalid or unenforceable,
which I'm pretty sure is the case. They also say you have to delete
all copies of the files if they choose to terminate it, which if enforced
against coreboot would require them to rewrite the git history.
Could someone please force them to write a license that doesn't boil
down to "this is what our legal team wrote and you can't take it at
face value"?
> -Sumit