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.
But I think that the unitid scan happens before and device/dts is used or called. This has to be done to set the HT link speed. See northbridge\amd\k8\incoherent_ht.c. By the time the device code starts they are setup and the bus can be scanned as normal pci.
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.
Because it is a unitid bus number it is already numbered. I think that the device code should use any bus number already set. That would be equivalent to setting the bus number with pci_x@ in the dts.
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.
How does the code treat an ht device differently at this point?
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.
So shouldn't you treat it like any bridge? ( I think this is how bridges should be treated.) pci@0,1{ /config/bridge dts pci@0,0{ /config/device dts }; }; Since ht bridges are getting special names should pci bridges? pcib@x,y
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 ... };
So a ht link off of another cpu will be a new domain? Do you know how the 8151 will be defined in the Serengeti dts?
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.
great
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.)
I meant if the ht bridge that acts like a pci bridge were a real pci bridge. I think then it is domain_0_pci_18_0_pci_0_6.
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.
This is what I noted above. Devices under a bridge need to be in the bridge brackets so you know where they are regardless of bus numbering.
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.
This still doesn't make sense to me. It is on the silicon that happens to be a HT device but it is just a pci device on bus 0. Think of it in terms of any other motherboard device. The device is always at the same location in the system. This one happens to be set to unitid+1. I think that you still set it in the dts as pci@0,7.
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.
Is the Subtractive or VGA bits set in the 8132 bridge or is the BAR claiming the area? Marc
-----Original Message----- From: Marc Jones [mailto:marcj303@gmail.com] Sent: Thursday, November 20, 2008 11:13 AM To: Myles Watson Cc: Coreboot Subject: Re: [coreboot] HT chains fixup
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.
But I think that the unitid scan happens before and device/dts is used or called. This has to be done to set the HT link speed. See northbridge\amd\k8\incoherent_ht.c. By the time the device code starts they are setup and the bus can be scanned as normal pci.
The problem is HTX slots and modules that can't be initialized without some 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.
Because it is a unitid bus number it is already numbered. I think that the device code should use any bus number already set. That would be equivalent to setting the bus number with pci_x@ in the dts.
That could happen. The problem is how you pick the "correct" early enumeration. It's easy to pick an enumeration that lets you see all the busses and optimize the HT links. It's not easy to make the busses get numbered correctly, which is why you need the dts information.
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.
How does the code treat an ht device differently at this point?
When it sets the UnitID, it also sets the function numbers of the children, since they are offsets from the UnitID.
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.
So shouldn't you treat it like any bridge? ( I think this is how bridges should be treated.)
coprocessors aren't necessarily bridges. Mine isn't.
pci@0,1{ /config/bridge dts pci@0,0{ /config/device dts }; };
Since ht bridges are getting special names should pci bridges? pcib@x,y
They don't need them unless you want to override automatic bus numbering.
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 ... };
So a ht link off of another cpu will be a new domain? Do you know how the 8151 will be defined in the Serengeti dts?
No. I'm not sure I understand domains yet, but I've been told you can implement multiple domains in a k8 or fam10. from the lspci: 08:01.0 Host bridge [0600]: Advanced Micro Devices [AMD] AMD-8151 System Controller [1022:7454] (rev 14) 08:02.0 PCI bridge [0604]: Advanced Micro Devices [AMD] AMD-8151 AGP Bridge [1022:7455] (rev 14) 09:00.0 VGA compatible controller [0300]: ATI Technologies Inc RV280 [Radeon 9200] [1002:5961] (rev 01) 09:00.1 Display controller [0380]: ATI Technologies Inc RV280 [Radeon 9200] (Secondary) [1002:5941] (rev 01) The 8151 will be: ht@1,1 (link 1, UnitID 1) pci_uniquifier@1,0 (8151 AGP bridge) and the dtsnames will then be: domain_0_ht_1_1 domain_0_pci_uniquifier_1_0
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.
great
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.)
I meant if the ht bridge that acts like a pci bridge were a real pci bridge. I think then it is domain_0_pci_18_0_pci_0_6.
? The 8111 pci is a real pci bridge.
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.
This is what I noted above. Devices under a bridge need to be in the bridge brackets so you know where they are regardless of bus numbering.
Maybe this is related to my previous misunderstanding?
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.
This still doesn't make sense to me. It is on the silicon that happens to be a HT device but it is just a pci device on bus 0. Think of it in terms of any other motherboard device. The device is always at the same location in the system. This one happens to be set to unitid+1. I think that you still set it in the dts as pci@0,7.
I think you meant pci@7,0. With ht@ it's link, unitid. With pci it's dev, fn (dev == unitid) If we later have a hierarchical dts so you don't have to specify all these numbers (since they don't change), we'll want them to be offsets.
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.
Is the Subtractive or VGA bits set in the 8132 bridge or is the BAR claiming the area? The BAR seems to be claiming the area.
Thanks, Myles
On Thu, Nov 20, 2008 at 11:55 AM, Myles Watson <mylesgw@gmail.com> wrote:
-----Original Message----- From: Marc Jones [mailto:marcj303@gmail.com] Sent: Thursday, November 20, 2008 11:13 AM To: Myles Watson Cc: Coreboot Subject: Re: [coreboot] HT chains fixup
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.
But I think that the unitid scan happens before and device/dts is used or called. This has to be done to set the HT link speed. See northbridge\amd\k8\incoherent_ht.c. By the time the device code starts they are setup and the bus can be scanned as normal pci.
The problem is HTX slots and modules that can't be initialized without some 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.
Because it is a unitid bus number it is already numbered. I think that the device code should use any bus number already set. That would be equivalent to setting the bus number with pci_x@ in the dts.
That could happen. The problem is how you pick the "correct" early enumeration. It's easy to pick an enumeration that lets you see all the busses and optimize the HT links. It's not easy to make the busses get numbered correctly, which is why you need the dts information.
So you are moving the HT_CHAIN_UNITID_BASE and HT_CHAIN_END_UNITID_BASE to be done by the device and dts setting? It seems to me that the device code hypertransport init is duplicate of setup that has already run in incoherent code. The setup needs to happen early to set the speed etc. I don't expect that you will see a "HyperT reset needed" from the device code because that already happened in stage1. You may also want to review the v3 fam10 code since it works a little bit differently but gets to the same result. Marc -- http://marcjstuff.blogspot.com/
-----Original Message----- From: Marc Jones [mailto:marcj303@gmail.com] Sent: Thursday, November 20, 2008 1:58 PM To: Myles Watson Cc: Coreboot Subject: Re: [coreboot] HT chains fixup
On Thu, Nov 20, 2008 at 11:55 AM, Myles Watson <mylesgw@gmail.com> wrote:
-----Original Message----- From: Marc Jones [mailto:marcj303@gmail.com] Sent: Thursday, November 20, 2008 11:13 AM To: Myles Watson Cc: Coreboot Subject: Re: [coreboot] HT chains fixup
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.
But I think that the unitid scan happens before and device/dts is used or called. This has to be done to set the HT link speed. See northbridge\amd\k8\incoherent_ht.c. By the time the device code starts they are setup and the bus can be scanned as normal pci.
The problem is HTX slots and modules that can't be initialized without some 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.
Because it is a unitid bus number it is already numbered. I think that the device code should use any bus number already set. That would be equivalent to setting the bus number with pci_x@ in the dts.
That could happen. The problem is how you pick the "correct" early enumeration. It's easy to pick an enumeration that lets you see all the busses and optimize the HT links. It's not easy to make the busses get numbered correctly, which is why you need the dts information.
So you are moving the HT_CHAIN_UNITID_BASE and HT_CHAIN_END_UNITID_BASE to be done by the device and dts setting?
Yes. I'm hoping that there will be no #ifs in the code. It's too fragile, especially when there are multiple chains. The way I envision it is that the HT chains get optimized (assign valid but unimportant UnitIDs), then collapsed and set by dts when it matters.
It seems to me that the device code hypertransport init is duplicate of setup that has already run in incoherent code. The setup needs to happen early to set the speed etc. I don't expect that you will see a "HyperT reset needed" from the device code because that already happened in stage1.
That's what I'm hoping.
You may also want to review the v3 fam10 code since it works a little bit differently but gets to the same result.
I'll look through it. Thanks, Myles
On Thu, Nov 20, 2008 at 2:45 PM, Myles Watson <mylesgw@gmail.com> wrote:
-----Original Message----- From: Marc Jones [mailto:marcj303@gmail.com] Sent: Thursday, November 20, 2008 1:58 PM To: Myles Watson Cc: Coreboot Subject: Re: [coreboot] HT chains fixup
On Thu, Nov 20, 2008 at 11:55 AM, Myles Watson <mylesgw@gmail.com> wrote:
-----Original Message----- From: Marc Jones [mailto:marcj303@gmail.com] Sent: Thursday, November 20, 2008 11:13 AM To: Myles Watson Cc: Coreboot Subject: Re: [coreboot] HT chains fixup
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.
But I think that the unitid scan happens before and device/dts is used or called. This has to be done to set the HT link speed. See northbridge\amd\k8\incoherent_ht.c. By the time the device code starts they are setup and the bus can be scanned as normal pci.
The problem is HTX slots and modules that can't be initialized without some 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.
Because it is a unitid bus number it is already numbered. I think that the device code should use any bus number already set. That would be equivalent to setting the bus number with pci_x@ in the dts.
That could happen. The problem is how you pick the "correct" early enumeration. It's easy to pick an enumeration that lets you see all the busses and optimize the HT links. It's not easy to make the busses get numbered correctly, which is why you need the dts information.
So you are moving the HT_CHAIN_UNITID_BASE and HT_CHAIN_END_UNITID_BASE to be done by the device and dts setting?
Yes. I'm hoping that there will be no #ifs in the code. It's too fragile, especially when there are multiple chains.
The way I envision it is that the HT chains get optimized (assign valid but unimportant UnitIDs), then collapsed and set by dts when it matters.
I'm hoping we can make it so that Stefan can have his automatic depth-first assignment too. If you don't assign UnitIDs in the dts, they just get assigned as they're reached. Thanks again for the good questions. I'm hoping to come out of this with much simpler code. Thanks, Myles
Myles Watson wrote:
I'm hoping to come out of this with much simpler code.
Reading up on this thread, I think you will. Looks like very good progress. Some comments; I would like the dtb to be available and usable earlier rather than later. I like that we can use it more. As Myles hinted at, I think HT does require us to have offset support in the tree. This also means that HT has to be treated differently than PCI. I didn't really like the idea of simplifying HT out of the tree, but - as Myles pointed out - I'm still learning about HT. :) How does HT unit arbitration work at power up? Ie. what determines the order of unit 0:s? //Peter
-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Peter Stuge Sent: Thursday, November 20, 2008 4:32 PM To: Coreboot Subject: Re: [coreboot] HT chains fixup
Myles Watson wrote:
I'm hoping to come out of this with much simpler code.
Reading up on this thread, I think you will. Looks like very good progress.
Thanks.
Some comments;
I would like the dtb to be available and usable earlier rather than later. I like that we can use it more.
I agree. I think the more things we make explicit in the dts, the easier it will be to port boards to v3.
As Myles hinted at, I think HT does require us to have offset support in the tree.
This also means that HT has to be treated differently than PCI. I didn't really like the idea of simplifying HT out of the tree, but - as Myles pointed out - I'm still learning about HT. :)
That wasn't directed to anyone in particular. Hopefully as we clean up the code it will be more and more obvious to everyone how it works and why it should be implemented in the way we chose.
How does HT unit arbitration work at power up? Ie. what determines the order of unit 0:s?
There is no arbitration. HT is point-to-point, so you always know which one you're talking to. The closest device set to the correct UnitID responds. At power up all of them are set to 0, so you can only see the configuration space of the first device (link on the chain.) If you want to be able to read configuration registers of the next device, you have to move the first device away from zero. Then the next read at 0 will be the next device. If it's the last device, when you move it no one responds at 0 and you know you're done. As soon as the UnitIDs are set, it appears to be PCI. Thanks, Myles
On Thu, Nov 20, 2008 at 4:31 PM, Peter Stuge <peter@stuge.se> wrote:
How does HT unit arbitration work at power up? Ie. what determines the order of unit 0:s?
The devices all come up with wiith unitid of 0 and are scanned depth first just as pci bridges are. The unitids can be set automatically but usually some devices are set specifically. The subtractive device is normally left as device 0. In the case or Serengeti it is 6 for historical reasons ( think there was a early 8111 bug that required the setting). Marc -- http://marcjstuff.blogspot.com/
-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Marc Jones Sent: Friday, November 21, 2008 10:19 AM To: Coreboot Subject: Re: [coreboot] HT chains fixup
On Thu, Nov 20, 2008 at 4:31 PM, Peter Stuge <peter@stuge.se> wrote:
How does HT unit arbitration work at power up? Ie. what determines the order of unit 0:s?
Physical placement. Since it's point-to-point, they hide in each other's shadows when they have equal UnitIDs.
The devices all come up with wiith unitid of 0 and are scanned depth first just as pci bridges are. The unitids can be set automatically but usually some devices are set specifically. The subtractive device is normally left as device 0. In the case or Serengeti it is 6 for historical reasons ( think there was a early 8111 bug that required the setting).
I think it's confusing to compare it to PCI since the meaning of depth is different until UnitIDs are assigned. It's not clear to me what it means to set the values depth first in a case like this: <-> is an ht link k8 <-> 8132 <-> 8132 <-> 8111 Since the 8132s are tunnels and consume 2 UnitIDs each, how do you decide which UnitIDs to assign to them. Until you get to the 8111 (end of chain), you don't know how many to skip. at the beginning the UnitIDs are assigned: k8 <-> 0 <-> 0 <-> 0 And only the first responds. You choose some "safe" place to put it, and continue. k8 <-> 0xa <-> 0 <-> 0 Now the second one is visible. You choose to increment the UnitID (2 were consumed) k8 <-> 0xa <-> 0xc <-> 0 Then you set the last one (cave) to 0x6 for historical reasons. k8 <-> 0xa <-> 0xc <-> 0x6 There's nothing that says that that was the right way. I could have easily used any other safe value, or moved the UnitIDs after I knew how many each device consumed. These would be just as valid: k8 <-> 0xc <-> 0xa <-> 0x6 k8 <-> 0x8 <-> 0xa <-> 0x6 etc. I realize that this is somewhat contrived since I can't say I've ever seen a board like that, but it would be easy to build. Thanks, Myles
participants (3)
-
Marc Jones -
Myles Watson -
Peter Stuge