Microwindows on Icecube/CoralP

Microwindows on Icecube/CoralP

[francois.ruvoen]

Hi all,=0D=0A=0D=0AI have been playing with the CoralP, Icecube and Debia=
n.=0D=0AWorks fine, thanks to the tutorial on the Denx site.=0D=0AI now w=
ould like to see the microwindows stuff working. I=0D=0Ahave been trying =
the demos from the ELDK but I get strange=0D=0Acolors, it seems my palett=
e is all wrong. The same happens=0D=0Awhen I recompile the latest version=
 of microwindows (except=0D=0AI get yet another palette).=0D=0AAny pointe=
rs?=0D=0A=0D=0AI am using the latest CVS for linuxppc_2_4_devel, ELDK 3.0=
=0D=0Aand Microwindows 0.90. The Lite5200 is a Rev 2 and the=0D=0ACoralP =
a Rev 5.=0A************************ ADSL JUSQU'A 16 MEGA + TELEPHONE GRAT=
UIT ************************=0AL'ultra haut d=E9bit =E0 30EUR/mois seulem=
ent ! Et vous t=E9l=E9phonez gratuitement en France vers les postes fixes=
, hors num=E9ros sp=E9ciaux.=0APour profiter de cette offre exceptionnell=
e, cliquez ici : http://register.tiscali.fr/adsl/  (voir conditions sur l=
e site)=0A=0A

Re: Microwindows on Icecube/CoralP

[Mark Chambers]

>I have been playing with the CoralP, Icecube and Debian.
>Works fine, thanks to the tutorial on the Denx site.
>I now would like to see the microwindows stuff working. I
>have been trying the demos from the ELDK but I get strange
>colors, it seems my palette is all wrong. The same happens
>when I recompile the latest version of microwindows (except
>I get yet another palette).
>Any pointers?

One unexpected thing about the 5200 is that it swaps bytes
to/from the PCI buss.  So if you write a 32 bit pixel, for
instance 0x12345678, it will be written to PCI as
0x78563412.  Presumably this is based on an assumption
that PCI targets will be little-endian.  So you might try
reversing bytes and see if the palettes make sense.

Mark Chambers

Re: Microwindows on Icecube/CoralP

[francois.ruvoen]

Thanks. Tweaking a little the source code and I now get the=0D=0Aright co=
lours. The funny thing is that byte swapping was:=0D=0A0x1234567 =3D> 0x3=
4126745. I initially thought I could just=0D=0Aswap the two least signifi=
cant bytes as I am pretty sure I=0D=0Aam using a 16-bit mode (fbset repor=
ts that anyway). Now I'd=0D=0Alike to see that in 640x480 and not just 10=
24x768 but that=0D=0Aissue seems tied the frame buffer driver this time.=0D=
=0A=0D=0A---------- Initial Header -----------=0D=0A=0D=0AFrom      : "Ma=
rk Chambers" <markc@mail.com>=0D=0ATo          :=0D=0A<francois.ruvoen@li=
bertysurf.fr>,"linuxppc-embedded"=0D=0A<linuxppc-embedded@ozlabs.org>=0D=0A=
Cc          : =0D=0ADate      : Mon, 7 Feb 2005 07:59:16 -0500=0D=0ASubje=
ct : Re: Microwindows on Icecube/CoralP=0D=0A=0D=0A=0D=0A>I have been pla=
ying with the CoralP, Icecube and Debian.=0D=0A>Works fine, thanks to the=
 tutorial on the Denx site.=0D=0A>I now would like to see the microwindow=
s stuff working. I=0D=0A>have been trying the demos from the ELDK but I g=
et strange=0D=0A>colors, it seems my palette is all wrong. The same happe=
ns=0D=0A>when I recompile the latest version of microwindows (except=0D=0A=
>I get yet another palette).=0D=0A>Any pointers?=0D=0A=0D=0AOne unexpecte=
d thing about the 5200 is that it swaps bytes=0D=0Ato/from the PCI buss. =
 So if you write a 32 bit pixel, for=0D=0Ainstance 0x12345678, it will be=
 written to PCI as=0D=0A0x78563412.  Presumably this is based on an assum=
