On 4 March 2017 at 22:58, BALATON Zoltan <bala...@eik.bme.hu> 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. thanks -- PMM
