Yeeehaaaa....

Mike found the problem I would say, because I used his patch and voila.
It works. Great, really Great. I had to set up the monitor manually but i
just works. This is the first time that I see a graphical environment for a
year now on my loved mac :)

However some more things occur now... 

Does anybody know what this means

./glxinfo
/usr/lib/libgcc_s.so.1:Unsupported relocation type 10 in non PLT relocation?

And...

Does anybody if a generic pci ide controller works on netbsd/macppc where I
can put a e.g. 80 GB harddisk?
I know it will not be compatible to open firmware, but this is not
necessary...
And what about generic USB controllers attached to pci??

I know that it should work... but ....

Anyone tried GLX on NetBSD/macppc with success? (duck, i tried it on
NetBSD/i386 last year but XFree always crashed) ... I know I am dreaming...

Regards 
And thanx a lot

PS:I would submit it if I were you- at least that we have a workaround ...
and what about the ofwboot.xcf issue
I just can use a current, because I crosscompiled a own smaller (~3MB)
kernel and netbooted the mac (ofw 1.05) . This was fun :)

Now I am going on watching glxgears while compiling my new desktop... :)

Mike wrote:
>The real problem seems to be that mmap'ing on wscons doesn't seem to
work, if the X came directly from XFree86.  (It seems to work for
XFree 4.3 if our guys have passed their magic over it and you download
the XFree from the NetBSD distribution.) It hasn't worked for some
time now, the

  xf86MapVidMem: could not mmap screen [s=10000,a=a0000] (Invalid argument)

or another popular one:

  -Fatal server error:
  -xf86MapVidMem: could not mmap screen [s=40000,a=c0000] (Invalid argument)


complaint has popped up on this mailing list many times.

In the instant case, however, xf86MapVidMem is trying to open the
frame buffer at the usual ISA (or PCI, maybe) memory hole for PC's and
such.  This is not likely to be successful on macs.

The usual complaint is:

1157123-(--) R128(0): Chipset: "ATI Rage 128 RE (PCI)" (ChipID = 0x5245)
1157124-(--) R128(0): Linear framebuffer at 0x84000000
1157125-(--) R128(0): MMIO registers at 0x80808000
1157126-(--) R128(0): BIOS at 0x80820000
1157127-
1157128-Fatal server error:
1157129:xf86MapVidMem: could not mmap screen [s=4000,a=80808000] (Invalid
argument)

which would be trying to open the MMIO registers at 80808000, which is
probably valid, or

1110230:xf86MapVidMem: could not mmap screen [s=80000,a=90000000] (invalid
argument)

which is what we got on an ibook, which we _know_ is valid.  (It's
trying to open a mmap over the MMIO registers at address 0x90000000
for a size of 0x80000.)

My first take on this, expressed in an email to this list on 5 Nov
2003 is bogus:

1156722-+       ppn = atop(off);
1156723-
1156724-which ppn needs to be expressed as the number of page_size pages to
1156725-_both_ test for >physmem (which is in page size pages), and as the
1156726-function return.  The original ppc code

the udv_attach and udv_fault routines call the mmmap routine, but also
use the pmap_phys_address() routine to re-translate the page back to a
physical address, which, on powerpc, is a null routine.

We wanted to try the (then) latest XFree86 to see if it would get rid
of the lines in our ibook, but we got the same mmap failure error.
So, we changed (working with a current
xfree)
(XFree86-4.3.99.16)/xc/programs/Xserver/hw/xfree86/os-support/bsd/ppc_video.c:

=====================================================================
--- ppc_video.c.original        2003-10-10 07:06:35.000000000 -0400
+++ ppc_video.c 2004-03-01 16:36:08.000000000 -0500
@@ -38,27 +38,31 @@
 #ifndef MAP_FAILED
 #define MAP_FAILED ((caddr_t)-1)
 #endif
 
 

/***************************************************************************/
 /* Video Memory Mapping section                                           
*/

/***************************************************************************/
 
+static int  devMemFd = -1;
+
 #ifndef __OpenBSD__
 #define DEV_MEM "/dev/mem"
 #else
 #define DEV_MEM "/dev/xf86"
 #endif
 
 static pointer ppcMapVidMem(int, unsigned long, unsigned long, int flags);
 static void ppcUnmapVidMem(int, pointer, unsigned long);
 
+#define DEBUG
+
 void
 xf86OSInitVidMem(VidMemInfoPtr pVidMem)
 {
        pVidMem->linearSupported = TRUE;
        pVidMem->mapMem = ppcMapVidMem;
        pVidMem->unmapMem = ppcUnmapVidMem;
        pVidMem->initialised = TRUE;
 }
 
