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

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

On 28/07/07, andrzej zaborowski <balrogg@gmail.com> wrote:
> On 26/07/07, Juergen Lock <nox@jelal.kn-bremen.de> 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 <nox@jelal.kn-bremen.de> 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:7168k@0k(smf),44032k@7168k(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

(/dev/mtdblock*)

> with a 10 byte header at the start of the file, which is discarded.

(rather 16)

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