On Thu, Feb 13, 2025 at 03:03:29PM +0000, Caleb Connolly wrote: > Hi all, > > On 2/12/25 17:41, Simon Glass wrote: > > Hi Tom, > > > > On Wed, 12 Feb 2025 at 09:40, Tom Rini <tr...@konsulko.com> wrote: > > > > > > On Tue, Feb 11, 2025 at 03:54:21PM -0700, Simon Glass wrote: > > > > > > > > The way I see it, both schemes remove the ambiguity. Mine retains a > > > > single deconfig file and a single 'make menuconfig' for each board. > > > > Yours feels more like building independent U-Boot images. > > > > > > It is explicitly building independent U-Boot images, yes. With a wrapper > > > around "make all of the images for a given platform". So much of our > > > confusing and messy code is because we aren't doing that. And since most > > > modern SoCs can work as (mostly )generic SPL selects correct DTB for PPL > > > we really could have fewer overall build configurations. > > Big +1 for this. Most Qualcomm platforms in the wild today that would > benefit from chainloading U-Boot will NEVER be able to run any stage except > PPL due to codesigning. For these I would ideally never like to even think > about non-PPL stages since they only added confusion. > > At the same time, it would be great to eventually have U-Boot SPL for > Qualcomm platforms that can replace Qualcomm's proprietary sbl1, and maybe > event some even smaller/earlier secure TPL(?) stage that replaces their > xbl_sec. > > I would very much prefer that these be distinct, since they vary in how > board specific they need to be (see below). > > Folks who are just contributing support for their device/soc (a few quirks > or simple driver ports from Linux in most cases) are going to have the best > experience when the learning curve from Linux to U-Boot is minimal. Mixing > up various boot stages into a single defconfig and having custom kbuild > infrastructure is the opposite of that, and seems unnecessary. > > > > > I'd really like to see a generic aarch64 U-Boot for PPL, although it > > would be quite large with all the drivers. Perhaps we could start by > > having a generic Rockchip one, for example. > > We already have this for Qualcomm. Some small QoL things still need to go > upstream but you can build a single U-Boot binary and boot it on a bunch of > differences devices just by using the right DTB. See this build script for > example which builds for just a few devices: > > https://gitlab.com/sdm845-mainline/validation/-/blob/main/build_uboot.sh > > I think a bunch of things in mach-snapdragon could be moved to a generic > mach-aarch64 that could also target other SoCs like Rockchip or Mediatek. > I'd be super interested in helping to make this happen. > > Probably would even want to put more things into common code so other > architectures can adopt it (and make themselves smaller), then mach-aarch64 > can just be a stub for devices that are fully generic.
I'm not sure how this works, exactly. Setting aside "U-Boot as EFI
application" (which could use EFI API calls for device specific
implementation of things like reading storage devices), there's still
the case of someone somewhere needs to do the device details. What I
had in mind is later in the email.
> The other potential concern with a generic aarch64 target is that we then
> lose track of what devices are actually supported. It would be nice to have
> something like a list of DTBs either in U-Boot or in some associated
> infrastructure we use to build reference images.
>
> Which all ties back to the goal of providing distro-agnostic U-Boot images
> to make Qualcomm (and other?) Android phones capable of running more Linux
> distros.
>
> Sorry for the big thought-dump, this has been on my mind for a while and
> since it seems like something you're both also interested in I just wanted
> to offer my perspective as a device and distro maintainer as well.
It's good to have more thoughts about all of this, especially from
someone that worries about that from more than just the bootloader
itself use case. Implementation wise, we could in theory start with
something like:
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index da6f11749343..111e3c4b6059 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -600,6 +600,10 @@ choice
prompt "Target select"
default TARGET_HIKEY
+config ARCH_MULTI_V8
+ bool "Multiple Aarch64 SoC support"
+ select ARCH_SNAPDRAGON
+
config ARCH_AT91
bool "Atmel AT91"
select GPIO_EXTRA_HEADER
@@ -1099,27 +1103,6 @@ config ARCH_RENESAS
imply SYS_THUMB_BUILD
imply ARCH_MISC_INIT if DISPLAY_CPUINFO
-config ARCH_SNAPDRAGON
- bool "Qualcomm Snapdragon SoCs"
- select ARM64
- select DM
- select DM_GPIO
- select DM_SERIAL
- select DM_RESET
- select POWER_DOMAIN
- select GPIO_EXTRA_HEADER
- select MSM_SMEM
- select OF_CONTROL
- select OF_SEPARATE
- select SMEM
- select SPMI
- select BOARD_LATE_INIT
- select OF_BOARD
- select SAVE_PREV_BL_FDT_ADDR
- select LINUX_KERNEL_IMAGE_HEADER if !ENABLE_ARM_SOC_BOOT0_HOOK
- imply OF_UPSTREAM
- imply CMD_DM
-
config ARCH_SOCFPGA
bool "Altera SOCFPGA family"
select ARCH_EARLY_INIT_R
@@ -1977,19 +1960,6 @@ config ARCH_UNIPHIER
Support for UniPhier SoC family developed by Socionext Inc.
(formerly, System LSI Business Division of Panasonic Corporation)
-config ARCH_SYNQUACER
- bool "Socionext SynQuacer SoCs"
- select ARM64
- select DM
- select GIC_V3
- select PSCI_RESET
- select SYSRESET
- select SYSRESET_PSCI
- select OF_CONTROL
- help
- Support for SynQuacer SoC family developed by Socionext Inc.
- This SoC is used on 96boards EE DeveloperBox.
-
config ARCH_STM32
bool "Support STMicroelectronics STM32 MCU with cortex M"
select CPU_V7M
@@ -2169,6 +2139,45 @@ config ARCH_GXP
endchoice
+menu "Aarch64 Multiple Platform SoC options"
+ depends on ARCH_MULTI_V8
+
+config ARCH_SNAPDRAGON
+ bool "Qualcomm Snapdragon SoCs"
+ select ARM64
+ select DM
+ select DM_GPIO
+ select DM_SERIAL
+ select DM_RESET
+ select POWER_DOMAIN
+ select GPIO_EXTRA_HEADER
+ select MSM_SMEM
+ select OF_CONTROL
+ select OF_SEPARATE
+ select SMEM
+ select SPMI
+ select BOARD_LATE_INIT
+ select OF_BOARD
+ select SAVE_PREV_BL_FDT_ADDR
+ select LINUX_KERNEL_IMAGE_HEADER if !ENABLE_ARM_SOC_BOOT0_HOOK
+ imply OF_UPSTREAM
+ imply CMD_DM
+
+config ARCH_SYNQUACER
+ bool "Socionext SynQuacer SoCs"
+ select ARM64
+ select DM
+ select GIC_V3
+ select PSCI_RESET
+ select SYSRESET
+ select SYSRESET_PSCI
+ select OF_CONTROL
+ help
+ Support for SynQuacer SoC family developed by Socionext Inc.
+ This SoC is used on 96boards EE DeveloperBox.
+
+endmenu
+
config SUPPORT_PASSING_ATAGS
bool "Support pre-devicetree ATAG-based booting"
depends on !ARM64
Which for qcom_defconfig (and now ARCH_MULTI_V8=y) and ARCH_SYNQUACER=y
only fails to build because our cpu reset drivers aren't quite namespace
clean enough. But that's an easy fix. However, I picked ARCH_SYNQUACER
because it's one of the platforms that doesn't have a lot of additional
code (there is no arch directory) for conflicts to arise in, and there's
no "now, SPL?" to worry about too.
But the above is where I'd start implementing, along with documenting
the run time entry requirements and some other important details. We
likely need to do some splitting up symbols so that a platform can
opt-out of ARCH_MULTI_V8, which might be required for "do care about
SPL", at least for some period of time.
--
Tom
signature.asc
Description: PGP signature
