Apple/IBM/Motorola - CHRP BoardCommon Hardware Reference Platform Architecture Version 1.0
Change Notice

Table of Contents

, Apple/IBM/Motorola - CHRP BoardThis paper presents a chronological list of all changes approved for the published version of the PowerPC Microprocessor Common Hardware Reference Platform: A System Architecture (CHRP). These changes are approved by the CHRP Board. These changes will be incorporated into the next version of the CHRP document at the next printing.

Editorial Comments June 6, 1996

The following editorial comments have been received through June 6, 1996.

"The description column ... Two documents are referenced extensively using an abbreviation in this description column. The abbreviations are as follows:

[20] refers to the PowerPC Microprocessor Common Hardware Reference Platform: I/O Device Reference. Use this document for additional information on the annotated specifications.
[23] refers to the Macintosh Technology in the Common Hardware Reference Platform. Use this document for specific physical, timing, and electrical requirements of the annotated specifications."
"Software Implementation Note: When in the discontiguous I/O mode software should not put out an operation to Peripheral I/O Space which crosses a 32-byte boundary. Results from such operations are undefined."

"Platforms must implement ... is sufficient for a system with a single operating system installed.

a. Platforms must provide an additional 1 KB for each installed operating system beyond the first."
"OS/2
International Business Machines Corporation"

Change Method of 64-bit RTAS Instantiate

This Architecture Change Request (ACR00003) was approved by the CHRP Board on June 6, 1996.

Issue

CHRP currently requires that instantiate-rtas be called in the mode (32 bit or 64 bit) in which the client program wishes to call RTAS. This requires that Open Firmware be capable of being called in both of these modes since instantiate-rtas is an Open Firmware method.

This approach added the expense of developing and testing Open Firmware in both 32 bit mode and 64 bit mode and the effort of testing FCODE developed for 32 bit systems in a system executing in 64 bit mode.

Changes

"RTAS must be called with the SF MSR bit set to match the mode used to instantiate RTAS (0 for instantiate-rtas or 1 for instantiate-rtas-64) and the LE bit set to the same value that was in effect at the time that RTAS was instantiated."

following locations:

"If the system is a 32 bit system, or if RTAS was instantiated by instantiate-rtas, then all cells in the RTAS argument buffer must be 32-bit sign extended values that are aligned to 4 byte boundaries."

"If the system is a 64 bit system and if RTAS was instantiated by instantiate-rtas-64, then all cells in the RTAS argument buffer must be 64-bit sign extended values that are aligned to 8 byte boundaries."

Require both SCC and 16550

ACR00004 was approved by the CHRP Board on June 6, 1996.

Issue

Even though Mac OS supports both SCC and 16550, there may not be drivers for all devices on either. Also some applications may not support both.

Changes

Power_on_mask Definition

ACR00005 was approved by the CHRP Board on June 6, 1996.

Issue

The Power-off RTAS function is intended for platforms which may or may not be power management capable. In support of platforms which are not there needs to be a means for the platform to inform the OS which power on triggers it supports. A power management capable platform uses the power-management-events node of the device tree to inform the OS which of the architecturally defined power management event types it supports. The device tree of a non power management capable platform would not contain this node.

There needs to be an independent definition of power on triggers and a corresponding mechanism used to inform the OS as to support for a given platform.

Changes

"For the Power Management option: The Resume_mask of the suspend RTAS call and the Wakeup_mask of the hibernate RTAS call must be defined by the 64 bit quantity generated by ... specified in Table 62 on page199."

"The Power_on_mask of the power-off RTAS call must be defined as specified in Table <62b>."

Author Note: The contents of table 62b were changed by ACR00024. Please refer to this change.

"If Software controlled ... implementations, must be a bit mask of power on triggers, refer to 11-3b. If a ..."

No Audio Programming Model

ACR00007 was approved by the CHRP Board on June 6, 1996.

Issue

