[LinuxBIOS] PCI: Left over static devices. Check your Config.lb

Steve Isaacs yasteve at gmail.com
Mon Dec 10 19:08:30 CET 2007


On Sun, 2007-12-09 at 19:12 +0100, Uwe Hermann wrote:
> On Wed, Dec 05, 2007 at 12:00:59PM -0800, Steve Isaacs wrote:
> > Is there anything that describes how to make a configuration in detail?
> > I'd rather learn the rules than have someone figure it out for me. 
> 
> There's a PDF which describes some parts of it, not sure how complete it is:
> 
> $ cd documentation
> $ make
> $ xpdf LinuxBIOS-AMD64.pdf
> 

I've seen this. It didn't appear to explain all of the Config files I
was seeing but they were all new to me at the time. I'll have to revisit
in case I was being dense.

> For the PCI parts, LinuxBIOS sets up the static/onboard devices and scans
> for other devices dynamically, if I'm not mistaken.
> This means you do not specify PCI/AGP/PCIe extention cards in Config.lb,
> they're rather detected at runtime.
> 
By "dynamic" is it meant devices for which it is possible to set the
device ID (DID) in the PCI configuration space? Which means that devices
for which the DID cannot be configured are considered "static"?

> For Super I/O stuff, the (PnP) settings are hardcoded from the options
> in the 'chip superio/foo/bar' section of Config.lb

If I understand this then it is correct to have the Super I/O as a
subsection under the southbridge? Oh, duh, it's there in the document
you mentioned.

> The CPU/socket/APIC stuff below tells LinuxBIOS which CPU init code
> to execute etc.
> 
I'm really confused about which init code. I'm calling init functions in
my cache_as_ram_auto.c (early functions?). btw: I've taken to calling
the "early" functions "bootstrap". Is that appropriate? Is this "stage
1" in V3?

After code is copied to RAM and execution resumes in RAM are there more
"init" functions? Looking at the code how do I know which is which? I've
been struggling looking at nohup captured build outputs, linker commands
and make files to sort this out.

Do the sections in Config.lb point to code that is executed after being
copied to RAM?


> >   device pci_domain 0 on
> >     chip northbridge/amd/amdk8
> >       device pci 18.0 on #  northbridge
> >                          #  devices on link 0
> >         chip southbridge/broadcom/bcm21000

The document shows names being appended to these (e.g.
northbridge/amd/amdk8 "mc0"). What effect does that have?


> >           device pci 1.0 on
> >             device pci e.0 on
> >             end
> >           end
> 
> I may be wrong, but I don't think you can nest PCI entries like this.
> 
> 
> >           device pci 1.1 on
> >           end
> >           device pci 2.0 on
> 
> 
> >             device pci b.0 on
> >             end
> >             device pci b.1 on
> >             end
> >             device pci b.2 on

> What is 2.0? What are the b.0 etc. entries? This doesn't seem to match
> the lspci you posted.

2.0 is a PCI bridge to a number of USB devices that are on the
southbridge chip.


> >           device pci 6.2 on
> 
> What device is 6.2? The Super I/O section below should be a child of
> the ISA/LPC device usually.
> 

6.2 is the LPC device on the southbridge.
> 
> >             chip superio/smsc/sch4304
> 
> Please use the 'superio/smsc/smscsuperio' driver, which is a common
> driver for many SMSC Super I/Os. It should be easy to add support
> for the sch4304 there.
> 
I've seen the superio code but haven't used it because the (obsolete)
snapshot of the repository which was used here before does not have it.
To get started I mixed two boards, one we've already built based upon a
reference design (using the AMD chipset) supported by LinuxBIOS at the
time and the Broadcom Blast from the same snapshot.

> Do you have the sch4304 datasheet? If so, it would be nice if you
> could add support for this chip to superiotool, see
> http://linuxbios.org/Superiotool
> 
Yes I do. I might have an opportunity to do as you ask when the
development schedule will allow more time. The snapshot I mentioned
predates this.


