Message-ID: <4c4efb31-14c8-9e58-edc2-7e2f787e6976@linaro.org>
Date:   Thu, 23 Jun 2022 12:55:55 +0300
From:   Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
To:     Konrad Dybcio <konrad.dybcio@...ainline.org>,
        krzysztof.kozlowski@...aro.org
Cc:     agross@...nel.org, arnd@...db.de, bjorn.andersson@...aro.org,
        devicetree@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        linux-kernel@...r.kernel.org, olof@...om.net, robh@...nel.org,
        sboyd@...nel.org
Subject: Re: Removal of qcom,board-id and qcom,msm-id

On 22/06/2022 14:53, Konrad Dybcio wrote:
> 
> 
> On 22.06.2022 10:21, Dmitry Baryshkov wrote:
>> On 22/05/2022 22:51, Konrad Dybcio wrote:
>>> Hi,
>>>
>>> removing these properties will not bring almost any benefit (other than making
>>> some checks happy any saving some <200 LoC) and will make the lives of almost
>>> all people doing independent development for linux-on-msm harder. There are
>>> almost unironically like 3 people outside Linaro and QUIC who have
>>> non-vendor-fused development boards AND the sources to rebuild the
>>> bootloader on their own. Making it harder to boot is only going to
>>> discourage people from developing on these devices, which is already not
>>> that pleasant, especially with newer platforms where you have to fight with
>>> the oh-so-bright ideas of Android boot chain..
>>>
>>> This only concerns devices released before sm8350, as the new ones will not
>>> even boot with these properties present (or at least SONY Sagami, but I
>>> doubt it's an isolated case), so other than completing support for older
>>> devices, it won't be an issue going forward, anyway.
>>
>> I almost missed this part of the discussion (and Krzysztof had to point me to it in discussion of his patches).
>>
>> I think this is a Sony peculiarity. At least the distributed SM8350 (lahaina) and SM8450 (waipio) Qualcomm device trees use these properties:
>>
>> https://github.com/MiCode/kernel_devicetree/blob/zeus-s-oss/qcom/lahaina-hdk.dts
>> https://github.com/MiCode/kernel_devicetree/blob/zeus-s-oss/qcom/lahaina-v2.1.dtsi
>> https://github.com/MiCode/kernel_devicetree/blob/zeus-s-oss/qcom/waipio-qrd-pm8010.dts
>> https://github.com/MiCode/kernel_devicetree/blob/zeus-s-oss/qcom/waipio-v2.dtsi
>>
>>
> Hi,
> 
> I was puzzled on this back when I first tried to get mainline booting on 8350 too. What I think happened, is that msm-id is used in some code paths, but not others (remember there are plenty of combinations including various Google's inventions from all over the years: QCDT, DTBO, vendor_boot, AVB signage, A/B presence/absence of recovery partition, virtual partitions etc etc).
> 
> Frankly, I have no idea why they are still here, but for booting just the kernel (no vendor_boot / GKI / dtbo mess), they need to be absent, at least on Sagami devices. This may be a bug in the Qualcomm bootloader, but they officially have to go with the GKI path to pass Google's compatibility tests, so this may not have been thouroughly tested (if at all), though I highly doubt this is going to change, as vendors are generally reluctant to update their bootloaders and Qualcomm is probably not interested in messing with a useless-to-the-main-purpose feature.

I remember that on early sm8450 boards/bootloaders we had the issues 
with the bootloader (I don't remember exact details). However I just 
checked the SM4850-HDK + the downstream kernel + appended dtb (which 
contains qcom,msm-id and qcom,board-id properties) and the kernel boots 
fine. So, I can suppose, there was some kind of an issue, which got 
fixed with later ABL releases.

Anyway the latest Krzysztof's text seems fine to me. And if anybody adds 
these properties to the DT, he knows what he is doing and why.

-- 
With best wishes
Dmitry

Powered by blists - more mailing lists