From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=57664 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Oz7bI-00042h-AE for qemu-devel@nongnu.org; Fri, 24 Sep 2010 08:42:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Oz7bH-0007OT-BF for qemu-devel@nongnu.org; Fri, 24 Sep 2010 08:42:04 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37784) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Oz7bH-0007ON-4z for qemu-devel@nongnu.org; Fri, 24 Sep 2010 08:42:03 -0400 From: Markus Armbruster Subject: Re: [Qemu-devel] [PATCH] CMOS file support References: <1284645517-32743-1-git-send-email-mathias.krause@secunet.com> <4C9251C6.2090705@codemonkey.ws> Date: Fri, 24 Sep 2010 14:42:00 +0200 In-Reply-To: <4C9251C6.2090705@codemonkey.ws> (Anthony Liguori's message of "Thu, 16 Sep 2010 12:20:06 -0500") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Mathias Krause , qemu-devel@nongnu.org Anthony Liguori 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 >> > > 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.