On Sat, Jul 28, 2007 at 12:27:33AM +0200, andrzej zaborowski wrote:
> On 28/07/07, andrzej zaborowski <[EMAIL PROTECTED]> wrote:
> > On 26/07/07, Juergen Lock <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED](smf),[EMAIL
> > > >> PROTECTED](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:[EMAIL PROTECTED](smf),[EMAIL
PROTECTED](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
