Subject: Fwd: Re: getting X11 on the 9500
To: None <email@example.com>
From: Andreas Drewke <firstname.lastname@example.org>
Date: 03/10/2004 23:01:06
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
/usr/lib/libgcc_s.so.1:Unsupported relocation type 10 in non PLT relocation?
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
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...
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... :)
>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
1157128-Fatal server error:
1157129:xf86MapVidMem: could not mmap screen [s=4000,a=80808000] (Invalid
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
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);
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
--- 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 @@
#define MAP_FAILED ((caddr_t)-1)
/* Video Memory Mapping section
+static int devMemFd = -1;
#define DEV_MEM "/dev/mem"
#define DEV_MEM "/dev/xf86"
static pointer ppcMapVidMem(int, unsigned long, unsigned long, int flags);
static void ppcUnmapVidMem(int, pointer, unsigned long);
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
int fd = xf86Info.screenFd;
xf86MsgVerb(X_INFO, 3, "mapVidMem %lx, %lx, fd = %d",
Base, Size, fd);
- 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));
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 188.8.131.52, module version = 0.1.0
ABI class: XFree86 Video Driver, version 0.7
(II) RADEON(0): vgaHWGetIOBase: hwp->IOBase is 0x03b0, hwp->PIOOffset is
(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.
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?
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