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