New subject: Fwd: HT chains fixup

20 Nov 2008

      ....and Myles reply
On Wed, Nov 19, 2008 at 9:16 PM, Myles Watson mylesgw@gmail.com wrote:
...
...
-----Original Message-----
From: Marc Jones [mailto:marcj303@gmail.com]
Sent: Wednesday, November 19, 2008 4:11 PM
To: Myles Watson
Subject: Re: [coreboot] HT chains fixup
Myles,
Hi, sorry to take so long to look at this. I have some possibly dumb
questions.
No problem.  I appreciate the review.
...
What is gained by knowing the ht path?
When a HT chain is powered on, all the devices have the same UnitID (0)
The subordinate busses get assigned bus numbers in the order that they are
found by PCI scan, but they are found in the order of the chain.  As you
assign each a device number, another device is visible at device 0 until the
end of the chain is found.
Right, But I think that unitid setting happens before device scanning
and the dts is available. Once they are set there is no reason to
change them. The only thing is that the pci bridge code
...
...
Every HT bridge/tunnel under a
CPU acts like a PCI device. Linux doesn't know about HT and I am not
sure that the dts needs to.
That's why I made ht devices morph into pci devices at chain enumeration
time.  Once they're assigned UnitIDs it doesn't matter where they are in the
chain.
...
The exception being that coreboot needs to
know the CPU that the bus comes off of.  I feel like I am missing
something obvious that you, Ron, and others understand.
I'm getting just as much push back from everyone else.  I'm not sure anyone
understands the code that well.  I feel silly for having to rewrite so much
of it.  It probably points to my lack of understanding.
...
What are you describing with and ht@? For example:

                ht@0,a {

/config/("southbridge/amd/amd8132/pcix.dts");
...

                };

                pci_a@0,1{

/config/("southbridge/amd/amd8132/apic.dts");
ht@0,a is ht chain 0, UnitID a.  I wanted it to be explicit where the chains
end and what the numbers are.  The way the code works is that it takes the
HT device and all the PCI devices that it implements off the list at once.
Without knowing which devices are HT, that's hard to tell.  The code before
used a heuristic and a lot of #if statements.
The reason I put pci_a here is that otherwise device 0,1 of the 8132
collides with 0,1 of the 8111 (their dts names are the same.)
The reason for specifying the chain number is that devices could be inserted
in a lot of places, and it is nice to be able to specify which one you mean.
Think of an 8-way box where you could replace any of the processors with a
co-processor.  It gets ugly in a hurry.
...
I would think that the dts and device code would work with this for
the 8132 device:

                pci_a@0,0 {

/config/("southbridge/amd/amd8132/pcix.dts");
...

                };

                pci_a@0,1{

/config/("southbridge/amd/amd8132/apic.dts");
Hopefully the explanation above helps here.
...
The HT is just a bus link.There is no HT bridge or device. The
bridge/device acts as a PCI bridge/device and should be treated as
such.
This is true once the chain is enumerated, but the 8111 isn't visible until
the 8132 is moved out of the way, so it isn't just a link before a UnitID is
assigned.
...
I also don't understand when something is under the ht@0,6 vs when it
should just be pci_6@x,y. All the onboard devices are directly on HT
and the bridges to PCI/e/X are also on HT. (There is a question about
this in the output also)
ht just means it's a HT device function 0.  It means that it consumes the
UnitID from the HT capability.  All the others are sub-devices.
...
Another nit I have is that pci_18_0 is the top device. Physically it
is but logically it isn't. The dts doesn't make sense when you compare
it with the lspci. I don't know if this is really better but maybe
something like this:
My next patches will move everything from being a child of 18.0 to being a
child of the domain.  That's assuming I ever get agreement for what I'm
doing :)  I plan to have it look like this:
domain {
       /k8/domain
       ht@0,a
       ht@0,6
       pci@18,0
       pci@18,1
       pci@18,2
       pci@18,3
       pci@19,0
       ...
};
Then the only difference between lspci and the dts will be the ht
enumeration ordering.  I do think that needs to be explicit.
...
pci@0,0(18,0){
  pci@x,y {
      config....
  };
  ...
  pci@18,0 {};
};
That way the top level bus resources are pointed at the CPU device but
the logical PCI connections are easy to follow.
Yes.
...
There are some more question in your output below.
On Mon, Nov 17, 2008 at 11:21 AM, Myles Watson mylesgw@gmail.com wrote:
...
...
Show all devs in tree form...After phase 3.
root(Root Device): enabled 1 have_resources 0
 cpus(CPU: 00): enabled 1 have_resources 0
 apic_0(APIC: 00): enabled 1 have_resources 0
 domain_0(PCI_DOMAIN: 0000): enabled 1 have_resources 0
  domain_0_pci_18_0(PCI: 00:18.0): enabled 1 have_resources 0
This might be easier to read if you use the lspci colon and period on
the device numbers.
For example domain_0_pci_18.0_ht_0:6
I could do that.  I don't know why Carl-Daniel and Ron decided on
underscores everywhere.  It seems like they went back and forth for a while
on dts names.
...
...
domain_0_pci_18_0_ht_0_6(PCI: 00:06.0): enabled 1 have_resources 0
This will be domain_0_ht_0_6 if I get my way.
...
What if this were a real PCI to PCI bridge? Would it be
domain_0_pci_18_0_pci_0_6?
Yes, but there's no such thing with an Opteron, right?  It would have to be
another level down in the hierarchy like domain_0_ht_0_6_pci_6_0 (remember
that HT UnitID and PCI dev are the same, so ht_0_6 becomes pci_6_0.)
...
...
domain_0_pci_18_0_ht_0_6_pci_0_0(PCI: 01:00.0): enabled 1

have_resources
...
0
Why isn't this domain_0_pci_18_0_ht_0_6_pci_1_0_0?
Bus numbers get assigned as they're discovered, so they aren't mentioned in
the dts.  That's why the 8111 has to be at 0x6 and the 8132 has to be at
0xa, otherwise the 8132's busses get numbered first, and  the southbridge
ends up on bus 3.  Actually the 8111 just has to have a lower number.  0x0
and 0x2 also work.
...
...
domain_0_pci_18_0_ht_0_6_pci_0_1(PCI: 01:00.1): enabled 1

have_resources
...
0
...
...
domain_0_pci_18_0_pci_6_1_0(PCI: 00:07.0): enabled 1 have_resources 0
I really don't understand this one. It is a device on bus 0 so what
does 6_1_0 mean?
It's device 1 function 0 of the pci_6 ht device.  Remember I had to add the
_6 so that it wouldn't have the same name as pci_a_1_0.  I agree it's
confusing.  I couldn't think of a really great way to do it.  Maybe just
taking out the extra underscore would help:
domain_0_pci6_0_1
or naming it explicitly
domain_0_pciht6_0_1
I'm open to suggestions.
...
...
domain_0_pci_18_0_pci_6_1_0_ioport_2e(IOPORT: 2e): enabled 1

have_resources 0
     domain_0_pci_18_0_pci_6_1_0_ioport_2e_pnp_child_0(PNP: 002e.0):
enabled
...
0 have_resources 0
     domain_0_pci_18_0_pci_6_1_0_ioport_2e_pnp_child_1(PNP: 002e.1):
enabled
...
0 have_resources 0
Putting the io on the subtractive device is good.
...
I'm glad you approve.  I like it that you can trace the path there.
...
...
Here are some of the next steps:

Get video working.

Do you know where the breakage is?
I think it's in resource allocation.  It's really hard to follow, though.
In the end the 8132 claims the address space that should be for the video
buffer, and it never gets to the card.
I'm in the middle of reorganizing resource allocation so that resources
always get read and allocated in order of the tree.  I also think the
devices should get enabled in that order.
Thanks for the good questions.  One of the hard things about coreboot is
that there are so many specialties required to get it working.  Some of the
folks on the list are amazing programmers, some have soldering and rework
skills, SuperIO knowledge,...  I don't think anyone has it all.
I didn't copy the list since you just sent it to me, but at some point I
might want to forward the answers to others.
Thanks,
Myles
-- 
http://marcjstuff.blogspot.com/