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

[Cyril Brulebois]

Hi Jim,

Jim Quinlan <james.quinlan at broadcom.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 at debamax.com>


Cheers,
-- 
Cyril Brulebois (kibi at debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20230503/bf82d5f0/attachment.sig>