qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] qemu-system-arm -M akita/terrier - which roms work? (mo


From: Juergen Lock
Subject: Re: [Qemu-devel] qemu-system-arm -M akita/terrier - which roms work? (more patches... :)
Date: Wed, 1 Aug 2007 01:32:00 +0200
User-agent: Mutt/1.5.16 (2007-06-09)

On Tue, Jul 31, 2007 at 11:31:58PM +0200, andrzej zaborowski wrote:
> On 31/07/07, Juergen Lock <address@hidden> 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 <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]