All of lore.kernel.org
 help / color / mirror / Atom feed
* [IPMBD] ipmbSend handling
@ 2018-08-24  6:02 KFTING
  2018-08-24 16:07 ` Tanous, Ed
  0 siblings, 1 reply; 8+ messages in thread
From: KFTING @ 2018-08-24  6:02 UTC (permalink / raw)
  To: openbmc

[-- Attachment #1: Type: text/plain, Size: 2196 bytes --]

Hi:

I check the ipmbd implementation from
https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.openbmc-2Dproject.xyz_-23_c_openbmc_ipmbbridge_-2B_11130_&d=DwICAg&c=ue8mO8zgC4VZ4q_aNVKt8G9MC01UFDmisvMR1k-EoDM&r=kGibSCEQz-PilnW-r9KNT7_zWJXJNtnSK5aYZCe7SVs&m=9vYrt5dE5uTcGZ0xJvXwlc2qHu9SzkgJbpR7h9W0jXE&s=xLAMWHrLSU8GJiEb4ObBmfmlBhRwK26Z3t4-piFCe1c&e= and find out that the IPMB request or response messages are passed down to the I2C slave device in the ipmbSend function.

The master device node is /dev/i2c-0 and the slave device node is /sys/bus/i2c/devices/0-1010/slave-mqueue in the ipmbbridge implementation.

The direction is always from the master device to the slave device.

In normal IPMB usage case, an IPMB request is sent to the master device (say /dev/i2c-3) and then the master device sends that IPMB request to the client device attached to the master device's bus.

While an IPMB response returns from the client device, the client device uses an I2C master-write transfer to send the response back to the request originator, which is /dev/i2c-3, according to IPMB spec. So the request originator becomes an I2C slave at this moment.

It seems to me that ipmbSend behavior doesn't get aligned with the description of request/response protocol in IPMB spec.

I might misunderstand the ipmbSend behavior and any comment is welcome.

Thank you.

Regards,
Tyrone


===========================================================================================
The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.

[-- Attachment #2: Type: text/html, Size: 5829 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* RE: [IPMBD] ipmbSend handling
  2018-08-24  6:02 [IPMBD] ipmbSend handling KFTING
@ 2018-08-24 16:07 ` Tanous, Ed
  2018-08-24 19:08   ` Tanous, Ed
  2018-08-28  2:14   ` KFTING
  0 siblings, 2 replies; 8+ messages in thread
From: Tanous, Ed @ 2018-08-24 16:07 UTC (permalink / raw)
  To: KFTING, openbmc

> 
> The direction is always from the master device to the slave device.
> 
Not true in either the spec or the implementation.  The IPMB bridge was designed to operate two ways.  First, requests could be made from external entities, like an IPMB header on the board, or the Management Engine (On x86 platforms).  These requests first require the BMC to be a slave for the request, and a master for the response.  Second, the BMC could initiate a request (Probably to the management engine).  In that case, it would be an master for the request, then a slave for the response.  In theory, both scenarios are supported by the daemon, but only the first case might be enabled at this point.

> 
> It seems to me that ipmbSend behavior doesn't get aligned with the description of request/response protocol in IPMB spec.
> 

What do you refer to as ipmbSend here?

It would help a lot if you could add your comments to the code in the gerrit review.  It might help track down where you think the issues are.

-Ed

^ permalink raw reply	[flat|nested] 8+ messages in thread

* RE: [IPMBD] ipmbSend handling
  2018-08-24 16:07 ` Tanous, Ed
@ 2018-08-24 19:08   ` Tanous, Ed
  2018-08-28  2:14   ` KFTING
  1 sibling, 0 replies; 8+ messages in thread
From: Tanous, Ed @ 2018-08-24 19:08 UTC (permalink / raw)
  To: Tanous, Ed, KFTING, openbmc

> 
> It would help a lot if you could add your comments to the code in the gerrit
> review.  It might help track down where you think the issues are.
> 

	
I should also mention, the code posted in the review does work for communication with Management Engine, as well as with an Aardvark debugger connected to a header on the board.  We haven't yet tested with any other IPMB capable add in cards, although it's on our list.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* RE: [IPMBD] ipmbSend handling
  2018-08-24 16:07 ` Tanous, Ed
  2018-08-24 19:08   ` Tanous, Ed
@ 2018-08-28  2:14   ` KFTING
  1 sibling, 0 replies; 8+ messages in thread
