From: Jon Erick Ween <hidden> Date: 2000-09-27 17:22:55
quoted
Can anyone tell me if there are any problems with overlapping memory
assignments for the ATY Mach64 chip on a Lombard PB? I'm having trouble
getting my 4.0.1 Xserver to detect the device although the system seems to
detect the chip alright at bootup. I've been through the Xpert list at
XFree86 and we've groud to a halt.
With a 2.2 kernel:
You need to use yaboot, or fix up the overlapping PCI resources allocated
by OF or MacOS yourself when using BootX. I've posted a diff to
debian-powerpc that remaps the MMIO region outside the VRAM region,
without any sanity checks to make sure that region hadn't been mapped
previously. It's a hack, and won't ever make it into the official kernel.
With 2.3:
Use Geert's PCI resource allocation patch, posted here a couple of months
back. Might be in 2.4.0pre already. Or, again, use yaboot.
BTW: in my case, the X server had no problem _detecting_ the chip, but
helpfully removed the PCI mapping for the VRAM region. The resulting
invalid access to MMIO registers aliased at the end of the VRAM region
(that's where atyfb puts them) crashed the kernel hard. If you get away
without a kernel crash, your problem might be different. Using yaboot
instead of BootX is a good idea nonetheless.
OK, I've switched from BootX to Yboot using a stable 2.2.17 kernel and the
most recent XF86-4.0.1 and ati driver sources I can find. I seem to get
different PCI assignments to the ATI chip on boot-up (looking at dmesg
compared with using BootX) but the X-server still doesn't detect the chip
with "startx" or "XFree86" and exits with a "device not found" and "no
screens" error. Any further suggestions?
Thanks
Jon
--
Jon Erik Ween, MD
Cognitive and Cerebrovascular Neurology
Assistant Professor
Loma Linda University School of Medicine
Director, Stroke Program
Loma Linda University Medical Center
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Olaf Hering <hidden> Date: 2000-09-27 17:42:34
On Wed, Sep 27, Jon Erick Ween wrote:
OK, I've switched from BootX to Yboot using a stable 2.2.17 kernel and the
most recent XF86-4.0.1 and ati driver sources I can find. I seem to get
different PCI assignments to the ATI chip on boot-up (looking at dmesg
compared with using BootX) but the X-server still doesn't detect the chip
with "startx" or "XFree86" and exits with a "device not found" and "no
screens" error. Any further suggestions?
There is a Modes line in the screen section, use a generic mode.
Don't specify a Modes section.
It could look like that:
Section "Screen"
DefaultDepth 24
SubSection "Display"
Depth 24
Modes "1024x768"
EndSubSection
Device "Device[0]"
Identifier "Screen[0]"
Monitor "Monitor[0]"
EndSection
Section "Device"
BoardName "mycard"
BusID "0:16:0"
Driver "ati"
Identifier "Device[0]"
Option "sw_cursor"
VendorName "ATI"
EndSection
Gruss Olaf
--
$ man clone
BUGS
Main feature not yet implemented...
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michael Schmitz <hidden> Date: 2000-09-27 18:17:02
quoted
OK, I've switched from BootX to Yboot using a stable 2.2.17 kernel and the
most recent XF86-4.0.1 and ati driver sources I can find. I seem to get
different PCI assignments to the ATI chip on boot-up (looking at dmesg
compared with using BootX) but the X-server still doesn't detect the chip
with "startx" or "XFree86" and exits with a "device not found" and "no
screens" error. Any further suggestions?
There is a Modes line in the screen section, use a generic mode.
Don't specify a Modes section.
It's probably just some error in the device section (the server doesn't
complain about 'no valid modes found' but 'no device found'.
Need to see your XF86Config's device section.
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Jon Erick Ween <hidden> Date: 2000-09-27 19:13:12
Here's a copy of my XF86Config file.
Two other minor nuisances:
Since using yaboot, my console cursor has disappeared. Is this an OF or a
yaboot problem? It's very hard to navigate in vi to edit anything (.config
files for one thing) without a cursor!
Also, I can't figure out how to uninstall BootX. Throwing it away under
MacOS doesn't seem to help.
Any suggestions?
Thanks
Jon
From: Michael Schmitz <redacted>
Date: Wed, 27 Sep 2000 20:17:02 +0200 (CEST)
To: Olaf Hering <redacted>
Cc: Jon Erick Ween <redacted> , linuxppc-dev@lists.linuxppc.org
Subject: Re: Xfree86-4.0.1, Lombard, Mach64 driver, X-server Crash
quoted
quoted
OK, I've switched from BootX to Yboot using a stable 2.2.17 kernel and the
most recent XF86-4.0.1 and ati driver sources I can find. I seem to get
different PCI assignments to the ATI chip on boot-up (looking at dmesg
compared with using BootX) but the X-server still doesn't detect the chip
with "startx" or "XFree86" and exits with a "device not found" and "no
screens" error. Any further suggestions?
There is a Modes line in the screen section, use a generic mode.
Don't specify a Modes section.
It's probably just some error in the device section (the server doesn't
complain about 'no valid modes found' but 'no device found'.
Need to see your XF86Config's device section.
Michael
From: Michael Schmitz <hidden> Date: 2000-09-27 19:13:35
Since using yaboot, my console cursor has disappeared. Is this an OF or a
yaboot problem? It's very hard to navigate in vi to edit anything (.config
files for one thing) without a cursor!
Happens to me occasionally, but it also happened during console switching
or some other console operation (rarely). Don't thing it's yaboot related.
Also, I can't figure out how to uninstall BootX. Throwing it away under
MacOS doesn't seem to help.
Throw away the extension not only the control panel app.
The config was attached as audio - trying hard to listen ...
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michael Schmitz <hidden> Date: 2000-09-27 19:21:44
Here's a copy of my XF86Config file.
Only differences I can see:
I don't use HwCursor, and I use ShadowFB off in the device section.
I use mode lines as returned by fbset -x in the monitor section.
Plus I don't use the empty Files section (fontpath there at least).
Order shouldn't matter I hope, otherwise try the layout at the end.
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Benjamin Herrenschmidt <hidden> Date: 2000-09-27 20:35:16
Here's a copy of my XF86Config file.
Two other minor nuisances:
Since using yaboot, my console cursor has disappeared. Is this an OF or a
yaboot problem? It's very hard to navigate in vi to edit anything (.config
files for one thing) without a cursor!
Completely ? Or does it appear with different colors depending on the VC
you are on ? I've seen such bug appear here or there but never took the
time to track it down...
I suspect an atyfb problem ;)
Also, I can't figure out how to uninstall BootX. Throwing it away under
MacOS doesn't seem to help.
Remove the bootx extension that is in your MacOS Extensions folder. it
should appear near the top of the list when vieweing them by name.
Ben.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Wed, 27 Sep 2000, Benjamin Herrenschmidt wrote:
quoted
Here's a copy of my XF86Config file.
Two other minor nuisances:
Since using yaboot, my console cursor has disappeared. Is this an OF or a
yaboot problem? It's very hard to navigate in vi to edit anything (.config
files for one thing) without a cursor!
Completely ? Or does it appear with different colors depending on the VC
you are on ? I've seen such bug appear here or there but never took the
time to track it down...
I suspect an atyfb problem ;)
I think this is more of a generic fb device layer problem or a combination
of driver bug and upper layer bug. Or I totally don't understand how
fbcon works.
My understanding is this:
Video console uses 16 colors, and it only initializes the cmap
corresponding to those 16 colors. The other entries in cmap are up to
each individual fb driver or undefined as far as console is concerned.
For software cursor, driver specific (struct display_switch *)ops->revc()
is used to make the cursor blink. For the generic fbcon_cfb{16,32}_revc,
it xors each pixel with masks 0xffff (depth 16) or 0xffffffff (depth 32).
For controlfb which I am very familiar with, the "correct" masks are
0x3def for 555 and 0x0f0f0f0f for 8888. That is, only 4 LSBs or low 16
for each red, green, and blue are xor'ed since cmap entries corresponding
to higher bits are undefined as far as fbcon support is concerned.
Takashi Oe
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Wed, 27 Sep 2000, Benjamin Herrenschmidt wrote:
quoted
quoted
Here's a copy of my XF86Config file.
Two other minor nuisances:
Since using yaboot, my console cursor has disappeared. Is this an OF or a
yaboot problem? It's very hard to navigate in vi to edit anything (.config
files for one thing) without a cursor!
Completely ? Or does it appear with different colors depending on the VC
you are on ? I've seen such bug appear here or there but never took the
time to track it down...
I suspect an atyfb problem ;)
I think this is more of a generic fb device layer problem or a combination
of driver bug and upper layer bug. Or I totally don't understand how
fbcon works.
My understanding is this:
Video console uses 16 colors, and it only initializes the cmap
corresponding to those 16 colors. The other entries in cmap are up to
each individual fb driver or undefined as far as console is concerned.
For software cursor, driver specific (struct display_switch *)ops->revc()
is used to make the cursor blink. For the generic fbcon_cfb{16,32}_revc,
it xors each pixel with masks 0xffff (depth 16) or 0xffffffff (depth 32).
For controlfb which I am very familiar with, the "correct" masks are
0x3def for 555 and 0x0f0f0f0f for 8888. That is, only 4 LSBs or low 16
for each red, green, and blue are xor'ed since cmap entries corresponding
to higher bits are undefined as far as fbcon support is concerned.
In 2.5.x, we'll have a user-defined xor mask for the cursor as the 17th entry
in the dispsw_data array.
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
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Jon Erick Ween <hidden> Date: 2000-09-28 16:51:38
Michael
I tried the changes you suggested, no difference. (I couldn't figure out
what you meant by "layout at the end.", was there more to the email that
didn't get through?)
But, honestly, I can't see why these changes should influence whether or not
the Xserver detects the video device. That seems to be the main problem.
It's looking for a particular device at a particular memory address
(presumably specified by the "ati" driver file) and is not finding it. I
thought switching from BootX to yaboot would fix this, but it hasn't. (I
thought I recompiled everything under a yaboot startup, assuming this would
fix the device name and memory specifications in the finished driver, but
maybe not. I'll do this again in any case, just to be sure.)
Do you have any other suggestions?
--
Jon Erik Ween, MD
Cognitive and Cerebrovascular Neurology
Assistant Professor
Loma Linda University School of Medicine
Director, Stroke Program
Loma Linda University Medical Center
From: Michael Schmitz <redacted>
Date: Wed, 27 Sep 2000 21:21:44 +0200 (CEST)
To: Jon Erick Ween <redacted>
Cc: Michael Schmitz <redacted> , Olaf Hering
[off-list ref], linuxppc-dev@lists.linuxppc.org
Subject: Re: Xfree86-4.0.1, Lombard, Mach64 driver, X-server Crash
quoted
Here's a copy of my XF86Config file.
Only differences I can see:
I don't use HwCursor, and I use ShadowFB off in the device section.
I use mode lines as returned by fbset -x in the monitor section.
Plus I don't use the empty Files section (fontpath there at least).
Order shouldn't matter I hope, otherwise try the layout at the end.
Michael
From: Michael Schmitz <hidden> Date: 2000-09-28 18:14:47
I tried the changes you suggested, no difference. (I couldn't figure out
what you meant by "layout at the end.", was there more to the email that
didn't get through?)
I meant move the first section (server layout IIRC) to the end of the
file. Nothing complicated.
But, honestly, I can't see why these changes should influence whether or not
the Xserver detects the video device. That seems to be the main problem.
It's looking for a particular device at a particular memory address
(presumably specified by the "ati" driver file) and is not finding it. I
Neither do I, and it works perfectly for me ...
I can send you my config if nothing else helps.
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
My understanding is this:
Video console uses 16 colors, and it only initializes the cmap
corresponding to those 16 colors. The other entries in cmap are up to
each individual fb driver or undefined as far as console is concerned.
For software cursor, driver specific (struct display_switch *)ops->revc()
is used to make the cursor blink. For the generic fbcon_cfb{16,32}_revc,
it xors each pixel with masks 0xffff (depth 16) or 0xffffffff (depth 32).
For controlfb which I am very familiar with, the "correct" masks are
0x3def for 555 and 0x0f0f0f0f for 8888. That is, only 4 LSBs or low 16
for each red, green, and blue are xor'ed since cmap entries corresponding
to higher bits are undefined as far as fbcon support is concerned.
In 2.5.x, we'll have a user-defined xor mask for the cursor as the 17th entry
in the dispsw_data array.
Can we put it for 2.4? As far as I can see, the actual size of
dispsw_data matters only between fb driver and fbcon-cfbxx.c, and the
changes required for each driver seem to be rather small. Besides,
controlfb is not the only one which will benefit from this change.
Takashi Oe
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
My understanding is this:
Video console uses 16 colors, and it only initializes the cmap
corresponding to those 16 colors. The other entries in cmap are up to
each individual fb driver or undefined as far as console is concerned.
For software cursor, driver specific (struct display_switch *)ops->revc()
is used to make the cursor blink. For the generic fbcon_cfb{16,32}_revc,
it xors each pixel with masks 0xffff (depth 16) or 0xffffffff (depth 32).
For controlfb which I am very familiar with, the "correct" masks are
0x3def for 555 and 0x0f0f0f0f for 8888. That is, only 4 LSBs or low 16
for each red, green, and blue are xor'ed since cmap entries corresponding
to higher bits are undefined as far as fbcon support is concerned.
In 2.5.x, we'll have a user-defined xor mask for the cursor as the 17th entry
in the dispsw_data array.
Can we put it for 2.4? As far as I can see, the actual size of
dispsw_data matters only between fb driver and fbcon-cfbxx.c, and the
changes required for each driver seem to be rather small. Besides,
controlfb is not the only one which will benefit from this change.
That's true. Personally, I see no problems with it if someone's willing to
write the patch for _all_ drivers at once. The real 2.4.0 is still a long way
to go, I think, and the impact of the required changes is known quite well.
The main thing we need to be careful about is that the xor mask is different
for truecolor and directcolor visuals: truecolor needs an `all ones' mask,
while directcolor needs `15' for each color component (drivers that incorrectly
report a directcolor instead of truecolor visual will easily be identified).
- Affected fbcon low level drivers:
o fbcon-cfb16.c
o fbcon-cfb24.c
o fbcon-cfb32.c
- Affected frame buffer device drivers:
o acornfb.c
o atafb.c
o aty128fb.c
o atyfb.c
o chipsfb.c
o clgenfb.c
o controlfb.c
o creatorfb.c
o cyber2000fb.c
o fm2fb.c
o hgafb.c
o hitfb.c
o igafb.c
o imsttfb.c
o macfb.c
o matrox/matroxfb_accel.c
o matrox/matroxfb_crtc2.c
o offb.c
o platinumfb.c
o pm2fb.c
o q40fb.c
o riva/fbdev.c
o sgivwfb.c
o sisfb.c
o skeletonfb.c
o tdfxfb.c
o tgafb.c
o valkyriefb.c
o vesafb.c
o vfb.c
o virgefb.c
Not that bad, only about 1/4 of all files...
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
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
In 2.5.x, we'll have a user-defined xor mask for the cursor as the 17th entry
in the dispsw_data array.
Can we put it for 2.4? As far as I can see, the actual size of
dispsw_data matters only between fb driver and fbcon-cfbxx.c, and the
changes required for each driver seem to be rather small. Besides,
controlfb is not the only one which will benefit from this change.
That's true. Personally, I see no problems with it if someone's willing to
write the patch for _all_ drivers at once. The real 2.4.0 is still a long way
to go, I think, and the impact of the required changes is known quite well.
Good! I'll work on it. Only a few allocate memory for dispsw_data
dynamically, the changes should be trivial for most.
The main thing we need to be careful about is that the xor mask is different
for truecolor and directcolor visuals: truecolor needs an `all ones' mask,
while directcolor needs `15' for each color component (drivers that incorrectly
report a directcolor instead of truecolor visual will easily be identified).
I don't know how it will work out for atyfb, but we'll see...
Takashi Oe
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
In 2.5.x, we'll have a user-defined xor mask for the cursor as the 17th entry
in the dispsw_data array.
Can we put it for 2.4? As far as I can see, the actual size of
dispsw_data matters only between fb driver and fbcon-cfbxx.c, and the
changes required for each driver seem to be rather small. Besides,
controlfb is not the only one which will benefit from this change.
That's true. Personally, I see no problems with it if someone's willing to
write the patch for _all_ drivers at once. The real 2.4.0 is still a long way
to go, I think, and the impact of the required changes is known quite well.
Good! I'll work on it. Only a few allocate memory for dispsw_data
dynamically, the changes should be trivial for most.
quoted
The main thing we need to be careful about is that the xor mask is different
for truecolor and directcolor visuals: truecolor needs an `all ones' mask,
while directcolor needs `15' for each color component (drivers that incorrectly
report a directcolor instead of truecolor visual will easily be identified).
I don't know how it will work out for atyfb, but we'll see...
Atyfb is directcolor. Grep fro VISUAL_ to find out :-)
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
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/