-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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. Alex -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) iEYEARECAAYFAk0jibgACgkQq7Wi27wfN1PtUACfdx6L4Sk/aR5/sC3QEg1Hciyy Zm0AnAxaD2jguRq+RcaI8TLsaWGE1gN7 =VioX -----END PGP SIGNATURE-----