Stephen Checkoway <stephen.checko...@oberlin.edu> writes: > On Feb 19, 2019, at 01:09, Markus Armbruster <arm...@redhat.com> wrote: > >> Stephen Checkoway <stephen.checko...@oberlin.edu> writes: >> >>> On Feb 18, 2019, at 13:08, Markus Armbruster <arm...@redhat.com> 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!
