AW: Microwindows on Icecube/CoralP

[Jarno Manninen]

On Tue, 8 Feb 2005, Martin Krause wrote:

> linuxppc-embedded-bounces at ozlabs.org wrote on :
> > > This will not work. Microwindows can only  use  a  plain framebuffer
> > > interface,  but  the Coral-P does not allow for such a driver
> > > because of the fact that it has a little-endian register interface.
> >
> > Or is it because 5200 swaps bytes around on PCI.  It sure looks to me
> > like Freescale has made a major screwup in their implementation of
> > PCI on the 5200.  I'd love for somebody to prove me wrong about this,
> > but I'm afraid I'm right.  I was under the impression that
> > CoralP worked
> > nicely on 5200, but now I see that it also requires software
> > tweaks to work
> > on 5200.
>
> I have similar problems with an MPC5200 board and a Silicon Motion
> SM501 (Voyager) grafic controller. The controller has a PCI and a
> local bus interface. We use the local bus interface to connect it
> with the 5200. In 32 bit truecolor mode everything works fine, but
> in 16 bit mode bytes are swapped: 0x12345678 => 0x34127856.
> I'm not sure, if this problem has something to do with the CoralP
> problem, but it is likely too similar to be completely independent.
> Does anyone use an SM501 in 16 bit mode?

This is the problem with big-endian systems with PCI bus. I've seen this
on sparc and on MPC5200 too. There is no other solution, but to swap the
bytes in SW.

The problem is that the PCI bus and CPU must agree when thinking of
arithmetic context. For example when talking about adresses, both parties
have to see address numbers in the same way. Problem is that with graphics
formats we are talking about bit masks, not actual numbers. So inner byte
order _does_ have meaning while with plain numbers it does _not_, right?

- Jarno