@@ -69,22 +73,29 @@
 ppcMapVidMem(int ScreenNum, unsigned long Base, unsigned long Size, int
flags)
 {
        int fd = xf86Info.screenFd;
        pointer base;
 #ifdef DEBUG
        xf86MsgVerb(X_INFO, 3, "mapVidMem %lx, %lx, fd = %d", 
                    Base, Size, fd);
 #endif
 
-       base = mmap(0, Size,
-                   (flags & VIDMEM_READONLY) ?
-                    PROT_READ : (PROT_READ | PROT_WRITE),
-                   MAP_SHARED, fd, Base);
+       if (devMemFd < 0) 
+            if ((devMemFd = open(DEV_MEM, O_RDWR)) < 0)
+            {
+               FatalError("ppcMapVidMem: failed to open %s (%s)\n",
+                       "/dev/mem", strerror(errno));
+            }
+
+       base = mmap(0, Size, PROT_READ | PROT_WRITE,
+                   /*(flags & VIDMEM_READONLY) ?
+                    PROT_READ : (PROT_READ | PROT_WRITE),*/
+                   MAP_SHARED, devMemFd, Base);
        if (base == MAP_FAILED)
                FatalError("%s: could not mmap screen [s=%x,a=%x] (%s)",
                           "xf86MapVidMem", Size, Base, strerror(errno));
 
        return base;
 }
 
 static void
 ppcUnmapVidMem(int ScreenNum, pointer Base, unsigned long Size)
=====================================================================

then, it worked:

(--) PCI:*(0:16:0) ATI Technologies Inc Radeon Mobility M7 LW [Radeon
 Mobility 7500] rev 0, Mem @ 0x98000000/27, 0x90000000/16, I/O @
 0x0400/8, BIOS @ 0x90020000/17

...

(II) Setting vga for screen 0.
(II) RADEON(0): MMIO registers at 0x90000000
(II) mapVidMem 90000000, 80000, fd = 6(II) Loading sub module "vgahw"
(II) LoadModule: "vgahw"
(II) Loading /usr/X11R6/lib/modules/libvgahw.a
(II) Module vgahw: vendor="The XFree86 Project"
        compiled for 4.3.99.16, module version = 0.1.0
        ABI class: XFree86 Video Driver, version 0.7
(II) RADEON(0): vgaHWGetIOBase: hwp->IOBase is 0x03b0, hwp->PIOOffset is
0x0000
(II) RADEON(0): PCI bus 0 card 16 func 0
(**) RADEON(0): Depth 8, (--) framebuffer bpp 8
(II) RADEON(0): Pixel depth = 8 bits stored in 1 byte (8 bpp pixmaps)
(==) RADEON(0): Default visual is PseudoColor
(**) RADEON(0): Option "MonitorLayout" "LVDS"
(II) RADEON(0): Using 8 bits per RGB (8 bit DAC)
(--) RADEON(0): Chipset: "ATI Radeon Mobility M7 LW (AGP)" (ChipID = 0x4c57)
(--) RADEON(0): Linear framebuffer at 0x98000000
(--) RADEON(0): BIOS at 0x90020000


and so on.

So, you might try the patch, but YMMV.

Our questions:

1.  How do we get the wscons to behave properly to do the mmap?  Is it
    that wscons isn't being properly opened, or somehow closed,
    before getting to the ppcMapVidMem() routine?

2.  How do we get rid of the lines in the LCD screen?  My guess is
    that the timings are incorrect. Anyone with a clue on how to set
    up an "ATI Technologies Inc Radeon Mobility M7 LW [Radeon Mobility
    7500]" on an Apple ibook?  There doesn't seem to be any specific
    set-up for this chip, or this combo, in the ATI driver routines.

    It's possible that we might be able to open the "BIOS at
    0x90020000" and get better values.  The ATI routines seem to think
    that the BIOS is bogus, but what does it know?  There might be a
    perfectly good (but i386-centric) BIOS there.

3.  The XFree INT10 subsection seems to have an i386 instruction
    decoder/interpreter that seems to work (on my MBX860 anyway) on
    the BIOS.  Can, should we take advantage of that?

Kind regards,

-Mike

-- 
www: http://drewke.net / icq:175089452

+++ NEU bei GMX und erstmalig in Deutschland: TÜV-geprüfter Virenschutz +++
100% Virenerkennung nach Wildlist. Infos: http://www.gmx.net/virenschutz