On Apr 9, 2019, at 12:15, Philippe Mathieu-Daudé <phi...@redhat.com> 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