diff mbox

vexpress fix flash device-width

Message ID d15e8de4-f7d8-1c28-7e5e-31d0aa10819d@sysgo.com
State New
Headers show

Commit Message

David Engraf Dec. 22, 2016, 2:02 p.m. UTC
The current implementation uses width = 4 and device-width = 2 for the 
flash configuration. When using u-boot or Linux, the flash is detected 
as 32 x 16 bit, thus the sector size is doubled to 512 KB. When u-boot 
sends a sector erase, only the first 256 KB are erased because the QEMU 
flash implementation uses the configured sector size of 256 KB and 
ignores the width and device-width ratio.

This patch will change device-width to 4, thus the width and 
device-width are equal and u-boot detects the flash as 32 x 32 bit with 
the correct sector size of 256 KB.

- David

Comments

Peter Maydell Jan. 5, 2017, 6:32 p.m. UTC | #1
On 22 December 2016 at 14:02, David Engraf <david.engraf@sysgo.com> wrote:
> The current implementation uses width = 4 and device-width = 2 for the flash

> configuration. When using u-boot or Linux, the flash is detected as 32 x 16

> bit, thus the sector size is doubled to 512 KB. When u-boot sends a sector

> erase, only the first 256 KB are erased because the QEMU flash

> implementation uses the configured sector size of 256 KB and ignores the

> width and device-width ratio.

>

> This patch will change device-width to 4, thus the width and device-width

> are equal and u-boot detects the flash as 32 x 32 bit with the correct

> sector size of 256 KB.


Thanks for this patch. However I'm not sure it is correct, because
I think the real hardware does have 2x16 devices here. On real vexpress
TC2 if you boot Linux it detects the flash as:
"8000000.flash: Found 2 x16 devices at 0x0 in 32-bit bank.
Manufacturer ID 0x000089 Chip ID 0x008919"

So while we presumably have a QEMU bug if this isn't behaving
like the hardware, I don't think that changing the device-width to
4 is the right fix for it. Maybe:
 * our erase implementation is broken?
 * one of the other parameters we use to create the flash
   is wrong?
 * the calculation of the erase block information that we put in
   the flash cfi_table[] is wrong?

(Does u-boot hard-code the erase block sizes, or does
it read them from the CFI data? QEMU's flash doesn't have the
hardware's two-eraseblock-regions setup where part of the disk is
256K erase-blocks and part is 64K blocks, but if u-boot doesn't
hardcode that it should be able to read the data from QEMU's
flash implementation.)

Also, for patches to QEMU we need you to provide a
Signed-off-by: line to say that you're happy to contribute the

patch to QEMU. More detail about what this means here:
http://wiki.qemu.org/Contribute/SubmitAPatch#Patch_emails_must_include_a_Signed-off-by:_line
(the other details of patch formatting are mostly nice-to-haves,
but the s-o-by line is a hard requirement.)

thanks
-- PMM
diff mbox

Patch

diff --git a/hw/arm/vexpress.c b/hw/arm/vexpress.c
index 58760f4..85ec347 100644
--- a/hw/arm/vexpress.c
+++ b/hw/arm/vexpress.c
@@ -526,7 +526,7 @@  static pflash_t *ve_pflash_cfi01_register(hwaddr base, const char *name,
                          VEXPRESS_FLASH_SIZE / VEXPRESS_FLASH_SECT_SIZE);
     qdev_prop_set_uint64(dev, "sector-length", VEXPRESS_FLASH_SECT_SIZE);
     qdev_prop_set_uint8(dev, "width", 4);
-    qdev_prop_set_uint8(dev, "device-width", 2);
+    qdev_prop_set_uint8(dev, "device-width", 4);
     qdev_prop_set_bit(dev, "big-endian", false);
     qdev_prop_set_uint16(dev, "id0", 0x89);
     qdev_prop_set_uint16(dev, "id1", 0x18);