Hi Jim, Jim Quinlan <james.quinlan@xxxxxxxxxxxx> (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@xxxxxxxxxxx> Cheers, -- Cyril Brulebois (kibi@xxxxxxxxxx) <https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
Attachment:
signature.asc
Description: PGP signature
