From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=58785 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PxqBv-000890-Tv for qemu-devel@nongnu.org; Thu, 10 Mar 2011 19:26:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PxqBq-00023N-55 for qemu-devel@nongnu.org; Thu, 10 Mar 2011 19:26:51 -0500 Received: from mailout-de.gmx.net ([213.165.64.22]:52893) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1PxqBp-00022f-QR for qemu-devel@nongnu.org; Thu, 10 Mar 2011 19:26:46 -0500 Message-ID: <4D796C81.5070801@gmx.net> Date: Fri, 11 Mar 2011 01:27:45 +0100 From: Carl-Daniel Hailfinger MIME-Version: 1.0 References: <4D794489.6010903@gmx.net> <4D794C56.6020809@gmx.net> <4D796A8E.6000204@web.de> In-Reply-To: <4D796A8E.6000204@web.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: RFC: emulation of system flash List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Gleb Natapov , Stefan Hajnoczi , qemu-devel , Michal Suchanek , Kevin O'Connor , Avi Kivity , Jordan Justen Auf 11.03.2011 01:19, Jan Kiszka schrieb: > On 2011-03-10 23:10, Carl-Daniel Hailfinger wrote: > >> Auf 10.03.2011 22:55, Jordan Justen schrieb: >> >>> On Thu, Mar 10, 2011 at 13:37, Carl-Daniel Hailfinger >>> wrote: >>> >>> >>>> Auf 10.03.2011 05:51, Jordan Justen schrieb: >>>> >>>> >>>>> I have documented a simple flash-like device which I think could be >>>>> useful for qemu/kvm in some cases. (Particularly for allowing >>>>> persistent UEFI non-volatile variables.) >>>>> >>>>> http://wiki.qemu.org/Features/System_Flash >>>>> >>>>> Let me know if you have any suggestions or concerns. >>>>> >>>>> >>>>> >>>> Is there any reason why you chose to invent an interface for the flash >>>> chip which is more complicated than the interface used by common flash >>>> chips out there? >>>> Maybe some EFI requirement? >>>> >>>> >>> This is a simpler version than the flash devices I'm used to dealing >>> with for x86/x86-64 UEFI systems. Can you suggest an alternative real >>> interface that is simpler? >>> >>> >> Pseudocode for the real interface most common on x86 before SPI came along: >> >> Write a page (256 bytes) or a few bytes: >> chip_writeb(0xAA, bios_base + 0x5555); >> chip_writeb(0x55, bios_base + 0x2AAA); >> chip_writeb(0xA0, bios_base + 0x5555); >> chip_writeb(databyte0, bios_base + addr); >> chip_writeb(databyte1, bios_base + addr + 1); >> chip_writeb(databyte2, bios_base + addr + 2); >> chip_writeb(databyte3, bios_base + addr + 3); >> ... up to 256 databytes. >> chip_readb(bios_base); >> The last chip_readb(bios_base) is repeated until the result does not >> change anymore. >> > Hmm, I may oversee some subtle difference, but this looks pretty much > like CFI to me (see hw/pflash_cfi02.c). > I thought CFI also implements a way to retrieve device size/geometry with the Query (0x98) command, but that part is rarely implemented on x86 flash (I didn't see any yet). That said, the non-query commands are identical AFAICS. > At least it's an in-band interface, which is the better choice as we > currently only have a PIIX3 southbridge for x86, predating even FWHs. > Right, that pretty much kills the option of using SPI unless someone wants to emulate a flash translation controller (e.g. the ITE IT8716F Super I/O). Can be done, would work, but the IT8716F has some quirks (max 1 MB SPI flash chips) which make it a less desirable option for emulation. Regards, Carl-Daniel -- http://www.hailfinger.org/