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

[Juergen Lock]

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)
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)
> 
>>  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), 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...
> 
>> > Installing debian however should not
>> >depend on what rom you use, afterall debian is supposed to replace the
>> >contents.
>> 
>>  Well I dont want to replace the contents, I want to run debian in
>> addition to the sharp stuff in a chroot :)  See e.g. here,
>>         http://wiki.debian.org/PocketWorkstation
>> and under `Installing Debian/PocketWorkstation' here:
>>         http://www.users.on.net/~hluc/myZaurus/jumbo/xqtjumbo.html
>> (these instructions and packages are a bit dated and not directly for
>> c3200 which is one of the reasons i'd like to test/prepare things
>> using qemu.)
> 
> I still think that debian shouldn't care about what was your original
> distribution or what distribution hosts the chroot environment.

 In an ideal world...  At least it interacts with the (old in this case)
kernel, and also the xserver (x/qt) that will run outside the chroot.

 Thanx,
        Juergen

patch-arm-oldparms
Description: Text document

patch-pxa-audio
Description: Text document