From: KFTING @ 2018-08-28  2:14 UTC (permalink / raw)
  To: ed.tanous, openbmc

Hi Ed:

> Not true in either the spec or the implementation.

Thank you for your description of the ipmbbridge design.

Now I get a better picture of it.

> It would help a lot if you could add your comments to the code in the gerrit review.  It might help track down where you think the issues are.

Sure, I'll do that.

Regards,
Tyrone
-----Original Message-----
From: Tanous, Ed [mailto:ed.tanous@intel.com]
Sent: Saturday, August 25, 2018 12:08 AM
To: CS00 KFTing; openbmc@lists.ozlabs.org
Subject: RE: [IPMBD] ipmbSend handling

>
> The direction is always from the master device to the slave device.
>
Not true in either the spec or the implementation.  The IPMB bridge was designed to operate two ways.  First, requests could be made from external entities, like an IPMB header on the board, or the Management Engine (On x86 platforms).  These requests first require the BMC to be a slave for the request, and a master for the response.  Second, the BMC could initiate a request (Probably to the management engine).  In that case, it would be an master for the request, then a slave for the response.  In theory, both scenarios are supported by the daemon, but only the first case might be enabled at this point.

>
> It seems to me that ipmbSend behavior doesn't get aligned with the description of request/response protocol in IPMB spec.
>

What do you refer to as ipmbSend here?

It would help a lot if you could add your comments to the code in the gerrit review.  It might help track down where you think the issues are.

-Ed


===========================================================================================
The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* RE: [IPMBD] ipmbSend handling
  2018-08-28  8:39   ` Henbin Chang
@ 2018-08-28 14:21     ` Tanous, Ed
  0 siblings, 0 replies; 8+ messages in thread
From: Tanous, Ed @ 2018-08-28 14:21 UTC (permalink / raw)
  To: Henbin Chang; +Cc: OpenBMC Maillist

This is the snippet from my patch to my DTS file that enables the slave queue, along with multi-master on i2c0.

