Re: [Qemu-devel] qemu-system-arm -M akita/terrier - which roms work? (more patches... :)

[Juergen Lock]

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 <address@hidden> wrote:
> > > On 26/07/07, Juergen Lock <address@hidden> 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 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:address@hidden(smf),address@hidden(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 address@hidden(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
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? :)

 Okay enough for today...
        Juergen

patch-nand-terrier
Description: Text document

patch-raw2flash-fullimage
Description: Text document