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

["andrzej zaborowski" <balrogg@gmail.com>]

Hi,

On 29/07/07, Juergen Lock <nox@jelal.kn-bremen.de> 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 <balrogg@gmail.com> wrote:
> > > > On 26/07/07, Juergen Lock <nox@jelal.kn-bremen.de> 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