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. :)
- 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
