[Qemu-devel] qemu-system-arm -M akita/terrier - which roms work? (and cursor issue)

[Qemu-devel] qemu-system-arm -M akita/terrier - which roms work? (and cursor issue)

[Juergen Lock]

Hi!

 I just played with this a bit and although I got the stuff at
	http://pokylinux.org/releases/clyde-2.0/
somewhat working (tried the akita ones going after
	http://butterfeet.org/?m=200705
, I seem to miss -showcursor and consequently got no cursor
which made navigating the gui a `little' difficult... :) - anyway
I couldnt get the sharp rom kernel to boot further than showing
the splash screen with a blinking cursor (i tried terrier and akita ones,
they both seem to hang somewhere regardless of a proper -mtdblock passed
or even none, at least info registers in the monitor showed no changes.)
Anyone know which roms work?  atm I want to play with debian for the
existing sharp rom that i have on the zaurus (a c3200), so a rom thats
at least similar to sharp would be preferable...

 Thanx,
	Juergen

Re: [Qemu-devel] qemu-system-arm -M akita/terrier - which roms work? (and cursor issue)

[andrzej zaborowski]

On 24/07/07, Juergen Lock <nox@jelal.kn-bremen.de> wrote:
> Hi!
>
>  I just played with this a bit and although I got the stuff at
>         http://pokylinux.org/releases/clyde-2.0/
> somewhat working (tried the akita ones going after
>         http://butterfeet.org/?m=200705
> , I seem to miss -showcursor and consequently got no cursor
> which made navigating the gui a `little' difficult... :) - anyway
> I couldnt get the sharp rom kernel to boot further than showing
> the splash screen with a blinking cursor (i tried terrier and akita ones,

That would suggest that it's hanging somewhere in the userspace (but
not necessarily). Have you tried booting with no init scripts? (e.g.
init=/bin/sh) Otherwise do you have sources for the kernel you're
using so that you could enable initcalls debugging in its config?

> they both seem to hang somewhere regardless of a proper -mtdblock passed
> or even none, at least info registers in the monitor showed no changes.)

When you issue "info registers" more than likely the kernel is always
in the idle loop saving the battery power, so it will almost always
show the same values, even if there are actually processes running and
doing some work.

> Anyone know which roms work?  atm I want to play with debian for the
> existing sharp rom that i have on the zaurus (a c3200), so a rom thats
> at least similar to sharp would be preferable...

Unfortunately I have no physical zaurus, so no access to any Sharp rom
because they are copyrighted. Installing debian however should not
depend on what rom you use, afterall debian is supposed to replace the
contents.

Cheers

Re: [Qemu-devel] qemu-system-arm -M akita/terrier - which roms work? (and cursor issue)

[Juergen Lock]

In article <fb249edb0707231825r57bd529dq742f6aba11ad3c69@mail.gmail.com>
 you write:
