qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] qemu-system-arm -M akita/terrier - which roms work? (ha


From: Juergen Lock
Subject: Re: [Qemu-devel] qemu-system-arm -M akita/terrier - which roms work? (have first patches now :)
Date: Sat, 28 Jul 2007 02:12:37 +0200
User-agent: Mutt/1.5.16 (2007-06-09)

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

Well its also a 2.4 kernel...
> >
> > > 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.
> >
 I though about that too, but in the end didn't bother...  also kernels
w/o CONFIG_SHARPSL_BOOTLDR_PARAMS will still understand the new-style
params, its just this code in linux/arch/arm/mach-pxa/corgi.c
that forces use of the old-style struct:

...
#ifdef CONFIG_SHARPSL_BOOTLDR_PARAMS
        if (params->u1.s.page_size != PAGE_SIZE) {
            params->u1.s.page_size = PAGE_SIZE;
            params->u1.s.nr_pages = 32 * 1024 * 1024 / PAGE_SIZE;
            params->u1.s.ramdisk_size = 0;
            params->u1.s.flags = FLAG_READONLY | FLAG_RDLOAD | FLAG_RDPROMPT;
            params->u1.s.rootdev = ROOT_DEV;
            params->u1.s.initrd_start = 0;
            params->u1.s.initrd_size = 0;
            params->u1.s.rd_start = 0;
            params->u1.s.system_rev = 0;
            params->u1.s.system_serial_low = 0;
            params->u1.s.system_serial_high = 0;
            strcpy(params->commandline, CONFIG_CMDLINE);
        }
#endif
...
> > > >
> > > >>  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)

 Yeah 2.6 has switched from oss to alsa...
> >
> > > 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.

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

        Juergen




reply via email to

[Prev in Thread] Current Thread [Next in Thread]