lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 21 Mar 2022 11:00:02 -0700
From:   Doug Anderson <dianders@...omium.org>
To:     Matthias Kaehlcke <mka@...omium.org>
Cc:     Rajendra Nayak <quic_rjendra@...cinc.com>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Stephen Boyd <swboyd@...omium.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1 2/4] arm64: dts: qcom: sc7280: Add 'piglin' to the
 crd-r3 compatible strings

"Hi,

On Mon, Mar 21, 2022 at 8:14 AM Matthias Kaehlcke <mka@...omium.org> wrote:
>
> On Mon, Mar 21, 2022 at 11:14:56AM +0530, Rajendra Nayak wrote:
> >
> > On 3/17/2022 5:58 AM, Matthias Kaehlcke wrote:
> > > With newer bootloader versions the crd-r3 (aka CRD 1.0 and 2.0) is
> > > identified as a 'piglin' board (like the IDP2 board), instead of 'hoglin'
> > > Add the compatible strings 'google,piglin-rev{3,4}'. The hoglin entries
> > > are kept to make sure the board keeps booting with older bootloader
> > > versions.
> >
> > The older bootloaders really look for the google,hoglin-rev3/google,hoglin-rev4
> > compatibles or just google,hoglin? If its just google,hoglin, won;t it pick the
> > crd-rev5+ dtb now?
>
> They look for the -revN compatible, I confirmed that on my CRD 2.0.

Thanks for confirming Matthias! I'll also note that, in general, these
"google,board-revX" type compatible strings are all programmatically
generated. You can see at:

https://chromium.googlesource.com/chromiumos/platform/depthcharge/+/refs/heads/main/src/boot/fit.c#70

...and whenever it's using this normal logic then it has a standard
fallback mechanism in place. On a random board in front of me
depthcharge prints out:

Compat preference: google,lazor-rev3-sku0 google,lazor-rev3
google,lazor-sku0 google,lazor

So it'll first try the very specific verison with rev and sku. Then
just by rev. Then just by sku. ...and if none of those match it'll
pick a device tree that has neither. The "newest" device tree always
has no revision number specified and that way if software doesn't
change but the revision bumps then we have no problem. We only add the
revision info for old boards.

There are a few cases where we add special compatible strings and
these don't match on board/rev. This is fairly uncommon, though. You
might be aware of the special case of adding "qcom,sc7180-idp"
(without rev/sku matching) for "bubs". See:

https://chromium.googlesource.com/chromiumos/platform/depthcharge/+/refs/heads/main/src/board/trogdor/board.c#136


-Doug

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