linux-kernel - Re: [PATCH v4 0/5] PCI: brcmstb: Configure appropriate HW CLKREQ# mode

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:   Wed, 3 May 2023 21:10:37 +0200
From:   Cyril Brulebois <kibi@...ian.org>
To:     Jim Quinlan <james.quinlan@...adcom.com>
Cc:     Jim Quinlan <jim2101024@...il.com>, linux-pci@...r.kernel.org,
        Nicolas Saenz Julienne <nsaenz@...nel.org>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Phil Elwell <phil@...pberrypi.com>,
        bcm-kernel-feedback-list@...adcom.com,
        Krzysztof Wilczyński <kw@...ux.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Lorenzo Pieralisi <lpieralisi@...nel.org>,
        Rob Herring <robh@...nel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" 
        <linux-arm-kernel@...ts.infradead.org>,
        open list <linux-kernel@...r.kernel.org>,
        "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" 
        <linux-rpi-kernel@...ts.infradead.org>
Subject: Re: [PATCH v4 0/5] PCI: brcmstb: Configure appropriate HW CLKREQ#
 mode

Hi Jim,

Jim Quinlan <james.quinlan@...adcom.com> (2023-05-03):
> >                            +----------+----------+----------+
> >                            |   006    |   006S   |   VIA    |
> >   +------------------------+----------+----------+----------+
> >   | 1. CM4 Lite Rev 1.0    |    KP*   |    KP*   |  OK, 72  |
> >   |    pristine            |          |          |          |
> >   +------------------------+----------+----------+----------+
> >   | 2. CM4 Lite Rev 1.0    |  boot +  |  OK, 72  |  OK, 72  |
> >   |    + brcm,enable-l1ss  | timeouts |          |          |
> >   +------------------------+----------+----------+----------+
> >   | 3. CM4 8/32 Rev 1.0    |    KP    |    KP    |    KP    |
> >   |    pristine            |          |          |          |
> >   +------------------------+----------+----------+----------+
> >   | 4. CM4 8/32 Rev 1.0    |  OK, 69  |  OK, 69  |  OK, 69  |
> >   |    + brcm,enable-l1ss  |          |          |          |
> >   +------------------------+----------+----------+----------+
> >   | 5. CM4 4/32 Rev 1.1    |  boot +  |  OK, 69  |  OK, 69  |
> >   |    pristine            | timeouts |          |          |
> >   +------------------------+----------+----------+----------+
> >   | 6. CM4 4/32 Rev 1.1    |  OK, 82  |  OK, 69  |  OK, 69  |
> >   |    + brcm,enable-l1ss  |          |          |          |
> >   +------------------------+----------+----------+----------+
> 
> Hello Cyril,
> 
> I'm confused by your result table above which has a number of
> failures.  Further in your message you say:
> 
> Takeaways:
>  - Upgrading the EEPROM solved all problems;
>  - brcm,enable-l1ss (which used to help) is not needed [...]
> 
> May I conclude that if one uses a modern CM4 eeprom that these
> failures go away?

Sorry that wasn't clear enough. The table with failures, quoted above,
was with 3 compute modules in their stock configuration:
 - CM4 Lite Rev 1.0 (lines 1-2) had an 2021-02-16 EEPROM;
 - CM4 8/32 Rev 1.0 (lines 3-4) had an 2021-02-16 EEPROM;
 - CM4 4/32 Rev 1.1 (lines 5-6) had an 2021-12-02 EEPROM.

Upgrading them all to current 2023-01-11 led to the second table when I
tested again, where everything worked fine.

The 2 versions (2021-02-16 and 2021-12-02) are marked as stable in the
rpi-eeprom.git repository.

> You mentioned in a personal email that at least one of your "CM4" was
> running a Beta eeprom image.

That one was another CM4 Lite Rev 1.0, and had a 2020-10-02 EEPROM. That
one is marked as an old beta in the rpi-eeprom.git. (That CM4 Lite also
works very fine once the current 2023-01-11 is deployed on it.)

[Regarding EEPROM variety in the field: I've mentioned this topic on the
#debian-raspberrypi IRC channel, warning others about troubles that
might be linked to the EEPROM version. I've seen at least one CM4 user
report the 2020-10-02 beta EEPROM, and another one report a different
2022-04-26 stable EEPROM.]

> I'm much less concerned about folks having problems with old  or
> pre-release versions of the CM4 eeprom because (a) most of these folks
> are using Raspian Linux anyway and (b) they can just upgrade their
> eeprom.

That looks totally fair to me. So I can stop here, wait for the next
iteration of your patch series if there's one (rechecking everything
still works fine), and only the latest EEPROM matters? Sounds good.

> Further, the Rpi eeprom is closed-source and my questions on the Rpi
> forum  and Rpi Github have not yet led to any answers  about why a
> different eeprom image is changing the behavior of a clkreq signal.

The following doesn't shed much light but seems consistent with results
getting better with newer EEPROM versions (a number of “PCIe” hits, some
about probing, some about resets):
  https://github.com/raspberrypi/rpi-eeprom/blob/master/firmware/release-notes.md

[If I had known how much of a difference an upgraded EEPROM would make,
and how easy it is to upgrade, I would have probably bothered you much
less with all those weird results… Sorry about that.]


The whole series is:

Tested-By: Cyril Brulebois <cyril@...amax.com>


Cheers,
-- 
Cyril Brulebois (kibi@...ian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)