Lines Matching +full:boot +full:- +full:method
7 Base Boot Requirements) [1] specifications. Both BSA and BBR are publicly
23 industry-standard Arm systems, they also apply to more than one operating
25 ACPI and Linux only, on an Arm system -- that is, what Linux expects of
30 ----------------
33 exist in Linux for describing non-enumerable hardware, after all. In this
40 - ACPI’s byte code (AML) allows the platform to encode hardware behavior,
45 - ACPI’s OSPM defines a power management model that constrains what the
49 - In the enterprise server environment, ACPI has established bindings (such
55 - Choosing a single interface to describe the abstraction between a platform
61 - The new ACPI governance process works well and Linux is now at the same
87 interfaces -- one for Linux and one for Windows.
91 --------------------
102 -- its baseline. ACPI firmware must continue to work, even though it may
111 -----------------------------
115 At boot time the kernel will only use one description method depending on
116 parameters passed from the boot loader (including kernel bootargs).
124 -------------------------
125 The only defined method for passing ACPI tables to the kernel on Arm
127 means that ACPI is only supported on platforms that boot via UEFI.
133 If neither is available, the kernel will not boot. If acpi=force is used
136 the kernel will not fail to boot unless it absolutely has no other choice.
144 is used, the kernel will disable ACPI and try to use DT to boot instead; the
159 for 32-bit addresses.
161 Further, the ACPI core will only use the 64-bit address fields in the FADT
162 (Fixed ACPI Description Table). Any 32-bit address fields in the FADT will
175 - RSDP (Root System Description Pointer), section 5.2.5
177 - XSDT (eXtended System Description Table), section 5.2.8
179 - FADT (Fixed ACPI Description Table), section 5.2.9
181 - DSDT (Differentiated System Description Table), section
184 - MADT (Multiple APIC Description Table), section 5.2.12
186 - GTDT (Generic Timer Description Table), section 5.2.24
188 - PPTT (Processor Properties Topology Table), section 5.2.30
190 - DBG2 (DeBuG port table 2), section 5.2.6, specifically Table 5-6.
192 - APMT (Arm Performance Monitoring unit Table), section 5.2.6, specifically Table 5-6.
194 …- AGDI (Arm Generic diagnostic Dump and Reset Device Interface Table), section 5.2.6, specificall…
196 - If PCI is supported, the MCFG (Memory mapped ConFiGuration
197 Table), section 5.2.6, specifically Table 5-6.
199 - If booting without a console=<device> kernel parameter is
201 section 5.2.6, specifically Table 5-6.
203 - If necessary to describe the I/O topology, SMMUs and GIC ITSs,
205 Table 5-6).
207 - If NUMA is supported, the following tables are required:
209 - SRAT (System Resource Affinity Table), section 5.2.16
211 - SLIT (System Locality distance Information Table), section 5.2.17
213 - If NUMA is supported, and the system contains heterogeneous memory,
216 - If the ACPI Platform Error Interfaces are required, the following
219 - BERT (Boot Error Record Table, section 18.3.1)
221 - EINJ (Error INJection table, section 18.6.1)
223 - ERST (Error Record Serialization Table, section 18.5)
225 - HEST (Hardware Error Source Table, section 18.3.2)
227 - SDEI (Software Delegated Exception Interface table, section 5.2.6,
228 specifically Table 5-6)
230 - AEST (Arm Error Source Table, section 5.2.6,
231 specifically Table 5-6)
233 - RAS2 (ACPI RAS2 feature table, section 5.2.21)
235 - If the system contains controllers using PCC channel, the
238 - If the system contains a controller to capture board-level system state,
242 - If NVDIMM is supported, the NFIT (NVDIMM Firmware Interface Table), section 5.2.26
244 - If video framebuffer is present, the BGRT (Boot Graphics Resource Table), section 5.2.23
246 - If IPMI is implemented, the SPMI (Server Platform Management Interface),
247 section 5.2.6, specifically Table 5-6.
249 - If the system contains a CXL Host Bridge, the CEDT (CXL Early Discovery
250 Table), section 5.2.6, specifically Table 5-6.
252 …- If the system supports MPAM, the MPAM (Memory Partitioning And Monitoring table), section 5.2.6,
253 specifically Table 5-6.
255 - If the system lacks persistent storage, the IBFT (ISCSI Boot Firmware
256 Table), section 5.2.6, specifically Table 5-6.
260 able to boot properly since it may not be able to configure all of the
267 --------------
273 In non-driver code, if the presence of ACPI needs to be detected at
279 ------------------
283 ACPI can be useful -- the driver takes into account that it may have less
292 value, this can be done in an ACPI method; all the driver needs to do is
293 invoke the method and not concern itself with what the method needs to do
295 by changing what the ACPI method does, and not the driver.
303 are always multiple ways to describe the same thing -- including device
309 wide registry that maintains a list of names, minimizing re-use; (3)
311 again making re-use difficult; and (4) how does one maintain backward
312 compatibility as new hardware comes out? The _DSD method was created
314 use the _DSD method for device properties and nothing else.
331 - UUID: daffd814-6eba-4d8c-8a91-bc9bbf4aa301
336 but not as "uefi-" common properties.
370 ------------------------------------
380 get that to work, ACPI assumes each device has defined D-states and that these
382 in ACPI, _PS0 is the method to invoke to turn a device full on, and _PS3 is for
387 - be managed in a _PSx method which gets called on entry to power
390 - be declared separately as power resources with their own _ON and _OFF
391 methods. They are then tied back to D-states for a particular device
399 - If either _PS0 or _PS3 is implemented, then the other method must also
402 - If a device requires usage or setup of a power resource when on, the ASL
403 should organize that it is allocated/enabled using the _PS0 method.
405 - Resources allocated or enabled in the _PS0 method should be disabled
406 or de-allocated in the _PS3 method.
408 - Firmware will leave the resources in a reasonable state before handing
413 and avoid having to read special non-standard values from ACPI tables. Further,
419 ------
420 ACPI makes the assumption that clocks are initialized by the firmware --
421 UEFI, in this case -- to some working value before control is handed over
422 to the kernel. This has implications for devices such as UARTs, or SoC-driven
426 working values. If for some reason the frequency needs to change -- e.g.,
427 throttling for power management -- the device driver should expect that
428 process to be abstracted out into some ACPI method that can be invoked
434 If an SoC vendor wants to provide fine-grained control of the system clocks,
444 ----------------------
448 DO try to structure the driver so that it is data-driven. That is, set up
449 a struct containing internal per-device state based on defaults and whatever
471 struct device_node node = pdev->dev.of_node;
476 else if (ACPI_HANDLE(&pdev->dev))
503 ----
506 the changes being driven by Arm-specific requirements. Proposed changes are
518 If this is because of errors, quirks and fix-ups may be necessary, but will
527 ----------
533 an ACPI method invokes the _OS method. On Arm
541 ------------
547 ----------
549 document Arm-DEN-0094: "Arm Base System Architecture", version 1.0C, dated 6 Oct 2022
552 Document Arm-DEN-0044: "Arm Base Boot Requirements", version 2.0G, dated 15 Apr 2022
555 Document Arm-DEN-0029: "Arm Server Base System Architecture", version 7.1, dated 06 Oct 2022
562 https://github.com/UEFI/DSD-Guide/blob/main/dsd-guide.pdf
570 -------
571 - Al Stone <[email protected]>
572 - Graeme Gregory <[email protected]>
573 - Hanjun Guo <[email protected]>
575 - Grant Likely <[email protected]>, for the "Why ACPI on ARM?" section