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 1power_on_after_fail
33 400 1 e 2hyper_threading
1 400 8 h 0century
this is probably winent/mb6047, which I recently fixed.
9 400 8 h 0volume
1 400 8 r 0stumpy_usb_reset_disable
2 400 8 h 0volume
# 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
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
