On Fri, 29 Apr 2022, Thomas Bogendoerfer wrote:
Fix the discrepancy between the two places we check for the CP0 counter erratum in along with the incorrect comparison of the R4400 revision number against 0x30 which matches none and consistently consider all R4000 and R4400 processors affected, as documented in processor errata publications[1][2][3], following the mapping between CP0 PRId register values and processor models:
PRId | Processor Model ---------+-------------------- 00000422 | R4000 Revision 2.2 00000430 | R4000 Revision 3.0 00000440 | R4400 Revision 1.0 00000450 | R4400 Revision 2.0 00000460 | R4400 Revision 3.0
interesting, where is this documented ? And it's quite funny that so far everybody messed up revision printing for R4400 CPUs.
That's just observation combined with past discussions with Ralf.
Basically the PRId implementation number is 0x04 for both the R4000 and the R4400 (the only difference between the two CPUs is the addition of the write-back buffer in the latter one, making it weakly ordered). And then the PRId revision number matches exactly the documented CPU revision for the R4000, while for the R4400 you need to subtract 3 from the PRId revision number to get the documented CPU revision (i.e. what would be R4000 Revision 4.0 actually became R4400 Revision 1.0).
At this time no old MIPSer from the SGI days may be around to confirm or contradict this observation. Documentation explicitly says[1]:
"The revision number can distinguish some chip revisions, however there is no guarantee that changes to the chip will necessarily be reflected in the PRId register, or that changes to the revision number necessarily reflect real chip changes. For this reason, these values are not listed and software should not rely on the revision number in the PRId register to characterize the chip."
but surely the author didn't have errata workarounds in mind plus all CPU revisions have already been manufactured so the mapping has been fixed.
Conversely a system can do without a high-precision clock source, in which case jiffies will be used. Of course such a system will suffer if used for precision timekeeping, but such is the price for broken hardware. Don't SNI systems have any alternative timer available, not even the venerable 8254?
all SNI systems have a i8254 in their EISA/PCI chipsets. But they aren't that nice for clock events as their interupts are connected via an i8259 addresses via ISA PIO.
Interrupts are used for clock events, so you don't need one here. For clock sources you just read the counter.
That said reading from the 8254 is messy too and you may need a spinlock (you need to write the Counter Latch or Read-Back command to the control register and then issue consecutive two reads to the requested timer's data register[2]). Which is I guess why support for it has been removed from x86 code. For non-SMP it might be good enough.
With the considerations above in mind, please apply.
will do later.
Great, thanks!
References:
[1] Joe Heinrich: "MIPS R4000 Microprocessor User's Manual", Second Edition, MIPS Technologies, Inc., April 1, 1994, Chapter 4 "Memory Management", p.90
[2] "8254 Programmable Interval Timer", Intel Corporation, Order Number: 231164-005, September 1993, Section "Read Operations", pp.7-9
Maciej