acpi_object_usage.rst (27462B)
1=========== 2ACPI Tables 3=========== 4 5The expectations of individual ACPI tables are discussed in the list that 6follows. 7 8If a section number is used, it refers to a section number in the ACPI 9specification where the object is defined. If "Signature Reserved" is used, 10the table signature (the first four bytes of the table) is the only portion 11of the table recognized by the specification, and the actual table is defined 12outside of the UEFI Forum (see Section 5.2.6 of the specification). 13 14For ACPI on arm64, tables also fall into the following categories: 15 16 - Required: DSDT, FADT, GTDT, MADT, MCFG, RSDP, SPCR, XSDT 17 18 - Recommended: BERT, EINJ, ERST, HEST, PCCT, SSDT 19 20 - Optional: BGRT, CPEP, CSRT, DBG2, DRTM, ECDT, FACS, FPDT, IBFT, 21 IORT, MCHI, MPST, MSCT, NFIT, PMTT, RASF, SBST, SLIT, SPMI, SRAT, 22 STAO, TCPA, TPM2, UEFI, XENV 23 24 - Not supported: BOOT, DBGP, DMAR, ETDT, HPET, IVRS, LPIT, MSDM, OEMx, 25 PSDT, RSDT, SLIC, WAET, WDAT, WDRT, WPBT 26 27====== ======================================================================== 28Table Usage for ARMv8 Linux 29====== ======================================================================== 30BERT Section 18.3 (signature == "BERT") 31 32 **Boot Error Record Table** 33 34 Must be supplied if RAS support is provided by the platform. It 35 is recommended this table be supplied. 36 37BOOT Signature Reserved (signature == "BOOT") 38 39 **simple BOOT flag table** 40 41 Microsoft only table, will not be supported. 42 43BGRT Section 5.2.22 (signature == "BGRT") 44 45 **Boot Graphics Resource Table** 46 47 Optional, not currently supported, with no real use-case for an 48 ARM server. 49 50CPEP Section 5.2.18 (signature == "CPEP") 51 52 **Corrected Platform Error Polling table** 53 54 Optional, not currently supported, and not recommended until such 55 time as ARM-compatible hardware is available, and the specification 56 suitably modified. 57 58CSRT Signature Reserved (signature == "CSRT") 59 60 **Core System Resources Table** 61 62 Optional, not currently supported. 63 64DBG2 Signature Reserved (signature == "DBG2") 65 66 **DeBuG port table 2** 67 68 License has changed and should be usable. Optional if used instead 69 of earlycon=<device> on the command line. 70 71DBGP Signature Reserved (signature == "DBGP") 72 73 **DeBuG Port table** 74 75 Microsoft only table, will not be supported. 76 77DSDT Section 5.2.11.1 (signature == "DSDT") 78 79 **Differentiated System Description Table** 80 81 A DSDT is required; see also SSDT. 82 83 ACPI tables contain only one DSDT but can contain one or more SSDTs, 84 which are optional. Each SSDT can only add to the ACPI namespace, 85 but cannot modify or replace anything in the DSDT. 86 87DMAR Signature Reserved (signature == "DMAR") 88 89 **DMA Remapping table** 90 91 x86 only table, will not be supported. 92 93DRTM Signature Reserved (signature == "DRTM") 94 95 **Dynamic Root of Trust for Measurement table** 96 97 Optional, not currently supported. 98 99ECDT Section 5.2.16 (signature == "ECDT") 100 101 **Embedded Controller Description Table** 102 103 Optional, not currently supported, but could be used on ARM if and 104 only if one uses the GPE_BIT field to represent an IRQ number, since 105 there are no GPE blocks defined in hardware reduced mode. This would 106 need to be modified in the ACPI specification. 107 108EINJ Section 18.6 (signature == "EINJ") 109 110 **Error Injection table** 111 112 This table is very useful for testing platform response to error 113 conditions; it allows one to inject an error into the system as 114 if it had actually occurred. However, this table should not be 115 shipped with a production system; it should be dynamically loaded 116 and executed with the ACPICA tools only during testing. 117 118ERST Section 18.5 (signature == "ERST") 119 120 **Error Record Serialization Table** 121 122 On a platform supports RAS, this table must be supplied if it is not 123 UEFI-based; if it is UEFI-based, this table may be supplied. When this 124 table is not present, UEFI run time service will be utilized to save 125 and retrieve hardware error information to and from a persistent store. 126 127ETDT Signature Reserved (signature == "ETDT") 128 129 **Event Timer Description Table** 130 131 Obsolete table, will not be supported. 132 133FACS Section 5.2.10 (signature == "FACS") 134 135 **Firmware ACPI Control Structure** 136 137 It is unlikely that this table will be terribly useful. If it is 138 provided, the Global Lock will NOT be used since it is not part of 139 the hardware reduced profile, and only 64-bit address fields will 140 be considered valid. 141 142FADT Section 5.2.9 (signature == "FACP") 143 144 **Fixed ACPI Description Table** 145 Required for arm64. 146 147 148 The HW_REDUCED_ACPI flag must be set. All of the fields that are 149 to be ignored when HW_REDUCED_ACPI is set are expected to be set to 150 zero. 151 152 If an FACS table is provided, the X_FIRMWARE_CTRL field is to be 153 used, not FIRMWARE_CTRL. 154 155 If PSCI is used (as is recommended), make sure that ARM_BOOT_ARCH is 156 filled in properly - that the PSCI_COMPLIANT flag is set and that 157 PSCI_USE_HVC is set or unset as needed (see table 5-37). 158 159 For the DSDT that is also required, the X_DSDT field is to be used, 160 not the DSDT field. 161 162FPDT Section 5.2.23 (signature == "FPDT") 163 164 **Firmware Performance Data Table** 165 166 Optional, not currently supported. 167 168GTDT Section 5.2.24 (signature == "GTDT") 169 170 **Generic Timer Description Table** 171 172 Required for arm64. 173 174HEST Section 18.3.2 (signature == "HEST") 175 176 **Hardware Error Source Table** 177 178 ARM-specific error sources have been defined; please use those or the 179 PCI types such as type 6 (AER Root Port), 7 (AER Endpoint), or 8 (AER 180 Bridge), or use type 9 (Generic Hardware Error Source). Firmware first 181 error handling is possible if and only if Trusted Firmware is being 182 used on arm64. 183 184 Must be supplied if RAS support is provided by the platform. It 185 is recommended this table be supplied. 186 187HPET Signature Reserved (signature == "HPET") 188 189 **High Precision Event timer Table** 190 191 x86 only table, will not be supported. 192 193IBFT Signature Reserved (signature == "IBFT") 194 195 **iSCSI Boot Firmware Table** 196 197 Microsoft defined table, support TBD. 198 199IORT Signature Reserved (signature == "IORT") 200 201 **Input Output Remapping Table** 202 203 arm64 only table, required in order to describe IO topology, SMMUs, 204 and GIC ITSs, and how those various components are connected together, 205 such as identifying which components are behind which SMMUs/ITSs. 206 This table will only be required on certain SBSA platforms (e.g., 207 when using GICv3-ITS and an SMMU); on SBSA Level 0 platforms, it 208 remains optional. 209 210IVRS Signature Reserved (signature == "IVRS") 211 212 **I/O Virtualization Reporting Structure** 213 214 x86_64 (AMD) only table, will not be supported. 215 216LPIT Signature Reserved (signature == "LPIT") 217 218 **Low Power Idle Table** 219 220 x86 only table as of ACPI 5.1; starting with ACPI 6.0, processor 221 descriptions and power states on ARM platforms should use the DSDT 222 and define processor container devices (_HID ACPI0010, Section 8.4, 223 and more specifically 8.4.3 and 8.4.4). 224 225MADT Section 5.2.12 (signature == "APIC") 226 227 **Multiple APIC Description Table** 228 229 Required for arm64. Only the GIC interrupt controller structures 230 should be used (types 0xA - 0xF). 231 232MCFG Signature Reserved (signature == "MCFG") 233 234 **Memory-mapped ConFiGuration space** 235 236 If the platform supports PCI/PCIe, an MCFG table is required. 237 238MCHI Signature Reserved (signature == "MCHI") 239 240 **Management Controller Host Interface table** 241 242 Optional, not currently supported. 243 244MPST Section 5.2.21 (signature == "MPST") 245 246 **Memory Power State Table** 247 248 Optional, not currently supported. 249 250MSCT Section 5.2.19 (signature == "MSCT") 251 252 **Maximum System Characteristic Table** 253 254 Optional, not currently supported. 255 256MSDM Signature Reserved (signature == "MSDM") 257 258 **Microsoft Data Management table** 259 260 Microsoft only table, will not be supported. 261 262NFIT Section 5.2.25 (signature == "NFIT") 263 264 **NVDIMM Firmware Interface Table** 265 266 Optional, not currently supported. 267 268OEMx Signature of "OEMx" only 269 270 **OEM Specific Tables** 271 272 All tables starting with a signature of "OEM" are reserved for OEM 273 use. Since these are not meant to be of general use but are limited 274 to very specific end users, they are not recommended for use and are 275 not supported by the kernel for arm64. 276 277PCCT Section 14.1 (signature == "PCCT) 278 279 **Platform Communications Channel Table** 280 281 Recommend for use on arm64; use of PCC is recommended when using CPPC 282 to control performance and power for platform processors. 283 284PMTT Section 5.2.21.12 (signature == "PMTT") 285 286 **Platform Memory Topology Table** 287 288 Optional, not currently supported. 289 290PSDT Section 5.2.11.3 (signature == "PSDT") 291 292 **Persistent System Description Table** 293 294 Obsolete table, will not be supported. 295 296RASF Section 5.2.20 (signature == "RASF") 297 298 **RAS Feature table** 299 300 Optional, not currently supported. 301 302RSDP Section 5.2.5 (signature == "RSD PTR") 303 304 **Root System Description PoinTeR** 305 306 Required for arm64. 307 308RSDT Section 5.2.7 (signature == "RSDT") 309 310 **Root System Description Table** 311 312 Since this table can only provide 32-bit addresses, it is deprecated 313 on arm64, and will not be used. If provided, it will be ignored. 314 315SBST Section 5.2.14 (signature == "SBST") 316 317 **Smart Battery Subsystem Table** 318 319 Optional, not currently supported. 320 321SLIC Signature Reserved (signature == "SLIC") 322 323 **Software LIcensing table** 324 325 Microsoft only table, will not be supported. 326 327SLIT Section 5.2.17 (signature == "SLIT") 328 329 **System Locality distance Information Table** 330 331 Optional in general, but required for NUMA systems. 332 333SPCR Signature Reserved (signature == "SPCR") 334 335 **Serial Port Console Redirection table** 336 337 Required for arm64. 338 339SPMI Signature Reserved (signature == "SPMI") 340 341 **Server Platform Management Interface table** 342 343 Optional, not currently supported. 344 345SRAT Section 5.2.16 (signature == "SRAT") 346 347 **System Resource Affinity Table** 348 349 Optional, but if used, only the GICC Affinity structures are read. 350 To support arm64 NUMA, this table is required. 351 352SSDT Section 5.2.11.2 (signature == "SSDT") 353 354 **Secondary System Description Table** 355 356 These tables are a continuation of the DSDT; these are recommended 357 for use with devices that can be added to a running system, but can 358 also serve the purpose of dividing up device descriptions into more 359 manageable pieces. 360 361 An SSDT can only ADD to the ACPI namespace. It cannot modify or 362 replace existing device descriptions already in the namespace. 363 364 These tables are optional, however. ACPI tables should contain only 365 one DSDT but can contain many SSDTs. 366 367STAO Signature Reserved (signature == "STAO") 368 369 **_STA Override table** 370 371 Optional, but only necessary in virtualized environments in order to 372 hide devices from guest OSs. 373 374TCPA Signature Reserved (signature == "TCPA") 375 376 **Trusted Computing Platform Alliance table** 377 378 Optional, not currently supported, and may need changes to fully 379 interoperate with arm64. 380 381TPM2 Signature Reserved (signature == "TPM2") 382 383 **Trusted Platform Module 2 table** 384 385 Optional, not currently supported, and may need changes to fully 386 interoperate with arm64. 387 388UEFI Signature Reserved (signature == "UEFI") 389 390 **UEFI ACPI data table** 391 392 Optional, not currently supported. No known use case for arm64, 393 at present. 394 395WAET Signature Reserved (signature == "WAET") 396 397 **Windows ACPI Emulated devices Table** 398 399 Microsoft only table, will not be supported. 400 401WDAT Signature Reserved (signature == "WDAT") 402 403 **Watch Dog Action Table** 404 405 Microsoft only table, will not be supported. 406 407WDRT Signature Reserved (signature == "WDRT") 408 409 **Watch Dog Resource Table** 410 411 Microsoft only table, will not be supported. 412 413WPBT Signature Reserved (signature == "WPBT") 414 415 **Windows Platform Binary Table** 416 417 Microsoft only table, will not be supported. 418 419XENV Signature Reserved (signature == "XENV") 420 421 **Xen project table** 422 423 Optional, used only by Xen at present. 424 425XSDT Section 5.2.8 (signature == "XSDT") 426 427 **eXtended System Description Table** 428 429 Required for arm64. 430====== ======================================================================== 431 432ACPI Objects 433------------ 434The expectations on individual ACPI objects that are likely to be used are 435shown in the list that follows; any object not explicitly mentioned below 436should be used as needed for a particular platform or particular subsystem, 437such as power management or PCI. 438 439===== ================ ======================================================== 440Name Section Usage for ARMv8 Linux 441===== ================ ======================================================== 442_CCA 6.2.17 This method must be defined for all bus masters 443 on arm64 - there are no assumptions made about 444 whether such devices are cache coherent or not. 445 The _CCA value is inherited by all descendants of 446 these devices so it does not need to be repeated. 447 Without _CCA on arm64, the kernel does not know what 448 to do about setting up DMA for the device. 449 450 NB: this method provides default cache coherency 451 attributes; the presence of an SMMU can be used to 452 modify that, however. For example, a master could 453 default to non-coherent, but be made coherent with 454 the appropriate SMMU configuration (see Table 17 of 455 the IORT specification, ARM Document DEN 0049B). 456 457_CID 6.1.2 Use as needed, see also _HID. 458 459_CLS 6.1.3 Use as needed, see also _HID. 460 461_CPC 8.4.7.1 Use as needed, power management specific. CPPC is 462 recommended on arm64. 463 464_CRS 6.2.2 Required on arm64. 465 466_CSD 8.4.2.2 Use as needed, used only in conjunction with _CST. 467 468_CST 8.4.2.1 Low power idle states (8.4.4) are recommended instead 469 of C-states. 470 471_DDN 6.1.4 This field can be used for a device name. However, 472 it is meant for DOS device names (e.g., COM1), so be 473 careful of its use across OSes. 474 475_DSD 6.2.5 To be used with caution. If this object is used, try 476 to use it within the constraints already defined by the 477 Device Properties UUID. Only in rare circumstances 478 should it be necessary to create a new _DSD UUID. 479 480 In either case, submit the _DSD definition along with 481 any driver patches for discussion, especially when 482 device properties are used. A driver will not be 483 considered complete without a corresponding _DSD 484 description. Once approved by kernel maintainers, 485 the UUID or device properties must then be registered 486 with the UEFI Forum; this may cause some iteration as 487 more than one OS will be registering entries. 488 489_DSM 9.1.1 Do not use this method. It is not standardized, the 490 return values are not well documented, and it is 491 currently a frequent source of error. 492 493\_GL 5.7.1 This object is not to be used in hardware reduced 494 mode, and therefore should not be used on arm64. 495 496_GLK 6.5.7 This object requires a global lock be defined; there 497 is no global lock on arm64 since it runs in hardware 498 reduced mode. Hence, do not use this object on arm64. 499 500\_GPE 5.3.1 This namespace is for x86 use only. Do not use it 501 on arm64. 502 503_HID 6.1.5 This is the primary object to use in device probing, 504 though _CID and _CLS may also be used. 505 506_INI 6.5.1 Not required, but can be useful in setting up devices 507 when UEFI leaves them in a state that may not be what 508 the driver expects before it starts probing. 509 510_LPI 8.4.4.3 Recommended for use with processor definitions (_HID 511 ACPI0010) on arm64. See also _RDI. 512 513_MLS 6.1.7 Highly recommended for use in internationalization. 514 515_OFF 7.2.2 It is recommended to define this method for any device 516 that can be turned on or off. 517 518_ON 7.2.3 It is recommended to define this method for any device 519 that can be turned on or off. 520 521\_OS 5.7.3 This method will return "Linux" by default (this is 522 the value of the macro ACPI_OS_NAME on Linux). The 523 command line parameter acpi_os=<string> can be used 524 to set it to some other value. 525 526_OSC 6.2.11 This method can be a global method in ACPI (i.e., 527 \_SB._OSC), or it may be associated with a specific 528 device (e.g., \_SB.DEV0._OSC), or both. When used 529 as a global method, only capabilities published in 530 the ACPI specification are allowed. When used as 531 a device-specific method, the process described for 532 using _DSD MUST be used to create an _OSC definition; 533 out-of-process use of _OSC is not allowed. That is, 534 submit the device-specific _OSC usage description as 535 part of the kernel driver submission, get it approved 536 by the kernel community, then register it with the 537 UEFI Forum. 538 539\_OSI 5.7.2 Deprecated on ARM64. As far as ACPI firmware is 540 concerned, _OSI is not to be used to determine what 541 sort of system is being used or what functionality 542 is provided. The _OSC method is to be used instead. 543 544_PDC 8.4.1 Deprecated, do not use on arm64. 545 546\_PIC 5.8.1 The method should not be used. On arm64, the only 547 interrupt model available is GIC. 548 549\_PR 5.3.1 This namespace is for x86 use only on legacy systems. 550 Do not use it on arm64. 551 552_PRT 6.2.13 Required as part of the definition of all PCI root 553 devices. 554 555_PRx 7.3.8-11 Use as needed; power management specific. If _PR0 is 556 defined, _PR3 must also be defined. 557 558_PSx 7.3.2-5 Use as needed; power management specific. If _PS0 is 559 defined, _PS3 must also be defined. If clocks or 560 regulators need adjusting to be consistent with power 561 usage, change them in these methods. 562 563_RDI 8.4.4.4 Recommended for use with processor definitions (_HID 564 ACPI0010) on arm64. This should only be used in 565 conjunction with _LPI. 566 567\_REV 5.7.4 Always returns the latest version of ACPI supported. 568 569\_SB 5.3.1 Required on arm64; all devices must be defined in this 570 namespace. 571 572_SLI 6.2.15 Use is recommended when SLIT table is in use. 573 574_STA 6.3.7, It is recommended to define this method for any device 575 7.2.4 that can be turned on or off. See also the STAO table 576 that provides overrides to hide devices in virtualized 577 environments. 578 579_SRS 6.2.16 Use as needed; see also _PRS. 580 581_STR 6.1.10 Recommended for conveying device names to end users; 582 this is preferred over using _DDN. 583 584_SUB 6.1.9 Use as needed; _HID or _CID are preferred. 585 586_SUN 6.1.11 Use as needed, but recommended. 587 588_SWS 7.4.3 Use as needed; power management specific; this may 589 require specification changes for use on arm64. 590 591_UID 6.1.12 Recommended for distinguishing devices of the same 592 class; define it if at all possible. 593===== ================ ======================================================== 594 595 596 597 598ACPI Event Model 599---------------- 600Do not use GPE block devices; these are not supported in the hardware reduced 601profile used by arm64. Since there are no GPE blocks defined for use on ARM 602platforms, ACPI events must be signaled differently. 603 604There are two options: GPIO-signaled interrupts (Section 5.6.5), and 605interrupt-signaled events (Section 5.6.9). Interrupt-signaled events are a 606new feature in the ACPI 6.1 specification. Either - or both - can be used 607on a given platform, and which to use may be dependent of limitations in any 608given SoC. If possible, interrupt-signaled events are recommended. 609 610 611ACPI Processor Control 612---------------------- 613Section 8 of the ACPI specification changed significantly in version 6.0. 614Processors should now be defined as Device objects with _HID ACPI0007; do 615not use the deprecated Processor statement in ASL. All multiprocessor systems 616should also define a hierarchy of processors, done with Processor Container 617Devices (see Section 8.4.3.1, _HID ACPI0010); do not use processor aggregator 618devices (Section 8.5) to describe processor topology. Section 8.4 of the 619specification describes the semantics of these object definitions and how 620they interrelate. 621 622Most importantly, the processor hierarchy defined also defines the low power 623idle states that are available to the platform, along with the rules for 624determining which processors can be turned on or off and the circumstances 625that control that. Without this information, the processors will run in 626whatever power state they were left in by UEFI. 627 628Note too, that the processor Device objects defined and the entries in the 629MADT for GICs are expected to be in synchronization. The _UID of the Device 630object must correspond to processor IDs used in the MADT. 631 632It is recommended that CPPC (8.4.5) be used as the primary model for processor 633performance control on arm64. C-states and P-states may become available at 634some point in the future, but most current design work appears to favor CPPC. 635 636Further, it is essential that the ARMv8 SoC provide a fully functional 637implementation of PSCI; this will be the only mechanism supported by ACPI 638to control CPU power state. Booting of secondary CPUs using the ACPI 639parking protocol is possible, but discouraged, since only PSCI is supported 640for ARM servers. 641 642 643ACPI System Address Map Interfaces 644---------------------------------- 645In Section 15 of the ACPI specification, several methods are mentioned as 646possible mechanisms for conveying memory resource information to the kernel. 647For arm64, we will only support UEFI for booting with ACPI, hence the UEFI 648GetMemoryMap() boot service is the only mechanism that will be used. 649 650 651ACPI Platform Error Interfaces (APEI) 652------------------------------------- 653The APEI tables supported are described above. 654 655APEI requires the equivalent of an SCI and an NMI on ARMv8. The SCI is used 656to notify the OSPM of errors that have occurred but can be corrected and the 657system can continue correct operation, even if possibly degraded. The NMI is 658used to indicate fatal errors that cannot be corrected, and require immediate 659attention. 660 661Since there is no direct equivalent of the x86 SCI or NMI, arm64 handles 662these slightly differently. The SCI is handled as a high priority interrupt; 663given that these are corrected (or correctable) errors being reported, this 664is sufficient. The NMI is emulated as the highest priority interrupt 665possible. This implies some caution must be used since there could be 666interrupts at higher privilege levels or even interrupts at the same priority 667as the emulated NMI. In Linux, this should not be the case but one should 668be aware it could happen. 669 670 671ACPI Objects Not Supported on ARM64 672----------------------------------- 673While this may change in the future, there are several classes of objects 674that can be defined, but are not currently of general interest to ARM servers. 675Some of these objects have x86 equivalents, and may actually make sense in ARM 676servers. However, there is either no hardware available at present, or there 677may not even be a non-ARM implementation yet. Hence, they are not currently 678supported. 679 680The following classes of objects are not supported: 681 682 - Section 9.2: ambient light sensor devices 683 684 - Section 9.3: battery devices 685 686 - Section 9.4: lids (e.g., laptop lids) 687 688 - Section 9.8.2: IDE controllers 689 690 - Section 9.9: floppy controllers 691 692 - Section 9.10: GPE block devices 693 694 - Section 9.15: PC/AT RTC/CMOS devices 695 696 - Section 9.16: user presence detection devices 697 698 - Section 9.17: I/O APIC devices; all GICs must be enumerable via MADT 699 700 - Section 9.18: time and alarm devices (see 9.15) 701 702 - Section 10: power source and power meter devices 703 704 - Section 11: thermal management 705 706 - Section 12: embedded controllers interface 707 708 - Section 13: SMBus interfaces 709 710 711This also means that there is no support for the following objects: 712 713==== =========================== ==== ========== 714Name Section Name Section 715==== =========================== ==== ========== 716_ALC 9.3.4 _FDM 9.10.3 717_ALI 9.3.2 _FIX 6.2.7 718_ALP 9.3.6 _GAI 10.4.5 719_ALR 9.3.5 _GHL 10.4.7 720_ALT 9.3.3 _GTM 9.9.2.1.1 721_BCT 10.2.2.10 _LID 9.5.1 722_BDN 6.5.3 _PAI 10.4.4 723_BIF 10.2.2.1 _PCL 10.3.2 724_BIX 10.2.2.1 _PIF 10.3.3 725_BLT 9.2.3 _PMC 10.4.1 726_BMA 10.2.2.4 _PMD 10.4.8 727_BMC 10.2.2.12 _PMM 10.4.3 728_BMD 10.2.2.11 _PRL 10.3.4 729_BMS 10.2.2.5 _PSR 10.3.1 730_BST 10.2.2.6 _PTP 10.4.2 731_BTH 10.2.2.7 _SBS 10.1.3 732_BTM 10.2.2.9 _SHL 10.4.6 733_BTP 10.2.2.8 _STM 9.9.2.1.1 734_DCK 6.5.2 _UPD 9.16.1 735_EC 12.12 _UPP 9.16.2 736_FDE 9.10.1 _WPC 10.5.2 737_FDI 9.10.2 _WPP 10.5.3 738==== =========================== ==== ==========