ption=0D=0Athat PCI targets will be little-endian.  So you might try=0D=0A=
reversing bytes and see if the palettes make sense.=0D=0A=0D=0AMark Chamb=
ers=0D=0A=0D=0A=0D=0A=0A************************ ADSL JUSQU'A 16 MEGA + T=
ELEPHONE GRATUIT ************************=0AL'ultra haut d=E9bit =E0 30EU=
R/mois seulement ! Et vous t=E9l=E9phonez gratuitement en France vers les=
 postes fixes, hors num=E9ros sp=E9ciaux.=0APour profiter de cette offre =
exceptionnelle, cliquez ici : http://register.tiscali.fr/adsl/  (voir con=
ditions sur le site)=0A=0A

Re: Microwindows on Icecube/CoralP

[Wolfgang Denk]

Dear Francois,

in message <IBJDLO$2F7CB4091C41824099E5E47AB0570FD3@tiscali.fr> you wrote:
>
> I have been playing with the CoralP, Icecube and Debian.
> Works fine, thanks to the tutorial on the Denx site.
> I now would like to see the microwindows stuff working. I

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.  For  the
frameboffer,  each color is defined by a bit offset and the number of
(contiguous bits) in a data word. For example, assuming a color depth
of 16 bpp you could have something like this:

	MSB          LSB
	rrrrrrgggggbbbbb

In this case the "green" color has bit offset 5 and is 5  bits  wide,
while  "red" has offset 10 and is 6 bits wide. On the Coral-P you see
the bytes swapped, i. e.

	MSB          LSB
	gggbbbbbrrrrrrgg

The "green" bits are  split  into  two  non-contiguous  groups  which
cannot  be  desribed  in  the  way  it  is  needed  for a framebuffer
interface.

You will need a custom graphics driver which  swaps  all  color  data
that  get  written  to  the  Coral-P.  Standard Microwindows does not
support this mode of operation.

> have been trying the demos from the ELDK but I get strange
> colors, it seems my palette is all wrong. The same happens

Yes, this is the effect explained above.

> when I recompile the latest version of microwindows (except
> I get yet another palette).

Again, thisis only to be expected.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"Here's a fish hangs in the net like a poor man's right in  the  law.
'Twill hardly come out."     - Shakespeare, Pericles, Act II, Scene 1

Re: Microwindows on Icecube/CoralP

[Mark Chambers]

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

Mark Chambers

AW: Microwindows on Icecube/CoralP

[Martin Krause]

linuxppc-embedded-bounces@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.
>=20
> 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 =3D> 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?

regards,
Martin Krause

Re: AW: Microwindows on Icecube/CoralP

[Jarno Manninen]

On Tue, 8 Feb 2005, Martin Krause wrote:

> linuxppc-embedded-bounces@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

Re: AW: Microwindows on Icecube/CoralP

[Geert Uytterhoeven]

On Tue, 8 Feb 2005, Jarno Manninen wrote:
> On Tue, 8 Feb 2005, Martin Krause wrote:
> > linuxppc-embedded-bounces@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@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

Re: Microwindows on Icecube/CoralP

[Mark Chambers]

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

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

Two questions:  Is your local bus set up as 32 bits wide, and are
you writing 32 bits at a time?  The little/big endian issue only 
shows up when writing smaller values than the width of the 
interface.  In other words, an x86 and a PPC will write a 32bit
word to 32bit memory in exactly the same way.  The difference
comes in how they address bytes or words within that 32bit data
lane.  So if you, for instance, are writing longs in truecolor mode
and bytes in 16 bit mode that could explain what you are seeing.

On the 5200 you've got two issues to deal with:  You've got 
the byte/short addressing mismatches that might show up, then
you've also got to take into account that 5200 swaps the
byte lanes around.

Mark