> 
> >               #device pnp 2e.7 off
> >               #end
> >               #device pnp 2e.B off
> >               #end
> 
> This section should have one entry per Super I/O LDN. If the Super I/O
> has some LDNs/capabilities you don't use on the board, it should still
> be listed, but with "off" (and a comment why it's off).
> 
This is an artifact from the config file I based this one on. I didn't
delete it since I didn't understand it's purpose at the time. It didn't
match the sch4304 but I need to go through the chip again to see if
there is a similar device. I suspect I'll discover these are not needed
and will delete them.

> >           device pci 6.3 off
> >           end
> >           device pci 6.4 on
> >           end
> >           device pci 6.5 on
> >           end
> >           device pci 6.6 on
> >           end
> 
> Where does this come from? I don't see 6.3, 6.4 etc. in the lspci output.
> 
This is part of my confusion. I installed a Phoenix BIOS to boot Linux
and be able to run lspci. I have no visibility into what it's (Phoenix
BIOS) design is for this board. I suspect there are several devices it
hides (a feature of the chipset) because the assumption is they won't be
needed for the reference board.


> >         end # bcm11000
> >       end #  device pci 18.0
> >       device pci 18.1 on
> >       end
> 
> Not sure about the above few lines. Other boards have e.g.
> 
>       device pci 18.0 on end                    # Link 1
>       device pci 18.0 on end
> 
> (yes, twice, there's some reason for that which was explained in the
> PDF, IIRC).
> 
I couldn't find an explanation for this in the PDF you mentioned. There
is an example showing 19.0 listed three times but no comment as to why.
Is this really part of hyper-transport configuration? The first for link
0, the second for link 1 and the third for link 2 (listed as LDT0, LDT1,
and LDT2 in the PDF)?


> You don't have the 19.* devices from lspci listed here; not sure what
> those devices are, but I guess they must be listed.
> 
19.* is the second node (CPU) which may or may not be installed.

> > -[0000:00]-+-01.0  1166:0031
> >            +-02.0-[0000:01]----0f.0  1166:0410
> >            +-03.0-[0000:02]--+-0c.0  1166:0412
> >            |                 +-0c.1  1166:0412
> >            |                 +-0c.2  1166:0414
> >            |                 +-0d.0  1166:0412
> >            |                 +-0d.1  1166:0412
> >            |                 +-0d.2  1166:0414
> >            |                 +-0e.0  1166:0412
> >            |                 +-0e.1  1166:0412
> >            |                 \-0e.2  1166:0416
> >            +-04.0-[0000:03]--
> >            +-05.0-[0000:04]--
> >            +-07.0  1166:0408
> >            +-07.1  1166:0214
> >            +-07.2  1166:040a
> >            +-08.0-[0000:05]--
> >            +-09.0-[0000:06]--
> >            +-0a.0-[0000:07]--
> >            +-0b.0-[0000:08]--
> >            +-0c.0-[0000:09]--
> >            +-0e.0  10ec:8139
> >            +-0f.0  1002:515e
> >            +-18.0  1022:1100
> >            +-18.1  1022:1101
> >            +-18.2  1022:1102
> >            +-18.3  1022:1103
> >            +-19.0  1022:1100
> >            +-19.1  1022:1101
> >            +-19.2  1022:1102
> >            \-19.3  1022:1103
> 
> Can you also post the 'lspci' output? Your version of lspci doesn't
> attach the device names to the -tvnn output.
> 
One thing that keeps tripping me is it appears that some device numbers
are 0 based and others are 1 based. For example 18.0 agrees with a PCI
bus scan as well as 19.0 but 6.0 in the Config shows up as 7.0 in the
scan and 0.0 as 1.0. What's up with that? Is there a rule I need to
understand? On the surface this seems very inconsistent.

Here's a portion of my Options.lb that might be relevant.

#HT Unit ID offset
default HT_CHAIN_UNITID_BASE=0x08

#real SB Unit ID
default HT_CHAIN_END_UNITID_BASE=0x1

#make the SB HT chain on bus 0
default SB_HT_CHAIN_ON_BUS0=1


Here's the output you requested. I've included the output from
print_pci_devices() (debug.c).

Thanks,

Steve

---------

