Messages in this thread | ![/](/images/icornerl.gif) | | Date | Mon, 23 May 2022 15:13:07 -0700 | Subject | Re: Removal of qcom,board-id and qcom,msm-id | From | Trilok Soni <> |
| |
Hi Bjorn,
On 5/23/2022 2:34 PM, Bjorn Andersson wrote: > On Mon 23 May 11:41 CDT 2022, Trilok Soni wrote: > >> Hello Krzysztof, >> >> On 5/23/2022 5:14 AM, Krzysztof Kozlowski wrote: >>> On 23/05/2022 14:02, Konrad Dybcio wrote: >>>> >>>> On 23/05/2022 09:21, Krzysztof Kozlowski wrote: >>>>> On 22/05/2022 21: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. But there are give >>>>>> or take 50 locked down devices in mainline right now, and many more waiting >>>>>> to be upstreamed in various downstream close-to-mainline trees that should >>>>>> not be disregarded just because Qualcomm is far from the best at making >>>>>> their BSP software stack clean. >>>>> I actually wonder why do you need these properties for community work on >>>>> such boards? You ship kernel with one concatenated DTB and the >>>>> bootloader does not need the board-id/msm-id fields, doesn't it? >>>> >>>> If that were the case, I would have never complained about this! It's >>>> the bootloader itself that needs it, you can see it in a "Best match >>>> [blah blah] 258/0x1000/...." log line, where it walks through the >>>> appended (or otherwise compiled into the boot.img) DTBs and looks for >>>> matches for the burnt-in msm-, board- and (on newer-older platforms) >>>> pmic-id. If it cannot find these, it refuses to boot with an Android >>>> Verified Boot red state and you get a not-so-nice "Your device has been >>>> unlocked and the boot image is not working" or something like this on >>>> your screen. >>>> >>>> >>>>> >>>>> Not mentioning that in the past bootloader was actually not using these >>>>> properties at all, because it was the dtbTool who was parsing them. >>>> >>>> Not sure when that was the case, maybe with very old arm32 bootloaders >>>> in the times before I did development on Qualcomm devices. >>>> >>>> >>>>> So >>>>> in any case either your device works fine without these properties or >>>>> you have to use dtbTool, right? >>>> >>>> To the best of my idea, wrong :( Unless the vendor modified the LK/XBL >>>> code on their own, it looks for a "best match" (but if it's not a >>>> precise match, it won't even bother trying to boot, just fyi..), meaning >>>> it tries to go through a list of SoC ID and revision pairs (msm-id), >>>> board IDs (board-id) and PMIC id+rev pairs (pmic-id) and if no match is >>>> found, it doesn't even exit the bootloader and says something like "no >>>> dtbs found". >>> >>> This would mean that dtbTool as described in the actual patch [1] is not >>> used and bootloader ignores the table. If that's the case, the commit >>> and requirement of such complex board-foundry-pmic-compatibles should be >>> dropped. So I am getting now to what Dmitry said... >>> >>> [1] >>> https://lore.kernel.org/all/1448062280-15406-2-git-send-email-sboyd@codeaurora.org/ >> >> >> The link above is from 2015. Lot has changed downstream. Most of what was >> mentioned by Konrad is right. Application bootloader acts on picking on >> platform DTBO based on the platform ID plus some combinations like PMIC etc; >> These platform DTBOs gets overlay on top of SOC DTB by the Application >> bootloader. >> >> We have moved to DTBO for all the latest targets, but I can understand that >> some old targets at upstream could be using the very old approaches. >> >> Downstream all of the platforms including the DTBO files will need board-id >> and msm-id since we also do the compile time stitching of dtb + dtbo and >> dtbo + dtbo to generate the proper SOC DTB and PLATFORM DTBOs which gets >> flashed in the DTBO partition and follows the Android boot requirements. >> Application bootloader then picks the right Platform DTBO as mentioned above >> w/ the right SOC DTB. It gets more complicated w/ GKI new requirements every >> year (better for GKI, may not be better for upstream kernel + downstream >> bootloader combination). >> > > FWIW, this doesn't fit with the upstream model at all. In particular the > DTBO that comes with the devices are not compatible with any upstream > DTB. > > As such, the first step to run an upstream DTB+kernel is to zero out the > dtbo partitions. > > > With the DTBO cleared, most devices (all Qualcomm reference devices) can > be booted with the dtb appended to the Image.gz, without the > qcom,{board,msm}-id. As such I would say things are working okay > currently. >
Thanks. Yup, I know things are working fine right now. May be we can look at changing the downstream bootloader so that you don't need to erase the DTBO partition for reference/unlocked devices. No promise, but it will make easy for anyone do the upstream development on the reference devices.
---Trilok Soni
| ![\](/images/icornerr.gif) |