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

[Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>]

Hi Jordan,

thanks for your insights.

Auf 10.03.2011 23:29, Jordan Justen schrieb:
> On Thu, Mar 10, 2011 at 14:10, Carl-Daniel Hailfinger
> <c-d.hailfinger.devel.2006@gmx.net> wrote:
>   
>> Auf 10.03.2011 22:55, Jordan Justen schrieb:
>>     
>>> On Thu, Mar 10, 2011 at 13:37, Carl-Daniel Hailfinger
>>> <c-d.hailfinger.devel.2006@gmx.net> wrote:
>>>       
>>>> 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.
>>     
> I disagree that you think my proposal is more complicated than this example.
>   

Upon rereading your proposal, I think the unfamiliarity of the proposed
interface and the index/data design triggered my "complicated" reflex.


> But, I would agree, that all other things being equal, emulating a
> real device would be preferable.
>
> I would like to know what people's thoughts are regarding supporting
> various devices sizes.  I think that right now -bios should support
> files sizes that are multiples of 64kb up to ~16MB.  (Perhaps even
> larger.)
>   

On recent Intel chipsets you are limited to 16 MB mapped to the top of
the 32bit address space. The same limitation exists for most other x86
chipsets as well. That said, some people may want bigger images, but for
x86 this may cause conflicts with the HPET region.


> A large -bios file can be interesting for embedding an OS image into
> the rom/flash device...
>   

I've seen people embed coreboot+Linux+X.org into a 4 MB image on x86, so
I think 16 MB are plenty (flash bigger than that is either NAND or
expensive or slow, and would require significant effort to emulate
correctly (NAND) or simply not exist in consumer equipment for
speed/money reasons).


> Carl-Daniel, do you think we can address this while still supporting
> real hardware emulation?
>   

If we restrict ourselves to the 128kB-16MB range, I think I can find a
flash chip family which has the criteria we want. 64 kByte flash chips
still exist, but usually not as part of a family which reaches 16 MByte.

We should decide first if we want SPI flash or Parallel flash, and then
I can try to find a matching flash chip family.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/