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, [email protected] wrote:
From: Michael Srba <[email protected]>
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
