PdcChassis

From Linux PARISC Wiki
(Difference between revisions)
Jump to: navigation, search
m (PDC CHASSIS)
m
 
(2 intermediate revisions by one user not shown)
Line 1: Line 1:
 
= PDC CHASSIS =
 
= PDC CHASSIS =
  
We are dealing with some kind of PA-RISC specific firmware: the ProcessorDependentCode (PDC).
+
We are dealing with some kind of PA-RISC specific firmware: the [[ProcessorDependentCode]] (PDC).
  
 
Files:
 
Files:
* include/asm-parisc/pdc_chassis.h
+
* <tt>include/asm-parisc/pdc_chassis.h</tt>
* arch/parisc/kernel/pdc_chassis.c
+
* <tt>arch/parisc/kernel/pdc_chassis.c</tt>
* arch/parisc/kernel/firmware.c
+
* <tt>arch/parisc/kernel/firmware.c</tt>
  
 
== What is PDC CHASSIS ==
 
== What is PDC CHASSIS ==
  
The `CHASSIS` PDC procedure aims at two things:
+
The <tt>CHASSIS</tt> PDC procedure aims at two things:
  
 
# Informing the hardware of the current state of the operating system.
 
# Informing the hardware of the current state of the operating system.
Line 17: Line 17:
 
The first part consists in sending the PDC some messages reflecting the current state of the system. Messages can be one of ''Off'', ''Fault'', ''Test'', ''Initialize'', ''Shutdown'', ''Warning'', ''Run'' or ''All On''. The second part allows the retrieval of chassis status. It's possible to get data about failing PSU, Fan or other (encoded in a HVERSION-dependent way), and to know whether NVRAM battery is getting low, and if ''Temp-Low'' and ''Temp-Mid'' temperature threshold have been exceeded.
 
The first part consists in sending the PDC some messages reflecting the current state of the system. Messages can be one of ''Off'', ''Fault'', ''Test'', ''Initialize'', ''Shutdown'', ''Warning'', ''Run'' or ''All On''. The second part allows the retrieval of chassis status. It's possible to get data about failing PSU, Fan or other (encoded in a HVERSION-dependent way), and to know whether NVRAM battery is getting low, and if ''Temp-Low'' and ''Temp-Mid'' temperature threshold have been exceeded.
  
On `PAT PDC` boxes, featuring a [[GuardianServiceProcessor]], it is possible to send messages to the VirtualFrontPanel. This code deals with that too, see PdcChassisLog.
+
On <tt>PAT PDC</tt> boxes, featuring a [[GuardianServiceProcessor]], it is possible to send messages to the [[VirtualFrontPanel]]. This code deals with that too, see [[PdcChassisLog]].
  
 
== What are we trying to do? ==
 
== What are we trying to do? ==
Line 23: Line 23:
 
The code takes care of reflecting the current state of the system (and its sudden changes) by sending messages to the PDC. The result varies from some LED state change (eg on E-class), to LCD messages ('''INI''' during bootup, '''RUN''' when booted and running, '''SHU''' after shutdown, or '''FLT''' upon kernel panic, etc) on systems with a LCD display.
 
The code takes care of reflecting the current state of the system (and its sudden changes) by sending messages to the PDC. The result varies from some LED state change (eg on E-class), to LCD messages ('''INI''' during bootup, '''RUN''' when booted and running, '''SHU''' after shutdown, or '''FLT''' upon kernel panic, etc) on systems with a LCD display.
  
It also adds a `proc` entry named `chassis`, giving some info about the chassis status (essentially battery and temperature threshold, and a message with an hex string if there is a redundant chassis component failing). Note that the states recorded by PDC are (seemingly) only cleared upon reboot. That is to say that if you have eg an overheat, even if the condition goes back to normal, it won't be noticeable until you reboot the machine. There's a persistence of warnings.
+
It also adds a <tt>proc</tt> entry named <tt>chassis</tt>, giving some info about the chassis status (essentially battery and temperature threshold, and a message with an hex string if there is a redundant chassis component failing). Note that the states recorded by PDC are (seemingly) only cleared upon reboot. That is to say that if you have eg an overheat, even if the condition goes back to normal, it won't be noticeable until you reboot the machine. There's a persistence of warnings.
  
 
== How do we do it? ==
 
