Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 26 Jun 2023 09:39:31 +0200
From:   Stephan Gerhold <stephan@gerhold.net>
To:     Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Cc:     "Lin, Meng-Bo" <linmengbo0689@protonmail.com>, agross@kernel.org,
        andersson@kernel.org, conor+dt@kernel.org,
        devicetree@vger.kernel.org, konrad.dybcio@linaro.org,
        krzysztof.kozlowski+dt@linaro.org, linux-arm-msm@vger.kernel.org,
        linux-kernel@vger.kernel.org, nikita@trvn.ru, robh+dt@kernel.org,
        ~postmarketos/upstreaming@lists.sr.ht
Subject: Re: [PATCH v2 2/2] arm64: dts: qcom: msm8939-samsung-a7: Add initial
 dts
Message-ID: <ZJlAs768g_lj0QuQ@gerhold.net>
References: <20230623100135.5269-1-linmengbo0689@protonmail.com>
 <20230623100237.5299-1-linmengbo0689@protonmail.com>
 <5fbba4e8-a8d9-0e99-e112-31b5781c1648@linaro.org>
 <20230623104647.5501-1-linmengbo0689@protonmail.com>
 <71ae3799-4668-891c-c32d-d36da655d56d@linaro.org>
 <ZJiY1PYtfeIN13ZG@gerhold.net>
 <2e7b0647-b108-5364-a7cf-955cacf9b322@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2e7b0647-b108-5364-a7cf-955cacf9b322@linaro.org>
Content-Transfer-Encoding: 7bit
Precedence: bulk

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