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
