On 03/07/2021 17:29, Philippe Mathieu-Daudé wrote:
On 7/3/21 4:39 PM, Mark Cave-Ayland wrote:
On 03/07/2021 15:19, Philippe Mathieu-Daudé wrote:
From: Mark Cave-Ayland <mark.cave-ayl...@ilande.co.uk>
Commit 3fe9a838ec "dp8393x: Always use 32-bit accesses" assumed that
all accesses
to the registers were 32-bit but this is actually not the case. The
access size is
determined by the CPU instruction used and not the number of physical
address lines.
The big_endian workaround applied to the register read/writes was
actually caused
by forcing the access size to 32-bit when the guest OS was using a
16-bit access.
Since the registers are 16-bit then we can simply set .impl.min_access
to 2 and
then the memory API will automatically do the right thing for both
16-bit accesses
used by Linux and 32-bit accesses used by the MacOS toolbox ROM.
The change should work, but the commit message above needs a slight
tweak - maybe something like this?
Since the registers are 16-bit then we can simply set both
.impl.min_access and .impl.max_access to 2 and then the memory API will
automatically do the right thing for both 16-bit accesses used by Linux
and 32-bit accesses used by the MacOS toolbox ROM.
Do you mind sending v3 of this patch reworded (and including the .valid
fields)?
I've sent a v3 with the rewording but dropping the .valid fields since that breaks
MacOS and removed Finn's T-b tag as it may be there is an issue here with mips64el -
whilst it works for me on all of my test images, I'm struggling to keep up with all
the patches flying around everywhere :/
Now that your MIPS PR has been applied, perhaps it is worth sending a rebased v2 of
your RFC "dp8393x: Housekeeping" patchset to ensure that everyone is up to date with
the latest fixes? I won't be able to have a look at the CRC patchset for a few days
though.
ATB,
Mark.
