On Tue, 7 Mar 2023, Paolo Bonzini wrote:
On 3/7/23 13:54, BALATON Zoltan wrote:
evt 3 1 write 1 // enable timer
evt 0 2 read
evt 0 2 write 1 // just writes again the same value, clearing sts
I am quite confident that the second guess is correct, because "write the
same value that was read" only makes sense for evt_sts and not for evt_en.
It could also make sense if the guest is trying to flip a bit that's
already set or cleared.
No, I checked what the guest actually does and it's read followed immediately
by a write, with no other ALU values in the middle.
AFAIU the device is little endian (VT8231 is a PCI device and primarily a
PC part so it's expected to be little endian) but the guest also knows this
and writes byte swaped values to it. But since the memory region is set to
LITTLE_ENDIAN and we're on a big endian CPU QEMU will byte swap it again
which it should not do as the guest already did that.
It's the opposite.
The CPU first swaps the value that was in the register, when it executes
sthbrx instructions. With DEVICE_LITTLE_ENDIAN, QEMU does the second swap
and restores the value that was in the register. With DEVICE_NATIVE_ENDIAN
it happens to fix the cases that matter for your testcase, but it breaks
others.
This means that the first write is almost certainly to evt_en. On a
little-endian machine the write would set bit 8 of evt.en (power button),
but what about a big-endian machine like yours? Should it set bit 0 or
bit 8? If it's bit 0 (which resides at offset 2 according to the device),
who flips the low bit of the address? Why is bit 0 flipped but not bit 1?
I think the guest already writes byte swapped value so it should work the
same as on little endian machine but the QEMU memory layer gets in the way.
The write in question is "evt addr=3 size=1 value=1" so it's a one-byte
write. There's no byte swapping involved here, rather the question is how
the addresses are interpreted.
- get a real machine, and figure out whether the write to offset 3
corresponds to the PM timer or the power button.
I don't have real machine but know somebody who does but I'm not sure what
to ast to test on it. Can you describe it what you want to see or maybe
write a sctipt for the fimrware to test it (if you're familiar enough with
Forth for that). I can try to find some more info on this but so far I was
concentrating on other bigger issues. This is a minor annoyance but would
be nice to fix eventually.
I didn't even have an idea that Forth was involved, honestly, or how to write
Forth code for this machine that I barely know exists. :)
It's supposed to be CHRP compatible which mandates OpenFirmware so it
should work about the same as similar IBM and Apple machines but those are
also kind of obscure. If you can describe what you want tested I can try
to make that a script and ask somebody to run it on real machine but I'm
not sure what to test.
Regards,
BALATON Zoltan
- continue the trace up to the point the OS runs, and see if you get some
clues similar to the one above that placed evt_sts at offset 2.
I'll try this once the machine is back in shape.
Paolo
