[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-trivial] [Qemu-devel] [PATCH v2 07/14] sm501: Fix device endia
Re: [Qemu-trivial] [Qemu-devel] [PATCH v2 07/14] sm501: Fix device endianness
Mon, 6 Mar 2017 10:32:14 +0000
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
> 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.