Bummer, I just uploaded the new version of the drivers. I'll include
the patch I did and I'm copying the mailing list so everyone knows :).
-corey
David Barksdale wrote:
After talking to a guy who knows what the heck our IPMC does I learned
the following.
When sending messages to the IPMC from the LMP or COM-E:
* Source lun does not matter.
* Source address shall be 0x01 or real IPMB address.
* Destination address shall be 0x01 lun 0.
When sending messages to other blades:
* Source lun shall be 1 for LMP, 0 for COM-E
* Source address shall be the real IPMB address.
* Destination address shall be real IPMB address.
Sending from 0x00 is an error. Which means everything should work if you
patch ipmi_serial_radisys_ascii.c to use 0x01. Then I can call
ipmi_set_my_LUN to fix the LMP/COM-E difference from userland after the
interface is registered. The codec could do this also if it had a
callback for ipmi_serial_start_processing.
I apologise for the format of this patch, it's the best ClearCase can
do.
300c300
< 0x00, /* source addr */
---
0x01, /* source addr */
340c340
< data->smi_i2c_addr = 0; /* Initial setting should work ok. */
---
data->smi_i2c_addr = 1; /* Initial setting should work ok. */
-----Original Message-----
From: Corey Minyard [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 07, 2008 9:12 PM
To: David Barksdale
Subject: Re: RadiSys ASCII serial driver
David Barksdale wrote:
Hi Cory,
Do you see any problem with adding a codec option to the RadiSys
serial driver module to set the source address and source lun on the
initial "getipmbaddr" message? Currently they are hard coded to 0. The
driver is not loading on our Com-E module because the module is at
address 0x01 lun 0. Some of our other modules use address 0x01 and lun
1. The lun needs to stay set after the real source address is learned.
I'm not an IPMI expert so I don't know if this is a sane request, all
I'm trying to do is get more of our products to use your driver.
Thanks.
Well, it's not a huge problem, but can the firmware be fixed to be
consistent with everything else? It seems more reasonable to make it
consistent, as then it is more likely to work with other OSes besides
linux. lun 1 is actually wrong, IMHO, that's a LUN with a special
purpose in IPMI.
But if the firmware cannot be reasonably fixed, then a patch is fine.
-corey
According to Radisys, the source address should always be 1 for
their boards. So, fix it.
Signed-off-by: Corey Minyard <[EMAIL PROTECTED]>
Cc: David Barksdale <[EMAIL PROTECTED]>
---
Index: linux-2.6.24/drivers/char/ipmi/ipmi_serial_radisys_ascii.c
===================================================================
--- linux-2.6.24.orig/drivers/char/ipmi/ipmi_serial_radisys_ascii.c
+++ linux-2.6.24/drivers/char/ipmi/ipmi_serial_radisys_ascii.c
@@ -310,7 +310,7 @@ static void ra_setup_termios(struct kter
static unsigned char get_ipmbaddr_msg[] = { 0x01,
RA_CONTROLLER_OEM_NETFN << 2,
0x07, /* checksum1 */
- 0x00, /* source addr */
+ 0x01, /* source addr */
0x00, /* seq num/rsLUN */
RA_GET_IPMB_ADDR_CMD,
0xee /* checksum2 */
@@ -364,7 +364,7 @@ static int ra_init(struct ipmi_serial_co
spin_lock_init(&data->lock);
data->info = info;
data->bmc_i2c_addr = 1; /* Initial setting should work ok. */
- data->smi_i2c_addr = 0; /* Initial setting should work ok. */
+ data->smi_i2c_addr = 1; /* Initial setting should work ok. */
data->handshake_time = RA_HANDSHAKE_TIME;
data->handshake_retries_left = RA_HANDSHAKE_RETRIES;
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Openipmi-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openipmi-developer
