Generic U-Boot (was: Re: xPL Proposal)

[Caleb Connolly]

Hi all,

On 2/12/25 17:41, Simon Glass wrote:
> Hi Tom,
> 
> On Wed, 12 Feb 2025 at 09:40, Tom Rini <trini at 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.

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.

Kind regards,

> 
> Regards,
> Simon
> 
>>
>> --
>> Tom


-- 
Caleb (they/them)