On Mon, Jun 26, 2023 at 01:05:22AM +0100, Bryan O'Donoghue wrote:
> On 25/06/2023 20:43, Stephan Gerhold wrote:
> > Is it really worth it to support a half-working bootloader though?
>
> > No one will ever be able to use this properly without fixing the
> > bootloader. SMP doesn't work with the stock bootloader, many devices
> > need display panel selection in the bootloader and on some Samsung
> > devices there is not even USB and UART without special fixes in the
> > bootloader.
>
> Why set the bar higher than necessary to boot a kernel though ?
>
> Its two lines in a dts.
>
I see your point but after adding some really weird workarounds for
various devices in lk2nd I can't help seeing it more complicated.
Adding "just two lines in a dts" is the general case, but I can also
give plenty other examples where one has to:
- Duplicate the entire downstream MDSS/MDP/display DT nodes because
the bootloader uses them to initialize the display (older Sony
MSM8974 devices) [1]
- Add random DT nodes because the stock bootloader insists on updating
random DT properties in them [2]
- Use a custom bootloader anyway to boot 64-bit Linux, because the
stock bootloader doesn't implement the 32-bit -> 64-bit switch
(most of these devices used ARM32 on the stock Android)
[I don't have a full overview which devices need this because
we have never tested booting mainline Linux with the stock
bootloader on most devices]
You also need to be really careful when building the Android boot
images. qcom,msm-id/board-ids are not unique, so when you use the
typical "dtbTool" building process which bundles all DTBs in
arch/arm64/boot/dts you risk device damage. Chances are good that the
bootloader will pick the wrong DTB, potentially with wrong regulator
voltages or anything like that.
When qcom,msm-id/board-id are missing such mistakes cannot happen
because the stock bootloader will just refuse to boot it. Personally I
actually consider that to be a good thing because booting with the stock
bootloader is almost always a naive mistake made by end users that have
no experience with the whole complicated DTB selection story.
I won't object to adding the properties but I also don't really see a
use case for them. People porting devices can easily add them when
building a custom kernel. End users want the full functionality
(including SMP) so if they boot through the stock bootloader it's most
likely accidental.
Thanks,
Stephan
[1]: https://github.com/msm8916-mainline/lk2nd/tree/master/dts/msm8974/sony
[2]: https://github.com/msm8916-mainline/lk2nd/blob/dd850aeb0c348cea085db8013f578615715cdd7f/dts/msm8916/msm8916-motorola-surnia.dts#L21-L32
