On Thu, Feb 13, 2025 at 03:10:36PM +0000, Caleb Connolly wrote: > > > On 2/13/25 15:03, 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. > > > > 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. > > This has been very successful for older Qualcomm SoC's using lk2nd which > supports a frankly ridiculous number of phones > > https://github.com/msm8916-mainline/lk2nd/blob/main/Documentation/devices.md > > notably with just a binary per soc: > https://github.com/msm8916-mainline/lk2nd/releases/tag/20.0 > > They also do some fun things with DT that we might find some inspiration in.
There's certainly a lot that can be done with "generic enough for a single family" as the goal. And there's cases where that's indeed both enough and the goal, and we should support that as much as we can. -- Tom
signature.asc
Description: PGP signature
