I'm trying to undertand dts better, and found this. This patch removes extra devices from the v2 Config.lb file for serengeti cheetah.
The only change without these devices is that now these lines are missing from the log:
Disabling static device: PCI: 00:19.0 Disabling static device: PCI: 00:19.1 Disabling static device: PCI: 00:19.2 Disabling static device: PCI: 00:19.3
Signed-off-by: Myles Watson mylesgw@gmail.com
Thanks, Myles
On Wed, Oct 8, 2008 at 7:43 AM, Myles Watson mylesgw@gmail.com wrote:
I'm trying to undertand dts better, and found this. This patch removes extra devices from the v2 Config.lb file for serengeti cheetah.
The only change without these devices is that now these lines are missing from the log:
Disabling static device: PCI: 00:19.0 Disabling static device: PCI: 00:19.1 Disabling static device: PCI: 00:19.2 Disabling static device: PCI: 00:19.3
Signed-off-by: Myles Watson mylesgw@gmail.com
no patch?
ron
Sorry! Patch attached.
Thanks, Myles
On Wed, Oct 8, 2008 at 8:43 AM, Myles Watson mylesgw@gmail.com wrote:
I'm trying to undertand dts better, and found this. This patch removes extra devices from the v2 Config.lb file for serengeti cheetah.
The only change without these devices is that now these lines are missing from the log:
Disabling static device: PCI: 00:19.0 Disabling static device: PCI: 00:19.1 Disabling static device: PCI: 00:19.2 Disabling static device: PCI: 00:19.3
Signed-off-by: Myles Watson mylesgw@gmail.com
Thanks, Myles
On Wed, Oct 8, 2008 at 8:14 AM, Myles Watson mylesgw@gmail.com wrote:
Sorry! Patch attached.
You don't want to do that. That's cpu1. We may need cpu1 someday :-)
ron
-----Original Message----- From: ron minnich [mailto:rminnich@gmail.com] Sent: Wednesday, October 08, 2008 9:18 AM To: Myles Watson Cc: Coreboot Subject: Re: [coreboot] AMD Serengeti Cheetah devices
On Wed, Oct 8, 2008 at 8:14 AM, Myles Watson mylesgw@gmail.com wrote:
Sorry! Patch attached.
You don't want to do that. That's cpu1. We may need cpu1 someday :-)
ron
Wouldn't that be a different board? Will it have an 8151 attached there?
Thanks, Myles
On Wed, Oct 8, 2008 at 8:19 AM, Myles Watson mylesgw@gmail.com wrote:
Wouldn't that be a different board? Will it have an 8151 attached there?
serengeti can have one or 2p IIRC.
ron
Wouldn't that be a different board? Will it have an 8151 attached
there?
serengeti can have one or 2p IIRC.
I only have the free version, which only allows one package. That's why I removed the second package and the 8151 which isn't even a supported chip in the free version.
It doesn't matter too much. It's just confusing when I'm trying to match up devices. In v3 there's no 8131 or 8151 in the dts.
Thanks,
Myles
ron
anyway, don't worry, I'm writing up a fix now which you can try (I will try too)
ron
OK, let's go through the v2 for this a bit. It's interesting because, well, I bet few people have bothered with it and I know I forgot.
Here we go.
chip southbridge/amd/amd8111 # this "device pci 0.0" is the parent the next one # PCI bridge device pci 0.0 on device pci 0.0 on end device pci 0.1 on end device pci 0.2 off end device pci 1.0 off end end device pci 1.0 on
So what happens here? The amd8111 is a chip, and it has kids, and it has this function: struct chip_operations southbridge_amd_amd8111_ops = { CHIP_NAME("AMD-8111 Southbridge") /* This only called when this device is listed in the * static device tree. */ .enable_dev = amd8111_enable, };
enable, and the first code in the enable is this:
void amd8111_enable(device_t dev) { device_t lpc_dev; device_t bus_dev; unsigned index; unsigned reg_old, reg;
/* See if we are on the behind the amd8111 pci bridge */ bus_dev = dev->bus->dev; if ((bus_dev->vendor == PCI_VENDOR_ID_AMD) && (bus_dev->device == PCI_DEVICE_ID_AMD_8111_PCI)) { unsigned devfn; devfn = bus_dev->path.u.pci.devfn + (1 << 3); lpc_dev = dev_find_slot(bus_dev->bus->secondary, devfn); index = ((dev->path.u.pci.devfn & ~7) >> 3) + 8; if (dev->path.u.pci.devfn == 2) { /* EHCI */ index = 16; } } else { unsigned devfn; devfn = (dev->path.u.pci.devfn) & ~7; lpc_dev = dev_find_slot(dev->bus->secondary, devfn); index = dev->path.u.pci.devfn & 7; }
At this point you might be saying, uh, what? What is this? It's the kind of code that tends to send people running for the exits.
The entity is a chip, not a device. Recall that a chip can have multiple devices but there are common chip-level registers that might need to be set to enable or control devices. If we look at static.c for v2,
struct device _dev15 = { .ops = 0, .bus = &_dev8.link[0], .path = {.type=DEVICE_PATH_PCI,.u={.pci={ .devfn = PCI_DEVFN(0x0,0)}}}, .enabled = 1, .on_mainboard = 1, .link = { [0] = { .link = 0, .dev = &_dev15, .children = &_dev16, }, }, .links = 1, .sibling = &_dev20, .chip_ops = &southbridge_amd_amd8111_ops, .chip_info = &southbridge_amd_amd8111_info_14, .next=&_dev16 }; note that in addition to chip_info we have chip_ops.
What is chip_ops? It has one struct member, and it looks like this:
/* Run the magice enable sequence for the device */ if (dev->chip_ops && dev->chip_ops->enable_dev) { dev->chip_ops->enable_dev(dev); }
So the amd8111 enable will be called for each device in this tree under the amd81111. That's why it has to check its own bus -- it has to figure out which of its devices it is being called for, then enable or disable that device.
Now, the pci device is the hardware that supports actual scanning. But note that structure above:
chip southbridge/amd/amd8111 # this "device pci 0.0" is the parent the next one # PCI bridge device pci 0.0 on device pci 0.0 on end device pci 0.1 on end device pci 0.2 off end device pci 1.0 off end end device pci 1.0 on
The pci 0.0 is the bridge, but the devices it refers to follow it.
What should this look like in dts?
Well, I made several mistakes.
First, the amd8111.c should not have a device struct. It should have nothing. It's just a function. In v3 we put support for functions like amd8111_enable right into the device struct: struct device_operations amd8111_lpc = { .id = {.type = DEVICE_ID_PCI, {.pci = {.vendor = PCI_VENDOR_ID_AMD, .device = PCI_DEVICE_ID_AMD_8111_ISA}}}, .constructor = default_device_constructor, .phase3_scan = scan_static_bus, .phase4_enable_disable = amd8111_enable, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
So the 'chip' keyword is gone as it did not fit well with dts.
So dts becomes this: pci@0,0 { /config/("southbridge/amd/amd8111/pci.dts"); pci{ /config/("southbridge/amd/amd8111/nic.dts"); }; };
because it's the pci device that is a bridge.
Hope this short writeup helps; I am testing this now.
ron
-----Original Message----- From: ron minnich [mailto:rminnich@gmail.com] Sent: Wednesday, October 08, 2008 9:46 AM To: Myles Watson Cc: Coreboot Subject: Re: [coreboot] AMD Serengeti Cheetah devices
OK, let's go through the v2 for this a bit. It's interesting because, well, I bet few people have bothered with it and I know I forgot.
Here we go.
This is great! Could we go back one more step to the 8132? It looks like the 8111 hangs off the 8132.
Hope this short writeup helps; I am testing this now.
Yes. Thanks, Myles
On Wed, Oct 8, 2008 at 8:54 AM, Myles Watson mylesgw@gmail.com wrote:
This is great! Could we go back one more step to the 8132? It looks like the 8111 hangs off the 8132.
it doesn't I think, because the 8132 is a tunnel. So 8111 and 8132 are peers. That was always my understanding. Marc?
Patch attached that gets us to a correct config space. :-) and a hang :-(
Spelling errors etc. in the 8111 code will be needed. Too much of the code in coreboot .c files is not written in any known language :-)
ron
Just FYI, here is what coreboot now says about devices:
<6>Phase 5: Done. <6>Show all devs... <8>root(Root Device): enabled 1 have_resources 0 initialized 0 <3>cpus: Unknown device path type: 0 <8>cpus(): enabled 1 have_resources 0 initialized 0 <8>apic_0(APIC: 00): enabled 1 have_resources 0 initialized 0 <8>domain_0_pci_1_0(PCI: 00:01.0): enabled 1 have_resources 0 initialized 0 <3>domain_0_pci0_18_0_pci_0_0_pci: Unknown device path type: 0 <8>domain_0_pci0_18_0_pci_0_0_pci(): enabled 1 have_resources 0 initialized 0 <8>domain_0_pci0_18_0_pci_0_0(PCI: 00:0a.0): enabled 1 have_resources 1 initialized 0 <8>domain_0_pci0_18_0_pci_4_0(PCI: 00:0e.0): enabled 0 have_resources 0 initialized 0 <8>domain_0_pci0_18_0(PCI: 00:18.0): enabled 1 have_resources 1 initialized 0 <8>domain_0_pci1_18_0(PCI: 00:18.0): enabled 1 have_resources 0 initialized 0 <8>domain_0_pci2_18_0_pci_2_0(PCI: 00:02.0): enabled 1 have_resources 0 initialized 0 <8>domain_0_pci2_18_0(PCI: 00:18.0): enabled 1 have_resources 0 initialized 0 <8>domain_0_pci_18_1(PCI: 00:18.1): enabled 1 have_resources 1 initialized 0 <8>domain_0_pci_18_2(PCI: 00:18.2): enabled 1 have_resources 1 initialized 0 <8>domain_0_pci_18_3(PCI: 00:18.3): enabled 1 have_resources 1 initialized 0 <8>domain_0_ioport_2e(IOPORT: 2e): enabled 1 have_resources 0 initialized 0 <8>domain_0(PCI_DOMAIN: 0000): enabled 1 have_resources 1 initialized 0 <8>dynamic PNP: 002e.0(PNP: 002e.0): enabled 1 have_resources 0 initialized 0 <8>dynamic PNP: 002e.1(PNP: 002e.1): enabled 1 have_resources 0 initialized 0 <8>dynamic PNP: 002e.2(PNP: 002e.2): enabled 1 have_resources 0 initialized 0 <8>dynamic PNP: 002e.3(PNP: 002e.3): enabled 1 have_resources 0 initialized 0 <8>dynamic PNP: 002e.5(PNP: 002e.5): enabled 1 have_resources 0 initialized 0 <8>dynamic PNP: 002e.6(PNP: 002e.6): enabled 1 have_resources 0 initialized 0 <8>dynamic PNP: 002e.7(PNP: 002e.7): enabled 1 have_resources 0 initialized 0 <8>dynamic PNP: 002e.8(PNP: 002e.8): enabled 1 have_resources 0 initialized 0 <8>dynamic PNP: 002e.9(PNP: 002e.9): enabled 1 have_resources 0 initialized 0 <8>dynamic PNP: 002e.a(PNP: 002e.a): enabled 1 have_resources 0 initialized 0 <8>dynamic PNP: 002e.b(PNP: 002e.b): enabled 1 have_resources 0 initialized 0 <8>dynamic PCI: 00:00.0(PCI: 00:06.0): enabled 1 have_resources 1 initialized 0 <8>dynamic PCI: 00:07.0(PCI: 00:07.0): enabled 1 have_resources 1 initialized 0 <8>dynamic PCI: 00:07.1(PCI: 00:07.1): enabled 1 have_resources 1 initialized 0 <8>dynamic PCI: 00:07.2(PCI: 00:07.2): enabled 1 have_resources 1 initialized 0 <8>dynamic PCI: 00:07.3(PCI: 00:07.3): enabled 1 have_resources 1 initialized 0 <8>dynamic PCI: 00:07.5(PCI: 00:07.5): enabled 1 have_resources 1 initialized 0 <8>dynamic PCI: 00:07.6(PCI: 00:07.6): enabled 1 have_resources 1 initialized 0 <8>dynamic PCI: 00:07.7(PCI: 00:07.7): enabled 1 have_resources 1 initialized 0 <8>dynamic PCI: 00:0a.1(PCI: 00:0a.1): enabled 1 have_resources 1 initialized 0 <8>dynamic PCI: 00:0b.0(PCI: 00:0b.0): enabled 1 have_resources 1 initialized 0 <8>dynamic PCI: 00:0b.1(PCI: 00:0b.1): enabled 1 have_resources 1 initialized 0 <8>dynamic PCI: 01:00.0(PCI: 01:00.0): enabled 1 have_resources 1 initialized 0 <8>dynamic PCI: 01:00.1(PCI: 01:00.1): enabled 1 have_resources 1 initialized 0 <8>dynamic PCI: 01:00.2(PCI: 01:00.2): enabled 1 have_resources 1 initialized 0 <8>dynamic PCI: 01:01.0(PCI: 01:01.0): enabled 1 have_resources 1 initialized 0 <8>dynamic PCI: 01:04.0(PCI: 01:04.0): enabled 1 have_resources 1 initialized 0 <8>dynamic PCI: 01:05.0(PCI: 01:05.0): enabled 1 have_resources 1 initialized 0
And here is the lockup: <6>Phase 6: Initializing devices... <7>Phase 6: Root Device init. <3>domain_0_pci0_18_0_pci_0_0_pci: Unknown device path type: 0 <7>Phase 6: init. <3>domain_0_pci0_18_0_pci_0_0_pci: Unknown device path type: 0 <0> missing resource: 10 <0> At this point it resets.
What I've realized is that 2 years ago we decided (in Hamburg) to get rid of the chip/device mess and unify around a device in both dts and C. It worked. I just forgot. Now we need to fix these last few nits and we are further along.
V3 is picking up speed. It's been a long, hard haul but we're getting there. Note that carl-daniels' naming scheme makes it quite easy to know what omain_0_pci0_18_0_pci_0_0_pci is ... ron
-----Original Message----- From: ron minnich [mailto:rminnich@gmail.com] Sent: Wednesday, October 08, 2008 9:58 AM To: Myles Watson Cc: Coreboot Subject: Re: [coreboot] AMD Serengeti Cheetah devices
On Wed, Oct 8, 2008 at 8:54 AM, Myles Watson mylesgw@gmail.com wrote:
This is great! Could we go back one more step to the 8132? It looks
like
the 8111 hangs off the 8132.
it doesn't I think, because the 8132 is a tunnel. So 8111 and 8132 are peers. That was always my understanding. Marc?
That makes sense. So the 8132 doesn't need to be mentioned at all in the dts? I think a comment in the dts would be great.
Thanks, Myles
ron minnich wrote:
On Wed, Oct 8, 2008 at 8:54 AM, Myles Watson mylesgw@gmail.com wrote:
This is great! Could we go back one more step to the 8132? It looks like the 8111 hangs off the 8132.
it doesn't I think, because the 8132 is a tunnel. So 8111 and 8132 are peers. That was always my understanding. Marc?
ht socketF -------- socketF | | |ht |ht | | AMD8151(AGP) AMD8132 (PCIX tunnel) | |ht | AMD8111 HT IO Hub --- IDE | |-- USB |lpc |-- PCI | LPC SIO
Fix the amd8111.
Remove the device struct for amd8111.c as it is not a device.
Make sure that the phase4_enable_disable is named (or similar is named) in all device structs.
Fix the mainboard dts to use the 8111 pci as the bridge. Add bridge keyword to the amd8111 pci dts.
This gets to this point:
Phase 6: Initializing devices... Phase 6: Root Device init. domain_0_pci0_18_0_pci_0_0_pci: Unknown device path type: 0 Phase 6: init. domain_0_pci0_18_0_pci_0_0_pci: Unknown device path type: 0 missing resource: 10
and stop. Still working on that. BUT: the config space shows bus 1 now!
Signed-off-by: Ronald G. Minnich rminnich@gmail.com
It didn't build until I removed the Makefile change. It complained about multiple definitions. I'm also wondering if all we need to do is disable the 8111's nic and serial controller. They showed up as extra compared to v2.
With the Makefile change: Acked-by: Myles Watson mylesgw@gmail.com
Thanks, Myles
You need to svn up or I need to commit one other file. I had to shuffle things a bit in one of the makefiles for dbm690t
ron
-
Marc Jones -
Myles Watson -
ron minnich