Re: [Qemu-devel] Testing sysbus devices

[Markus Armbruster]

Stephen Checkoway <address@hidden> writes:

> On Feb 19, 2019, at 01:09, Markus Armbruster <address@hidden> wrote:
>
>> Stephen Checkoway <address@hidden> writes:
>> 
>>> On Feb 18, 2019, at 13:08, Markus Armbruster <address@hidden> wrote:
>>> 
>>>> Any chance you could do multiple region support, too?
>>> 
>>> Can you point me at the data sheet for a flash chip with multiple region 
>>> support? For my purposes, I only need the features I mentioned, but if it's 
>>> a simple change, I'll consider it.
>> 
>> I'm not familiar with CFI pflash, but I can operate a search engine.
>> Have a look at page 27 and 56 of
>> 
>> https://media.digikey.com/pdf/Data%20Sheets/Intel%20PDFs/28F160C3,320C3,640C3,800C3%20(x16).pdf
>> 
>> and tell us whether it's helpful.
>
> That's a flash chip that uses the Intel command set (pflash_cfi01.c in
> qemu), I'm only touching the AMD command set (pflash_cfi02.c). Also
> those pages seem to be about block locking, not multiple regions.
>
> I'm not entirely sure what you meant by multiple regions. If you meant
> blocks* having different sizes (usually in the top or bottom of the
> flash as boot blocks), then I've implemented that (the nonuniform
> sectors* I mentioned in my first email).
>
> * Some flash chips differentiate between sectors and blocks. E.g., the
> flash chip used by hw/arm/musicpal.c
> <http://ww1.microchip.com/downloads/en/DeviceDoc/SST39VF6401B-SST39VF6402B-64-Mbit-x16-Multi-Purpose-Flash-Plus-Data-Sheet-DS20005008C.pdf>
> has sectors and blocks with separate erase commands. Qemu treats these
> the same and does not support separate erase commands.

My terminology might be confused...

Let me backtrack a bit an explain my use case.  On physical PCs, the
single flash chip is commonly configured to have a read-only part and a
read/write part.  The read-only part holds UEFI code, and the read-write
part holds its persistent state.

Since our virtual flash chips lack this feature, our virtual PCs have
*two* of them: one configured read-only, and one configured read/write.
Cleaning that up would be nice.

The comment "It does not implement software data protection as found in
many real chips" in both pflash_cfi0*.c might be referring to this
missing feature.

>> I think a test would be quite welcome even if it only tests what's
>> testable now with reasonable effort.
>
> I used Thomas Huth's suggestion for testing the autoselect, CFI,
> sector erase, chip erase, programming, and reset commands. I'll see
> how much I can test.

Sounds good!