== How do we do it? ==
  
We had to implement the missing abstraction logic in `firmware.c` to access Chassis. We had to add the required interfaces to PDC_CHASSIS calls:
+
We had to implement the missing abstraction logic in <tt>firmware.c</tt> to access Chassis. We had to add the required interfaces to <tt>PDC_CHASSIS</tt> calls:
  
 
{| class="wikitable"
 
{| class="wikitable"
 
|-
 
|-
| '''Interfaces (`firmware.c`)'''
+
|+ '''Interfaces (<tt>firmware.c</tt>)'''
| '''Function'''
+
! Function
 +
! Role
 
|-
 
|-
| int pdc_chassis_disp(unsigned long disp)
+
| <code>int pdc_chassis_disp(unsigned long disp)</code>
| This call sends the state expressed by `disp` PDC CHASSIS
+
| This call sends the state expressed by <tt>disp</tt> PDC CHASSIS
 
|-
 
|-
| int pdc_chassis_warn(unsigned long *warn)
+
| <code>int pdc_chassis_warn(unsigned long *warn)</code>
| This call retrieves the chassis status in `*warn`
+
| This call retrieves the chassis status in <tt>*warn</tt>
 
|}
 
|}
  
The `PAT_PDC` implementation is discussed in [[PdcChassisLog]].
+
The <tt>PAT_PDC</tt> implementation is discussed in [[PdcChassisLog]].
  
 
=== Linking kernel events to messages ===
 
=== Linking kernel events to messages ===
Line 60: Line 61:
 
  </nowiki>
 
  </nowiki>
  
We have added panic and reboot notifiers in `pdc_chassis.c`; and we have added a few hooks in the places where an important kernel state change -- that will affect the whole system -- might happen. Through these, we are able to monitor reliably the state of the system and reflect it accurately via PDC or Chassis Log.
+
We have added panic and reboot notifiers in <tt>pdc_chassis.c</tt>; and we have added a few hooks in the places where an important kernel state change -- that will affect the whole system -- might happen. Through these, we are able to monitor reliably the state of the system and reflect it accurately via PDC or Chassis Log.
  
 
== Kernel parameter ==
 
== Kernel parameter ==
  
Last but not least, if enabled at build time in the kernel, this "driver" -- so to speak -- can be disabled at boot time by passing `pdcchassis=0` on the kernel command line. This is especially useful on [[GuardianServiceProcessor -featuring]] machines, when debugging the kernel during the boot sequence, as it avoids the console to be clobbered with informative messages from the VirtualFrontPanel.
+
Last but not least, if enabled at build time in the kernel, this "driver" -- so to speak -- can be disabled at boot time by passing <tt>pdcchassis=0</tt> on the kernel command line. This is especially useful on [[GuardianServiceProcessor]]-featuring machines, when debugging the kernel during the boot sequence, as it avoids the console to be clobbered with informative messages from the [[VirtualFrontPanel]].

Latest revision as of 21:39, 29 May 2014

Contents

[edit] PDC CHASSIS

We are dealing with some kind of PA-RISC specific firmware: the ProcessorDependentCode (PDC).

Files:

  • include/asm-parisc/pdc_chassis.h
  • arch/parisc/kernel/pdc_chassis.c
  • arch/parisc/kernel/firmware.c

[edit] What is PDC CHASSIS

The CHASSIS PDC procedure aims at two things:

  1. Informing the hardware of the current state of the operating system.
  2. Informing the OS of the current state of the hardware.

