Shiunbird wrote:However, on point 1, I'm not entirely sure of this. I have problems with graphic drivers that should in theory work with Linux. After a lot of digging out, it seems that the matrox drivers expect a different memory address and I'm not sure that's related to the way PCI initializes. It runs well with framebuffer.
well, with IBM OF ... at least you won't see this
Code: Select all
PCI: Probing PCI hardware
PCI host bridge to bus 0008:00
pci_bus 0008:00: root bus resource [io 0x2000-0x2fff]
pci_bus 0008:00: root bus resource [mem 0x80000000-0x9fffffff]
pci_bus 0008:00: root bus resource [bus 00-ff]
PCI: Hiding 4xx host bridge resources 0008:00:00.0
pci 0008:00:04.0: [Firmware Bug]: reg 0x10: invalid BAR (can't size)
pci 0008:00:04.0: [Firmware Bug]: reg 0x14: invalid BAR (can't size)
pci 0008:00:04.0: [Firmware Bug]: reg 0x18: invalid BAR (can't size)
pci 0008:00:04.0: [Firmware Bug]: reg 0x1c: invalid BAR (can't size)
pci 0008:00:00.0: of_irq_parse_pci: failed with rc=-22
pci 0008:00:03.0: BAR 1: assigned [mem 0x80000000-0x807fffff pref]
pci 0008:00:04.0: BAR 5: assigned [mem 0x80800000-0x8081ffff]
pci 0008:00:03.0: BAR 6: assigned [mem 0x80820000-0x8082ffff pref]
pci 0008:00:03.0: BAR 0: assigned [mem 0x80830000-0x80833fff]
pci 0008:00:04.0: BAR 6: assigned [mem 0x80834000-0x80837fff pref]
pci 0008:00:02.0: BAR 0: assigned [mem 0x80838000-0x80838fff]
pci 0008:00:02.1: BAR 0: assigned [mem 0x80839000-0x808390ff]
pci 0008:00:04.0: BAR 4: assigned [io 0x2000-0x203f], invalid, disabled
For two reasons
- IBM moved the PCI stuff into PCI64, so if you have a 64bit IBM machine you are already aligned
- IBM released devicetree configurations for their machines (it's "in-Trunk", a git-term which means you can find them in linux kernel source, somewere), so both the firmware and the kernel shouldn't have problems in probing since things are (should be?) already properly described
In my case .. I am on a 32bit machine, dead since 2.6.25, with a strange DMA engine on where I need to invalidate data cache to enforce coherency. And it uses an old firmware (uboot v1.2 ~ 2008) which neither understand nor provides support for dts blob.
It's unaligned with modern kernels, which expect some job done by the firmware, e.g. uboot doesn't initialize the PCI, and it doesn't understand the dts description encoded into the kernel, so you see Quirks
Quirks means ... you have a problem with PCI_IO, there is a conflict with address translation, things are NOT correctly pre-initialized by the firmware (OF is much more advanced, especially in PCI-auto-remapping), and the kernel is NOT able to handle them, resulting a failure.
To solve it, I had to add a boot wrapper between the bootloader and the kernel: it does the properly initialization, it understands the device tree, it passes the information to the kernel, making it happy. So it can bootstrap without Quirks.
Video boards like Ati Radeon, Voodoo3-4-5, use both PCI_IO and PCI_MEM. Before fixing the Quirks problem I was using Matrox M1 (MGA first generation), which is PCI_MEM only, therefore it only requires a windows in the PCI memory
and here it is
Code: Select all
matroxfb: framebuffer at 0x80000000, mapped to 0xc4080000, size 4194304
4Mbyte mapped in the PCI_MEM space without a problem!
But I have a lot of issues with vgaarb, as some "legacy" VGA devices implemented on PCI typically have the same hard-decoded addresses as they did on ISA. When multiple PCI devices are accessed at same time they need some kind of coordination.
I don't need confb (text console, directly offered by kernel), therefore I simply removed this module, enjoying a pure framebuffer on which I can attach (/dev/fb0, in userspace) an homemade directfb-vt200-terminal.
It works with less problems, even if it's a bit slower, but not so bad.
Shiunbird wrote:This affects Power Macs as well.
You could try to reprogram the Matrox's bios into OF-BIOS. I know there are Matrox with PC-bios, and Matrox with OF-bios. Some hardware, different firmware. It might help.
Shiunbird wrote:3D acceleration.
3D acceleration, as well as 2D acceleration, are X11's matter, and they go more complex. They involve DRI and DRM. Direct Rendering Manager (XFree86 4.1.0) and higher DRI support. They both need kernel support as well as X11 drivers support
From my point of view, they are "userspace modules", /usr/lib/xorg/modules/*, therefore I handle them as "catalyst" problems if any. It's not kernel matter, I mean, once you have provided the proper kernel support.
Also, I don't know if Debian uses "fbdev" or a dedicated framebuffer, e.g. VIDEO="mga, ati, stl1, ...."
This is what I am using in a product I am developing. It's an X11-terminal made around an embedded CPU, PowerPC405GP, attached to a MGA video card. There is also an fpga for other PCI stuff, but it doesn't matter
Code: Select all
Option "NoAccel" "True"
Option "DRI" "false"
Option "MergedFB" "False"
Option "MetaModes" "1024x768 800x600"
# X11 can also use
# Driver "FBDev"
# but it uses a lot of system ram, and it's 20% slower
I am not planning to add a video card to my C3600 workstation, it's already happy without it and I don't want to put Xorg stuff on the harddirve (because it costs a lot of time and effort with catalyst. HPPA is ... experimental)
So, I'd prefer to use a dedicated X11-term, which can be a laptop loaded with MobaXterm (you can download a free copy, you can buy a full featured commercial version for 60 euro). The HP box is more happy of being a server, and I am more happy if I can put my effort only on one machine (e.g. the PowerPC405GP) instead of supporting X11 everywhere.
You might consider to do the same: just assure you have a good lan connectivity (100Mbps), and no bottleneck in the network.
Oh, about tektronix and HP envizex xterminals: as far as I experimented, they are all pseudocolor (except NCD900 which costs a leg and an arm, plus an eye of your head), you can used them but only if you can forget gtk, kde, qt. They work good only with motif.