On 4 March 2017 at 22:58, BALATON Zoltan <address@hidden> wrote:
On Sat, 4 Mar 2017, Peter Maydell wrote:
Right, but we should test the PCI-on-a-little-endian CPU
case, because right now your code has #ifdef TARGET_WORDS_BIGENDIAN
in it which means that the PCI device will behave differently
on big and little endian CPUs, and you have a case that you
haven't tested.
I could not find an image to test this. I've tried removing the sysbus
version from SH and add a PCI one instead but then Linux did not seem to
find the card.
I was thinking about testing the PCI card on x86.
I could not find any other OS images that would have this
combination that is also known to work on any real hardware so I think if
someone ever finds a problem with such combination then we can fix it when
having a test case, since I could not figure out theoretically what should
be the right way.
(At the moment with the set of cases you've tested the
sh embedded device ones will always be using the "not
TARGET_WORDS_BIGENDIAN" code and the PCI-on-PPC will
always use the "is TARGET_WORDS_BIGENDIAN" code. But
TARGET_WORDS_BIGENDIAN set/not set is orthogonal to
PCI-vs-embedded.)
Why do you think that framebuffer endianness is dependent on PCI-vs-embedded
as opposed to target endianness? The latter seems more plausible to me.
The PCI card should behave the same way whether you plug it
into a PPC system or an x86 system (since it's the same
hardware). So code in the handling of the PCI card that
looks at TARGET_WORDS_BIGENDIAN is suspicious.