Searched +full:boot +full:- +full:method (Results 1 – 25 of 108) sorted by relevance
12345
| /Documentation/devicetree/bindings/arm/hisilicon/controller/ |
| D | hip04-bootwrapper.yaml | 1 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
3 ---
4 $id: http://devicetree.org/schemas/arm/hisilicon/controller/hip04-bootwrapper.yaml#
5 $schema: http://devicetree.org/meta-schemas/core.yaml#
7 title: Bootwrapper boot method
10 - Wei Xu <xuwei5@hisilicon.com>
12 description: Bootwrapper boot method (software protocol on SMP)
17 - const: hisilicon,hip04-bootwrapper
19 boot-method:
20 $ref: /schemas/types.yaml#/definitions/uint32-array
[all …]
|
| /Documentation/firmware-guide/acpi/ |
| D | chromeos-acpi-device.rst | 1 .. SPDX-License-Identifier: GPL-2.0
11 .. flat-table:: Supported ACPI Objects
13 :header-rows: 1
15 * - Object
16 - Description
18 * - CHSW
19 - Chrome OS switch positions
21 * - HWID
22 - Chrome OS hardware ID
24 * - FWID
[all …]
|
| D | method-tracing.rst | 1 .. SPDX-License-Identifier: GPL-2.0
15 method tracing facility.
20 ACPICA provides method tracing capability. And two functions are
24 -----------
28 ACPI_DEBUG_PRINT() macro can be reduced at 2 levels - per-component
30 /sys/module/acpi/parameters/debug_layer) and per-type level (known as
33 But when the particular layer/level is applied to the control method
37 logs when the control method evaluation is started, and disable the
38 detailed logging when the control method evaluation is stopped.
52 control method is being evaluated::
[all …]
|
| D | debug.rst | 1 .. SPDX-License-Identifier: GPL-2.0
10 Compile-time configuration
16 Boot- and run-time configuration
20 you're interested in. At boot-time, use the acpi.debug_layer and
21 acpi.debug_level kernel command line options. After boot, you can use the
32 You can set the debug_layer mask at boot-time using the acpi.debug_layer
33 command line argument, and you can change it after boot by writing values
59 those related to initialization, method execution, informational messages, etc.
66 You can set the debug_level mask at boot-time using the acpi.debug_level
67 command line argument, and you can change it after boot by writing values
[all …]
|
| /Documentation/devicetree/bindings/arm/bcm/ |
| D | brcm,bcm63138.txt | 1 Broadcom BCM63138 DSL System-on-a-Chip device tree bindings
2 -----------------------------------------------------------
4 Boards compatible with the BCM63138 DSL System-on-a-Chip should have the
11 An optional Boot lookup table Device Tree node is required for secondary CPU
13 defined in reset/brcm,bcm63138-pmb.txt for this secondary CPU, and an
14 'enable-method' property.
16 Required properties for the Boot lookup table node:
17 - compatible: should be "brcm,bcm63138-bootlut"
18 - reg: register base address and length for the Boot Lookup table
21 - enable-method: should be "brcm,bcm63138"
[all …]
|
| /Documentation/arch/arm64/ |
| D | cpu-hotplug.rst | 1 .. SPDX-License-Identifier: GPL-2.0
10 CPUs that were not available during boot to be added to the system later.
15 CPU Hotplug on physical systems - CPUs not present at boot
16 ----------------------------------------------------------
34 boot to discover the system wide supported features. ACPI's MADT GICC
42 CPU Hotplug on virtual systems - CPUs not enabled at boot
43 ---------------------------------------------------------
46 ever have can be described at boot. There are no power-domain considerations
63 that firmware wishes to disable either from boot (or later) should not be
65 bit set, to indicate they can be enabled later. The boot CPU must be marked as
[all …]
|
| D | arm-acpi.rst | 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
[all …]
|
| D | acpi_object_usage.rst | 16 - Required: DSDT, FADT, GTDT, MADT, MCFG, RSDP, SPCR, XSDT
18 - Recommended: BERT, EINJ, ERST, HEST, PCCT, SSDT
20 - Optional: AGDI, BGRT, CEDT, CPEP, CSRT, DBG2, DRTM, ECDT, FACS, FPDT,
24 - Not supported: AEST, APMT, BOOT, DBGP, DMAR, ETDT, HPET, IVRS, LPIT,
41 This table describes a non-maskable event, that is used by the platform
53 **Boot Error Record Table**
58 BOOT Signature Reserved (signature == "BOOT")
60 **simple BOOT flag table**
66 **Boot Graphics Resource Table**
68 Optional, not currently supported, with no real use-case for an
[all …]
|
| D | booting.rst | 13 (EL0 - EL3), with EL0, EL1 and EL2 having a secure and a non-secure
17 For the purposes of this document, we will use the term `boot loader`
21 preparing a minimal boot environment.
23 Essentially, the boot loader should provide (as a minimum) the
33 ---------------------------
37 The boot loader is expected to find and initialise all RAM that the
41 the RAM in the machine, or any other method the boot loader designer
46 -------------------------
50 The device tree blob (dtb) must be placed on an 8-byte boundary and must
59 ------------------------------
[all …]
|
| /Documentation/arch/arm/ |
| D | booting.rst | 9 The following documentation is relevant to 2.4.18-rmk6 and beyond.
11 In order to boot ARM Linux, you require a boot loader, which is a small
12 program that runs before the main kernel. The boot loader is expected
16 Essentially, the boot loader should provide (as a minimum) the
28 ---------------------------
30 Existing boot loaders:
32 New boot loaders:
35 The boot loader is expected to find and initialise all RAM that the
39 the RAM in the machine, or any other method the boot loader designer
44 -----------------------------
[all …]
|
| /Documentation/PCI/ |
| D | acpi-info.rst | 1 .. SPDX-License-Identifier: GPL-2.0
12 method for accessing PCI config space below it, the address space windows
34 know early in boot, before it can parse the ACPI namespace. If a new table
39 If the OS is expected to manage a non-discoverable device described via
50 These are all device-specific, non-architected things, so the only way a
52 the device-specific details. The host bridge registers also include ECAM
66 bridge registers (including ECAM space) in PNP0C02 catch-all devices [6].
67 With the exception of ECAM, the bridge register space is device-specific
78 PNP0C02 "motherboard" devices are basically a catch-all. There's no
84 The PCIe spec requires the Enhanced Configuration Access Method (ECAM)
[all …]
|
| /Documentation/arch/riscv/ |
| D | boot.rst | 1 .. SPDX-License-Identifier: GPL-2.0
4 RISC-V Kernel Boot Requirements and Constraints
10 This document describes what the RISC-V kernel expects from bootloaders and
12 touching the early boot process. For the purposes of this document, the
13 ``early boot process`` refers to any code that runs before the final virtual
16 Pre-kernel Requirements and Constraints
19 The RISC-V kernel expects the following of bootloaders and platform firmware:
22 --------------
24 The RISC-V kernel expects:
30 ---------
[all …]
|
| /Documentation/virt/kvm/s390/ |
| D | s390-pv-boot.rst | 1 .. SPDX-License-Identifier: GPL-2.0
4 s390 (IBM Z) Boot/IPL of Protected VMs
8 -------
13 Documentation/virt/kvm/s390/s390-pv.rst for details."
15 On IPL (boot) a small plaintext bootloader is started, which provides
28 executables and data via every available method (network, dasd, scsi,
29 direct kernel, ...) without the need to change the boot process.
33 -------
36 IPL information blocks, that specify the IPL method/devices and
46 The new PV load-device-specific-parameters field specifies all data
[all …]
|
| /Documentation/devicetree/bindings/arm/ |
| D | cpus.yaml | 1 # SPDX-License-Identifier: GPL-2.0
3 ---
5 $schema: http://devicetree.org/meta-schemas/core.yaml#
10 - Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
21 with updates for 32-bit and 64-bit ARM systems provided in this document.
30 - square brackets define bitfields, eg reg[7:0] value of the bitfield in
59 On 32-bit ARM v7 or later systems this property is
68 On ARM v8 64-bit systems this property is required
71 * If cpus node's #address-cells property is set to 2
79 * If cpus node's #address-cells property is set to 1
[all …]
|
| /Documentation/admin-guide/nfs/ |
| D | nfsroot.rst | 10 Updated 2006 by Nico Schottelius <nico-kernel-nfsroot@schottelius.org>
18 In order to use a diskless system, such as an X-terminal or printer server for
19 example, it is necessary for the root filesystem to be present on a non-disk
21 Documentation/filesystems/ramfs-rootfs-initramfs.rst), a ramdisk (see
22 Documentation/admin-guide/initrd.rst) or a filesystem mounted via NFS. The
34 built-in during configuration. Once this has been selected, the nfsroot
47 When the kernel has been loaded by a boot loader (see below) it needs to be
54 This is necessary to enable the pseudo-NFS-device. Note that it's not a
59 nfsroot=[<server-ip>:]<root-dir>[,<nfs-options>]
63 <server-ip> Specifies the IP address of the NFS server.
[all …]
|
| /Documentation/trace/ |
| D | debugging.rst | 11 - Written for: 6.12
14 ------------
21 $ sudo mount -t tracefs tracefs /sys/kernel/tracing
25 --------------------
57 ------------------------
77 buffers is broken up into sub-buffers that are by default PAGE_SIZE. The
82 -------------------------------
86 following boot. There's two ways to reserve memory for the use of the ring
92 advantage of using this method, is that the memory for the ring buffer will
107 at boot is with the "reserve_mem" option::
[all …]
|
| /Documentation/ABI/stable/ |
| D | sysfs-bus-mhi | 6 using a BHI (Boot Host Interface) register read after at least
17 obtained using a BHI (Boot Host Interface) register read after
28 a reset of last resort, and will require a complete re-init.
29 This can be useful as a method of recovery if the device is
30 non-responsive, or as a means of loading new firmware as a
37 Description: Writing a non-zero value to this file will force devices to
|
| /Documentation/arch/x86/ |
| D | microcode.rst | 1 .. SPDX-License-Identifier: GPL-2.0
7 :Authors: - Fenghua Yu <fenghua.yu@intel.com>
8 - Borislav Petkov <bp@suse.de>
9 - Ashok Raj <ashok.raj@intel.com>
13 updating the microcode on platforms beyond the OEM End-Of-Life support,
14 and updating the microcode on long-running systems without rebooting.
21 The kernel can update microcode very early during boot. Loading
23 kernel boot time.
25 The microcode is stored in an initrd file. During boot, it is read from
30 loader parses the combined initrd image during boot.
[all …]
|
| /Documentation/admin-guide/acpi/ |
| D | ssdt-overlays.rst | 1 .. SPDX-License-Identifier: GPL-2.0
7 In order to support ACPI open-ended hardware configurations (e.g. development
46 Method (_CRS, 0, Serialized)
59 ASL Optimizing Compiler version 20140214-64 [Mar 29 2014]
60 Copyright (c) 2000 - 2014 Intel Corporation
62 ASL Input: minnomax.asl - 30 lines, 614 bytes, 7 keywords
63 AML Output: minnowmax.aml - 165 bytes, 6 named objects, 1 executable opcodes
90 mkdir -p kernel/firmware/acpi
95 find kernel | cpio -H newc --create > /boot/instrumented_initrd
96 cat /boot/initrd >>/boot/instrumented_initrd
[all …]
|
| /Documentation/ABI/removed/ |
| D | sysfs-selinux-disable | 3 KernelVersion: 2.6.12-rc2 (predates git)
14 The preferred method of disabling SELinux is via the "selinux=0" boot
|
| /Documentation/arch/powerpc/ |
| D | bootwrapper.rst | 2 The PowerPC boot wrapper
8 a boot wrapper to make it usable by the system firmware. There is no
9 standard PowerPC firmware interface, so the boot wrapper is designed to
12 The boot wrapper can be found in the arch/powerpc/boot/ directory. The
17 others. U-Boot is typically found on embedded PowerPC hardware, but there
21 The boot wrapper is built from the makefile in arch/powerpc/boot/Makefile and
22 it uses the wrapper script (arch/powerpc/boot/wrapper) to generate target
28 U-Boot (for versions that don't understand the device
30 the image. The boot wrapper, kernel and device tree
31 are all embedded inside the U-Boot uImage file format
[all …]
|
| D | booting.rst | 1 .. SPDX-License-Identifier: GPL-2.0
4 ------------------
9 bootloader <-> kernel interfaces, in order to avoid the degeneration that had
14 merged architecture for ppc32 and ppc64, new 32-bit platforms and 32-bit
19 of a device-tree whose format is defined after Open Firmware specification.
21 doesn't require the device-tree to represent every device in the system and only
41 a) Boot from Open Firmware. If your firmware is compatible
47 bindings to powerpc. Only the 32-bit client interface
54 extract the device-tree and other information from open
55 firmware and build a flattened device-tree as described
[all …]
|
| /Documentation/driver-api/early-userspace/ |
| D | early_userspace_support.rst | 5 Last update: 2004-12-20 tlh
15 - gen_init_cpio, a program that builds a cpio-format archive
18 - initramfs, a chunk of code that unpacks the compressed cpio image
19 midway through the kernel boot process.
20 - klibc, a userspace C library, currently packaged separately, that is
23 The cpio file format used by initramfs is the "newc" (aka "cpio -H newc")
24 format, and is documented in the file "buffer-format.txt". There are
29 CPIO ARCHIVE method
30 -------------------
38 IMAGE BUILDING method
[all …]
|
| /Documentation/devicetree/bindings/mtd/partitions/ |
| D | tplink,safeloader-partitions.yaml | 1 # SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
3 ---
4 $id: http://devicetree.org/schemas/mtd/partitions/tplink,safeloader-partitions.yaml#
5 $schema: http://devicetree.org/meta-schemas/core.yaml#
7 title: TP-Link SafeLoader partitions
10 TP-Link home routers store various data on flash (e.g. bootloader,
14 Flash space layout of TP-Link devices is stored on flash itself using
15 a custom ASCII-based format. That format was first found in TP-Link
17 CFE and U-Boot bootloaders.
21 calibration data). Others are semi-static (like kernel). Finally some
[all …]
|
| /Documentation/ABI/testing/ |
| D | evm | 7 against integrity attacks. The initial method maintains an
8 HMAC-sha1 value across the extended attributes, storing the
12 an HMAC-sha1 generated locally with a
26 2 Permit modification of EVM-protected metadata at
50 modification of EVM-protected metadata and
89 as part of the trusted boot. For more information on
92 Documentation/security/keys/trusted-encrypted.rst. Both
94 core/ima-setup) have support for loading keys at boot
106 additional attributes are configured on system boot. Writing
|
12345