Support for enumerating non-local endpoint IDs #61
Comments
|
The I3C specification seems to have a strong assumption that the PIDs of devices on a bus are unique, looking at MIPI I3C Basic v1.1.1, sections 5.1.4.1.1 and 5.1.4.1.2. Are there any strapping/configuration options for the devices on your system? |
|
Further to the same bus & PID concept, and ignoring the MCTP side for now, how is i3c dynamic address allocation able to work at all? Any devices with the identical PID will not lose arbitration during the ENTDAA-triggered dynamic address assignment process, and so you would be targeting multiple devices during each phase of the following dynamic address assignment.. Or is it that the two CXL devices actually have different i3c PIDs (or are even on non-i3c busses), but you're using the BIC 1's i3c address as a proxy for the devices behind BIC 1? |
|
Hi @mkj , Thank you for comments regarding the I3C PID uniqueness requirement. Unfortunately, I don't have any other hardware strapping or configuration options available for my system. Hi @jk-ozlabs , I am using the BIC1's I3C address as a proxy for the devices behind BIC1. BIC1 acts as a bridge for communications between the BMC and devices behind it (BIC2, CXL1, CXL2). Thus, flowchart LR;
BMC[BMC]
subgraph Proxy[Proxy]
BIC1["BIC 1
StaticEID: 10"]
end
BIC2["BIC 2
StaticEID: 12"]
CXL1["CXL 1
StaticEID: 14"]
CXL2["CXL 2
StaticEID: 15"]
BMC-->Proxy;
Proxy-->BIC2;
BIC2-->CXL1;
BIC2-->CXL2;
Thanks for your help. |
|
Hi @yikaitsaiww
OK, so you don't actually have two devices with the same PID on the same i3c bus then, which is a big relief :) The physical addressing mechanism is only used when So, it does not make sense to call Can you elaborate what you're trying to achieve, perhaps? You already know the endpoint EIDs, right? What information are you hoping to find from the endpoint objects in the dbus hierarchy? It sounds like we may need a new mechanism for enumerating those particular endpoints (specifically: they already have a static EID, and we do not have an intermediate bus owner that would be allocating an EID pool). That "enumeration" would not be performing any address allocation, only the endpoint query (ie. Get Message Type Support). |
|
Thank you for your detailed explanation. Yes, we already know the EIDs. We are using static EID, currently. The reason BMC needs to access the EIDs of BIC2 and CXL1, 2 is to monitor sensors and logs and update FW.
Currently, we are using I hope the information provided above is comprehensive. BTW, I may be slower to respond due to the upcoming Chinese New Year :) Thanks a lot. |
Just to clarify: I wasn't querying why you need to access those devices over MCTP, but instead: what information do you need to consume from the dbus representation of those endpoints? No problem at all about the delay, we have some upcoming holidays here too 😄 |
|
Understood. I will gather more information and get back to you. Have a great holiday. 😀 |
|
Let me take BIC1 (EID10) & BIC2 (EID12) for example. For each EID, we need to know if it supports PLDM/CCI by |
|
Hi @yikaitsaiww , thanks for the info!
So the next question: how does the bmc machine know about the presence of EID 12, 13 and 14? Since they're not directly connected to the BMC (in which case they would have been detected on the local physical bus), how has it decided to query those endpoints for their supported message types? (I am aware of multiple possibilities for this, but I'm keen to hear about your specific use-case) |
|
Thank you for your question. Let me provide additional context: It's entity-manager, which detects the FRUs, enabling the BMC to know their presence. BIC2 (EID10), CXL1 (EID14), and CXL2 (EID15) are set in the same json file. When entity-manager recognizes the FRU of BIC2, it also know the existence of CXL1 (EID14), and CXL2 (EID15). Thank you very much! |
|
OK, neat. So the EIDs are known in advance. We should be able to trigger enumeration on the network object given the EID. I'll propose a new dbus interface on the network to allow this. |
|
OK, I think I have a design worked out, and prototyped here. New dbus interface would be: The How does that sound? |
|
Basic process would be this: start state: $ busctl tree au.com.codeconstruct.MCTP1
└─/au
└─/au/com
└─/au/com/codeconstruct
└─/au/com/codeconstruct/mctp1
├─/au/com/codeconstruct/mctp1/interfaces
│ └─/au/com/codeconstruct/mctp1/interfaces/mctp0
└─/au/com/codeconstruct/mctp1/networks
└─/au/com/codeconstruct/mctp1/networks/1
└─/au/com/codeconstruct/mctp1/networks/1/endpoints
└─/au/com/codeconstruct/mctp1/networks/1/endpoints/8enumerate directly-attached endpoint: $ busctl call au.com.codeconstruct.MCTP1 \
/au/com/codeconstruct/mctp1/interfaces/mctp0 \
au.com.codeconstruct.MCTP.BusOwner1 \
SetupEndpoint ay 1 0x1d
yisb 9 1 "/au/com/codeconstruct/mctp1/networks/1/endpoints/9" true
$ busctl tree au.com.codeconstruct.MCTP1
└─/au
└─/au/com
└─/au/com/codeconstruct
└─/au/com/codeconstruct/mctp1
├─/au/com/codeconstruct/mctp1/interfaces
│ └─/au/com/codeconstruct/mctp1/interfaces/mctp0
└─/au/com/codeconstruct/mctp1/networks
└─/au/com/codeconstruct/mctp1/networks/1
└─/au/com/codeconstruct/mctp1/networks/1/endpoints
├─/au/com/codeconstruct/mctp1/networks/1/endpoints/8
└─/au/com/codeconstruct/mctp1/networks/1/endpoints/9
$ busctl introspect au.com.codeconstruct.MCTP1 /au/com/codeconstruct/mctp1/networks/1/endpoints/9
NAME TYPE SIGNATURE RESULT/VALUE FLAGS
au.com.codeconstruct.MCTP.Endpoint1 interface - - -
.Recover method - - -
.Remove method - - -
.SetMTU method u - -
.Connectivity property s "Available" emits-change
org.freedesktop.DBus.Introspectable interface - - -
.Introspect method - s -
org.freedesktop.DBus.Peer interface - - -
.GetMachineId method - s -
.Ping method - - -
org.freedesktop.DBus.Properties interface - - -
.Get method ss v -
.GetAll method s a{sv} -
.Set method ssv - -
.PropertiesChanged signal sa{sv}as - -
xyz.openbmc_project.Common.UUID interface - - -
.UUID property s "c39e2a40-e85e-11ef-8e9c-f02f74cfe867" const
xyz.openbmc_project.MCTP.Endpoint interface - - -
.EID property y 9 const
.NetworkId property u 1 const
.SupportedMessageTypes property ay 2 0 1 constenumerate bridged endpoint: (note the different UUID and SupportedMessageTypes between the two endpoints) The latter |
|
It looks like there are no issues. This should correspond to our situation. Thank you. |
|
Development branch is up, as If you can give that some testing, that would be great. |
|
Thank you very much! We will find time to test it and give you feedback. |
|
Hi Jeremy, I tested the branch. I mounted the directly-attached endpoint using Then, I changed all directly-attached endpoints back to using I found that starting from this commit, mctpd: use object vtable for links · CodeConstruct/mctp@919285d, In the previous commit mctpd: clean vtable definitions · CodeConstruct/mctp@68f083f, everything was still working normally as before. I'd like to ask if there are any package dependencies or anything else we should be aware of? Thank you. |
|
Looks like there may be a systemd dependency on the old dbus names, but that shouldn't be important for this test. I suspect something wrong in the new dbus-handling code, so likely something wrong on my side. I'll take a look and update with a new branch. |
|
Do you have any plans or an estimated timeline for when the updates might be available? Thank you very much for your assistance. 😀 |
|
I have just been traveling last week - I'll get something sorted before the end of the week. |
|
In the meantime though, could you add |
|
actually, don't worry about that at this stage; we don't have any additional debugging data in the interface add path. I'll keep looking here :) |
|
OK, I have added some extra debug info to that branch (you should see cfc5a39 there). If you can run with |
|
Howdy! Also seeing this For context: with |
|
This did the trick for me. I am now able to call diff --git a/src/mctpd.c b/src/mctpd.c
index a7b262c..8292f3a 100644
--- a/src/mctpd.c
+++ b/src/mctpd.c
@@ -3855,14 +3855,8 @@ static int add_interface(struct ctx *ctx, int ifindex)
}
- rc = emit_interface_added(link);
- if (rc < 0)
- return rc;
-
-
link->published = true;
-
- return rc;
+ return emit_interface_added(link);
err_free:
free(link); |
|
Ah, super! I'll do some testing and incorporate that into the series. Let me know how any further testing goes, and I'll consider for merging. |
|
Worked great! After learning my downstream endpoints, My bridge is connected via your MCTP/USB kernel transport binding, so I've been manually adding routes then relearning the interface. |
|
I've now done a few updates, and this support is in the |
We are facing a challenge where multiple devices in our system share the same I3C address and bus. This configuration is not supported by
AssignEndpointandAssignEndpointStatic.Let me show our system architecture:
flowchart LR; BIC1["BIC 1 StaticEID: 10"] BIC2["BIC 2 StaticEID: 12"] CXL1["CXL 1 StaticEID: 14"] CXL2["CXL 2 StaticEID: 15"] BMC-->BIC1-->BIC2; BIC2-->CXL1; BIC2-->CXL2;To accommodate this architecture, we've configured all devices (BIC1, BIC2, CXL1, and CXL2) with the same I3C address in the entity-manager, distinguished only by their EIDs.
The MCTP tree we expect will be:
Here's a breakdown of the issue:
AssignEndpointStaticchecks if it hasalready assigned a different EID, so the final MCTP tree will be:Only BIC1 is assigned EID.
AssignEndpointautomatically assigns EIDs, and we confirmed journal that all four devices were assigned EID 9,resulting in the MCTP tree shown in
Since all devices have the same EID, BIC1 cannot differentiate the destination based on the EID when the BMC tries to send data to BIC2, CXL1, or CXL2.
Given this, we're seeking alternative solutions to accommodate our specific configuration.
Thanks a lot.
The text was updated successfully, but these errors were encountered: