Re: Xorg on Fujitsu Lime with MPC5200b?
Hello Bill, On Thursday 15 April 2010 22:14:09 Bill Gatliff wrote: I'm not sure what the *Weak stuff is doing. Can I just hack shadowUpdatePacked() itself? I think so. But take care if you want to use that code on other systems or without shadowfb. If I search for shadowUpdatePacked, then I'll find it in quite some other locations. Roman -- Roman FietzeTelemotive AG Büro Mühlhausen Breitwiesen 73347 Mühlhausen Tel.: +49(0)7335/18493-45http://www.telemotive.de Amtsgericht UlmHRB 541321 Vorstand: Peter Kersten, Markus Fischer, Franz Diller, Markus Stolz signature.asc Description: This is a digitally signed message part. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Xorg on Fujitsu Lime with MPC5200b?
Hello Bill,
On Thursday 15 April 2010 18:07:03 Bill Gatliff wrote:
I would love it if you posted your code! Thanks!!
In this source file I just added my own routines:
Index: programs/Xserver/hw/xfree86/drivers/fbdev/fbdev.c
===
--- programs/Xserver/hw/xfree86/drivers/fbdev/fbdev.c (revision 6)
+++ programs/Xserver/hw/xfree86/drivers/fbdev/fbdev.c (revision 7)
@@ -139,8 +139,8 @@
shadowInit,
shadowSetup,
shadowUpdatePacked,
- shadowUpdatePackedSwapped16Weak,
- shadowUpdatePackedSwapped32Weak,
+ shadowUpdatePackedSwapped16,
+ shadowUpdatePackedSwapped32,
shadowUpdateRotatePacked,
NULL
};
@@ -619,6 +619,7 @@
ScrnInfoPtr pScrn = xf86Screens[pScreen-myNum];
FBDevPtr fPtr = FBDEVPTR(pScrn);
VisualPtr visual;
+ ShadowUpdateProc pupdate;
int init_picture = 0;
int ret,flags,width,height;
@@ -794,7 +795,7 @@
xf86DrvMsg(pScrn-scrnIndex, X_WARNING,
RENDER extension initialisation failed.\n);
- pupdate = pScrn-bitsPerPixel 16 ? shadowUpdatePackedSwapped32Weak() :
shadowUpdatePackedSwapped16Weak();
+ pupdate = pScrn-bitsPerPixel 16 ? shadowUpdatePackedSwapped32 : shado
wUpdatePackedSwapped16;
if (fPtr-shadowFB
(!shadowSetup(pScreen) || !shadowAdd(pScreen, NULL,
And here's my complete programs/Xserver/miext/shadow/shpacked.c
/*
* $XFree86: xc/programs/Xserver/miext/shadow/shpacked.c,v 1.5 2001/10/28
03:34:16 tsi Exp $
*
* Copyright © 2000 Keith Packard
*
* Permission to use, copy, modify, distribute, and sell this software and its
* documentation for any purpose is hereby granted without fee, provided that
* the above copyright notice appear in all copies and that both that
* copyright notice and this permission notice appear in supporting
* documentation, and that the name of Keith Packard not be used in
* advertising or publicity pertaining to distribution of the software without
* specific, written prior permission. Keith Packard makes no
* representations about the suitability of this software for any purpose. It
* is provided as is without express or implied warranty.
*
* KEITH PACKARD DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
* INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
* EVENT SHALL KEITH PACKARD BE LIABLE FOR ANY SPECIAL, INDIRECT OR
* CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
* DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
* TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
* PERFORMANCE OF THIS SOFTWARE.
*/
#includebyteswap.h
#includeunistd.h
#includeX.h
#includescrnintstr.h
#includewindowstr.h
#includefont.h
#includedixfontstr.h
#includefontstruct.h
#includemi.h
#includeregionstr.h
#includeglobals.h
#includegcstruct.h
#includeshadow.h
#includefb.h
void
shadowUpdatePacked (ScreenPtr pScreen,
shadowBufPtrpBuf)
{
RegionPtr damage = pBuf-damage;
PixmapPtr pShadow = pBuf-pPixmap;
int nbox = REGION_NUM_RECTS (damage);
BoxPtr pbox = REGION_RECTS (damage);
FbBits *shaBase, *shaLine, *sha;
FbStrideshaStride;
int scrBase, scrLine, scr;
int shaBpp;
int shaXoff, shaYoff; /* XXX assumed to be zero */
int x, y, w, h, width;
int i;
FbBits *winBase = NULL, *win;
CARD32 winSize;
fbGetDrawable (pShadow-drawable, shaBase, shaStride, shaBpp, shaXoff,
shaYoff);
while (nbox--)
{
x = pbox-x1 * shaBpp;
y = pbox-y1;
w = (pbox-x2 - pbox-x1) * shaBpp;
h = pbox-y2 - pbox-y1;
scrLine = (x FB_SHIFT);
shaLine = shaBase + y * shaStride + (x FB_SHIFT);
x = FB_MASK;
w = (w + x + FB_MASK) FB_SHIFT;
while (h--)
{
winSize = 0;
scrBase = 0;
width = w;
scr = scrLine;
sha = shaLine;
while (width) {
/* how much remains in this window */
i = scrBase + winSize - scr;
if (i = 0 || scr scrBase)
{
winBase = (FbBits *) (*pBuf-window) (pScreen,
y,
scr * sizeof (FbBits),
SHADOW_WINDOW_WRITE,
winSize,
pBuf-closure);
if(!winBase)
return;
scrBase = scr;
Re: Xorg on Fujitsu Lime with MPC5200b?
Hello Bill, On Friday 16 April 2010 04:51:38 Bill Gatliff wrote: Apparently, there are several similar modifications that need to be made, ... I'm SW-Engineer, so I assume HW, that's always a good bet. ;) Please take care, that I forgot to tell you that my X server runs well on a Futjitsu 86295 chip, also connected to a MPC5200(B). I silently assumed that those two are identical in terms of byte ordering and (non) existant automatic byte swapping. At least, when you get a black screen when copying out nothing, you might be able to copy over some fixed pattern to find out what bits cause what, e.g. start writing 0x03 and shift that pattern left every 16 scanlines. In what mode is your X server running? 16/24/32 bit? DirectColor, etc? Roman -- Roman FietzeTelemotive AG Büro Mühlhausen Breitwiesen 73347 Mühlhausen Tel.: +49(0)7335/18493-45http://www.telemotive.de ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Xorg on Fujitsu Lime with MPC5200b?
On Fre, 2010-04-16 at 08:14 +0200, Roman Fietze wrote: On Thursday 15 April 2010 18:07:03 Bill Gatliff wrote: I would love it if you posted your code! Thanks!! In this source file I just added my own routines: Index: programs/Xserver/hw/xfree86/drivers/fbdev/fbdev.c === --- programs/Xserver/hw/xfree86/drivers/fbdev/fbdev.c (revision 6) +++ programs/Xserver/hw/xfree86/drivers/fbdev/fbdev.c (revision 7) @@ -139,8 +139,8 @@ shadowInit, shadowSetup, shadowUpdatePacked, - shadowUpdatePackedSwapped16Weak, - shadowUpdatePackedSwapped32Weak, + shadowUpdatePackedSwapped16, + shadowUpdatePackedSwapped32, shadowUpdateRotatePacked, NULL }; @@ -619,6 +619,7 @@ ScrnInfoPtr pScrn = xf86Screens[pScreen-myNum]; FBDevPtr fPtr = FBDEVPTR(pScrn); VisualPtr visual; + ShadowUpdateProc pupdate; int init_picture = 0; int ret,flags,width,height; @@ -794,7 +795,7 @@ xf86DrvMsg(pScrn-scrnIndex, X_WARNING, RENDER extension initialisation failed.\n); - pupdate = pScrn-bitsPerPixel 16 ? shadowUpdatePackedSwapped32Weak() : shadowUpdatePackedSwapped16Weak(); + pupdate = pScrn-bitsPerPixel 16 ? shadowUpdatePackedSwapped32 : shado wUpdatePackedSwapped16; if (fPtr-shadowFB (!shadowSetup(pScreen) || !shadowAdd(pScreen, NULL, I hope you're aware that this really just hacks around the kernel framebuffer device not exposing the framebuffer to userspace according to the fbdev interface (see struct fb_bitfield in /usr/include/linux/fb.h), and this will affect everything else using the framebuffer device as well. It would be better to handle this in the kernel framebuffer device, either via hardware byte swapping facilities if available, or otherwise e.g. via FB_DEFERRED_IO. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Xorg on Fujitsu Lime with MPC5200b?
On Thu, Apr 15, 2010 at 03:53:53PM +0200, Roman Fietze wrote:
Hello Bill,
On Thursday 15 April 2010 15:01:59 Bill Gatliff wrote:
Are you talking about this code here?
void
shadowUpdatePacked (ScreenPtr pScreen,
shadowBufPtr pBuf)
{
...
while (i--)
*win++ = *sha++;
Yes. I added a routine like
/* Swap frame buffer bytes in 32 bit value. */
static __inline unsigned int
fbbits_swap32(unsigned int __bsx)
{
return __bsx) 0xff00) 8) | (((__bsx) 0x00ff) 8) |
(((__bsx) 0xff00) 8) | (((__bsx) 0x00ff) 8));
}
I don't see the difference with:
return (((__bsx 0xff00ff00) 8) | ((__bsx 0x00ff00ff) 8));
for which the compiler (GCC 4.3.2) generates better code (GCC 4.3.2) as shown.
In the first case:
.L3:
lwzx 9,3,8
rlwinm 0,9,8,0,7
rlwinm 11,9,24,8,15
rlwinm 10,9,24,24,31
or 0,0,11
or 0,0,10
rlwinm 9,9,8,16,23
or 0,0,9
stwx 0,4,8
addi 8,8,4
bdnz .L3
in the second:
.L9:
lwzx 0,3,11
and 9,0,10
and 0,0,8
slwi 0,0,8
srwi 9,9,8
or 0,0,9
stwx 0,4,11
addi 11,11,4
bdnz .L9
saving 2 instructions. AFAIR the MPC5200 is based on a 603e core,
so the integer instructions have to go to the single integer unit that
can handle them (the second IU can only handle add and cmp), so the
mimimum is 5 clocks/iteration versus 7. Even with two IU (or 3), the
second code has better latency.
Gabriel
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Xorg on Fujitsu Lime with MPC5200b?
Hallo Bill, On Thursday 15 April 2010 05:07:08 Bill Gatliff wrote: Actually, I *have* Debian squeeze's xorg running on the platform just fine, with a 2.6.34-rc1 kernel (kernel.org). Problem is, every single diagonal line is very blocky--- not smooth at all. I'm 95% sure it's an endianess problem, on our boards we had to modify the X11 driver. What I did was swapping bytes when updating the device from the shadowfb inside programs/Xserver/miext/shadow/shpacked.c Roman -- Roman FietzeTelemotive AG Büro Mühlhausen Breitwiesen 73347 Mühlhausen Tel.: +49(0)7335/18493-45http://www.telemotive.de ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Xorg on Fujitsu Lime with MPC5200b?
On Wed, 14 Apr 2010 22:07:08 -0500 Bill Gatliff b...@billgatliff.com wrote: Put simply, I have an MPC5200b platform with a Fujitsu Lime GDC, and I'm trying to run Debian squeeze's xorg on it. Actually, I *have* Debian squeeze's xorg running on the platform just fine, with a 2.6.34-rc1 kernel (kernel.org). Problem is, every single diagonal line is very blocky--- not smooth at all. I used to think this was a problem with X's fonts, but now I don't think so because the mouse cursor's diagonal lines also look equally bad. It's almost as if any time the platform tries to draw a diagonal line, truncation/rounding errors are causing it problems in figuring out which pixels to turn on and off. On all PowerPC based boards with Lime (PPC440EPx, MPC85xx) I have seen so far there is a similar problem with direct access to the frame buffer in 16-bit mode. A non-Linux kernel on this hardware, running a non-X GUI, seems to work fine so I think the hardware isn't the problem. It is possible that this non-X GUI doesn't access the frame buffer directly but only uses the accelerated driver for rendering. In this case all drawing is done by Lime itself triggered by 32-bit accesses to the drawing command FIFO. Anyone have any suggestions on where to start with this one? Anyone else running a similar configuration with any success? I'm completely lost, and running out of hair *fast*... You probably have to fix Xorg driver for swapping. Anatolij ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Xorg on Fujitsu Lime with MPC5200b?
Roman Fietze wrote:
Hallo Bill,
On Thursday 15 April 2010 05:07:08 Bill Gatliff wrote:
Actually, I *have* Debian squeeze's xorg running on the platform just
fine, with a 2.6.34-rc1 kernel (kernel.org). Problem is, every single
diagonal line is very blocky--- not smooth at all.
I'm 95% sure it's an endianess problem, on our boards we had to modify
the X11 driver. What I did was swapping bytes when updating the device
from the shadowfb inside programs/Xserver/miext/shadow/shpacked.c
Are you talking about this code here?
void
shadowUpdatePacked (ScreenPtr pScreen,
shadowBufPtr pBuf)
{
...
while (i--)
*win++ = *sha++;
Do I endian-swap each *sha? Or, do I reorder the sha array before
dereferencing it (e.g. each *sha is right, but adjacent ones are in the
wrong order)?
b.g.
--
Bill Gatliff
b...@billgatliff.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Xorg on Fujitsu Lime with MPC5200b?
Hello Bill,
On Thursday 15 April 2010 15:01:59 Bill Gatliff wrote:
Are you talking about this code here?
void
shadowUpdatePacked (ScreenPtr pScreen,
shadowBufPtr pBuf)
{
...
while (i--)
*win++ = *sha++;
Yes. I added a routine like
/* Swap frame buffer bytes in 32 bit value. */
static __inline unsigned int
fbbits_swap32(unsigned int __bsx)
{
return __bsx) 0xff00) 8) | (((__bsx) 0x00ff) 8) |
(((__bsx) 0xff00) 8) | (((__bsx) 0x00ff) 8));
}
Then I added void shadowUpdatePackedSwapped16() and
shadowUpdatePackedSwapped32() which I was using instead of the
original *Weak functions, which in turn uses the above swap routine
when copying from shadow to the device.
If you want I can post (in the ML) or mail you the files that I
changed. A diff probably won't help a lot, because I think we changed
more than that, and we are using a pretty old XFree version.
Roman
--
Roman FietzeTelemotive AG Büro Mühlhausen
Breitwiesen 73347 Mühlhausen
Tel.: +49(0)7335/18493-45http://www.telemotive.de
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Xorg on Fujitsu Lime with MPC5200b?
I would love it if you posted your code! Thanks!!
b.g.
On Apr 15, 2010 8:53 AM, Roman Fietze roman.fie...@telemotive.de wrote:
Hello Bill,
On Thursday 15 April 2010 15:01:59 Bill Gatliff wrote:
Are you talking about this code here?
...
Yes. I added a routine like
/* Swap frame buffer bytes in 32 bit value. */
static __inline unsigned int
fbbits_swap32(unsigned int __bsx)
{
return __bsx) 0xff00) 8) | (((__bsx) 0x00ff) 8) |
(((__bsx) 0xff00) 8) | (((__bsx) 0x00ff) 8));
}
Then I added void shadowUpdatePackedSwapped16() and
shadowUpdatePackedSwapped32() which I was using instead of the
original *Weak functions, which in turn uses the above swap routine
when copying from shadow to the device.
If you want I can post (in the ML) or mail you the files that I
changed. A diff probably won't help a lot, because I think we changed
more than that, and we are using a pretty old XFree version.
Roman
--
Roman Fietze Telemotive AG Büro Mühlhausen
Breitwiesen ...
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Xorg on Fujitsu Lime with MPC5200b?
Roman Fietze wrote: Then I added void shadowUpdatePackedSwapped16() and shadowUpdatePackedSwapped32() which I was using instead of the original *Weak functions, which in turn uses the above swap routine when copying from shadow to the device. I'm not sure what the *Weak stuff is doing. Can I just hack shadowUpdatePacked() itself? b.g. -- Bill Gatliff b...@billgatliff.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Xorg on Fujitsu Lime with MPC5200b?
Roman Fietze wrote:
Yes. I added a routine like
/* Swap frame buffer bytes in 32 bit value. */
static __inline unsigned int
fbbits_swap32(unsigned int __bsx)
{
return __bsx) 0xff00) 8) | (((__bsx) 0x00ff) 8) |
(((__bsx) 0xff00) 8) | (((__bsx) 0x00ff) 8));
}
I baked the above code into shadowUpdatePacked(), and it didn't seem to
help anything--- my icewm mouse cursor was still quite jagged, as was
all the text on the screen (clock widget, etc). So I replaced the above
code with a return 0, and the icewm desktop went completely black--- and
everything else remained unchanged.
Apparently, there are several similar modifications that need to be
made, i.e. the shadowUpdatePacked() function isn't the only way to the
framebuffer memory? I'm really looking forward to seeing your code, as
I have no idea how to even identify the places that need hacking. I
understand the utility of the hack, however.
Makes me think that we're all just soldering this chip down to the wrong
data lines, and makes me wonder if there isn't an endianness bit in
the memory bus controller that can undo this damage for us. I know I've
seen such a bit in other SoCs...
Thanks!
b.g.
--
Bill Gatliff
b...@billgatliff.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Xorg on Fujitsu Lime with MPC5200b?
On Wed, 2010-04-14 at 22:07 -0500, Bill Gatliff wrote: Anyone have any suggestions on where to start with this one? Anyone else running a similar configuration with any success? I'm completely lost, and running out of hair *fast*... Most probably endian bugs in the Lime driver ... Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
