On Mon, Nov 16, 2009 at 04:11:49PM -0600, Bjorn Helgaas wrote:
> On Monday 16 November 2009 02:13:50 pm Ira W. Snyder wrote:
> > On Mon, Nov 16, 2009 at 02:52:11PM -0600, Bjorn Helgaas wrote:
> > > On Monday 16 November 2009 12:54:17 pm Ira W. Snyder wrote:
> > >
> > > > + pci_read_config_word(dev, 0xc0, &word1);
> > > > + pci_read_config_word(dev, 0xc2, &word2);
> > > > + dev_dbg(&dev->dev, "CNB20LE: noPF 0x%.4x 0x%.4x\n", word1, word2);
> > > > + if (word1 != word2) {
> > > > + start = word1;
> > > > + end = word2;
> > >
> > > This looks much closer to something that might work, but I think
> > > you forgot the "(word1 << 16) | 0x0000" stuff here. And it got
> > > added to the IO aperture, where it shouldn't be.
> > >
> >
> > You're exactly right. I must have left my brain turned off when I wrote
> > that. :)
> >
> > Adding the shifts for the memory regions, and removing them for the IO
> > regions, the machine boots! There is still some problem left: the system
> > prints some messages about not being able to reserve IO ranges. Ideas?
>
> > [ 0.592029] pci 0000:00:0f.1: BAR 0: reserving [io 0x01f0-0x01f7 flags 0x110] (d=0, p=0)
> > [ 0.596012] pci 0000:00:0f.1: no compatible bridge window for [io 0x01f0-0x01f7]
> > [ 0.600011] pci 0000:00:0f.1: can't reserve [io 0x01f0-0x01f7]
> > [ 0.604013] pci 0000:00:0f.1: BAR 1: reserving [io 0x03f6 flags 0x110] (d=0, p=0)
> > [ 0.608011] pci 0000:00:0f.1: no compatible bridge window for [io 0x03f6]
> > [ 0.612011] pci 0000:00:0f.1: can't reserve [io 0x03f6]
> > [ 0.616013] pci 0000:00:0f.1: BAR 2: reserving [io 0x0170-0x0177 flags 0x110] (d=0, p=0)
> > [ 0.620012] pci 0000:00:0f.1: no compatible bridge window for [io 0x0170-0x0177]
> > [ 0.624011] pci 0000:00:0f.1: can't reserve [io 0x0170-0x0177]
> > [ 0.628013] pci 0000:00:0f.1: BAR 3: reserving [io 0x0376 flags 0x110] (d=0, p=0)
> > [ 0.632011] pci 0000:00:0f.1: no compatible bridge window for [io 0x0376]
> > [ 0.636011] pci 0000:00:0f.1: can't reserve [io 0x0376]
> > [ 0.640013] pci 0000:00:0f.1: BAR 4: reserving [io 0xffa0-0xffaf flags 0x20101] (d=0, p=0)
> > [ 0.644012] pci 0000:00:0f.1: no compatible bridge window for [io 0xffa0-0xffaf]
> > [ 0.648011] pci 0000:00:0f.1: can't reserve [io 0xffa0-0xffaf]
>
> This looks like legacy IDE stuff for a device that is probably built into
> the southbridge. Since it lives on PCI bus 0, I suppose these regions
> should somehow be added as apertures that the host bridge claims. This
> is all the sort of stuff that firmware is supposed to handle for you
> when it builds the host bridge _CRS (if you have ACPI).
>
> I can't think of anything better than just adding these as hard-coded
> apertures.
>
Ok. This makes sense, they are part of the IDE device, a function of the
south bridge. Interestingly, they do not show up on the Force computer
at all, only on the Trenton.
===== Force: =====
iws@labslcor4 ~ $ lspci -vvv -s 00:0f.1
00:0f.1 IDE interface: Broadcom OSB4 IDE Controller (prog-if 8a [Master SecP PriP])
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64
Region 4: I/O ports at 1400 [size=16]
Kernel driver in use: Serverworks_IDE
These I/O ports *do* show up on Bridge 0, where I decoded them to be.
They are 1000-140c. All of the I/O ports show up correctly in the bridge
on the Force.
iws@labslcor4 ~ $ lspci -vvv | grep 'I/O ports'
Region 1: I/O ports at 1080 [size=64]
Region 1: I/O ports at 10c0 [size=64]
Region 1: I/O ports at 1000 [size=128]
Region 4: I/O ports at 1400 [size=16]
===== Trenton: =====
iws@labslcor3 ~ $ lspci -vvv -s 00:0f.1
00:0f.1 IDE interface: Broadcom OSB4 IDE Controller (prog-if 8a [Master SecP PriP])
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64
Region 0: [virtual] Memory at 000001f0 (32-bit, non-prefetchable) [size=8]
Region 1: [virtual] Memory at 000003f0 (type 3, non-prefetchable) [size=1]
Region 2: [virtual] Memory at 00000170 (32-bit, non-prefetchable) [size=8]
Region 3: [virtual] Memory at 00000370 (type 3, non-prefetchable) [size=1]
Region 4: I/O ports at ffa0 [size=16]
Kernel driver in use: pata_serverworks
These I/O ports *do not* show up on Bridge 0, where I decoded them to
be. Bridge #0 shows: d000-dffc. Bridge #1 shows: e000-effc. All of the
I/O ports in the system are:
iws@labslcor3 ~ $ lspci -vvv | grep 'I/O ports'
Region 1: I/O ports at de80 [size=64]
Region 1: I/O ports at df00 [size=64]
Region 4: I/O ports at ffa0 [size=16]
So the Trenton's BIOS missed the ffa0-ffac range, I guess. Since the
ranges do not seem to be identical between my two boards, what should I
do here? The legacy IDE I/O ports don't even show up on the Force.
Ira
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
