Generic U-Boot

[Caleb Connolly]

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 <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.

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.
> 
> 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)