From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=49129 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OwHfC-00036U-MS for qemu-devel@nongnu.org; Thu, 16 Sep 2010 12:50:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OwHes-0006LR-Fu for qemu-devel@nongnu.org; Thu, 16 Sep 2010 12:50:03 -0400 Received: from moutng.kundenserver.de ([212.227.17.8]:52045) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OwHes-0006KL-2d for qemu-devel@nongnu.org; Thu, 16 Sep 2010 12:50:02 -0400 Message-ID: <4C924AB5.1030802@mail.berlios.de> Date: Thu, 16 Sep 2010 18:49:57 +0200 From: Stefan Weil MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] CMOS file support References: <1284645517-32743-1-git-send-email-mathias.krause@secunet.com> In-Reply-To: <1284645517-32743-1-git-send-email-mathias.krause@secunet.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mathias Krause Cc: qemu-devel@nongnu.org Am 16.09.2010 15:58, schrieb Mathias Krause: > 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 > --- > hw/mc146818rtc.c | 62 ++++++++++++++++++++++++++++++++++++++++++++++++----- > 1 files changed, 56 insertions(+), 6 deletions(-) > > [snip] The intention of this patch is ok. Loading CMOS with initial data is needed. I just want to add two questions / remarks how the implementation might be improved. Are there use cases where having a smaller CMOS size is better? For example, when I want to emulate a system with 128 byte CMOS? The size of CMOS could be derived from the size of the data or specified by an additional parameter. Using QEMU's block devices instead of a simple file would be more consistent with the rest of QEMU and allow reading the CMOS data not only from a file but also from an URL or other sources. Regards Stefan