I have run into an unsual (to me) situation, and I was hoping
someone here has expertise on the subject they'd be willing to
share.
I have a Mac G4 with Yellow Dog Linux 2.1 (kernel 2.4.10-12a).
I have put a second video card in the system (first one being the
"standard" ATI Rage128 RF which came with the system).
At the boot time, the Linux kernel spits out a message I haven't
seen before:
Linux version 2.4.10-12a (gcc version 2.95.3 20010111
(prerelease/franzo/20010111)) #1 Tue Oct 9 04:29:39 EDT 2001
PowerMac model: PowerMac3,1
Uninorth at 0xf8000000
Uni-N revision: 3, KeyLargo revision: 2
Registered 1 feature controller(s)
Found UniNorth PCI host bridge at 0xf0000000. Firmware bus number: 0->0
Found UniNorth PCI host bridge at 0xf2000000. Firmware bus number: 0->1
Found UniNorth PCI host bridge at 0xf4000000. Firmware bus number: 0->0
PCI: Cannot allocate resource region 2 of PCI bridge 2
PCI: resource is 80000000..8fffffff (200), parent c0468068
PCI:02:03.0: Resource 0: 82000000-82ffffff (f=1208)
PCI: Cannot allocate resource region 0 of device 02:03.0
PCI: parent is c0468068: 80000000-8fffffff (f=200)
PCI:02:03.0: Resource 1: 81000000-81ffffff (f=1208)
PCI: Cannot allocate resource region 1 of device 02:03.0
PCI: parent is c0468068: 80000000-8fffffff (f=200)
PCI:02:03.0: Resource 2: 80084000-80084fff (f=200)
PCI:02:03.0: Resource 4: 800a0000-800affff (f=200)
PCI:02:03.0: Resource 5: 00001000-000010ff (f=101)
Once the system is up, all the PCI BARs are marked as disabled. I
used 'setpci' to enable them:
setpci -s 02:03.0 COMMAND=0007
After it successfully completes, 'lspci -vv' reports the following:
02:03.0 VGA compatible controller: Number 9 Computer Company Revolution 4 (rev 02)
(prog-if 00 [VGA])
Subsystem: Unknown device
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin A routed to IRQ 53
Region 0: Memory at 81000000 (32-bit, prefetchable) [size=16M]
Region 1: Memory at 82000000 (32-bit, prefetchable) [size=16M]
Region 2: Memory at 80084000 (32-bit, non-prefetchable) [size=4K]
Region 4: Memory at 800a0000 (32-bit, non-prefetchable) [size=64K]
Region 5: I/O ports at 1000 [size=256]
Expansion ROM at 80090000 [disabled] [size=64K]
Capabilities: [80] AGP version 1.0
Status: RQ=15 SBA- 64bit- FW- Rate=x1,x2
Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>
Capabilities: [90] Power Management version 1
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Things look fairly normal to me, so am I understanding the situation
correctly if I assume that the kernel swapped the values in BAR[0]
and BAR[1] at the boot time?
Does that mean that the device is OK to use now?
Unfortunately, the first inl() causes the system to core dump.
It's a static server, so a quick back trace points to the first
inl() which is trying to access the first I/O port from BAR[5]
(i.e. inl( 0x00001000 ) is what causes the core dump).
Looking at the <compiler.h>, there is a need for the 'ioBase' variable
to be set prior to using inl()/outl() on a PPC system. I assume
that the value for 'ioBase' would be the value in the BAR[5].
So I would do something like:
ioBase = 0x00001000; /* I get 0x00001000 by reading BAR[5] */
first_reg = inl( 0 ); /* Zero being the offset from ioBase */
Is this correct way to use inl() on PPC?
I cannot find an example in the source code which sets the 'ioBase'
prior to using inl()/outl() on a PPC system. Am I overlooking such
an example? Has anyone done such a thing? I don't see why else
there would be inl()/outl() implementation in the <compiler.h>...
Perhaps I should mention that I'm not looking to set things up as a
multihead system. I only want to test some code for the #9 card on
a PPC system, and this G4 is the best I got (and not too bad, might
I add). So the server would only look for, and use the #9 card.
BTW, The #9 card does not support any Open Firmware functions.
Many thanks, in advance,
========================================================================
Nikola Miljanic [Nick] | | Metro Link, Inc.
[EMAIL PROTECTED] | | http://www.metrolink.com
========================================================================
progress [n.] 1. In computing; advancing from one error message to the next
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
