diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/arch/x86.rst | 28 | ||||
| -rw-r--r-- | doc/device-tree-bindings/device.txt | 36 |
2 files changed, 64 insertions, 0 deletions
diff --git a/doc/arch/x86.rst b/doc/arch/x86.rst index a441738ad1..c6b70ce61a 100644 --- a/doc/arch/x86.rst +++ b/doc/arch/x86.rst @@ -712,6 +712,34 @@ to load a 'u-boot-payload.efi', see below test logs on QEMU. See :doc:`../uefi/u-boot_on_efi` and :doc:`../uefi/uefi` for details of EFI support in U-Boot. +Chain-loading +------------- +U-Boot can be chain-loaded from another bootloader, such as coreboot or +Slim Bootloader. Typically this is done by building for targets 'coreboot' or +'slimbootloader'. + +For example, at present we have a 'coreboot' target but this runs very +different code from the bare-metal targets, such as coral. There is very little +in common between them. + +It is useful to be able to boot the same U-Boot on a device, with or without a +first-stage bootloader. For example, with chromebook_coral, it is helpful for +testing to be able to boot the same U-Boot (complete with FSP) on bare metal +and from coreboot. It allows checking of things like CPU speed, comparing +registers, ACPI tables and the like. + +To do this you can use ll_boot_init() in appropriate places to skip init that +has already been done by the previous stage. This works by setting a +GD_FLG_NO_LL_INIT flag when U-Boot detects that it is running from another +bootloader. + +With this feature, you can build a bare-metal target and boot it from +coreboot, for example. + +Note that this is a development feature only. It is not intended for use in +production environments. Also it is not currently part of the automated tests +so may break in the future. + TODO List --------- - Audio diff --git a/doc/device-tree-bindings/device.txt b/doc/device-tree-bindings/device.txt new file mode 100644 index 0000000000..27bd3978d9 --- /dev/null +++ b/doc/device-tree-bindings/device.txt @@ -0,0 +1,36 @@ +Devices +======= + +Device bindings are described by their own individual binding files. + +U-Boot provides for some optional properties which are documented here. See +also hid-over-i2c.txt which describes HID devices. See also +Documentation/firmware-guide/acpi/enumeration.rst in the Linux kernel for +the acpi,compatible property. + + - acpi,has-power-resource : (boolean) true if this device has a power resource. + This causes an ACPI PowerResource to be written containing the properties + provided by this binding, to describe how to handle powering the device up + and down using GPIOs + - acpi,compatible : compatible string to report + - acpi,ddn : Contains the string to use as the _DDN (DOS (Disk Operating + System) Device Name) + - acpi,hid : Contains the string to use as the HID (Hardware ID) + identifier _HID + - acpi,uid : _UID value for device + - linux,probed : Tells U-Boot to add 'linux,probed' to the ACPI tables so that + Linux will only load the driver if the device can be detected (e.g. on I2C + bus). Note that this is an out-of-tree Linux feature. + + +Example +------- + +elan_touchscreen: elan-touchscreen@10 { + compatible = "i2c-chip"; + reg = <0x10>; + acpi,hid = "ELAN0001"; + acpi,ddn = "ELAN Touchscreen"; + interrupts-extended = <&acpi_gpe GPIO_21_IRQ IRQ_TYPE_EDGE_FALLING>; + linux,probed; +}; |