Anthony Liguori <anth...@codemonkey.ws> writes: > On 09/16/2010 08:58 AM, Mathias Krause wrote: >> In contrast to the BIOS and Option ROMs the CMOS content cannot be >> predefined by the user. Also the amount of useable CMOS ARM is pretty >> limited, even though the amount of CMOS bytes emulated by qemu is >> already twice as much as of the original MC146818. Nevertheless those >> limitations are pretty annoying when testing different BIOS replacement >> implementations like coreboot in combination with FILO that use CMOS >> values above the basic RTC range for its own purpose to, e.g., control >> the boot device order using a string containing the boot devices to >> probe. >> >> This patch adds support to specify a file to read the initial CMOS >> content from. It also increases the CMOS size to 256 bytes and >> implements access to the extended memory range via I/O ports 0x72 and >> 0x73. >> >> Use it like: `qemu -global mc146818rtc.file=cmos.bin ...' where cmos.bin >> is a binary file, sized 256 bytes containing the CMOS RAM. >> >> Signed-off-by: Mathias Krause<mathias.kra...@secunet.com> >> > > Instead of using FILE, I'd suggest using a BlockDriver to read and > write the data. > > I think it would be very nice to add write support too so that writes > to CMOS were persisted across boots.
Persisting CMOS makes it state instead of configuration. Use of block layer (treat it like a drive) makes more sense then.
