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