qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] Issue when using Flash emulation on Versatile PB platform


From: Thomas Petazzoni
Subject: [Qemu-devel] Issue when using Flash emulation on Versatile PB platform
Date: Wed, 24 Sep 2008 15:50:05 +0200

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, address@hidden, http://thomas.enix.org
Jabber, address@hidden
Toulibre, http://www.toulibre.org - APRIL, http://www.april.org
Fingerprint : 0BE1 4CF3 CEA4 AC9D CC6E  1624 F653 CB30 98D3 F7A7

Attachment: signature.asc
Description: PGP signature


reply via email to

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