On Tue, Jul 31, 2007 at 11:31:58PM +0200, andrzej zaborowski wrote:
> 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)
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
