Hi,
Are there plans to implement the ability to independently control all 4 LEDs on the front panel through the CERN-IPMC? I would like the ability to create a test program for the LED lines to prove they are functional on a hardware level.
Kind Regards,
Mars Lyukova
Hello,
I have the same requirement please ?
Cheers,
Hello,
Your request is not clear to me.
Cheers,
Markus
Hello,
I was not realizing that you are referring to a ticket of 2021. I may have some code but I need a bit of time to find it.
Cheers,
Markus
Hello Sylvain,
the LEDs can be written from the user code (e.g. main loop or timer callback, sensor driver, OEM command), from the power sequence or from the shelf manager (although I’m not sure how useful this is). Below is some example code on how to switch on and off an LED, they are treated like any GPIO signal:
// FRU LED signals
signal_t fru_led_red_sig = CFG_FRU_LED_1_SIGNAL;
// Switch LED on
signal_activate(&fru_led_red_sig);
// Switch LED off
signal_deactivate(&fru_led_red_sig);
The following three ATCA LEDs are defined:
CFG_FRU_LED_1_SIGNAL
CFG_FRU_LED_2_SIGNAL
CFG_FRU_LED_3_SIGNAL
In the power-on/off sequence you can control the LEDs using the following entries:
<step>PSQ_ENABLE_SIGNAL(CFG_FRU_LED_2_SIGNAL)</step> <!-- Switch on the green FRU LED -->
<step>PSQ_DISABLE_SIGNAL(CFG_FRU_LED_2_SIGNAL)</step> <!-- Switch off the green FRU LED -->
Let us know if you need additional information.
cheers,
Stefan
Hi Stefan,
We use LEDs in the power-on/off sequence (e.g. CFG_FRU_LED_2_SIGNAL and CFG_FRU_LED_1_SIGNAL). I have noticed that when I use the ‘Get FRU LED State’ command to query the state of FRU_LED2, the local control LED state does not reflect reality. Note that the ‘Get FRU LED State’ command works fine when we query the state of BLUE_LED.
I have also noticed that FRU_LED3 is not described in the FRU Multi Record Area. Would it be possible to add it (e.g. in config.xml) ?
Cheers,
Fatih
Hello Fatih,
I will be trying to help you but your problem is not yet entirely clear to me.
Here is how my reference IPMC responds to FRU LED commands:
ipmc@ipmc-tester14:~$ ipmitool -I lan -H 192.168.1.34 -U “” -P “” picmg led cap 0 1
LED Color Capabilities: RED,
Default LED Color in
LOCAL control: RED
OVERRIDE state: RED
ipmc@ipmc-tester14:~$ ipmitool -I lan -H 192.168.1.34 -U “” -P “” picmg led cap 0 2
LED Color Capabilities: GREEN,
Default LED Color in
LOCAL control: GREEN
OVERRIDE state: GREEN
ipmc@ipmc-tester14:~$ ipmitool -I lan -H 192.168.1.34 -U “” -P “” picmg led cap 0 3
LED Color Capabilities: ORANGE,
Default LED Color in
LOCAL control: ORANGE
OVERRIDE state: ORANGE
Can you run these commands on your system and tell me what you get?
Cheers,
Markus
Hi Markus,
Thank you for your help.
In fact, the command regarding LED color capabilities (i.e. picmg led cap ...) works fine, and I get the same results. The issue concerns the LED state, when the board is in M4, the green LED (i.e. FRU_LED2) on the front panel is ON. Logically, I should have the “local control function” ON, but this is not the case (see below):
$ ipmitool -I lan -H 192.168.1.174 -U "" -P "" sensor get "Hot Swap"
Locating sensor record...
Sensor ID : Hot Swap (0x0)
Entity ID : 160.96
Sensor Type (Discrete): FRU Hot Swap
States Asserted : FRU Hot Swap
[Transition to M4]
$ ipmitool -I lan -H 192.168.1.174 -U "" -P "" picmg led get 0 2
LED states: 1 [LOCAL CONTROL]
Local Control function: 0 [OFF]
Local Control On-Duration: 0
Local Control Color: 3 [GREEN]
For reference, Here is the state of the blue LED when the board is in M1.
$ ipmitool -I lan -H 192.168.1.174 -U "" -P "" sensor get "Hot Swap"
Locating sensor record...
Sensor ID : Hot Swap (0x0)
Entity ID : 160.96
Sensor Type (Discrete): FRU Hot Swap
States Asserted : FRU Hot Swap
[Transition to M1]
ipmitool -I lan -H 192.168.1.174 -U "" -P "" picmg led get 0 0
LED states: 1 [LOCAL CONTROL]
Local Control function: ff [ON]
Local Control On-Duration: 0
Local Control Color: 1 [BLUE]
Cheers,
Fatih
Hello Fatih,
At https://gitlab.cern.ch/ep-ese-be-xtca/ipmc-project/-/blob/master/ipmc-user/user_mainfile.c?ref_type=heads you can see some (inactive) code in lines 91-122 that can be used to control the FRU LEDs. Stefan has pointed out that the functions signal_activate() / signal_deactivate() may bee too low level. They are apparently manipulating the states of the signals that drive the LEDs without notifying the higher level S/W about the state change. I will ask PigeonPoint if there are higher level functions that should be used.
Cheers,
Markus
Hi Markus,
Thanks for this clarification.
So, for our use case, I deduce that the PSQ_ENABLE_SIGNAL(…) and PSQ_DISABLE_SIGNAL(…) steps use the low-level functions signal_activate(...) and signal_deactivate(...) respectively.
Regarding the second point, about the PICMG LED description record (i.e. PICMG record ID 0x2F in the FRU Multi Record Area), would it be possible to add/change the legend, symbol and description of a user LED (e.g. orange LED ID 3) in the config.xml file?
# clia fruinfo -v board 9
Pigeon Point Shelf Manager Command Line Interpreter
92: FRU # 0, FRU Info
Common Header: Format Version = 1
Board Info Area:
Version = 1
Language Code = 25
Mfg Date/Time = Sep 11 00:00:00 2024 (15092640 minutes since 1996)
Board Manufacturer = LAPP
Board Product Name = LATS
Board Serial Number = 00001
Board Part Number = P000000000
FRU Programmer File ID = fru-info.inf
Custom Board Info =
Product Info Area:
Version = 1
Language Code = 25
Manufacturer Name = LAPP
Product Name = LATS
Product Part / Model# = PN00001
Product Version = v.2.0
Product Serial Number = 0000001
Asset Tag =
FRU Programmer File ID = fru-info.inf
Custom Product Info =
Multi Record Area:
PICMG LED Description Record (ID=0x2f)
Version = 0
LED Descriptor Count = 0x3
LED ID 0:
Legend:
Symbol:
Description: The BLUE LED
LED ID 1:
Legend: FRU_LED1
Symbol:
Description: Out-of-service LED
LED ID 2:
Legend: FRU_LED2
Symbol:
Description: In-service LED
AMC Carrier Information Table Record (ID=0x1a)
Version = 0
Site Count = 0
AMC Carrier Activation and Current Management Record (ID=0x17)
Version = 0
Maximum Internal Current Draw = 3.0 Amps at 12V Payload
Allowance for Module Activation Readiness = 5 seconds
Module Activation and Power Descriptor count = 0
Cheers,
Fatih
Hello Fatih,
In your last post you asked if the legend of the LEDs (e.g. “Out-of-service LED”) can be changed.
These legends are currently defined in a file that a user cannot access (unless they have signed a NDA). Do you want to define custom strings or would a more generic string (e.g. “FRU LED 1”) work for you as well?
The FRU LED3 has been added to the code.
As far as the LED control is concerned, I have figured out a few things:
In ipmc-user/user_mainfile.c · master · ep-ese-be-xtca / ipmc-project · GitLab the lines 102 – 121 show how Julian proposed to control the LEDs from the user code. According to Pigeon Point we should do it this way:
#include <mainfru.h>
#include <fru.h>
#include <fru_led.h>
(…)
MAIN_LOOP_CALLBACK(usermain_mainloop)
{
static int waitabit = 0;
static char led_toggle = 0;waitabit++;
if (waitabit == 1000)
{
if (led_toggle == 0)
{
fru_led_set_local(&mainfru, 1, 1, 0, LED_COLOR_RED, 0);
debug_printf(“MAIN_LOOP_CALLBACK: FRU_LED 1 ON\n\r”);
led_toggle = 1;
}
else
{
fru_led_set_local(&mainfru, 1, 0, 1, LED_COLOR_RED, 0);
debug_printf(“MAIN_LOOP_CALLBACK: FRU_LED 1 OFF\n\r”);
led_toggle = 0;
}
waitabit = 0;
}
}
Here is a definition of the parameters of the function:
void fru_led_set_local(fru_desc_t *fru, unsigned char lednum, unsigned char on, unsigned char off, unsigned char color, unsigned char off_first)
*fru: This is is a pointer to the fru_desc structure. Use “&mainfru” (from the include file “mainfru.h”)
lednum: 0 = HS LED; 1,2,3 = FRU LEDs
on/off: 1,0: LED ON, 0,1: LED OFF. More generally, these parameters define the timing for blinking the LED, they can be in range 0 – 255.
color: My understanding is that this parameter only matters for multi-color LEDs. FRU_LED1, for example, can be red or green.
off_first: is a parameter defining that the “off” timing should be applied before the “on” timing. Set it to 0 for your case.
As you want to use the LEDs for the power sequencing, we have also looked into this issue.
Stefan pointed out that it is possible (via the PSQ_CALL_FUNC macro) to inject user code into the power sequencing.
In my “config.xml” file I have:
<PowerONSeq> <step>PSQ_ENABLE_SIGNAL(CFG_PAYLOAD_DCDC_EN_SIGNAL)</step> <step>PSQ_CALL_FUNC(hello_psq_function)</step> <step>PSQ_END</step> </PowerONSeq>
To the file “ipmc-user/user_mainfile.c” I have added:
unsigned int hello_psq_function(void)
{
debug_printf(“User function hello_psq_function called \n\r”);
}
When I install this F/W on the IPMC and look at the UART debug port, I can see:
<>: FRU 0 state: M1->M2, cause = 2
MAIN_LOOP_CALLBACK: FRU_LED 1 ON
<>: FRU 0 state: M2->M3, cause = 1
<>: CORE_10100: Link is UP, 100Mb FD
User function hello_psq_function called
<>: FRU 0 state: M3->M4, cause = 0
With these tricks you should be able to use the FRU LEDs in the power monitoring. We are, however, wondering if using the LEDs to track the power sequencing is the best strategy. Would it, if it was possible, be useful to you if e.g. event messages could be sent from the power sequencing macros to have information about problems with the powering of a card logged in the SEL? We can ask PigeonPoint for advise on how to do that.
Cheers,
Markus
Hi Markus,
Thanks for the tricks.
In reality, we don’t use LEDs to track the power sequencing, but rather in the case of a state control, it has to match the reality (i.e. what the operator sees).
Cheers,
Fatih