-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04.01.2011, at 22:59, Andreas Färber wrote: > Am 04.01.2011 um 22:43 schrieb Alexander Graf: > >> On 04.01.2011, at 22:36, Andreas Färber wrote: >> >>> Am 04.01.2011 um 21:57 schrieb Alexander Graf: >>> >>>> On 27.12.2010, at 01:25, Andreas Färber wrote: >>>> >>>>> Am 27.12.2010 um 01:11 schrieb Alexander Graf: >>>>> >>>>>> Am 27.12.2010 um 00:28 schrieb Andreas Färber <andreas.faer...@web.de>: >>>>>> >>>>>>> Am 14.12.2010 um 01:49 schrieb Andreas Färber: >>>>>>> >>>>>>>> Workaround the following error: >>>>>>>> >>>>>>>> qemu: hardware error: register_ioport_read: invalid opaque >>>>>>> >>>>>>> I found out that this is a conflict with i8042 registering I/O port >>>>>>> 0x0092 in pckbd.c, too. >>>>>>> Not sure what the proper fix should look like - add some qdev property >>>>>>> to ISAKBDState to disable the port? >>>>>> >>>>>> Well, why does the PREP board have its own mapping there in the first >>>>>> place? It should be the same as a PC from a port pov, no? >>>>> >>>>> Why does the i8042 controller have a System Control Port in the first >>>>> place rather than the 'pc' machine? :) >>>>> >>>>> The PReP spec v1.1 has a Special Port 0x0092 that includes two bits of >>>>> significence - softreset and endian mode. So wherever the port is >>>>> registered, the latter behavior is board-specific and does not match >>>>> pckbd.c (A20 gate or HDD activity depending on bit numbering). >>>>> >>>>> A similar issue arises between PReP machines: The ioport currently does >>>>> not allow using a different opaque for reads and writes to the same >>>>> address. So either we need to change ioport or create some >>>>> inheritence/override mechanism for port behavior. >>>> >>>> Hmm - sounds to me like that register simply doesn't belong there then, so >>>> a split would be the correct solution. The alternative would be to have >>>> the keyboard controller create a bus that those bits send signals to. An >>>> x86 system could then implement its A20 gate in x86 specific code while >>>> PREP could do its specific stuff. >>> >>> Coincidentally there's a recent pckbd patch from Blue that resolves the >>> conflict. Feel free to review. :) >> >> Ah, sorry :). Still catching up. Just now finished to watch news of the last >> 1 1/2 weeks :). > > Welcome back. Did they have to pay much? ;) The only one ending up paying was me to get in for the 27c3 ;). >>> Any thoughts on the read vs. write port issue? Do we need to register both >>> ports in the base device and add hooks to the device state? Sounds >>> problematic VMState-wise, just like some of the qemu_irq constructs in the >>> ppc devices. (My prep_pci changes are still far from perfect, UniNorth has >>> similar issues I noticed.) >> >> Well, the general idea is that a single IO always gets routed to the same >> device. I don't fully understand why you need separate handlers there tbh. >> Mind to explain this? > > In short: Inheritance. > > The actual issue appears to be snip'ed above, it's about apparent subtle > machine differences concerning non-standard register uses (here, "Motorola > ... register" in -M prep vs. nothing in PReP 1.1 spec). Hrm. So the port belongs to machine specific code then and should only call helper functions for other generic bits, no? Alex -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) iEYEARECAAYFAk0jmOYACgkQq7Wi27wfN1Pp2ACdFf7aa8y/tNC7fx9Z4zFheNnU 1RQAnjGNJqAGhYNvEOKuNihLVJKsVeG9 =QdiF -----END PGP SIGNATURE-----