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

Reply via email to