* [Qemu-devel] Issue when using Flash emulation on Versatile PB platform
@ 2008-09-24 13:50 Thomas Petazzoni
0 siblings, 0 replies; only message in thread
From: Thomas Petazzoni @ 2008-09-24 13:50 UTC (permalink / raw)
To: qemu-devel
[-- Attachment #1: Type: text/plain, Size: 3329 bytes --]
Hi,
I am currently trying to add Flash emulation to the ARM Versatile PB
platform support. I've done this by calling pflash_cfi01_register() in
the versatilepb initialization code. See the patch at:
http://toulibre.org/~thomas/qemu/add-flash-support-to-versatilepb
With this patch in place, the MTD layer of the Linux kernel running
under Qemu is able to detect the flash, and with the proper mtdparts
kernel arguments, I'm able to see a Flash partition in /proc/mtd. So
everything looks fine.
But, when I try to use the erase_flash tool from mtd-tools to erase the
flash, it hangs during the erase procedure. First, I add an
"unimplemented command" message from the Flash emulation:
pflash_write: Unimplemented flash cmd sequence (offset 00000000,
wcycle 0x1 cmd 0x20 value 0x70)
The command 0x70 (status register) was issued after the erase confirm
command by the kernel MTD layer. But in the erase confirm command
emulation of Qemu, pfl->wcycle was set to 1 and not reset to 0, so that
the 0x70 command was misinterpreted (this is my interpretation of the
issue, but I'm might be wrong since my knowledge of the Intel Flash
protocol is limited). I've that problem using the patch available at:
http://toulibre.org/~thomas/qemu/pflash-cfi01-after-erase-confirm-reset-wcycle
With this patch in place, I don't have the «Unimplemented flash cmd
sequence» anymore, but the erase process still hangs. The Qemu monitors
tells me that r15 is 0xffff000c and that r14 is 0xffff0010, which seems
to indicate that a prefetch abort exception has been raised, but I have
no idea why, what is the faulting address, etc. The hang doesn't happen
at the exact same place every time, it seems to appear more and less
randomly during the erase procedure (single setting in gdb of the
kernel execution seems to tell that the hang occur during the
do_erase_oneblock() function in drivers/mtd/chip/cfi_cmdset0001.c).
For reference, here is the execution log of the flash erase process,
with pflash emulation debugging enabled:
=========================================================================
MTD_open
Erase Total 1 Units
MTD_ioctl
MTD_ioctl
Performing Flash Erase of length 262144 at offset 0x0MTD_ioctl
PFLASH: pflash_write: offset 00000000 value/cmd 00000050 width 4 wcycle 0x0
PFLASH: pflash_write: Clear status bits
PFLASH: pflash_write: offset 00000000 value/cmd 00000020 width 4 wcycle 0x0
PFLASH: pflash_write: block erase at 00000000 bytes 00040000
PFLASH: pflash_write: offset 00000000 value/cmd 000000d0 width 4 wcycle 0x1
PFLASH: pflash_read: reading offset 00000000 under cmd 20
PFLASH: pflash_read: status 80
PFLASH: pflash_write: offset 00000000 value/cmd 00000070 width 4 wcycle 0x0
PFLASH: pflash_write: Read status register
PFLASH: pflash_read: reading offset 00000000 under cmd 70
PFLASH: pflash_read: status 80
=========================================================================
Does anyone has a clue on what's happening ? Or maybe just an hint on
how to debug this problem ?
Thanks,
Thomas
--
Thomas Petazzoni, thomas.petazzoni@enix.org, http://thomas.enix.org
Jabber, thomas.petazzoni@jabber.dk
Toulibre, http://www.toulibre.org - APRIL, http://www.april.org
Fingerprint : 0BE1 4CF3 CEA4 AC9D CC6E 1624 F653 CB30 98D3 F7A7
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2008-09-24 13:50 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-09-24 13:50 [Qemu-devel] Issue when using Flash emulation on Versatile PB platform Thomas Petazzoni
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).