linux-kernel - Re: [PATCH v2 2/2] arm64: dts: qcom: msm8939-samsung-a7: Add initial dts

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZJlAs768g_lj0QuQ@gerhold.net>
Date:   Mon, 26 Jun 2023 09:39:31 +0200
From:   Stephan Gerhold <stephan@...hold.net>
To:     Bryan O'Donoghue <bryan.odonoghue@...aro.org>
Cc:     "Lin, Meng-Bo" <linmengbo0689@...tonmail.com>, agross@...nel.org,
        andersson@...nel.org, conor+dt@...nel.org,
        devicetree@...r.kernel.org, konrad.dybcio@...aro.org,
        krzysztof.kozlowski+dt@...aro.org, linux-arm-msm@...r.kernel.org,
        linux-kernel@...r.kernel.org, nikita@...n.ru, robh+dt@...nel.org,
        ~postmarketos/upstreaming@...ts.sr.ht
Subject: Re: [PATCH v2 2/2] arm64: dts: qcom: msm8939-samsung-a7: Add initial
 dts

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