[Top][All Lists]

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

Re: [Qemu-devel] [PATCH] vexpress fix flash device-width

From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH] vexpress fix flash device-width
Date: Thu, 5 Jan 2017 18:32:20 +0000

On 22 December 2016 at 14:02, David Engraf <address@hidden> 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:
(the other details of patch formatting are mostly nice-to-haves,
but the s-o-by line is a hard requirement.)

-- PMM

reply via email to

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