I have to agree with you. It is too much trouble especially for a Linux newbie like me.Note the UART connector refers to the physical serial port on the Pi. You can wire the serial port of one Pi to the serial port of the other. Then use a terminal emulator with a logging facility or scroll back buffer.
In my opinion connecting to the serial port is too much trouble just to determine the RAM vendor. I think there must be a way to obtain the same vendor information after the Pi has booted.
On an x86 machine one could use dmidecode to read the vendor strings from the EEPROM on the DIMM but on a Pi this only reportswhich is not at all surprising.Code:
# dmidecode # dmidecode 3.5# No SMBIOS nor DMI entry point found, sorry.
In my opinion it doesn't matter whether the RAM was manufactured by Hynix, Micron or Samsung but only how it performs. It would be nice if someone found or wrote an open-source program that behaved in a way similar to the GeekBench 5 text rendering benchmark to distinguish RAM chips that behave strangely when overclocking.
If I were looking for such a program I'd check bzip2 first and then the other compression utilities. Since most compression utilities are not parallel, four copies likely need to be launched at a time using a script to see the weirdness as clock speed is increased.
Alternatively, one could try "mksquashfs -comp xz" since that program is automatically parallel. If that doesn't trigger the weirdness it might be possible to increase -Xdict-size to 32 or 64 MB.
Anyway, thank you very much for sharing.
Statistics: Posted by AkulaMD — Tue Dec 12, 2023 5:18 am