could it be a almost dead cmos battery?
maybe? it shouldnāt though.
related side-question:
How does a CMOS clear work on āmodern consumerā mainboards?
If I understand correctly on Chromebooks, information like memory training data is stored in SMMSTORE on the SPI flash. I assume this is the same on consumer mainboards, right? Or do they actually have a separate CMOS chip?
So if you remove all power including the CMOS battery, this information is not lost automatically. Is the firmware on next power-up purposefully clearing information from SPI flash in order to emulate behavior of CMOS?
The behavior is certainly like this on my AM5 board. If I remove power (including the button cell), all firmware settings are restored to default and the first boot takes ages for the DDR5 memory training.
1 Like
memory training data is cached on the SPI flash chip, where is arbitrary. coreboot uses one or more MRC_CACHE regions. SMMSTORE is used only for UEFI NVRAM.
CMOS is used for RTC and thatās about it
some (non-ChromeOS) devices might store a NVRAM hash in CMOS and invalidate their NVRAM settings if the CMOS is cleared / hash is cleared.
2 Likes
Once the update is released and ill update and feedback if this bug or problem is fixed
I have no reason to suspect that it will be magically fixed in the new release, there are no changes which affect this device or platform
Okay then, Iāll stick with this setup for now until a solution is found, but still thank you for taking the time to look into the issue!