qemu-block
[Top][All Lists]
Advanced

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

Re: [Qemu-block] [Qemu-devel] [PATCH 00/10] block/pflash_cfi02: Implemen


From: Stephen Checkoway
Subject: Re: [Qemu-block] [Qemu-devel] [PATCH 00/10] block/pflash_cfi02: Implement missing AMD pflash functionality
Date: Tue, 9 Apr 2019 14:00:24 -0400


On Apr 9, 2019, at 12:15, Philippe Mathieu-Daudé <address@hidden> wrote:

> Since you did changes in the CFI table, I think we should add a tests
> verifying the table is correctly generated for all you FlashConfig entries.

That's a good idea. Some of the values are essentially arbitrary (e.g., how 
long an erase typically takes) but the CFI values that indicate support for 
erase/suspend and erase regions at least should be tested. I'll take a closer 
look at what all I changed (it has been a few months since I wrote the code). 
Are there any in particular you think I should be sure to test? Do you want me 
to add those tests to the appropriate patches in the series or would you like 
an additional patch that adds those tests? (The later is easier to do as 
modifying the earlier patches in the series are likely to cause conflicts with 
later patches that I'd need to resolve, but I can do either.)

> I suppose you can not share the firmware binary. Can you share these
> unlock addresses? Maybe once I reviewed carefully your series I might
> ask you the (pflash) trace event output.

I probably cannot share the binary but the unlock addresses are 0x1554 and 
0x2AA8. This is for two interleaved x8/x16 chips in x16 mode so shifting right 
by 2 (1 for the interleaving and 1 because it's an x16 chip) gives 0x555 and 
0xAAA. The appropriate (word) unlock addresses for the chips are 0x555 and 
0x2AA which is what you get if you restrict to 11 bits.

My guess is that the firmware authors took the byte unlock addresses (0xAAA and 
0x555), shifted left by 2, discovered that this didn't work, tried the unlock 
addresses in the opposite order, and found that that worked due to the chips 
only looking at 11 bits.

Looking at hw/arm/musicpal.c, I see that it is using unlock addresses 0x5555 
and 0x2AAA. My guess is this reflects a bug in some firmware and it should be 
using 0x555 and 0x2AA. I haven't seen any AMD pflash chips that used other 
unlock addresses, but I've only looked at about a dozen part sheets and I'm not 
sure what chips the musicpal is actually using.


-- 
Stephen Checkoway








reply via email to

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