The CHRP I/O Device Reference specification does not contain a programming model for the audio subsystem.

Change

Clarify RTAS private data area usage

This Document Error Report (DER00002) was approved by the CHRP Board July 8, 96.

Issue

The RTAS sections on resource allocation and use (7.2.4) and RTAS instantiation (7.2.5) refer to the RTAS private data area in different ways, sometimes causing confusion. Also, handling the case when rtas-size is zero is unclear.

Change

"RTAS is instantiated by an explicit client interface service call into Open Firmware. The Open Firmware Device Tree contains a property (rtas-size, under the rtas node) which defines how much real memory RTAS requires for its private data area. The operating system allocates rtas-size bytes of real memory, and then invokes the instantiate-rtas method of the RTAS node, passing the real address of the private data area (or zero, if rtas-size is zero) as the rtas-base-address input argument. Firmware binds RTAS to that address, binds the addresses of devices that RTAS uses, performs any RTAS initialization, and returns the address of the rtas-call function that is appropriate for the current machine state."

RTAS Call to Update Flash

ACR00001 and ACR00019 were approved by the CHRP Board on July 26, 1996.

Issue

Customers have asked for the ability to perform system administration operations remotely. Flash update, viewed as a system administration function, fits in this category.

Requiring the customer to use diskettes for updating flash code can be very cumbersome, especially in large installations and in configurations involving parallel systems.

A single way to update flash makes it possible for all OS's to have the capability to update the flash on any vendor's platform with one implementation.

Change

7.3.9.2 Update-flash

The update-flash and update-flash-and-reboot functions are described in this section. They are essentially the same, except that the update-flash-and -reboot will both update the flash and call for a reboot. It does not return to the operating system if successful.

Requirements:

7-130+1. The RTAS update-flash and update-flash-and-reboot calls must be implemented using the argument call buffer defined by Table 40+1 on page ???. 

Table 40+1 update-flash and update-flash-and-reboot Argument Call Buffer 
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Parameter Type                                                                                            Name        Value                                                      
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
In                                                                                                        Token       Token for update-flash or for update-flash-and-reboot      
                                                                                                          Number In   1                                                          
                                                                                                          puts                                                                   
                                                                                                          Number Out  1                                                          
                                                                                                          puts                                                                   
                                                                                                          Block_list  A real pointer to a block list                             
