Re: [Qemu-devel] Testing sysbus devices

[Stephen Checkoway]

> On Feb 19, 2019, at 10:28, Markus Armbruster <address@hidden> wrote:
> 
> 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 understand now, thank you for explaining. I noticed the comments about 
software data protection in the code, but I didn't investigate.

From a quick look at <https://www.cypress.com/file/195291/download> Table 27 on 
page 8, I see there are at least 4 different protection modes. I think the most 
common one (based on my reading of a handful of data sheets for flash chips) is 
the high voltage one. Essentially, there are sector groups that can be 
locked/unlocked using high voltage. It seems easy enough to model this by 
configuring sectors as locked and refusing to erase or program them.

Software command locking would probably involve implementing a few additional 
commands.

I'm not sure what the others are.

Which locking method do you need?

-- 
Stephen Checkoway