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.
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.
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!
Hey everyone,
Big news for those of us running 10th-gen (Comet Lake) Chromeboxes! If youâve been dealing with those annoyingly long hangs during a cold boot, the latest MrChromebox-2603.0 firmware release is officially out and addresses this head-on.