Out                                                                                                       Status      0 Success (update-flash-and-reboot does not return on suc  
                                                                                                                      cess) 

                                                    
                                                                                                                      -1 Hardware cannot be updated

                             
                                                                                                                      -2 Image unacceptable to update program

                   
                                                                                                                      -3 programming failed when partially complete, and the     
                                                                                                                      flash is now corrupted -- reboot may fail                  
                                                                                                                                                                                 
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
The -3 return is to cover the case where the update failed before the image was fully updated.  In this                                                                          
case, the OS has the responsibility for reporting the failure.                                                                                                                   
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
7-130+2. The block_list must start with a list length in bytes and must have pairs of real address and length of memory blocks, as shown in Table 40+2 on page ???.
7-130+3. The block list must be a sequence of cells as defined in requirements 7-34 and 7-35.
7-130+4. A memory block included in the block_list must only include System Memory outside that reserved for firmware (both the RTAS data area and Open Firmware's memory defined by real-base and real-size).
7-130+5. A memory block included in the block_list must only include System Memory below 4 GB.
7-130+6. A memory block included in the block_list must be aligned on a 4 KB boundary.
7-130+7. A memory block included in the block_list must not cross a 256 MB boundary.
Table 40+2 Format of Block List 
-----------------------------
Length of block_list in bytes  
Address of memory area 1       
Length of memory area 1        
...                            
Address of memory area n       
Length of memory area n        
                               
-----------------------------
7-130+8. The update-flash-and-reboot call must test the image to make sure it has the right format and is not damaged, update the flash from the block list and then perform a system reset and reboot, as for the system-reboot call.
7-130+9. The update-flash call must test the image to make sure it has the right format and is not damaged, update the flash from the block_list and then return to the OS.
Hardware and Software Implementation Note: Platform vendors should embed vendor-specific information in their flash images to identify the firmware unambiguously and to ensure that the firmware will operate correctly on the platform. Such information might include platform board model and revision numbers covered by the firmware, vendor name, and firmware revision number used for external display. This information should include a CRC or other check which ensures the integrity of the data. The format of this information is left to the platform vendor.

Software Implementation Note: The execution time for these calls will be in the order of seconds, rather than "a few tens of microseconds" as noted on page 97.

Software Implementation Note: These RTAS flash update programs should display progress, completion, and error information via the display-character mechanism while the flash update is underway, if possible.

Software Implementation Note: The OS does not expect a return from the update-flash-and-reboot call other than for the case where the hardware can't be accessed, the flash image is unacceptable to the RTAS flash update program, or the result of the update corrupted the flash.

Add requirement for PHB to do TCE table extent checking

ACR00013 was approved by the CHRP Board July 26,1996.

Issue

The set-64-bit-addressing OF method sets up the base and size of the TCE table, but currently no requirement exists for the hardware to do anything with the size parameter. The intent of specifying the size was to have the hardware check to see that a device doesn't try to access PCI Memory Space which is not covered by the TCE table. There is even an existing error defined in Chapter 10 for this error (TCE extent error). This change request adds the missing requirement.

Change

3-18+1. For 64-bit addressing option in HBs: If the address that the PHB would use to access the TCE table (in order to get the TCE) would access outside of the TCE table, then the PHB must create a TCE extent error (see Chapter 10).

RTAS cache-control

ACR00015 was approved by the CHRP Board on July 26, 1996.

Issue

The requirement to take a phandle as input for the cache-control call is extra overhead for both the firmware and the OS. The correlation to the correct cache can be made by indicating the level of the cache with respect to the current processor. For SMP, this relies on the processor's PIR being preserved by the OS from boot to RTAS call, so firmware and RTAS can assume the same PIR contents.

Change

4-2. For the Symmetric Multiprocessor option: Multiprocessing platforms must use only processors which implement the processor identification register.
"See PowerPC 604 RISC Microprocessor User's Manual [6] for a definition of the processor identification register (PIR). See {reference to chapter 12} for additional information on the implementation, initialization, and use of the PIR."

12-9. For the Symmetric Multiprocessor option: SMP operating systems must not alter the PIR(s).
12-10. For the Symmetric Multiprocessor option: The platform must initialize each PIR to a value which is unique for each processor and corresponds to the Open PIC identity of that processor.
12-11. For the Symmetric Multiprocessor option: If firmware and RTAS use the PIR for processor identification, then they must use the same PIR value to refer to the same processor.
12-12. For the Symmetric Multiprocessor option: Firmware must not alter the PIR(s) once they are initialized.
Software Implementation Note: The operating system is permitted to read the PIR to determine the identity of the processor on which it is running. To minimize the differences between uniprocessor and multiprocessor run-time environments (since a uniprocessor might not have a PIR), the operating system may wish to copy this and other per-processor data into a data structure based off a pointer, perhaps kept in a SPRG.

Hardware and Software Implementation Note: Some processors which implement the 6xx bus use a portion of the PIR value to help identify bus transactions. These implementations typically provide a set of pins which are read when power is first applied to the processor to hardware-initialize the PIR value. On such processors, firmware and software should never attempt to write the PIR value, since the integrity of transactions on the bus would likely be lost as a result.

NVRAM changes from System Binding

ACR00016 was approved by the CHRP Board on July 26,1996.

Issue

These changes are a result of work completed on the CHRP Open Firmware System Binding.

Change

"Software Implementation Note: Although the data areas of CHRP NVRAM partitions are not required to have error checking, it is strongly recommended that the system software implement robust data structures and error checking. Loss of NVRAM structures due to data corruption can be catastrophic, potentially leading to OS reinstallation and/or complete system initialization."

"The name field is a 12 byte string (or a null-terminated string of less than 12 bytes) used to identify a particular partition within a signature group. In order to reduce the likelihood of a naming conflict, each platform-specific or OS-specific partition name should be prefixed with a company name as specified under the description of the "name" string in the IEEE Standard for Boot (Initialization Configuration) Firmware: Core Requirements and Practices, that is, a company name string in one of the three forms described in the reference, followed by a comma (","). If the company name string is null, the name will be interpreted as `other'."

Indicate Required Indicators

ACR00017 was approved by the CHRP Board July 26, 1996.

Issue

Table 12 on page 99 indicates for set-indicator that "Some specific indicators are required and some are optional". Section 7.3.6.2, "Set-indicator", does not indicate which indicators are required.

Change

7-88+. Of the indicator types defined by Table 29 on page 120, RTAS must implement at least Tone Frequency and Tone Volume.

RTAS PCI config read/write clarification

ACR00022 was approved by the CHRP Board on July 26,1996.

Issue

CHRP Specification Sections 7.3.5.1 and 7.3.5.2 do not say anything about the endianess of the data in configuration space and whether it should be returned "as-is" or "byte-reversed" depending on the endianess of the processor. Requirement 5-12 would infer that the byte-reversed instructions should be used if the processor is in Big-Endian mode (since the data in PCI configuration space is always Little-Endian), but the requirement is not clear for RTAS since RTAS is not considered software.

Change

7-72+. RTAS must follow the rules of Table 9 on page 76 when accessing PCI configuration space.
Software implementation Note: Since PCI Configuration space is defined to be Little-Endian, RTAS will access this area using the byte-reversed forms of the Load and Store instructions when operating in Big-Endian mode (LE=0). In this fashion, the values passed are defined to be Little-Endian when LE=1 and Big-Endian when LE=0.

RTAS Hibernate

DER00004 was approved by the CHRP Board on July 26, 1996.

Issue

AIX already has all the logic to write out the hibernation image to disk. We see little reason to change that. But there may be reasons that are platform specific that would lead us to call hibernate to power off the platform for hibernation. The platform may want to output indicators that we do not know of, the platform may have different triggers for resume than for normal power on, etc. So we are thinking of using hibernate with a null block list (first word, length in bytes, of the block list is 0).

Change

Add a note at the end of section 7.3.8.1.2 on page 134

Software Implementation Note: The OS is not required to specify a non-zero amount of data. RTAS should be prepared to deal with a pointer to a block list describing no non-zero-sized memory areas. That is to say, the block list would contain a length in bytes, and one or more sets of area descriptions each containing a length of zero. In this case RTAS would put the system in the hibernate state without recording any data.

Load and Store Ordering Rules

ACR00006 was approved by the CHRP Board on September 23, 1996.

Issue

Requirement 5-6 only solves a small part of the problem described in the PCI Local Bus Specification version 2.1, on pages 116-117. Since it does not solve the whole problem, and since non-CHRP systems deal with this PCI anomaly, this change deletes 5-6, which is difficult to implement in the PHB.

Change

Software Implementation Note: The PCI architecture delayed transaction operations creates a potential data inconsistency problem when two entities are accessing the same address when that address is on the opposite side of a PCI to PCI bridge which supports delayed transactions. In particular, if a PCI device requests a read of an address on the other side of one of these PCI to PCI bridges and that read gets delayed, and then a second device writes to that address through the same bridge and then that second device reads the exact same address with the same length as the first device, the second device will get the data from the first device's read (instead of the data that it just wrote). The two devices doing the reading and writing can be the same device; for example, it might be the PHB and the Loads and Stores to the same address may be coming from the same processor or different processors. This potential delayed transaction data inconsistency scenario is documented in the PCI Local Bus specification.

Software should create the appropriate protocols to avoid these scenarios.

Identification of Vendor-unique Extended Error Log Formats

ACR00014 was approved by the CHRP Board on September 23, 1996.

Issue

The CHRP extended error log provides a means of defining vendor-specific log formats, indicated by a format indicator of 12, 13, 14, or 15 in byte 2, bits 4:7 of the general extended error log format (see page 176 in CHRP). However, if two companies both decide to define format 12 for their own vendor-specific purposes, there is no way to tell the formats apart. The same problem occurs for any vendor-specific log data that is appended after the standard 40-byte log. Since this log data may get forwarded across the network or to a service provider, proper identification of the log data is critical.

This ACR requires that for vendor-specific error log formats, the first four bytes of that format must contain a unique identifier for the company that has defined the format. This is being raised as an ACR so that all vendors who use vendor-specific formats will implement it consistently, preventing misinterpretation of log content.

Change

10-18. When extended product-unique error log data is appended after the first 40 bytes of the Extended Error Log Format, the first 4 bytes of this extended log data (bytes 40-43) must contain a company identifier for the company that defined the format of this extended log data.
Requirement 10--18 and Table 54B on page 22 require that four bytes of the vendor-specific format contain a unique identifier for the company that has defined the format. The description of the "name" string in the "IEEE 1275 Standard for Boot (Initialization Configuration) Firmware: Core Requirements and Practices" provides alternatives for defining this identifier. Examples of these unique identifiers include stock ticker labels and Organizationally Unique Identifiers (OUIs). Since the different options in IEEE 1275 provide different guarantees of uniqueness and different identifier lengths, the company should use its best judgement in selecting a unique identifier that fits the four character field. The length of this field is limited to 4 bytes to conserve available log data space. As an example, if Allied Information Monitoring (a fictional name for the purposes of this example) were to create a vendor-specific log format 12, then bytes 12-15 of such a log may contain "AIM<null>".

This identifier is intended to apply to the company that defines the specific format, and may be used by other companies that wish to be compatible with that format. For example, if another company wanted to take advantage of existing support in one of the operating systems by using an AIM-specific error log format for logs generated on their own platform, their log would have to contain an identifier of "AIM<null>".

RTAS set-time-for-power-on

ACR00018 was approved by the CHRP Board on September 23, 1996.

Issue

The current specification places no restrictions on the time allowed for this call. Some hardware supports about a 30 day horizon.

Change

7-56+1. Hardware must support power on times of up to four weeks into the future, at a minimum.
7-56+2. RTAS must schedule the time for power on as close as it can approach to the desired time.
Software Implementation Note: Hardware limitations on the duration of the power-on timer may result in power-on sooner than requested by software. If present in the RTAS node, the Open Firmware property "power-on-max-latency" gives in days the maximum power-on duration capability of the hardware. If the property is not present, software should expect the default of a maximum of 28 days. A "day" is defined as 24 hour increments from the current time.

Get-sensor-state return of state and value

ACR00021 was approved by the CHRP Board on September 23, 1996.

Issue

This ACR addresses three items:

  1. Environmental sensors such as Thermal and Battery voltage may be monitored within a platform - for example by a support processor. If the value goes outside of some predefined limit an EPOW may be invoked. Software should be able to see what sensor was out of limits and which were normal. For instance, an EPOW of WARN_COOLING does not tell software which temperature sensor or fan was out of limits in the case of multiple sensors. In addition, when the sensor returns to within limits there is no indication that the "WARN_COOLING event is over. This change provides information to an operating system to allow it to determine these conditions.
  2. The Units of the Battery Voltage sensor are in volts which provides little precision for this sensor. The units should be changed to millivolts to give more precision.
  3. Table 30 refers to "Current sensor's state" and Table 31 has a column labeled "Defined Values" which is the returned value. Clarify this nomenclature.

Change

7-89+1. If a platform tests sensor values against limits, then RTAS must return the result of these tests using the status output parameter."
Change the "Out" row of table 30 as follows:

Table 55. get-sensor-state Argument Call Buffer 
---------------------------------------------------------------------
Parameter Type  Name    Values                                         
---------------------------------------------------------------------
Out             Status  13: Sensor value >= critical high           
                        12: Sensor value >= Warning high            
                        11: Sensor value normal                        
                        10: Sensor value <= Warning low             
                        9: Sensor value <= critical low             
                        0: Success                                     
                        -1: Hardware Error                             
                        -2: Hardware Busy, Try again later             
                        -3: No such sensor implemented                 
                State   Current value as defined in the |"Defined Val  
                        ues" column of Table 31 on page 121            
                                                                       
---------------------------------------------------------------------
Hardware Implementation Note: Some platforms may compare the value of environmental sensors (such as the Battery Voltage or Thermal Sensor) to some limits. When the value of the sensor meets or exceeds a limit the platform may take some action. RTAS makes the operating system aware of the relationship of the sensor values to the limit by using the status code to return this information.

Software and Hardware Implementation Note: The meaning of these limits are as follows:

Where:

Platform Implementation Note: The existence of this sensor state reporting capability should not be construed as a requirement to have any limits on sensors or to always have all four limits.

RTAS query-cpu-stopped-state

ACR00023 was approved by the CHRP Board on September 23, 1996.

Issue

The RTAS rule about allowing only one cpu to call RTAS at a time is somewhat problematical in the case of the stop-self call. There is no way to know when the cpu is stopped so another call can be made, since the call does not return.

The basic problem with the RTAS stop-self service is that it is a non-terminal RTAS call that does not return to the caller. This basically implies that an operating system can not acquire the RTAS lock prior to calling stop-self.

Change

7-13. Except as noted in requirements 7-19 and 7--19+1, the operating system must ensure that RTAS calls are not re-entered and are not simultaneously called from different processors in a multi-processor system.
7-19+1. The stop-self service need only be serialized with calls to the stop-self, start-cpu, and set-power-level services. The operating system is free to call other RTAS services on other processors while a processor is being stopped.
7-107. In an SMP system, all other processors must be in the stopped state before invoking suspend. This is the responsibility of the operating system.

7.3.11.5 query-cpu-stopped-state

The query-cpu-stopped-state primitive is used to query a different processor to determine its status with respect to the RTAS stopped state.

Requirements:

7-143. For the Symmetric Multiprocessor option: RTAS must implement a query-cpu-stopped-state call which returns the CPU_status of the processor specified by the CPU_id parameter. This call must be implemented using the argument call buffer defined by Table 46+1 on page 29.

Table 46+1. query-cpu-stopped-state Argument Call Buffer 
-------------------------------------------------------------------------------
Parameter Type  Name            Values                                           
-------------------------------------------------------------------------------
In              Token           Token for query-cpu-stopped-state                
                Number Inputs   1                                                
                Number Outputs  2                                                
                CPU_id          Token identifying the processor to be queried,   
                                obtained from the reg value for the CPU in the   
                                Open Firmware device tree                        
Out             Status          0: Success                                       
                                -1: Hardware Error                               
                                -2: Hardware Busy, Try again later               
                CPU_status      0: The processor is in the RTAS stopped state    
                                1: Stop-self is in progress                      
                                2: The processor is not in the RTAS stopped      
                                state                                            
                                                                                 
-------------------------------------------------------------------------------
Firmware Implementation Note: RTAS serialization may be required between the stop-self and the query-cpu-stopped-state calls.

Software Implementation Note: The operating system must perform a stop-self on the desired processor, then periodically call query-cpu-stopped-state on another processor until the desired processor is stopped before calling set-power-level to power off the desired processor.

Defined Power on Triggers

ACR00024 was approved by the CHRP Board on September 23, 1996.

Issue

ACR 00005 added table 62b for power on triggers, but defined different mask positions than table 62. It would be convenient for software, if the power on mask was a subset of table 62 and included every possible power on event.

Clarify that the power on events supported on a specific platform should be reported to the operating system via the property "power-on-triggers" of the Open Firmware device tree.

Change

should....". This sentence is not a requirement and should be in the

clarification text below the requirement.

If a bit in the Power_on_mask is set to 1, then the hardware should enable the corresponding hardware power-on mechanism. The Open Firmware property "power-on-triggers" in the RTAS node is used to indicate which of these triggers are supported by the particular platform.

Add System Bus

ACR00025 was approved by the CHRP Board on September 23, 1996.

Issue

Since devices are allowed on the system bus, the I/O Device Reset States table should be expanded to include the system bus.

Change

Table 1\>. I/O Device Reset States 
------------------------------------------------------------------------------------------------------------------------------
Bus                                                        Devices Left Open by Open Firmware  Other Devices                    
------------------------------------------------------------------------------------------------------------------------------
System                                                     Configured per OF Device Tree       The device is in hardware reset  
                                                            Interrupts inactive                state (see note) or inactive:    
                                                            DMA inactive                        Interrupts inactive             
                                                            No outstanding I/O operations       DMA inactive                    
------------------------------------------------------------------------------------------------------------------------------
Note: May optionally be configured, but must be inactive.                                                                       
------------------------------------------------------------------------------------------------------------------------------

Clarification of display-character

ACR00028 was approved by the CHRP Board on September 23, 1996.

Issue

CHRP does not specify the character set which is displayable with the RTAS display-character command.

Change

7-86+1. The ASCII characters that must be displayed are generally those coded from 0x20 to 0x7E.
Software Implementation Note: Care should be taken in using the full character set for all systems as some characters may not be available or may display in a different fashion. For instance, the currency symbol, $ (0x24), may be modified to a national currency symbol. Other currently known differences occur for the reverse slant, \ (0x5C), and the tilde, ~ (0x7E).

RTAS Functions

Table 12 on page 24 shows the cumulative changes of all new and modified RTAS functions.

Table 12. RTAS Tokens for Functions (Continued) 
--------------------------------------------------------------------------------------------
RTAS property/function    Required?           Notes                                           
--------------------------------------------------------------------------------------------
restart-rtas              Required                                                            
nvram-fetch               Required            Execution time proportional to amount of data   
nvram-store               Required            Execution time proportional to amount of data   
get-time-of-day           Required                                                            
set-time-of-day           Required                                                            
set-time-for-power-on                                                                         
event-scan                Required                                                            
check-exception           Required                                                            
read-pci-config           Required                                                            
write-pci-config          Required                                                            
display-character                                                                             
set-indicator             Required            Some specific indicators are required, and      
                                              some are optional                               
get-sensor-state                                                                              
set-power-level           Required in Power                                                   
                          Managed Platforms                                                   
get-power-level                                                                               
assume-power-management                                                                       
relinquish-power-manage                                                                       
ment                                                                                          
power-off                                     Provided for platforms with software con        
                                              trolled power off capability, with or without   
                                              other Power Management capability               
hibernate                                                                                     
suspend                                                                                       
system-reboot             Required                                                            
update-flash-and-reboot                       See update-flash section                        
update-flash                                                                                  
cache-control             Required in Power                                                   
                          Managed Platforms                                                   
                          Required in SMP                                                     
                          Platforms                                                           
freeze_time_base                              Turn off time base                              
                          Required in SMP                                                     
                          Platforms                                                           
thaw_time_base                                Turn time base back on                          
stop-self                                                                                     
start-cpu                                                                                     
 query-cpu-stopped-state  Required in SMP                                                     
                          |Platforms                                                          
--------------------------------------------------------------------------------------------
This is the last page of the CHRP Version 1.0 Change Notice