From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IExrl-00065z-7L for qemu-devel@nongnu.org; Sat, 28 Jul 2007 21:46:41 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IExrj-00062t-QZ for qemu-devel@nongnu.org; Sat, 28 Jul 2007 21:46:40 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IExrj-00062d-NT for qemu-devel@nongnu.org; Sat, 28 Jul 2007 21:46:39 -0400 Received: from ug-out-1314.google.com ([66.249.92.173]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IExrj-0007km-6T for qemu-devel@nongnu.org; Sat, 28 Jul 2007 21:46:39 -0400 Received: by ug-out-1314.google.com with SMTP id m2so841199uge for ; Sat, 28 Jul 2007 18:46:37 -0700 (PDT) Message-ID: Date: Sun, 29 Jul 2007 03:46:37 +0200 From: "andrzej zaborowski" Subject: Re: [Qemu-devel] qemu-system-arm -M akita/terrier - which roms work? (more patches... :) In-Reply-To: <20070729011535.GA24527@saturn.kn-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070724011115.GA44643@saturn.kn-bremen.de> <200707242025.l6OKPSnJ010124@saturn.kn-bremen.de> <20070726213747.GA23871@saturn.kn-bremen.de> <20070728001237.GA17097@saturn.kn-bremen.de> <20070729011535.GA24527@saturn.kn-bremen.de> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Juergen Lock Cc: qemu-devel@nongnu.org Hi, On 29/07/07, Juergen Lock wrote: > On Sat, Jul 28, 2007 at 02:12:37AM +0200, Juergen Lock wrote: > > On Sat, Jul 28, 2007 at 12:27:33AM +0200, andrzej zaborowski wrote: > > > On 28/07/07, andrzej zaborowski wrote: > > > > On 26/07/07, Juergen Lock wrote: > > > > > > and now I get lots of > > > > > nand ecc errors and mount failures, I guess the mtdparts= arg isnt right > > > > > yet and/or the raw2flash.c source needs fixing... > > Okay the first reason for this was the terrier kernel doing long reads > from the nand flash io port, expecting to get 2 bytes at a time. > (enabled by CONFIG_ARCH_PXA_TERRIER at least in the sharp kernel), > see patch-nand-terrier (attached). > > > > > > > > Likely the input to raw2flash.c was not what it expected. It expects a > > > > 1:1 image of the entire flash chip (but excluding oob - only data that > > > > can be normally read from /dev/mtblock* and in the same order), and > > > > > > (/dev/mtdblock*) > > > > > > > with a 10 byte header at the start of the file, which is discarded. > > > > > > (rather 16) > > > > Yeah I hat removed that, but was overlooking the fact that it > repeats the first PARTITION_START (0x00700000) bytes in the output, > because it didnt expect this data in the input, and so it just fills > it out. Added another #ifndef which fixed that, see attached > patch-raw2flash-fullimage. The repeating of the first chunk is basically a hack to have jffs2 formatted blocks also before the start of the root partition (in range 0 to 0x00700000) so that Linux doesn't complain that the nand is unformatted. AFAIK the jffs2 driver doesn't care what data is there but it whines if it doesn't have the appearance of a jffs2 partition. > > > > > The partitions layout also matters. This format is the one that > > > > OpenEmbedded outputs, but maybe the original format is also the same, > > > > I don't know. > > > > Guess not, at least my zaurus uses > > mtdparts=sharpsl-nand:7168k@0k(smf),44032k@7168k(root),-(home) > > and the 44032k is filled in by the sharp firmware as you can see when > > you do a `strings -a' on the image. (It would be interesting to know > > how it finds out that value btw...) > > Found a table that seems to define that, example in the terrier image: > > 00644000 00 00 00 00 00 00 70 00 42 4F 4F 54 00 00 00 00 ......p.BOOT.... > 00644010 00 00 70 00 00 00 20 03 46 53 52 4F 00 00 00 00 ..p... .FSRO.... > 00644020 00 00 20 03 00 00 00 08 46 53 52 57 00 00 00 00 .. .....FSRW.... > > (entries of 1 long offset, 1 long length, 4 chars type, 1 long 0, so > the 44032k@7168k(root) above is indeed right. The akita image has a > similar table at 0x00660000.) > > Anyway, boot now fails with: > qemu: fatal: pxa2xx_gpio_read: Bad offset 0x1c > i.e. it is apparently expecting something there that is not yet Oh, it's Sharp's poor code :) the GPSR (0x1c) and GPCR registers are write-only. I think it's safe to assume that the real hardware returns the last written value in these addresses when reading, but in the documentation they are write-only. > emulated. And when i boot with init=/bin/sh I can't do much because > the keymap seems to be wrong or the fn key otherwise gets lost. > (similar effect with the poky image btw, I wonder is this a qemu > problem or is just noone using the terminal there? :) The problem here is the 2.6 kernel's default keymap and the zaurusd daemon used in poky and openzaurus. They use this strange keymap and qemu tries to account for that. I had first set a keymap in qemu that matched the console keymap but later when I started using X it was unusable and other users also didn't like that so I remapped all the keys, but the remapping is not perfect even now, because the real Zaurus keymap is too far from a normal pc keyboard (and I don't have a physical one). Thanks for the patches, I will have a look tomorrow (hopefully). Cheers, Andrzej