From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=34723 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pxo3E-0002AH-CI for qemu-devel@nongnu.org; Thu, 10 Mar 2011 17:09:47 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pxo30-0004Yf-8n for qemu-devel@nongnu.org; Thu, 10 Mar 2011 17:09:31 -0500 Received: from mailout-de.gmx.net ([213.165.64.22]:42517) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1Pxo2z-0004YV-Qg for qemu-devel@nongnu.org; Thu, 10 Mar 2011 17:09:30 -0500 Message-ID: <4D794C56.6020809@gmx.net> Date: Thu, 10 Mar 2011 23:10:30 +0100 From: Carl-Daniel Hailfinger MIME-Version: 1.0 Subject: Re: [Qemu-devel] RFC: emulation of system flash References: <4D794489.6010903@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jordan Justen Cc: Gleb Natapov , Stefan Hajnoczi , qemu-devel , Michal Suchanek , Kevin O'Connor , Avi Kivity 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. For me, that looks pretty simple and straightforward, especially compared to other more exotic flash chip interfaces. Regards, Carl-Daniel -- http://www.hailfinger.org/