$ lspci
00:01.0 Host bridge: Broadcom Unknown device 0031 (rev a0)
00:02.0 PCI bridge: Broadcom Unknown device 0406 (rev a0)
00:03.0 PCI bridge: Broadcom Unknown device 0406 (rev a0)
00:04.0 PCI bridge: Broadcom Unknown device 0420 (rev a0)
00:05.0 PCI bridge: Broadcom Unknown device 0422 (rev a0)
00:07.0 Host bridge: Broadcom Unknown device 0408
00:07.1 IDE interface: Broadcom HT1000 Legacy IDE controller (rev a0)
00:07.2 ISA bridge: Broadcom Unknown device 040a
00:08.0 PCI bridge: Broadcom Unknown device 0140 (rev a2)
00:09.0 PCI bridge: Broadcom Unknown device 0142 (rev a2)
00:0a.0 PCI bridge: Broadcom Unknown device 0144 (rev a2)
00:0b.0 PCI bridge: Broadcom Unknown device 0142 (rev a2)
00:0c.0 PCI bridge: Broadcom Unknown device 0144 (rev a2)
00:0f.0 VGA compatible controller: ATI Technologies Inc ES1000 (rev 02)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
Miscellaneous Control
00:19.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
HyperTransport Technology Configuration
00:19.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
Address Map
00:19.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
DRAM Controller
00:19.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
Miscellaneous Control
01:0f.0 RAID bus controller: Broadcom Unknown device 0410
02:0c.0 USB Controller: Broadcom Unknown device 0412 (rev a0)
02:0c.1 USB Controller: Broadcom Unknown device 0412 (rev a0)
02:0c.2 USB Controller: Broadcom Unknown device 0414 (rev a0)
02:0d.0 USB Controller: Broadcom Unknown device 0412 (rev a0)
02:0d.1 USB Controller: Broadcom Unknown device 0412 (rev a0)
02:0d.2 USB Controller: Broadcom Unknown device 0414 (rev a0)
02:0e.0 USB Controller: Broadcom Unknown device 0412 (rev a0)
02:0e.1 USB Controller: Broadcom Unknown device 0412 (rev a0)
02:0e.2 USB Controller: Broadcom Unknown device 0416 (rev a0)


Output from print_pci_devices() (running using cache as ram).

PCI: 00:01.00 0x1166 0x0031
PCI: 00:01.01 0x1166 0x0428
PCI: 00:02.00 0x1166 0x0406
PCI: 00:02.01 0x1166 0x0429
PCI: 00:03.00 0x1166 0x0406
PCI: 00:03.01 0x1166 0x0429
PCI: 00:04.00 0x1166 0x0420
PCI: 00:04.01 0x1166 0x042a
PCI: 00:05.00 0x1166 0x0422
PCI: 00:05.01 0x1166 0x042a
PCI: 00:07.00 0x1166 0x0408
PCI: 00:07.01 0x1166 0x0215
PCI: 00:07.02 0x1166 0x040a
PCI: 00:07.04 0x1166 0x040e
PCI: 00:07.05 0x1166 0x040e
PCI: 00:07.06 0x1166 0x040e
PCI: 00:0f.00 0x1002 0x515e
PCI: 00:0f.01 0x1002 0x515e
PCI: 00:0f.02 0x1002 0x515e
PCI: 00:0f.03 0x1002 0x515e
PCI: 00:0f.04 0x1002 0x515e
PCI: 00:0f.05 0x1002 0x515e
PCI: 00:0f.06 0x1002 0x515e
PCI: 00:0f.07 0x1002 0x515e
PCI: 00:10.00 0x1166 0x0140
PCI: 00:11.00 0x1166 0x0142
PCI: 00:12.00 0x1166 0x0144
PCI: 00:13.00 0x1166 0x0142
PCI: 00:14.00 0x1166 0x0144
PCI: 00:18.00 0x1022 0x1100
PCI: 00:18.01 0x1022 0x1101
PCI: 00:18.02 0x1022 0x1102
PCI: 00:18.03 0x1022 0x1103
PCI: 00:19.00 0x1022 0x1100
PCI: 00:19.01 0x1022 0x1101
PCI: 00:19.02 0x1022 0x1102
PCI: 00:19.03 0x1022 0x1103







More information about the coreboot mailing list