+&i2c0 {
+       multi-master = <1>;
+       status = "okay";
+
+       ipmb0@10 {
+               compatible = "slave-mqueue";
+               reg = <(0x10 | I2C_OWN_SLAVE_ADDRESS)>;
+               message-size = <256>;
+               queue-size = <32>;
+       };
+};

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [IPMBD] ipmbSend handling
  2018-08-28  6:12 ` Tanous, Ed
@ 2018-08-28  8:39   ` Henbin Chang
  2018-08-28 14:21     ` Tanous, Ed
  0 siblings, 1 reply; 8+ messages in thread
From: Henbin Chang @ 2018-08-28  8:39 UTC (permalink / raw)
  To: Tanous, Ed; +Cc: OpenBMC Maillist

[-- Attachment #1: Type: text/plain, Size: 2102 bytes --]

Thanks to Ed's response.
I could build the 'ipmbbridged' successfully.

I find the ipmbbridged can execute the below steps after rough review.

1. Wait for the incoming IPMB request
from "/sys/bus/i2c/devices/0-1010/slave-mqueue"
2. Decode IPMB request from above 1 into netFn, rsLun, rqSA,
seq, rqLun and cmd.
3. Send the 'ReceivedMessage' signal with netFn, rsLun, rqSA, seq, rqLun
 and cmd.
4. ipmbMessageSend is called after the 'ReceivedMessage' signal is received.
5. In ipmbMessageSend(), it encodes the IPMB packet using netFn, rsLun, rqSA,
seq, rqLun and cmd.
6. And then send IPMB packet into "/dev/i2c-0"

Some questions about the ipmbbridged  daemon
1. how should I have "/sys/bus/i2c/devices/0-1010/slave-mqueue" in my
openbmc?
2. It doesn't seem any implementation to receive the IPMB response from
"/dev/i2c-0", right?

Thanks.
BRs,
Henbin

Tanous, Ed <ed.tanous@intel.com> 於 2018年8月28日 週二 下午2:14寫道:

> This was a change in yocto made to the i2c-tools repo.  It formerly copied
> i2c-dev.h to i2c-dev-user.h to help with the duplication between the two
> headers.  In modern packages, smbus.h should be used, which is part of the
> refactor we’re doing that’s in progress.
>
>
>
> I will update the code review when it’s done, but it might take some time,
> as we’re tackling several other things at the same time.
>
>
>
> -Ed
>
>
>
> *From:* Henbin Chang [mailto:henbinchang@gmail.com]
> *Sent:* Monday, August 27, 2018 7:02 PM
> *To:* Tanous, Ed <ed.tanous@intel.com>; OpenBMC Maillist <
> openbmc@lists.ozlabs.org>
> *Subject:* [IPMBD] ipmbSend handling
>
>
>
> Hi Ed,
>
>
>
> I tried to build ipmbbridge but got the below error.
>
>
>
> Could you please share where I should get 'linux/i2c-dev-user.h'?
>
>
>
> |....
>
> | ../ipmbbridged.cpp:24:10: fatal error: linux/i2c-dev-user.h: No such
> file or directory
>
> |  #include <linux/i2c-dev-user.h>
>
> |           ^~~~~~~~~~~~~~~~~~~~~~
>
> | compilation terminated.
>
> | ...
>
>
>
> Thanks.
>
> BRs,
>
> Henbin
>

[-- Attachment #2: Type: text/html, Size: 8280 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* RE: [IPMBD] ipmbSend handling
  2018-08-28  2:01 Henbin Chang
@ 2018-08-28  6:12 ` Tanous, Ed
  2018-08-28  8:39   ` Henbin Chang
  0 siblings, 1 reply; 8+ messages in thread
From: Tanous, Ed @ 2018-08-28  6:12 UTC (permalink / raw)
  To: Henbin Chang, OpenBMC Maillist

[-- Attachment #1: Type: text/plain, Size: 991 bytes --]

This was a change in yocto made to the i2c-tools repo.  It formerly copied i2c-dev.h to i2c-dev-user.h to help with the duplication between the two headers.  In modern packages, smbus.h should be used, which is part of the refactor we’re doing that’s in progress.

I will update the code review when it’s done, but it might take some time, as we’re tackling several other things at the same time.

-Ed

From: Henbin Chang [mailto:henbinchang@gmail.com]
Sent: Monday, August 27, 2018 7:02 PM
To: Tanous, Ed <ed.tanous@intel.com>; OpenBMC Maillist <openbmc@lists.ozlabs.org>
Subject: [IPMBD] ipmbSend handling

Hi Ed,

I tried to build ipmbbridge but got the below error.

Could you please share where I should get 'linux/i2c-dev-user.h'?

|....
| ../ipmbbridged.cpp:24:10: fatal error: linux/i2c-dev-user.h: No such file or directory
|  #include <linux/i2c-dev-user.h>
|           ^~~~~~~~~~~~~~~~~~~~~~
| compilation terminated.
| ...

Thanks.
BRs,
Henbin

[-- Attachment #2: Type: text/html, Size: 4867 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [IPMBD] ipmbSend handling
@ 2018-08-28  2:01 Henbin Chang
  2018-08-28  6:12 ` Tanous, Ed
  0 siblings, 1 reply; 8+ messages in thread
From: Henbin Chang @ 2018-08-28  2:01 UTC (permalink / raw)
  To: Tanous, Ed, OpenBMC Maillist

[-- Attachment #1: Type: text/plain, Size: 347 bytes --]

Hi Ed,

I tried to build ipmbbridge but got the below error.

Could you please share where I should get 'linux/i2c-dev-user.h'?

|....
| ../ipmbbridged.cpp:24:10: fatal error: linux/i2c-dev-user.h: No such file
or directory
|  #include <linux/i2c-dev-user.h>
|           ^~~~~~~~~~~~~~~~~~~~~~
| compilation terminated.
| ...

Thanks.
BRs,
Henbin

[-- Attachment #2: Type: text/html, Size: 567 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2018-08-28 14:21 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-08-24  6:02 [IPMBD] ipmbSend handling KFTING
2018-08-24 16:07 ` Tanous, Ed
2018-08-24 19:08   ` Tanous, Ed
2018-08-28  2:14   ` KFTING
2018-08-28  2:01 Henbin Chang
2018-08-28  6:12 ` Tanous, Ed
2018-08-28  8:39   ` Henbin Chang
2018-08-28 14:21     ` Tanous, Ed

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.