The first part consists in sending the PDC some messages reflecting the current state of the system. Messages can be one of Off, Fault, Test, Initialize, Shutdown, Warning, Run or All On. The second part allows the retrieval of chassis status. It's possible to get data about failing PSU, Fan or other (encoded in a HVERSION-dependent way), and to know whether NVRAM battery is getting low, and if Temp-Low and Temp-Mid temperature threshold have been exceeded.

On PAT PDC boxes, featuring a GuardianServiceProcessor, it is possible to send messages to the VirtualFrontPanel. This code deals with that too, see PdcChassisLog.

[edit] What are we trying to do?

The code takes care of reflecting the current state of the system (and its sudden changes) by sending messages to the PDC. The result varies from some LED state change (eg on E-class), to LCD messages (INI during bootup, RUN when booted and running, SHU after shutdown, or FLT upon kernel panic, etc) on systems with a LCD display.

It also adds a proc entry named chassis, giving some info about the chassis status (essentially battery and temperature threshold, and a message with an hex string if there is a redundant chassis component failing). Note that the states recorded by PDC are (seemingly) only cleared upon reboot. That is to say that if you have eg an overheat, even if the condition goes back to normal, it won't be noticeable until you reboot the machine. There's a persistence of warnings.

[edit] How do we do it?

We had to implement the missing abstraction logic in firmware.c to access Chassis. We had to add the required interfaces to PDC_CHASSIS calls:

Interfaces (firmware.c)
Function Role
int pdc_chassis_disp(unsigned long disp) This call sends the state expressed by disp PDC CHASSIS
int pdc_chassis_warn(unsigned long *warn) This call retrieves the chassis status in *warn

The PAT_PDC implementation is discussed in PdcChassisLog.

[edit] Linking kernel events to messages

According to what we said, we have prepared a set of preformatted messages that we will use to reflect the current state of the system, through hooks we have placed in various key points in the kernel:

arch/parisc/kernel/pdc_chassis.c:95:    pdc_chassis_send_status(PDC_CHASSIS_DIRECT_PANIC);
arch/parisc/kernel/pdc_chassis.c:115:   pdc_chassis_send_status(PDC_CHASSIS_DIRECT_SHUTDOWN);
arch/parisc/kernel/process.c:140:       pdc_chassis_send_status(PDC_CHASSIS_DIRECT_SHUTDOWN);
arch/parisc/kernel/process.c:181:       pdc_chassis_send_status(PDC_CHASSIS_DIRECT_SHUTDOWN);
arch/parisc/kernel/setup.c:304:         pdc_chassis_send_status(PDC_CHASSIS_DIRECT_BSTART);
arch/parisc/kernel/traps.c:498:         pdc_chassis_send_status(PDC_CHASSIS_DIRECT_HPMC);
arch/parisc/kernel/traps.c:519:         pdc_chassis_send_status(PDC_CHASSIS_DIRECT_LPMC);
arch/parisc/kernel/traps.c:728:         pdc_chassis_send_status(PDC_CHASSIS_DIRECT_PANIC);
arch/parisc/kernel/traps.c:761:         pdc_chassis_send_status(PDC_CHASSIS_DIRECT_PANIC);
arch/parisc/mm/init.c:410:              pdc_chassis_send_status(PDC_CHASSIS_DIRECT_BCOMPLETE);
 

We have added panic and reboot notifiers in pdc_chassis.c; and we have added a few hooks in the places where an important kernel state change -- that will affect the whole system -- might happen. Through these, we are able to monitor reliably the state of the system and reflect it accurately via PDC or Chassis Log.

[edit] Kernel parameter

Last but not least, if enabled at build time in the kernel, this "driver" -- so to speak -- can be disabled at boot time by passing pdcchassis=0 on the kernel command line. This is especially useful on GuardianServiceProcessor-featuring machines, when debugging the kernel during the boot sequence, as it avoids the console to be clobbered with informative messages from the VirtualFrontPanel.

Personal tools