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? ;)
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).
Andreas