Message-ID: <Yov99WPNrGRg86sS@builder.lan>
Date:   Mon, 23 May 2022 16:34:45 -0500
From:   Bjorn Andersson <bjorn.andersson@...aro.org>
To:     Trilok Soni <quic_tsoni@...cinc.com>
Cc:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        Konrad Dybcio <konrad.dybcio@...ainline.org>,
        agross@...nel.org, arnd@...db.de, 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 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.

Regards,
Bjorn

Powered by blists - more mailing lists