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

[andrzej zaborowski]

On 26/07/07, Juergen Lock <address@hidden> wrote:
> Okay I got a little further now...
>
> On Wed, Jul 25, 2007 at 10:13:42PM +0200, andrzej zaborowski wrote:
> > On 24/07/07, Juergen Lock <address@hidden> wrote:
> >>  I was under the impression that -append doesnt work, is this wrong?
> >> Also /proc/cmdline on the zaurus is
> >>         console=ttyS0 root=/dev/mtdblock2
> >> mtdparts=sharpsl-nand:address@hidden(smf),address@hidden(root),-(home)
> >> jffs2_orphaned_inodes=delete EQUIPMENT=5 LOGOLANG=1 DEFYEAR=2007 LOGO=1
> >> LAUNCH=q
> >> and even when I do pass that with -append to qemu I still dont get
> >> anything on the serial console.  So maybe the problem is just missing
> >> kernel commandline...  Can -append be fixed?
> >
> > No, not in qemu :(  zaurus kernels don't accept any parameters from
> > bootloaders, that's because they use the
> > arch/arm/boot/compressed/head-sharpsl.S file instead of the generic
> > arm head.S. Set the parameters in your .config.
>
>  Actually...  at least the sharp kernel does in fact take args as
> I found out, but it wants them in the old-style struct param_struct
> as defined in linux/include/asm-arm/setup.h (because of
> CONFIG_SHARPSL_BOOTLDR_PARAMS e.g. in linux/arch/arm/mach-pxa/corgi.c)

This must be only in the Sharp's kernel because 2.6 doesn't have it.

> I've prepared a patch that adds an -old-param flag to qemu (to be used
> together with -append), see patch-arm-oldparms (attached).  And the
> reason I got nothing on ttyS0 was simply that the sharp kernel had
> CONFIG_SERIAL_CONSOLE unset...  (as seen e.g. in
> linux/arch/arm/def-configs/terrier-j)

Great, I merged the patch, hopefully I didn't break anything. I think
the hardcoded root device shouldn't be much problem, if there's anyone
interested, they can change it.

I'm wondering if there's a way to autodetect older Linux kernels
through some magic numbers and automatically set up the old style boot
parameters, and get rid of the -old-param switch.

> >
> >>  Could be, but can `info jit' also show no change then?  (qemu is still
> >> using all the cpu time it can get.)
> >
> > Oh, then maybe it really hangs. I have only tested 2.6 kernels from
> > different trees (but they were all descendants of linus' tree more
> > than Sharp's) and OpenBSD (some post 4.0 cvs checkout). It's possible
> > that Sharp kernels depend on something that is set up by the Sharp
> > PROM code, which is closed-source (the one that runs the japanese
> > menu). It should be possible to run it in qemu though.
>
>  I've managed to build a sharp kernel with a modified config now
> (sidux live cd to the rescue!) and then saw that its hanging after the
> sound init.  built a cross gdb (which was easier than I thought, luckily
> qemu's gdbserver listens on the network so I didn't even have to build
> a qemu snapshot on linux :), and found it hanging in a tight loop
> waiting for bit 0 (TNF) of SASR0 in corgi_i2s_write in
> linux/drivers/sound/pxa-i2s_spitz.c .  Patched that (not sure its
> right but it works for me, see patch-pxa-audio),

Yes, I think your fix is correct, also merged. I don't know why I
missed this bit.
(drivers/sound/ doesn't exist in 2.6 either)

> 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...

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
with a 10 byte header at the start of the file, which is discarded.
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.

Regards,
Andrzej