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