>On 24/07/07, Juergen Lock <nox@jelal.kn-bremen.de> wrote:
>> Hi!
>>
>>  I just played with this a bit and although I got the stuff at
>>         http://pokylinux.org/releases/clyde-2.0/
>> somewhat working (tried the akita ones going after
>>         http://butterfeet.org/?m=200705
>> , I seem to miss -showcursor and consequently got no cursor
>> which made navigating the gui a `little' difficult... :) - anyway

(-show-cursor worked, thx!)

>> I couldnt get the sharp rom kernel to boot further than showing
>> the splash screen with a blinking cursor (i tried terrier and akita ones,
>
>That would suggest that it's hanging somewhere in the userspace (but
>not necessarily).

Hmm maybe, after a while the cursor stops blinking...

> Have you tried booting with no init scripts? (e.g.
>init=/bin/sh)

 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?

> Otherwise do you have sources for the kernel you're
>using so that you could enable initcalls debugging in its config?

 Kernel source can apparently be downloaded here,
	http://support.ezaurus.com/developer/source/source_dl.asp
(page is in japanese, but you can look at the links and filenames),
but to build it i guess I'd have to update my linux installation first
and then figure out how to cross-build a kernel...
>
>> they both seem to hang somewhere regardless of a proper -mtdblock passed
>> or even none, at least info registers in the monitor showed no changes.)
>
>When you issue "info registers" more than likely the kernel is always
>in the idle loop saving the battery power, so it will almost always
>show the same values, even if there are actually processes running and
>doing some work.

 Could be, but can `info jit' also show no change then?  (qemu is still
using all the cpu time it can get.)
>
>> Anyone know which roms work?  atm I want to play with debian for the
>> existing sharp rom that i have on the zaurus (a c3200), so a rom thats
>> at least similar to sharp would be preferable...
>
>Unfortunately I have no physical zaurus, so no access to any Sharp rom
>because they are copyrighted.

 Hmm they are also available e.g. here (english version, clink on
model below `Downloads' in the left column, then look for `NAND-Backup'):
	http://trisoft.de/downloads.htm
(see below for the hack I used to convert the .dbk files to a raw image)

 There's also cacko,
	http://my-zaurus.narod.ru/cacko.html
which may be similar enough to the sharp rom, but I haven't yet tried it.

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

 And now the .dbk extraction hack, adapted from the mountjffs script
in this thread,
	http://www.oesf.org/forums/index.php?showtopic=22034
(I didn't really clean up all the comments; run e.g. as
	./dumpjffs.sh c3200all all SYSTC320.DBK
, assumes 128MB size.  If you want to extract parts i.e. `rom' or `root'
or `user' instead of `all' you may need to adjust ROOTFS and/or ROMFS
below too.)

-----------cut-here---------
#!/bin/bash

#######################################################################
#
#  Copyright (C) 2007 SCL Internet
#                www.scl.co.uk
#
#  Original Author:      John Sutton john@scl.co.uk
#
#  $Id: dumpjffs$
#
#  This program is free software; you can redistribute it and/or modify
#  it under the terms of the GNU General Public License as published by
#  the Free Software Foundation; either version 2 of the License, or
#  (at your option) any later version.
#
#  This program is distributed in the hope that it will be useful,
#  but WITHOUT ANY WARRANTY; without even the implied warranty of
#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
#  GNU General Public License for more details.
#
#  You should have received a copy of the GNU General Public License
#  along with this program; if not, write to the Free Software
#  Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
#
#######################################################################
#
#  dumpjffs : a shell script for extracting the jffs filesystems which
#              are contained in the 128Mb NAND flash backup image produced
#              by a Zaurus SL-C1000.
#
#######################################################################

: <<EOC

The primitive block in a SYSTC100.DBK flash file is 16 bytes long, we call
this a pblock.

The filesystems contained in the flash file are split up into a number of
datablocks each of which is 8192 pblocks = 128kb long.  Each datablock is
followed by a checkblock (which presumably contains some kind of checksums,
of unknown type), each checkblock is 256 pblocks.

A repeatblock is made up of a 1 pblock header followed by a datablock and
then a checkblock, i.e., a total of 1+8192+256 pblocks per repeatblock.

The flash file as a whole consists of a 1 pblock header followed by 1024
repeatblocks, i.e., (1+1024*(1+8192+256))*16 = 138428432 bytes total.

The flash file contains 3 filesystems in this order: rom, root, user.  The
rom fs contains the diagnostics menu etc and is NOT a jffs fs at all.  We only
need to know how long it is so that we can skip over it to find the root fs.
Ditto, if we know the size of the rom and root fs's, we can skip over both to
find the user fs.  So, we need to specify the size, in 128k blocks, of the
rom and root fs's and then the whole structure is specified.

YOU MAY NEED TO ADJUST THE TWO PARAMETERS BELOW.

Run the indicated commands on the zaurus to find your values.  It is unlikely
that ROMFS needs changing - I think this is fixed in the firmware at 7Mb,
i.e., 7 x 8 = 56 128kb blocks.  ROOTFS on the other hand will depend on how
you have divided up the remaining 121Mb between the root and user partitions.

EOC

ROMFS=56	# Use 'wc -c </dev/mtdblock1' and divide result by 128x1024.
ROOTFS=464	# Use 'df' to find the 1k-blocks for /dev/root and divide by 128.

# START

progname=`basename $0`

function usage {
	[ $# -gt 0 ] && echo "$@" >&2
	echo "usage: $progname outfile {{rom|root|user|all} flashfilename}" >&2
	exit 1
}

# Check the arguments.
[ $# = 2 -o $# = 3 ] || usage
[ -e "$1" ] && usage "file exists: $1"
#MP=$1
OF=$1

[ root = "$2" -o user = "$2" -o rom = "$2" -o all = "$2" ] || \
				usage "Invalid filesystem identifier or operation: $2"
FS=$2

# We don't actually need the flash file if umount is specified, but if the
# user has given a 3rd arg we'll check it anyway.
[ $# = 3 ] && {
	[ -r "$3" ] || usage "Can't open flash file: $3"
	FF="$3"
}

# Unmount and unload the 5 modules.
#umount $MP 2>/dev/null
#modprobe -r mtdblock mtdchar mtdram jffs2 mtdcore || exit 2

# If umount specified, we are finished.
[ $FS = umount ] && exit 0

# Define the number of pblocks in each element of a repeatblock.
datablock=8192
checkblock=256

# Calculate the number of repeatblocks for the specified fs.
[ $FS = root ] && numrepeats=$ROOTFS || numrepeats=$((1024-ROMFS-ROOTFS))
[ $FS = rom ] && numrepeats=$ROMFS
[ $FS = all ] && numrepeats=1024

# Calculate the number of repeatblocks which come before this fs.
[ $FS = root ] && offset=$ROMFS || offset=$((ROMFS+ROOTFS))
[ $FS = rom ] && offset=0
[ $FS = all ] && offset=0

# Load up the 5 modules.
#modprobe mtdcore
#modprobe jffs2
#modprobe mtdram total_size=$((numrepeats*128))
#modprobe mtdchar
#modprobe mtdblock

# Find the device files
#while true
#do
#	CDEV=/dev/mtd0; [ -c $CDEV ] && break
#	CDEV=/dev/mtd/0; [ -c $CDEV ] && break
#	echo "Can't find mtd character device" >&2; exit 2
#done
#while true
#do
#	BDEV=/dev/mtdblock0; [ -b $BDEV ] && break
#	BDEV=/dev/mtdblock/0; [ -b $BDEV ] && break
#	echo "Can't find mtd block device" >&2; exit 2
#done

# Set up the pointer variable (in pblocks) for the loop.
in=$(( 1+offset*(1+datablock+checkblock) ))

# One iteration per repeatblock.
for (( i = 0; i < numrepeats; i++ ))
do
	# Skip over the repeatblock header.
	(( in += 1 ))

	# Write out the datablock.
	dd bs=16 skip=$in count=$datablock if="$FF"

	# Increment the pointer for the next repeatblock.
	(( in += datablock+checkblock ))

done 2>&1 >$OF | grep -v "^$datablock+0 records \(in\|out\)$" >&2

# Mount it readonly - not much point in allowing it to be modified since
# we don't know how to calculate the checkblocks which would be needed to
# construct a new flash file.
#mount -t jffs2 -r $BDEV $MP || echo "Maybe you need to adjust ROMFS or ROOTFS?"

Re: [Qemu-devel] qemu-system-arm -M akita/terrier - which roms work? (and cursor issue)

[andrzej zaborowski]

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.

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

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

Regards

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

[Juergen Lock]

[-- Attachment #1: Type: text/plain, Size: 3555 bytes --]

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

[-- Attachment #2: patch-arm-oldparms --]
[-- Type: text/plain, Size: 3703 bytes --]

Index: qemu/hw/arm_boot.c
@@ -76,6 +76,76 @@
     stl_raw(p++, 0);
 }
 
+static void set_kernel_args_old(uint32_t ram_size, int initrd_size,
+                            const char *kernel_cmdline,
+                            target_phys_addr_t loader_start)
+{
+    uint32_t *p;
+    unsigned char *s;
+
+    /* see linux/include/asm-arm/setup.h */
+    p = (uint32_t *)(phys_ram_base + KERNEL_ARGS_ADDR);
+    /* page_size */
+    stl_raw(p++, 4096);
+    /* nr_pages */
+    stl_raw(p++, ram_size / 4096);
+    /* ramdisk_size */
+    stl_raw(p++, 0);
+#define FLAG_READONLY	1
+#define FLAG_RDLOAD	4
+#define FLAG_RDPROMPT	8
+    /* flags */
+    stl_raw(p++, FLAG_READONLY | FLAG_RDLOAD | FLAG_RDPROMPT);
+    /* rootdev */
+    stl_raw(p++, (31 << 8) | 0);	/* /dev/mtdblock0 */
+    /* video_num_cols */
+    stl_raw(p++, 0);
+    /* video_num_rows */
+    stl_raw(p++, 0);
+    /* video_x */
+    stl_raw(p++, 0);
+    /* video_y */
+    stl_raw(p++, 0);
+    /* memc_control_reg */
+    stl_raw(p++, 0);
+    /* unsigned char sounddefault */
+    /* unsigned char adfsdrives */
+    /* unsigned char bytes_per_char_h */
+    /* unsigned char bytes_per_char_v */
+    stl_raw(p++, 0);
+    /* pages_in_bank[4] */
+    stl_raw(p++, 0);
+    stl_raw(p++, 0);
+    stl_raw(p++, 0);
+    stl_raw(p++, 0);
+    /* pages_in_vram */
+    stl_raw(p++, 0);
+    /* initrd_start */
+    if (initrd_size)
+	stl_raw(p++, loader_start + INITRD_LOAD_ADDR);
+    else
+	stl_raw(p++, 0);
+    /* initrd_size */
+    stl_raw(p++, initrd_size);
+    /* rd_start */
+    stl_raw(p++, 0);
+    /* system_rev */
+    stl_raw(p++, 0);
+    /* system_serial_low */
+    stl_raw(p++, 0);
+    /* system_serial_high */
+    stl_raw(p++, 0);
+    /* mem_fclk_21285 */
+    stl_raw(p++, 0);
+    /* zero unused fields */
+    memset(p, 0, 256 + 1024 - (p - ((uint32_t *)(phys_ram_base + KERNEL_ARGS_ADDR))));
+    s = phys_ram_base + KERNEL_ARGS_ADDR + 256 + 1024;
+    if (kernel_cmdline)
+        strcpy (s, kernel_cmdline);
+    else
+        stb_raw(s, 0);
+}
+
 void arm_load_kernel(CPUState *env, int ram_size, const char *kernel_filename,
                      const char *kernel_cmdline, const char *initrd_filename,
                      int board_id, target_phys_addr_t loader_start)
@@ -140,6 +210,9 @@
         bootloader[6] = entry;
         for (n = 0; n < sizeof(bootloader) / 4; n++)
             stl_raw(phys_ram_base + (n * 4), bootloader[n]);
-        set_kernel_args(ram_size, initrd_size, kernel_cmdline, loader_start);
+        if (old_param)
+            set_kernel_args_old(ram_size, initrd_size, kernel_cmdline, loader_start);
+        else
+            set_kernel_args(ram_size, initrd_size, kernel_cmdline, loader_start);
     }
 }
Index: qemu/vl.c
@@ -204,6 +204,7 @@
 int nb_option_roms;
 int semihosting_enabled = 0;
 int autostart = 1;
+int old_param = 0;
 const char *qemu_name;
 int alt_grab = 0;
 #ifdef TARGET_SPARC
@@ -6949,6 +6950,7 @@
     QEMU_OPTION_semihosting,
     QEMU_OPTION_name,
     QEMU_OPTION_prom_env,
+    QEMU_OPTION_old_param,
 };
 
 typedef struct QEMUOption {
@@ -7050,6 +7052,9 @@
 #if defined(TARGET_SPARC)
     { "prom-env", HAS_ARG, QEMU_OPTION_prom_env },
 #endif
+#if defined(TARGET_ARM)
+    { "old-param", 0, QEMU_OPTION_old_param },
+#endif
     { NULL },
 };
 
@@ -7825,6 +7830,8 @@
                 nb_prom_envs++;
                 break;
 #endif
+            case QEMU_OPTION_old_param:
+                old_param = 1;
             }
         }
     }
