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@xxxxxxxxxxxxxx/ Best regards, Krzysztof
