qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: RFC: emulation of system flash


From: Carl-Daniel Hailfinger
Subject: [Qemu-devel] Re: RFC: emulation of system flash
Date: Fri, 11 Mar 2011 01:27:45 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.1.16) Gecko/20101124 SUSE/2.0.11-0.2.1 SeaMonkey/2.0.11

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
>>> <address@hidden> 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/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]