AW: Microwindows on Icecube/CoralP

Geert Uytterhoeven geert at linux-m68k.org
Tue Feb 8 20:17:52 EST 2005


On Tue, 8 Feb 2005, Jarno Manninen wrote:
> 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.

Yep, the Cybervision graphics cards on Amiga (S3 Trio or ViRGE) suffer from the
same problem.

> 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?

If your graphics chip has separate apertures for big and little endian (and a
control register to `fix' swapping depending on the color depth), you may be
able to find a configuration that doesn't need any swapping on the CPU.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds



More information about the Linuxppc-embedded mailing list