Index: qemu/vl.h
@@ -170,6 +170,7 @@
 extern int no_quit;
 extern int semihosting_enabled;
 extern int autostart;
+extern int old_param;
 extern const char *bootp_filename;
 
 #define MAX_OPTION_ROMS 16

[-- Attachment #3: patch-pxa-audio --]
[-- Type: text/plain, Size: 322 bytes --]

Index: qemu/hw/pxa2xx.c
@@ -1564,7 +1564,12 @@
     case SACR1:
         return s->control[1];
     case SASR0:
+#if 1
+        /* XXX is this right? (TNF) */
+        return s->status | (s->fifo_len < 16 || !s->enable);
+#else
         return s->status;
+#endif
     case SAIMR:
         return s->mask;
     case SAICR:

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

[andrzej zaborowski]

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
with a 10 byte header at the start of the file, which is discarded.
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

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

[andrzej zaborowski]

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
>

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

[Juergen Lock]

On Sat, Jul 28, 2007 at 12:27:33AM +0200, andrzej zaborowski wrote:
> 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.

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:7168k@0k(smf),44032k@7168k(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

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

[Juergen Lock]

[-- Attachment #1: Type: text/plain, Size: 2678 bytes --]

On Sat, Jul 28, 2007 at 02:12:37AM +0200, Juergen Lock wrote:
> On Sat, Jul 28, 2007 at 12:27:33AM +0200, andrzej zaborowski wrote:
> > On 28/07/07, andrzej zaborowski <balrogg@gmail.com> wrote:
> > > On 26/07/07, Juergen Lock <nox@jelal.kn-bremen.de> wrote:

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

Okay the first reason for this was the terrier kernel doing long reads
from the nand flash io port, expecting to get 2 bytes at a time.
(enabled by CONFIG_ARCH_PXA_TERRIER at least in the sharp kernel),
see patch-nand-terrier (attached).
> > >
> > > 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)
> > 
 Yeah I hat removed that, but was overlooking the fact that it
repeats the first PARTITION_START (0x00700000) bytes in the output,
because it didnt expect this data in the input, and so it just fills
it out.  Added another #ifndef which fixed that, see attached
patch-raw2flash-fullimage.

> > > 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:7168k@0k(smf),44032k@7168k(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...)

 Found a table that seems to define that, example in the terrier image:

00644000  00 00 00 00 00 00 70 00 42 4F 4F 54 00 00 00 00 ......p.BOOT....
00644010  00 00 70 00 00 00 20 03 46 53 52 4F 00 00 00 00 ..p... .FSRO....
00644020  00 00 20 03 00 00 00 08 46 53 52 57 00 00 00 00 .. .....FSRW....

 (entries of 1 long offset, 1 long length, 4 chars type, 1 long 0, so
the 44032k@7168k(root) above is indeed right.  The akita image has a
similar table at 0x00660000.)

 Anyway, boot now fails with:
	qemu: fatal: pxa2xx_gpio_read: Bad offset 0x1c
i.e. it is apparently expecting something there that is not yet
emulated.  And when i boot with init=/bin/sh I can't do much because
the keymap seems to be wrong or the fn key otherwise gets lost.
(similar effect with the poky image btw, I wonder is this a qemu
problem or is just noone using the terminal there? :)

 Okay enough for today...
	Juergen

[-- Attachment #2: patch-nand-terrier --]
[-- Type: text/plain, Size: 891 bytes --]

Index: qemu/hw/spitz.c
+++ work-arm3/qemu-snapshot-2007-07-02_05/hw/spitz.c	Sun Jul 29 00:33:34 2007
@@ -78,6 +78,23 @@
     return 0;
 }
 
+static uint32_t sl_readl(void *opaque, target_phys_addr_t addr)
+{
+    struct sl_nand_s *s = (struct sl_nand_s *) opaque;
+    int ryby;
+    addr -= s->target_base;
+
+    switch (addr) {
+    case FLASH_FLASHIO:
+        return ecc_digest(&s->ecc, nand_getio(s->nand)) |
+            (ecc_digest(&s->ecc, nand_getio(s->nand)) << 16);
+
+    default:
+        spitz_printf("Bad register offset " REG_FMT "\n", addr);
+    }
+    return 0;
+}
+
 static void sl_writeb(void *opaque, target_phys_addr_t addr,
                 uint32_t value)
 {
@@ -139,7 +156,7 @@
     CPUReadMemoryFunc *sl_readfn[] = {
         sl_readb,
         sl_readb,
-        sl_readb,
+        sl_readl,
     };
     CPUWriteMemoryFunc *sl_writefn[] = {
         sl_writeb,

[-- Attachment #3: patch-raw2flash-fullimage --]
[-- Type: text/plain, Size: 658 bytes --]

--- orig/raw2flash.c	Wed May  2 00:35:49 2007
+++ new/raw2flash.c	Sun Jul 29 01:56:50 2007
@@ -203,12 +203,14 @@
 		}
 		*partition = 1;
 	case 1:
+#ifndef FULLIMAGE
 		if (count - PARTITION_START < PARTITION_START) {
 			memcpy(buffer, jffs_buffer + count - PARTITION_START,
 					ecc->style->eccbytes);
 			*len = ecc->style->eccbytes;
 			break;
 		}
+#endif
 
 		while (*len < ecc->style->eccbytes) {
 			ret = TFR(read(0, buffer + *len, 0x800 - *len));
@@ -254,8 +256,10 @@
 	fprintf(stderr, "[");
 # endif
 
+#ifndef FULLIMAGE
 	/* Skip first 10 bytes */
 	TFR(read(0, buffer, 0x10));
+#endif
 
 	len = 0;
 	jffs = (uint8_t *) malloc(PARTITION_START);

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

[andrzej zaborowski]

Hi,

On 29/07/07, Juergen Lock <nox@jelal.kn-bremen.de> wrote:
> On Sat, Jul 28, 2007 at 02:12:37AM +0200, Juergen Lock wrote:
> > On Sat, Jul 28, 2007 at 12:27:33AM +0200, andrzej zaborowski wrote:
> > > On 28/07/07, andrzej zaborowski <balrogg@gmail.com> wrote:
> > > > On 26/07/07, Juergen Lock <nox@jelal.kn-bremen.de> wrote:
>
> > > > > 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...
>
> Okay the first reason for this was the terrier kernel doing long reads
> from the nand flash io port, expecting to get 2 bytes at a time.
> (enabled by CONFIG_ARCH_PXA_TERRIER at least in the sharp kernel),
> see patch-nand-terrier (attached).
> > > >
> > > > 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)
> > >
>  Yeah I hat removed that, but was overlooking the fact that it
> repeats the first PARTITION_START (0x00700000) bytes in the output,
> because it didnt expect this data in the input, and so it just fills
> it out.  Added another #ifndef which fixed that, see attached
> patch-raw2flash-fullimage.

The repeating of the first chunk is basically a hack to have jffs2
formatted blocks also before the start of the root partition (in range
0 to 0x00700000) so that Linux doesn't complain that the nand is
unformatted. AFAIK the jffs2 driver doesn't care what data is there
but it whines if it doesn't have the appearance of a jffs2 partition.

>
> > > > 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:7168k@0k(smf),44032k@7168k(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...)
>
>  Found a table that seems to define that, example in the terrier image:
>
> 00644000  00 00 00 00 00 00 70 00 42 4F 4F 54 00 00 00 00 ......p.BOOT....
> 00644010  00 00 70 00 00 00 20 03 46 53 52 4F 00 00 00 00 ..p... .FSRO....
> 00644020  00 00 20 03 00 00 00 08 46 53 52 57 00 00 00 00 .. .....FSRW....
>
>  (entries of 1 long offset, 1 long length, 4 chars type, 1 long 0, so
> the 44032k@7168k(root) above is indeed right.  The akita image has a
> similar table at 0x00660000.)
>
>  Anyway, boot now fails with:
>         qemu: fatal: pxa2xx_gpio_read: Bad offset 0x1c
> i.e. it is apparently expecting something there that is not yet

Oh, it's Sharp's poor code :)  the GPSR (0x1c) and GPCR registers are
write-only. I think it's safe to assume that the real hardware returns
the last written value in these addresses when reading, but in the
documentation they are write-only.

> emulated.  And when i boot with init=/bin/sh I can't do much because
> the keymap seems to be wrong or the fn key otherwise gets lost.
> (similar effect with the poky image btw, I wonder is this a qemu
> problem or is just noone using the terminal there? :)

The problem here is the 2.6 kernel's default keymap and the zaurusd
daemon used in poky and openzaurus. They use this strange keymap and
qemu tries to account for that. I had first set a keymap in qemu that
matched the console keymap but later when I started using X it was
unusable and other users also didn't like that so I remapped all the
keys, but the remapping is not perfect even now, because the real
Zaurus keymap is too far from a normal pc keyboard (and I don't have a
physical one).

Thanks for the patches, I will have a look tomorrow (hopefully).

Cheers,
Andrzej

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

[Juergen Lock]

[-- Attachment #1: Type: text/plain, Size: 2047 bytes --]

On Sun, Jul 29, 2007 at 03:46:37AM +0200, andrzej zaborowski wrote:
> Hi,
Hi,
> 
> On 29/07/07, Juergen Lock <nox@jelal.kn-bremen.de> wrote:

> >  Anyway, boot now fails with:
> >         qemu: fatal: pxa2xx_gpio_read: Bad offset 0x1c
> > i.e. it is apparently expecting something there that is not yet
> 
> Oh, it's Sharp's poor code :)  the GPSR (0x1c) and GPCR registers are
> write-only. I think it's safe to assume that the real hardware returns
> the last written value in these addresses when reading, but in the
> documentation they are write-only.

Yeah it was crashing in static int force_8bit_access_check_and_set
in linux/drivers/pcmcia/cistpl.c, apparently while doing an
	GPSR(GPIO54_nPCE_2) = GPSR(GPIO54_nPCE_2);
Patched that (patch-pxa-gpsr, attached), and now the boot seems
to be hanging somewhere in userland...
> 
> > emulated.  And when i boot with init=/bin/sh I can't do much because
> > the keymap seems to be wrong or the fn key otherwise gets lost.
> > (similar effect with the poky image btw, I wonder is this a qemu
> > problem or is just noone using the terminal there? :)
> 
> The problem here is the 2.6 kernel's default keymap and the zaurusd
> daemon used in poky and openzaurus. They use this strange keymap and
> qemu tries to account for that. I had first set a keymap in qemu that
> matched the console keymap but later when I started using X it was
> unusable and other users also didn't like that so I remapped all the
> keys, but the remapping is not perfect even now, because the real
> Zaurus keymap is too far from a normal pc keyboard (and I don't have a
> physical one).

 Yeah it has an fn key that is used to generate most special characters...
But even shift didn't work on the 2.4 kernel's console (and as I said
fn apparently got lost too), and with the poky rxvt it seemed like
anything that uses fn caused an error (cursor flashes quickly) instead
of sending the corresponding character.
> 
> Thanks for the patches, I will have a look tomorrow (hopefully).

 Thanx for committing, :)
	Juergen

[-- Attachment #2: patch-pxa-gpsr --]
[-- Type: text/plain, Size: 320 bytes --]

Index: qemu/hw/pxa2xx_gpio.c
@@ -152,6 +152,9 @@
     case GPDR:		/* GPIO Pin-Direction registers */
         return s->dir[bank];
 
+    case GPSR:		/* GPIO Pin-Output Set registers */
+        return s->olevel[bank];
+
     case GRER:		/* GPIO Rising-Edge Detect Enable registers */
         return s->rising[bank];
 

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

[Juergen Lock]

[-- Attachment #1: Type: text/plain, Size: 3598 bytes --]

On Mon, Jul 30, 2007 at 12:30:23AM +0200, Juergen Lock wrote:
> On Sun, Jul 29, 2007 at 03:46:37AM +0200, andrzej zaborowski wrote:
> > Hi,
> Hi,
> > 
> > On 29/07/07, Juergen Lock <nox@jelal.kn-bremen.de> wrote:
> 
> > >  Anyway, boot now fails with:
> > >         qemu: fatal: pxa2xx_gpio_read: Bad offset 0x1c
> > > i.e. it is apparently expecting something there that is not yet
> > 
> > Oh, it's Sharp's poor code :)  the GPSR (0x1c) and GPCR registers are
> > write-only. I think it's safe to assume that the real hardware returns
> > the last written value in these addresses when reading, but in the
> > documentation they are write-only.
> 
> Yeah it was crashing in static int force_8bit_access_check_and_set
> in linux/drivers/pcmcia/cistpl.c, apparently while doing an
> 	GPSR(GPIO54_nPCE_2) = GPSR(GPIO54_nPCE_2);
> Patched that (patch-pxa-gpsr, attached), and now the boot seems
> to be hanging somewhere in userland...

Ok I set a breakpoint on do_execve and found that it was repeatedly
calling `/bin/grep ^1 /var/lib/pcmcia/stab'.  On my zaurus that file
looks like:
	Socket 0: empty
	Socket 1: ATA/IDE Fixed Disk
	1     ide       ide_cs 0        hda     3  0
and indeed in qemu it has the disk in socket 0.  Patched that
(see patch-spitz-hda, attached), and now (well I also added an
sd image since I got lots of
	pxa_sd_put_command: responce time out by jiffies (cmd=01)
) I at least get
	INIT: version 2.78 booting
	mount: Mounting /dev/hda1 on /hdd1 failed: Invalid argument
and when I hit ^c (btw, the left shift key does work, only the
right one doesnt) it continues with
	INIT: Entering runlevel: 4
	INIT: Switching to runlevel: 6
	INIT: Sending processes the TERM signal
	umount: forced umount of /dev/ram1 failed!
	Can't find /dev in /etc/fstab
	umount: /proc: Device or resource busy
	Rebooting the system...
and the kernel's last words on the serial console are
	flushing ide devices: 
	Restarting system.
	reboot the kernel (1)
	Reboot failed -- System halted

 Okay, time to sfdisk the hda image (it was empty :), boot with
`rw init=/bin/sh', mknod /dev/hda*, mounting /proc and /home and
then try sfdisk:
	# sfdisk /dev/hda
	modprobe: modprobe: Can't locate module block-major-3
	/dev/hda: No such device or address

	sfdisk: cannot open /dev/hda read-write

 Hmm, some module not loaded?  looking around in /lib/modules/
I see no obvious candidate, anyone have an idea?

 Okay, back to the akita image...  booting that to runlevel 2 or 4 now
in fact gets me a login prompt on the serial console, and in runlevel 4
I even see the gui splash screen flashing, but the gui doesnt
start, and after a few iterations I get
	INIT: Id "ln" respawning too fast: disabled for 5 minutes
ln is (grep ln /etc/inittab):
	ln:345:respawn:survive -l 6 /sbin/launch

 Playing around I also found that both `more /etc/inittab' and `ps'
exit with `Illegal instruction', ouch!  Afer adding CONFIG_DEBUG_USER
to the kernel I get
	more (25): undefined instruction: pc=0002087c
	Code: ed9fa149 e59f0128 ee012190 ee400181 (ee100182)
and
	ps (26): undefined instruction: pc=0200d94c
	Code: e24b204c ebffce16 ed1bb113 ed1ba10c (ee230182)
(the one in brackets seems to be the insn in question), and 
tracing the kernel's fpu emulator (starting with EmulateAll in
linux/arch/arm/nwfpe/fpa11.c) I find that both failure seem to be
caused by an fpa11->fType[x] being 0 == typeNone, i.e. it seems
an fpu emulator's register is uninitialized...  Anyone have an idea
what's up with that?  (oh, I didn't rebuild the akita kernel so this
was actually debugged with the terrier image.)

 Thanx,
	Juergen

[-- Attachment #2: patch-spitz-hda --]
[-- Type: text/plain, Size: 309 bytes --]

Index: qemu/hw/spitz.c
@@ -929,7 +929,8 @@
 
     if (bs && bdrv_is_inserted(bs) && !bdrv_is_removable(bs)) {
         md = dscm1xxxx_init(bs);
-        pxa2xx_pcmcia_attach(cpu->pcmcia[0], md);
+	/* at least terrier microdrive is in socket 1 */
+        pxa2xx_pcmcia_attach(cpu->pcmcia[1], md);
     }
 }
 

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

[Juergen Lock]

On Tue, Jul 31, 2007 at 02:37:04AM +0200, Juergen Lock wrote:
> On Mon, Jul 30, 2007 at 12:30:23AM +0200, Juergen Lock wrote:
> > On Sun, Jul 29, 2007 at 03:46:37AM +0200, andrzej zaborowski wrote:
> > > Hi,
> > Hi,
> > > 
> > > On 29/07/07, Juergen Lock <nox@jelal.kn-bremen.de> wrote:
> > 
> > > >  Anyway, boot now fails with:
> > > >         qemu: fatal: pxa2xx_gpio_read: Bad offset 0x1c
> > > > i.e. it is apparently expecting something there that is not yet
> > > 
> > > Oh, it's Sharp's poor code :)  the GPSR (0x1c) and GPCR registers are
> > > write-only. I think it's safe to assume that the real hardware returns
> > > the last written value in these addresses when reading, but in the
> > > documentation they are write-only.
> > 
> > Yeah it was crashing in static int force_8bit_access_check_and_set
> > in linux/drivers/pcmcia/cistpl.c, apparently while doing an
> > 	GPSR(GPIO54_nPCE_2) = GPSR(GPIO54_nPCE_2);
> > Patched that (patch-pxa-gpsr, attached), and now the boot seems
> > to be hanging somewhere in userland...
> 
> Ok I set a breakpoint on do_execve and found that it was repeatedly
> calling `/bin/grep ^1 /var/lib/pcmcia/stab'.  On my zaurus that file
> looks like:
> 	Socket 0: empty
> 	Socket 1: ATA/IDE Fixed Disk
> 	1     ide       ide_cs 0        hda     3  0
> and indeed in qemu it has the disk in socket 0.  Patched that
> (see patch-spitz-hda, attached), and now (well I also added an
> sd image since I got lots of
> 	pxa_sd_put_command: responce time out by jiffies (cmd=01)
> ) I at least get
> 	INIT: version 2.78 booting
> 	mount: Mounting /dev/hda1 on /hdd1 failed: Invalid argument
> and when I hit ^c (btw, the left shift key does work, only the
> right one doesnt) it continues with
> 	INIT: Entering runlevel: 4
> 	INIT: Switching to runlevel: 6
> 	INIT: Sending processes the TERM signal
> 	umount: forced umount of /dev/ram1 failed!
> 	Can't find /dev in /etc/fstab
> 	umount: /proc: Device or resource busy
> 	Rebooting the system...
> and the kernel's last words on the serial console are
> 	flushing ide devices: 
> 	Restarting system.
> 	reboot the kernel (1)
> 	Reboot failed -- System halted
> 
>  Okay, time to sfdisk the hda image (it was empty :), boot with
> `rw init=/bin/sh', mknod /dev/hda*, mounting /proc and /home and
> then try sfdisk:
> 	# sfdisk /dev/hda
> 	modprobe: modprobe: Can't locate module block-major-3
> 	/dev/hda: No such device or address
> 
> 	sfdisk: cannot open /dev/hda read-write
> 
>  Hmm, some module not loaded?  looking around in /lib/modules/
> I see no obvious candidate, anyone have an idea?
> 
>  Okay, back to the akita image...  booting that to runlevel 2 or 4 now
> in fact gets me a login prompt on the serial console, and in runlevel 4
> I even see the gui splash screen flashing, but the gui doesnt
> start, and after a few iterations I get
> 	INIT: Id "ln" respawning too fast: disabled for 5 minutes
> ln is (grep ln /etc/inittab):
> 	ln:345:respawn:survive -l 6 /sbin/launch

Ok i now created a proper terrier hda image using the
	http://www.trisoft.de/download/SLC3200SYSPART.zip
and now I get essentially the same behaviour as with the akita
image, and I can confirm the gui startup is crashing with
	gawk (277): undefined instruction: pc=00023dd4
	Code: e3130020 1d908100 1a000000 eb0020d1 (ee103170) 
and
	qpe (297): undefined instruction: pc=4044fc88
	Code: ed81110a ee120180 ee00018e e5913008 (ee102170)
(repeated as init respawns it.)

 I also posted a FreeBSD qemu-devel port update,
	http://docs.freebsd.org/cgi/mid.cgi?20070731201608.GA30162
using the 2007-07-31_05 snapshot with the pxa-gpsr and spitz-hda
patches added.

 So if anyone has an idea about the fpu emulation crashes I'd be
thankful.

 Cheers,
	Juergen

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

[andrzej zaborowski]

On 31/07/07, Juergen Lock <nox@jelal.kn-bremen.de> wrote:
> On Tue, Jul 31, 2007 at 02:37:04AM +0200, Juergen Lock wrote:
> > On Mon, Jul 30, 2007 at 12:30:23AM +0200, Juergen Lock wrote:
> > > On Sun, Jul 29, 2007 at 03:46:37AM +0200, andrzej zaborowski wrote:
> > > > Hi,
> > > Hi,
> > > >
> > > > On 29/07/07, Juergen Lock <nox@jelal.kn-bremen.de> wrote:
> > >
> > > > >  Anyway, boot now fails with:
> > > > >         qemu: fatal: pxa2xx_gpio_read: Bad offset 0x1c
> > > > > i.e. it is apparently expecting something there that is not yet
> > > >
> > > > Oh, it's Sharp's poor code :)  the GPSR (0x1c) and GPCR registers are
> > > > write-only. I think it's safe to assume that the real hardware returns
> > > > the last written value in these addresses when reading, but in the
> > > > documentation they are write-only.
> > >
> > > Yeah it was crashing in static int force_8bit_access_check_and_set
> > > in linux/drivers/pcmcia/cistpl.c, apparently while doing an
> > >     GPSR(GPIO54_nPCE_2) = GPSR(GPIO54_nPCE_2);
> > > Patched that (patch-pxa-gpsr, attached), and now the boot seems
> > > to be hanging somewhere in userland...
> >
> > Ok I set a breakpoint on do_execve and found that it was repeatedly
> > calling `/bin/grep ^1 /var/lib/pcmcia/stab'.  On my zaurus that file
> > looks like:
> >       Socket 0: empty
> >       Socket 1: ATA/IDE Fixed Disk
> >       1     ide       ide_cs 0        hda     3  0
> > and indeed in qemu it has the disk in socket 0.  Patched that
> > (see patch-spitz-hda, attached), and now (well I also added an
> > sd image since I got lots of
> >       pxa_sd_put_command: responce time out by jiffies (cmd=01)
> > ) I at least get
> >       INIT: version 2.78 booting
> >       mount: Mounting /dev/hda1 on /hdd1 failed: Invalid argument
> > and when I hit ^c (btw, the left shift key does work, only the
> > right one doesnt) it continues with
> >       INIT: Entering runlevel: 4
> >       INIT: Switching to runlevel: 6
> >       INIT: Sending processes the TERM signal
> >       umount: forced umount of /dev/ram1 failed!
> >       Can't find /dev in /etc/fstab
> >       umount: /proc: Device or resource busy
> >       Rebooting the system...
> > and the kernel's last words on the serial console are
> >       flushing ide devices:
> >       Restarting system.
> >       reboot the kernel (1)
> >       Reboot failed -- System halted
> >
> >  Okay, time to sfdisk the hda image (it was empty :), boot with
> > `rw init=/bin/sh', mknod /dev/hda*, mounting /proc and /home and
> > then try sfdisk:
> >       # sfdisk /dev/hda
> >       modprobe: modprobe: Can't locate module block-major-3
> >       /dev/hda: No such device or address
> >
> >       sfdisk: cannot open /dev/hda read-write
> >
> >  Hmm, some module not loaded?  looking around in /lib/modules/
> > I see no obvious candidate, anyone have an idea?
> >
> >  Okay, back to the akita image...  booting that to runlevel 2 or 4 now
> > in fact gets me a login prompt on the serial console, and in runlevel 4
> > I even see the gui splash screen flashing, but the gui doesnt
> > start, and after a few iterations I get
> >       INIT: Id "ln" respawning too fast: disabled for 5 minutes
> > ln is (grep ln /etc/inittab):
> >       ln:345:respawn:survive -l 6 /sbin/launch
>
> Ok i now created a proper terrier hda image using the
>         http://www.trisoft.de/download/SLC3200SYSPART.zip
> and now I get essentially the same behaviour as with the akita
> image, and I can confirm the gui startup is crashing with
>         gawk (277): undefined instruction: pc=00023dd4
>         Code: e3130020 1d908100 1a000000 eb0020d1 (ee103170)

According to objdump this is:

   0:   e3130020        tst     r3, #32 ; 0x20
   4:   1d908100        wldrwne wr8, [r0]
   8:   1a000000        bne     0x10
   c:   eb0020d1        bl      0x8358
  10:   ee103170        fixz    r3, f0

So the last opcode is not an iWMMXt opcode and not XScale-specific,
but somehow it got generated by gcc, right?  (and if the gcc knew that
it's compiling for an iWMMXt enabled processor, there would be no fpu
insns)

So unless the idea is that the condition for bne was supposed to be
always false and the function at 0x8358 is supposed to not return,
it's the kernel's emulation fault.

Are you running the stock kernel? otherwise maybe some fpu emulation is missing.

With fpu this code would be:
   0:   e3130020        tst     r3, #32 ; 0x20
   4:   1d908100        ldfned  f0, [r0]
   8:   1a000000        bne     0x10
   c:   eb0020d1        bl      0x8358
  10:   ee103170        fixz    r3, f0

can you try this change:
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -840,7 +840,7 @@ void helper_set_cp15(CPUState *env, uint32_t insn, uint32_t
val)
             if (op2 == 0 && crm == 1) {
                 /* Changes cp0 to cp13 behavior, so needs a TB flush.  */
                 tb_flush(env);
-                env->cp15.c15_cpar = (val & 0x3fff) | 2;
+                env->cp15.c15_cpar = val & 0x3fff;
                 break;
             }
             goto bad_reg;

> and
>         qpe (297): undefined instruction: pc=4044fc88
>         Code: ed81110a ee120180 ee00018e e5913008 (ee102170)
> (repeated as init respawns it.)

and this would be:
  14:   ed81100a        stc     0, cr1, [r1, #40]
  18:   ee120180        mufd    f0, f2, f0
  1c:   ee00018e        adfd    f0, f0, #0.5
  20:   e5913008        ldr     r3, [r1, #8]
  24:   ee102170        fixz    r2, f0

>
>  I also posted a FreeBSD qemu-devel port update,
>         http://docs.freebsd.org/cgi/mid.cgi?20070731201608.GA30162
> using the 2007-07-31_05 snapshot with the pxa-gpsr and spitz-hda
> patches added.

I'm trying to confirm where the HDA is attached on Spitz and Borzoi
and then will change the arrangement in the slots.

Regards,
Andrew

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

[Juergen Lock]

On Tue, Jul 31, 2007 at 11:31:58PM +0200, andrzej zaborowski wrote:
> On 31/07/07, Juergen Lock <nox@jelal.kn-bremen.de> wrote:
> > On Tue, Jul 31, 2007 at 02:37:04AM +0200, Juergen Lock wrote:
> > > On Mon, Jul 30, 2007 at 12:30:23AM +0200, Juergen Lock wrote:
> > > > On Sun, Jul 29, 2007 at 03:46:37AM +0200, andrzej zaborowski wrote:
> > > > > Hi,
> > > > Hi,
> > > > >
> > > > > On 29/07/07, Juergen Lock <nox@jelal.kn-bremen.de> wrote:
> > > >
> > > > > >  Anyway, boot now fails with:
> > > > > >         qemu: fatal: pxa2xx_gpio_read: Bad offset 0x1c
> > > > > > i.e. it is apparently expecting something there that is not yet
> > > > >
> > > > > Oh, it's Sharp's poor code :)  the GPSR (0x1c) and GPCR registers are
> > > > > write-only. I think it's safe to assume that the real hardware returns
> > > > > the last written value in these addresses when reading, but in the
> > > > > documentation they are write-only.
> > > >
> > > > Yeah it was crashing in static int force_8bit_access_check_and_set
> > > > in linux/drivers/pcmcia/cistpl.c, apparently while doing an
> > > >     GPSR(GPIO54_nPCE_2) = GPSR(GPIO54_nPCE_2);
> > > > Patched that (patch-pxa-gpsr, attached), and now the boot seems
> > > > to be hanging somewhere in userland...
> > >
> > > Ok I set a breakpoint on do_execve and found that it was repeatedly
> > > calling `/bin/grep ^1 /var/lib/pcmcia/stab'.  On my zaurus that file
> > > looks like:
> > >       Socket 0: empty
> > >       Socket 1: ATA/IDE Fixed Disk
> > >       1     ide       ide_cs 0        hda     3  0
> > > and indeed in qemu it has the disk in socket 0.  Patched that
> > > (see patch-spitz-hda, attached), and now (well I also added an
> > > sd image since I got lots of
> > >       pxa_sd_put_command: responce time out by jiffies (cmd=01)
> > > ) I at least get
> > >       INIT: version 2.78 booting
> > >       mount: Mounting /dev/hda1 on /hdd1 failed: Invalid argument
> > > and when I hit ^c (btw, the left shift key does work, only the
> > > right one doesnt) it continues with
> > >       INIT: Entering runlevel: 4
> > >       INIT: Switching to runlevel: 6
> > >       INIT: Sending processes the TERM signal
> > >       umount: forced umount of /dev/ram1 failed!
> > >       Can't find /dev in /etc/fstab
> > >       umount: /proc: Device or resource busy
> > >       Rebooting the system...
> > > and the kernel's last words on the serial console are
> > >       flushing ide devices:
> > >       Restarting system.
> > >       reboot the kernel (1)
> > >       Reboot failed -- System halted
> > >
> > >  Okay, time to sfdisk the hda image (it was empty :), boot with
> > > `rw init=/bin/sh', mknod /dev/hda*, mounting /proc and /home and
> > > then try sfdisk:
> > >       # sfdisk /dev/hda
> > >       modprobe: modprobe: Can't locate module block-major-3
> > >       /dev/hda: No such device or address
> > >
> > >       sfdisk: cannot open /dev/hda read-write
> > >
> > >  Hmm, some module not loaded?  looking around in /lib/modules/
> > > I see no obvious candidate, anyone have an idea?
> > >
> > >  Okay, back to the akita image...  booting that to runlevel 2 or 4 now
> > > in fact gets me a login prompt on the serial console, and in runlevel 4
> > > I even see the gui splash screen flashing, but the gui doesnt
> > > start, and after a few iterations I get
> > >       INIT: Id "ln" respawning too fast: disabled for 5 minutes
> > > ln is (grep ln /etc/inittab):
> > >       ln:345:respawn:survive -l 6 /sbin/launch
> >
> > Ok i now created a proper terrier hda image using the
> >         http://www.trisoft.de/download/SLC3200SYSPART.zip
> > and now I get essentially the same behaviour as with the akita
> > image, and I can confirm the gui startup is crashing with
> >         gawk (277): undefined instruction: pc=00023dd4
> >         Code: e3130020 1d908100 1a000000 eb0020d1 (ee103170)
> 
> According to objdump this is:
> 
>    0:   e3130020        tst     r3, #32 ; 0x20
>    4:   1d908100        wldrwne wr8, [r0]
>    8:   1a000000        bne     0x10
>    c:   eb0020d1        bl      0x8358
>   10:   ee103170        fixz    r3, f0
> 
> So the last opcode is not an iWMMXt opcode and not XScale-specific,
> but somehow it got generated by gcc, right?  (and if the gcc knew that
> it's compiling for an iWMMXt enabled processor, there would be no fpu
> insns)

I guess the guys at sharp just didn't realize their cpu had no fpu
or something :)  (Or that you can compile to use softfloats.)
> 
> So unless the idea is that the condition for bne was supposed to be
> always false and the function at 0x8358 is supposed to not return,
> it's the kernel's emulation fault.
> 
> Are you running the stock kernel? otherwise maybe some fpu emulation is missing.

 I tried with the stock kernel too.  (I had used its config as a base.)
And as I said when I traced the kernel's fpu emulation code the
problem seemed to be unitialized registers...  It's weird.
> 
> With fpu this code would be:
>    0:   e3130020        tst     r3, #32 ; 0x20
>    4:   1d908100        ldfned  f0, [r0]
>    8:   1a000000        bne     0x10
>    c:   eb0020d1        bl      0x8358
>   10:   ee103170        fixz    r3, f0
> 
> can you try this change:
> --- a/target-arm/helper.c
> +++ b/target-arm/helper.c
> @@ -840,7 +840,7 @@ void helper_set_cp15(CPUState *env, uint32_t insn, uint32_t
> val)
>              if (op2 == 0 && crm == 1) {
>                  /* Changes cp0 to cp13 behavior, so needs a TB flush.  */
>                  tb_flush(env);
> -                env->cp15.c15_cpar = (val & 0x3fff) | 2;
> +                env->cp15.c15_cpar = val & 0x3fff;
>                  break;
>              }
>              goto bad_reg;
> 
 Hmm that fixed the undefined instruction crahes, at least ps, more
and dc now work.  The gui still doesn't start tho.

>...
> I'm trying to confirm where the HDA is attached on Spitz and Borzoi
> and then will change the arrangement in the slots.

 Okay, thanx!
	Juergen

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

[Juergen Lock]

On Wed, Aug 01, 2007 at 01:32:00AM +0200, Juergen Lock wrote:
> On Tue, Jul 31, 2007 at 11:31:58PM +0200, andrzej zaborowski wrote:

> > can you try this change:
> > --- a/target-arm/helper.c
> > +++ b/target-arm/helper.c
> > @@ -840,7 +840,7 @@ void helper_set_cp15(CPUState *env, uint32_t insn, uint32_t
> > val)
> >              if (op2 == 0 && crm == 1) {
> >                  /* Changes cp0 to cp13 behavior, so needs a TB flush.  */
> >                  tb_flush(env);
> > -                env->cp15.c15_cpar = (val & 0x3fff) | 2;
> > +                env->cp15.c15_cpar = val & 0x3fff;
> >                  break;
> >              }
> >              goto bad_reg;
> > 
>  Hmm that fixed the undefined instruction crahes, at least ps, more
> and dc now work.  The gui still doesn't start tho.

Okay I now updated qemu again and added an strace to the gui (qpe)
invocation, and it ends like this:
...
[pid   299] [4086c154] open("/etc/group", O_RDONLY) = 0
[pid   299] [4086c37c] fcntl64(0, F_GETFD) = 0
[pid   299] [4086c37c] fcntl64(0, F_SETFD, FD_CLOEXEC) = 0
[pid   299] [4086b350] fstat64(0, {st_mode=S_IFREG|0664, st_size=254, ...}) = 0
[pid   299] [40875fcc] old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40019000
[pid   299] [40878fa0] _llseek(0, 0, [0], SEEK_CUR) = 0
[pid   299] [4086c1a4] read(0, "root:x:0:\nwheel:x:10:\nbin:x:1:bi"..., 4096) = 254
[pid   299] [4086c194] close(0)         = 0
[pid   299] [40875fe4] munmap(0x40019000, 4096) = 0
[pid   299] [40851cc4] geteuid32()      = 0
[pid   299] [40872f38] setreuid32(0x1f4, 0) = 0
[pid   299] [40873034] setregid32(0x1f4, 0x1f4) = 0
pid 299 stray syscall exit
) = 500
[pid   299] upeek: ptrace(PTRACE_PEEKUSER,299,60,0): No such process
[????????] +++ killed by SIGKILL +++
Process 300 detached

 Is the `stray syscall exit' caused by the SIGKILL?  And anyone have
an idea where a SIGKILL could come from?  I don't think it is running
out of memory, `free' shows about half of the memory free shortly
before it exits, and also it works on the real hardware...

 Oh and something else: even with a valid -sd image I can't seem
to mount /dev/mmcda1 in the guest, and I see the following in dmesg:

pxa_sd_wait_response: card removed (cmd=00)
pxa_sd_wait_response: card removed (cmd=00)
pxa_sd_wait_response: card removed (cmd=00)
pxa_sd_wait_id_response: card removed (cmd=00)
sharp_mmcsd 0.30 13 Oct 2004
pxa_sd_wait_response: card removed (cmd=00)
pxa_sd_wait_response: card removed (cmd=00)
pxa_sd_wait_response: card removed (cmd=00)
pxa_sd_wait_id_response: card removed (cmd=00)

 (It's not that big an issue tho, since at least with the terrier
emulation I do have -hda which works.  Of course working network
would be even nicer...  I guess emulating the usb netowrk thingy
would take some work, but could the ne2k optionally be hooked up to
pcmcia socket 0?)

 Cheers,
	Juergen

Re: [Qemu-devel] qemu-system-arm -M akita/terrier - which roms work? (more patches, this time keyboard... :)

[Juergen Lock]

[-- Attachment #1: Type: text/plain, Size: 2706 bytes --]

On Mon, Jul 30, 2007 at 12:30:23AM +0200, Juergen Lock wrote:
> On Sun, Jul 29, 2007 at 03:46:37AM +0200, andrzej zaborowski wrote:
> > Hi,
> Hi,
> > 
> > On 29/07/07, Juergen Lock <nox@jelal.kn-bremen.de> wrote:
> 
> > >  Anyway, boot now fails with:
> > >         qemu: fatal: pxa2xx_gpio_read: Bad offset 0x1c
> > > i.e. it is apparently expecting something there that is not yet
> > 
> > Oh, it's Sharp's poor code :)  the GPSR (0x1c) and GPCR registers are
> > write-only. I think it's safe to assume that the real hardware returns
> > the last written value in these addresses when reading, but in the
> > documentation they are write-only.
> 
> Yeah it was crashing in static int force_8bit_access_check_and_set
> in linux/drivers/pcmcia/cistpl.c, apparently while doing an
> 	GPSR(GPIO54_nPCE_2) = GPSR(GPIO54_nPCE_2);
> Patched that (patch-pxa-gpsr, attached), and now the boot seems
> to be hanging somewhere in userland...

Btw that patch is not yet committed, did it get lost?  or does it
cause problems...
> > 
> > > emulated.  And when i boot with init=/bin/sh I can't do much because
> > > the keymap seems to be wrong or the fn key otherwise gets lost.
> > > (similar effect with the poky image btw, I wonder is this a qemu
> > > problem or is just noone using the terminal there? :)
> > 
> > The problem here is the 2.6 kernel's default keymap and the zaurusd
> > daemon used in poky and openzaurus. They use this strange keymap and
> > qemu tries to account for that. I had first set a keymap in qemu that
> > matched the console keymap but later when I started using X it was
> > unusable and other users also didn't like that so I remapped all the
> > keys, but the remapping is not perfect even now, because the real
> > Zaurus keymap is too far from a normal pc keyboard (and I don't have a
> > physical one).
> 
>  Yeah it has an fn key that is used to generate most special characters...
> But even shift didn't work on the 2.4 kernel's console (and as I said
> fn apparently got lost too), and with the poky rxvt it seemed like
> anything that uses fn caused an error (cursor flashes quickly) instead
> of sending the corresponding character.

 Anyway I just played with this a bit again and got the fn key
working by exchanging 0x3d and 0x38 in hw/spitz.c, spitz_keymap... :)
(after looking at linux/drivers/char/spitz_rawmap.h in the sharp kernel.)
I also added definitions for < > { and } while I was at it, and now
the keyboard mostly works, only the right shift key still does nothing
on the sharp kernel's console and there seem to be the occasional
timing issues especially with 2.6 kernels i.e. sometimes the fn key
still gets lost etc.

 Patch attached, enjoy...
	Juergen

[-- Attachment #2: patch-fnkey --]
[-- Type: text/plain, Size: 1125 bytes --]

Index: qemu/hw/spitz.c
@@ -194,8 +194,8 @@
     { 0x0f, 0x10, 0x12, 0x14, 0x22, 0x16, 0x24, 0x25,  -1 ,  -1 ,  -1  },
     { 0x3c, 0x11, 0x1f, 0x21, 0x2f, 0x23, 0x32, 0x26,  -1 , 0x36,  -1  },
     { 0x3b, 0x1e, 0x20, 0x2e, 0x30, 0x31, 0x34,  -1 , 0x1c, 0x2a,  -1  },
-    { 0x44, 0x2c, 0x2d, 0x0c, 0x39, 0x33,  -1 , 0x48,  -1 ,  -1 , 0x3d },
-    { 0x37, 0x38,  -1 , 0x45, 0x57, 0x58, 0x4b, 0x50, 0x4d,  -1 ,  -1  },
+    { 0x44, 0x2c, 0x2d, 0x0c, 0x39, 0x33,  -1 , 0x48,  -1 ,  -1 , 0x38 },
+    { 0x37, 0x3d,  -1 , 0x45, 0x57, 0x58, 0x4b, 0x50, 0x4d,  -1 ,  -1  },
     { 0x52, 0x43, 0x01, 0x47, 0x49,  -1 ,  -1 ,  -1 ,  -1 ,  -1 ,  -1  },
 };
 
@@ -425,6 +428,10 @@
     s->pre_map[0x35 | SHIFT	] = 0x34 | SHIFT;	/* question */
     s->pre_map[0x49		] = 0x48 | FN;		/* Page_Up */
     s->pre_map[0x51		] = 0x50 | FN;		/* Page_Down */
+    s->pre_map[0x33 | SHIFT	] = 0x33 | FN;		/* less */
+    s->pre_map[0x34 | SHIFT	] = 0x34 | FN;		/* greater */
+    s->pre_map[0x1a | SHIFT	] = 0x16 | FN;		/* braceleft */
+    s->pre_map[0x1b | SHIFT	] = 0x17 | FN;		/* braceright */
 
     s->modifiers = 0;
     s->imodifiers = 0;

Re: [Qemu-devel] qemu-system-arm -M akita/terrier - which roms work? (and cursor issue)

[andrzej zaborowski]

On 24/07/07, Juergen Lock <nox@jelal.kn-bremen.de> wrote:
>  I just played with this a bit and although I got the stuff at
>         http://pokylinux.org/releases/clyde-2.0/
> somewhat working (tried the akita ones going after
>         http://butterfeet.org/?m=200705
> , I seem to miss -showcursor and consequently got no cursor

Oh, there's a typo in that post, it's -show-cursor.

Regards