[Top][All Lists]

[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, this time keyboard... :)
Date: Tue, 21 Aug 2007 00:45:37 +0200
User-agent: Mutt/1.5.16 (2007-06-09)

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

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

Attachment: patch-fnkey
Description: Text document

reply via email to

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