Nikola,
The problem is that there are multiple busses (as you already know) on the
G4 and multiple ISA IO bases. On PowerMac's the ISA IO region lies in the
first 128M (or 64) of the PCI host bus. See in
../xfree86/os-support/linux/lnx_video in xf86EnableIO() where on PPC we
use the pciconfig_iobase syscall to grab the PCI bus base address
(physical) and then map it.
Here you can see the problem when you are using a card in the second bus
and are mapping the IO for the first. To solve this there needs to be a
bit of abstraction involved. I suppose one could map all the IO's, and
then set a flag in the driver which tells which bus this particular driver
or IO operation is dealing with.
So, if you want to hack your way into just using that second board (and
cease the use of the first, or make the first not do any ISA IO), change
this line in lnx_video.c:
ioBase_phys = syscall(__NR_pciconfig_iobase, 2, 0, 0);
to:
ioBase_phys = syscall(__NR_pciconfig_iobase, 2, 1, 0);
(or 2, I believe there are 3 busses on the G4)
ani
On Tue, 29 Jan 2002, Nikola Miljanic wrote:
> 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
