On Thu, Jul 02, 2015 at 07:42:39PM +0200, Alexander Couzens wrote:
Hi,
I mentioned some problems while debugging windows on a x201. Also linux throw a warning with the RTC, but it could recover the correct time. coreboot multiple use of one nvram byte on lots of boards. On most board 0x32/b400 is used by some nvram settings as well as the OS interprets the time (century) from the same byte. The century byte saves the century in bcd format. The default location is 0x32 / b400.
find src/mainboard/ -iname cmos.layout | xargs grep -h '^400' | sort | uniq -c 112 400 1 e 1 power_on_after_fail 33 400 1 e 2 hyper_threading 1 400 8 h 0 century
this is probably winent/mb6047, which I recently fixed.
9 400 8 h 0 volume 1 400 8 r 0 stumpy_usb_reset_disable 2 400 8 h 0 volume# 37 boards can be removed from this list, because they disabled the century byte in facp.
This leads to 3 topic:
- how can we change cmos.layout in a way no or less settings gets lost? e.g. add a version field and a way to migrate these. or do we ignore the loss of data?
Doesn't look like any of the affected settings are extremely important.
- do we want to support the century byte?
We pretty much have to. Between all the FACPs that say to use it and the OSes (such as NetBSD) that look at byte 0x32 for the century without checking the FACP.
- how do we fix the multiusage, because it makes problems atm.
I say we mark it like I did mb6047 or mark it reserved. Also we probably have a problem with checksumming come January 1st 2100 A.D....
Jonathan Kollasch