Hi, On 29/07/07, Juergen Lock <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > > > On 26/07/07, Juergen Lock <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED](smf),[EMAIL > > PROTECTED](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 [EMAIL PROTECTED](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
