-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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 :). > 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? Alex -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) iEYEARECAAYFAk0jlJcACgkQq7Wi27wfN1N/agCeL6hOC6c+DHjLQ7Q3uXsp1Clo x94An0lSzs/kvXGynRy1y2UMmLwpltp1 =NkaJ -----END PGP SIGNATURE-----
