On 31/07/07, Juergen Lock <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
