[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 00/10] block/pflash_cfi02: Implement missing AMD
From: |
Stephen Checkoway |
Subject: |
Re: [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
- [Qemu-devel] [PATCH 04/10] block/pflash_cfi02: Implement intereleaved flash devices, (continued)
- [Qemu-devel] [PATCH 04/10] block/pflash_cfi02: Implement intereleaved flash devices, Stephen Checkoway, 2019/04/08
- [Qemu-devel] [PATCH 05/10] block/pflash_cfi02: Implement nonuniform sector sizes, Stephen Checkoway, 2019/04/08
- [Qemu-devel] [PATCH 07/10] block/pflash_cfi02: Fix reset command not ignored during erase, Stephen Checkoway, 2019/04/08
- [Qemu-devel] [PATCH 08/10] block/pflash_cfi02: Implement multi-sector erase, Stephen Checkoway, 2019/04/08
- [Qemu-devel] [PATCH 10/10] block/pflash_cfi02: Use the chip erase time specified in the CFI table, Stephen Checkoway, 2019/04/08
- [Qemu-devel] [PATCH 09/10] block/pflash_cfi02: Implement erase suspend/resume, Stephen Checkoway, 2019/04/08
- Re: [Qemu-devel] [PATCH 00/10] block/pflash_cfi02: Implement missing AMD pflash functionality, no-reply, 2019/04/08
- Re: [Qemu-devel] [PATCH 00/10] block/pflash_cfi02: Implement missing AMD pflash functionality, Philippe Mathieu-Daudé, 2019/04/09