From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KiUl6-0006mZ-UT for qemu-devel@nongnu.org; Wed, 24 Sep 2008 09:50:24 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KiUl2-0006ig-2L for qemu-devel@nongnu.org; Wed, 24 Sep 2008 09:50:23 -0400 Received: from [199.232.76.173] (port=48605 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KiUl1-0006iU-SC for qemu-devel@nongnu.org; Wed, 24 Sep 2008 09:50:19 -0400 Received: from the-doors.enix.org ([193.19.211.1]:44263) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KiUl0-0008WS-Ag for qemu-devel@nongnu.org; Wed, 24 Sep 2008 09:50:18 -0400 Received: from surf (localhost [127.0.0.1]) by the-doors.enix.org (Postfix) with ESMTP id BA25E91C84 for ; Wed, 24 Sep 2008 15:50:16 +0200 (CEST) Date: Wed, 24 Sep 2008 15:50:05 +0200 From: Thomas Petazzoni Message-ID: <20080924155005.31dacb9f@surf> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/44up33BG/7bsOBZetFdITG="; protocol="application/pgp-signature"; micalg=PGP-SHA1 Subject: [Qemu-devel] Issue when using Flash emulation on Versatile PB platform Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org --Sig_/44up33BG/7bsOBZetFdITG= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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-wcy= cle With this patch in place, I don't have the =C2=ABUnimplemented flash cmd sequence=C2=BB 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: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Does anyone has a clue on what's happening ? Or maybe just an hint on how to debug this problem ? Thanks, Thomas --=20 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 --Sig_/44up33BG/7bsOBZetFdITG= Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFI2kWk9lPLMJjT96cRAmaMAJ0Y8g/P4MlpmmAtowkVv+c/mX84NgCguGsF 8gYhYPpkAU+JcZPCeRV+haA= =z8IB -----END PGP SIGNATURE----- --Sig_/44up33BG/7bsOBZetFdITG=--