summaryrefslogtreecommitdiffstats
path: root/doc
Commit message (Collapse)AuthorAgeFilesLines
* video_osd: Add ihs_video_out driverMario Six2018-09-281-0/+23
| | | | | | | Add a driver for IHS OSDs on IHS FPGAs. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Mario Six <mario.six@gdsys.cc>
* dm: Update README.txt to clarify device tree usageTom Rini2018-09-251-0/+9
| | | | | | | | | | | | | | In the section about Device Trees add a paragraph at the end that clarifies how we decide of a tree is valid or not. We say that all bindings must either be in the specification (link provided) or in our device-tree-bindings directory. We say that most of these come from the Linux Kernel and as such some design decisions are made for us already, but that in most cases we wish to retain compatibility. Cc: Simon Glass <sjg@chromium.org> Cc: Bin Meng <bmeng.cn@gmail.com> Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* pinctrl: bcm6838: add pinctrl supportPhilippe Reynes2018-09-221-0/+35
| | | | | | Add pinctrl support for broadcom bcm6838 SoC. Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>
* doc/git-mailrc: add Stefan Roese to the kirkwood aliasBaruch Siach2018-09-191-1/+1
| | | | | | | | Stefan is listed as a kirkwood maintainer since commit f822d8578ba3 (MAINTAINERS: Update Marvell custodianship). Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Stefan Roese <sr@denx.de>
* remoteproc: Introduce K3 remoteproc driverLokesh Vutla2018-09-111-0/+50
| | | | | | | | Add support for K3 based remoteproc driver that communicates with TISCI to start start a remote processor. Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
* remoteproc: Introduce K3 system controllerLokesh Vutla2018-09-111-0/+24
| | | | | | | | | | | | | | | | | K3 specific SoCs have a dedicated microcontroller for doing resource management. Any HLOS/firmware on compute clusters should load a firmware to this microcontroller before accessing any resource. Adding support for loading this firmware. After the K3 system controller got loaded with firmware and started up it sends out a boot notification message through the secure proxy facility using the TI SCI protocol. Intercept and receive this message through the rproc start operation which will need to get invoked explicitly after the firmware got loaded. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
* mailbox: Introduce K3 Secure Proxy DriverLokesh Vutla2018-09-111-0/+40
| | | | | | | | | | Secure Proxy module manages hardware threads that are meant for communication between the processor entities. Adding support for this driver. Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
* sysreset: Add TI System Control Interface (TI SCI) sysreset driverAndreas Dannenberg2018-09-111-0/+29
| | | | | | | | | | | | | | | | | Devices from the TI K3 family of SoCs like the AM654x contain a Device Management and Security Controller (SYSFW) that manages the low-level device control (like clocks, resets etc) for the various hardware modules present on the SoC. These device control operations are provided to the host processor OS through a communication protocol called the TI System Control Interface (TI SCI) protocol. This patch adds a system reset driver that communicates to the system controller over the TI SCI protocol for allowing to perform a system- wide SoC reset. Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
* power domain: Introduce TI System Control Interface (TI SCI) power domain driverAndreas Dannenberg2018-09-111-0/+52
| | | | | | | | | | | | | | | | | | | | | | | Some TI Keystone 2 and K3 family of SoCs contain a system controller (like the Power Management Micro Controller (PMMC) on 66AK2G SoCs and the Device Management and Security Controller on AM65x SoCs) that manage the low-level device control (like clocks, resets etc) for the various hardware modules present on the SoC. These device control operations are provided to the host processor OS through a communication protocol called the TI System Control Interface (TI SCI) protocol. This patch adds a power domain driver that communicates to the system controller over the TI SCI protocol for performing power management of various devices present on the SoC. Various power domain functionalities are achieved by the means of different TI SCI device operations provided by the TI SCI framework. This code is loosely based on the drivers/soc/ti/ti_sci_pm_domains.c driver of the Linux kernel. Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
* clk: Introduce TI System Control Interface (TI SCI) clock driverAndreas Dannenberg2018-09-111-0/+53
| | | | | | | | | | | | | | | | | | | | | | | | Some TI Keystone 2 and K3 family of SoCs contain a system controller (like the Power Management Micro Controller (PMMC) on 66AK2G SoCs and the Device Management and Security Controller on AM65x SoCs) that manage the low-level device control (like clocks, resets etc) for the various hardware modules present on the SoC. These device control operations are provided to the host processor OS through a communication protocol called the TI System Control Interface (TI SCI) protocol. This patch adds a clock driver that communicates to the system controller over the TI SCI protocol for performing clock management of various devices present on the SoC. Various clock functionality is achieved by the means of different TI SCI device operations provided by the TI SCI framework. This code is loosely based on the drivers/clk/keystone/sci-clk.c driver of the Linux kernel. Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Signed-off-by: Vignesh R <vigneshr@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
* reset: Introduce TI System Control Interface (TI SCI) reset driverAndreas Dannenberg2018-09-111-0/+54
| | | | | | | | | | | | | | | | | | | | | | | Some TI Keystone 2 and K3 family of SoCs contain a system controller (like the Power Management Micro Controller (PMMC) on 66AK2G SoCs and the Device Management and Security Controller on AM65x SoCs) that manage the low-level device control (like clocks, resets etc) for the various hardware modules present on the SoC. These device control operations are provided to the host processor OS through a communication protocol called the TI System Control Interface (TI SCI) protocol. This patch adds a reset driver that communicates to the system controller over the TI SCI protocol for performing reset management of various devices present on the SoC. Various reset functionalities are achieved by the means of different TI SCI device operations provided by the TI SCI framework. This code is loosely based on the drivers/reset/reset-ti-sci.c driver of the Linux kernel. Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
* firmware: Add basic support for TI System Control Interface (TI SCI) protocolLokesh Vutla2018-09-111-0/+76
| | | | | | | | | | | | | | | | | | | | Texas Instrument's System Control Interface (TI SCI) message protocol is used in Texas Instrument's System on Chip (SoC) such as those in the K3 family AM654 SoC to communicate between various compute processors with a central system controller entity. The TI SCI message protocol provides support for management of various hardware entities within the SoC. Add support driver to allow communication with system controller entity within the SoC using the mailbox client. This is mostly derived from the TI SCI driver in Linux located at drivers/firmware/ti_sci.c. Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
* arm: armv7-a: Compile and tune for armv7-a instead of armv5Adam Ford2018-09-101-7/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | arch/arm/Makefile references armv5 for backwards compatibility with older compilers. This patch removes those references to armv5, since by now newer compilers are required which should have armv7 support enabled. The Makefile also also has a list of options for mtune, but the entry for CONFIG_CPU_V7A is empty, so this patch tunes the CPU_V7A architecture to generic-armv7-a. The following size changed apply to omap3_logic using GCC. Stock text data bss dec hex filename 50910 429 67580 118919 1d087 spl/u-boot-spl 540713 22700 327072 890485 d9675 u-boot Without Armv5 text data bss dec hex filename 50916 429 67580 118925 1d08d spl/u-boot-spl 540719 22700 327064 890483 d9673 u-boot mtune=generic-armv7-a text data bss dec hex filename 50932 429 67580 118941 1d09d spl/u-boot-spl 540519 22700 327080 890299 d95bb u-boot Signed-off-by: Adam Ford <aford173@gmail.com>
* Merge git://git.denx.de/u-boot-x86Tom Rini2018-08-201-22/+0
|\
| * x86: dts: Remove coreboot_fb.dtsiBin Meng2018-08-201-7/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | There is no need to keep a separate coreboot_fb.dtsi since now we have a generic coreboot payload dts. While we are here, this also remove the out-of-date description in the documentation regarding to coreboot framebuffer driver with U-Boot loaded as a payload from coreboot. As the testing result with QEMU 2.5.0 shows, the driver just works like a charm. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * x86: coreboot: Add generic coreboot payload supportBin Meng2018-08-201-15/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently building U-Boot as the coreboot payload requires user to change the build configuration for a specific board during menuconfig process. This uses the board's native device tree to configure the hardware. For example, the device tree provides PCI address range for the PCI host controller and U-Boot will re-program all PCI devices' BAR to be within this range. In order to make sure we don't mess up the hardware, we should guarantee the range matches what coreboot programs the chipset. But we really should make the coreboot payload support easier. Just like EFI payload, we can create a generic coreboot payload for all x86 boards as well. The payload is configured to include as many generic drivers as possible. All stuff that touches low level initialization are not allowed as such is the coreboot's responsibility. Platform specific drivers (like gpio, spi, etc) are not included. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
* | doc: FIT image: fix typoPierre-Jean Texier2018-08-201-1/+1
| | | | | | | | | | | | Fix typo in beaglebone verified boot documentation. Signed-off-by: Pierre-Jean Texier <texier.pj2@gmail.com>
* | drivers: regulator: fixed: add u-boot, off-on-delay-usPeng Fan2018-08-191-0/+1
|/ | | | | | | | | | | | | | Add u-boot,off-on-delay-us for fixed regulator. Depends on board design, the gpio regulator sometimes connects with a big capacitance. When need to off, then on the regulator, if there is no enough delay, the voltage does not drop to 0, so introduce this property to handle such case. Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Simon Glass <sjg@chromium.org> Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
* doc: FIT image: clarify usage of "compression" propertySimon Goldschmidt2018-08-101-1/+3
| | | | | | | | | | Compressed images should have their compression property set to "none" if U-Boot should leave them compressed. This is especially the case for compressed ramdisks that should be uncompressed by the kernel only. Signed-off-by: Simon Goldschmidt <sgoldschmidt@de.pepperl-fuchs.com>
* doc: README.iscsi: make compatible with restructured textHeinrich Schuchardt2018-08-101-62/+68
| | | | | | | The Sphinx documentation system uses restructured text. Make the README.iscsi file compatible. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
* Merge branch 'master' of git://git.denx.de/u-boot-usbTom Rini2018-08-101-3/+8
|\
| * usb: rockchip: implement K_FW_LBA_ERASE_10 commandAlberto Panizzo2018-08-081-0/+1
| | | | | | | | | | | | | | | | | | This command is part of the write partition sequence performed by rkdeveloptool: one partition is first completely erased and than wrote. Signed-off-by: Alberto Panizzo <alberto@amarulasolutions.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * usb: rockchip: implement K_FW_LBA_READ_10 commandAlberto Panizzo2018-08-081-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implement reading blocks form selected device with LBA addressing. Corresponding command on workstation is: rkdeveloptool rl <start_blk> <blk_cnt> <file> While we support reading more than one blocks per K_FW_LBA_READ_10 request, rkdeveloptool and original rockchip tool do perform chunk reads limiting the maximum size per chunk far lower than max int values. Signed-off-by: Alberto Panizzo <alberto@amarulasolutions.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * usb: rockchip: implement skeleton for K_FW_GET_CHIP_VER commandAlberto Panizzo2018-08-081-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | Chip Version is a string saved in BOOTROM address space Little Endian. Ex for rk3288: 0x33323041 0x32303134 0x30383133 0x56323030 which brings: 320A20140813V200 Note that memory version do invert MSB/LSB so printing the char buffer would show: A02341023180002V Signed-off-by: Alberto Panizzo <alberto@amarulasolutions.com>
* | pci: sandbox: Support dynamically binding device driverBin Meng2018-08-081-0/+28
|/ | | | | | | | | | At present all emulated sandbox pci devices must be present in the device tree in order to be used. The real world pci uclass driver supports pci device driver matching, and we should add such support on sandbox too. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* dt-bindings: Document STM32 ADC DT bindingsFabrice Gasnier2018-08-031-0/+141
| | | | | | | | | This patch adds documentation of device tree bindings for the STM32 ADC. It's based on linux-v4.18-rc* dt-bindings, at the time of writing: - Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* CREG GPIO: add device tree bindingsEugeniy Paltsev2018-07-311-0/+43
| | | | | Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com> Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
* Merge tag 'signed-efi-next' of git://github.com/agraf/u-bootTom Rini2018-07-301-2/+0
|\ | | | | | | | | | | | | | | | | | | | | Patch queue for efi - 2018-07-25 Highlights this time: - Many small fixes to improve spec compatibility (found by SCT) - Almost enough to run with sandbox target - GetTime() improvements - Enable EFI_LOADER and HYP entry on ARMv7 with NONSEC=y
| * Revert "efi_loader: no support for ARMV7_NONSEC=y"Mark Kettenis2018-07-251-2/+0
| | | | | | | | | | | | | | | | | | This reverts commit c524997acb3d322e1bbd36c06ad02ef589705e7c. Booting ARMv7 in non-secure mode using bootefi works now. Signed-off-by: Mark Kettenis <kettenis@openbsd.org> Signed-off-by: Alexander Graf <agraf@suse.de>
* | Merge git://git.denx.de/u-boot-dmTom Rini2018-07-262-3/+3
|\ \
| * | doc: driver-model: Fix typoChris Packham2018-07-261-1/+1
| | | | | | | | | | | | | | | Signed-off-by: Chris Packham <judge.packham@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * | git-mailrc: Replace tabs with spaces in alias entriesAdam Sampson2018-07-261-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | patman's _ReadAliasFile only splits on spaces, not tabs, so the entries for dinh and maxime weren't being recognised as valid. I'll fix patman in a separate patch, but this makes all the entries consistent. Signed-off-by: Adam Sampson <ats@offog.org> Reviewed-by: Simon Glass <sjg@chromium.org>
* | | MAINTAINERS: Mark NAND as OrphanedTom Rini2018-07-261-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | Scott is no longer maintaining the NAND subsystem, mark as orphaned for now. Acked-by: Scott Wood <oss@buserror.net> Signed-off-by: Tom Rini <trini@konsulko.com>
* | | Merge branch 'master' of git://git.denx.de/u-boot-uniphierTom Rini2018-07-241-0/+55
|\ \ \
| * | | ARM: uniphier: enable distro bootMasahiro Yamada2018-07-251-0/+55
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Switch to the distro boot for UniPhier platform. - Remove the environment vairalbes used to load images from raw block devices. - Keep the command to download images via tftp. This will be useful to boot the kernel when no valid kernel image is ready yet in the file system. - Use root.cpio.gz instead of root.cpio.uboot because we always know the file size of the init ramdisk; it is loaded via either a file system or network. - Rename fit_addr_r to kernel_addr_r, which the distro command checks to get the load address of FIT image. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* | | doc: Move device tree bindings documentation to doc/device-tree-bindingsBreno Lima2018-07-243-0/+111
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently the U-Boot project contains 2 documentation directories: - doc/ - Documentation/ The Documentation directory only contains device tree bindings related content, so move the 3 files to doc/device-tree-bindings/. Signed-off-by: Breno Lima <breno.lima@nxp.com>
* | | avb2.0: add proper dependenciesIgor Opaniuk2018-07-241-0/+1
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1. Since libavb library alone is highly portable, introduce dedicated Kconfig symbol for AVB bootloader-dependent operations, so it's possible to build libavb separately. AVB bootloader-dependent operations include: * Helpers to process strings in order to build OS bootargs. * Helpers to access MMC, similar to drivers/fastboot/fb_mmc.c. * Helpers to alloc/init/free avb ops. 2. Add CONFIG_FASTBOOT dependency, as fastboot buffer is re-used in partition verification operations. Reported-by: Eugeniu Rosca <rosca.eugeniu@gmail.com> Signed-off-by: Igor Opaniuk <igor.opaniuk@linaro.org> Reviewed-by: Eugeniu Rosca <rosca.eugeniu@gmail.com> Tested-by: Eugeniu Rosca <rosca.eugeniu@gmail.com>
* | doc: Replace DocBook with sphinx-based docsMario Six2018-07-237-372/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Linux kernel moved to sphinx-based documentation and got rid of the DocBook based documentation quite a while ago. Hence, the DocBook documentation for U-Boot should be converted as well. To achieve this, import the necessary files from Linux v4.17, and convert the current DocBook documentation (three files altogether) to sphinx/reStructuredText. For now, all old DocBook documentation was merged into a single handbook, tentatively named "U-Boot Hacker Manual". For some source files, the documentation style was changed to comply with kernel-doc; no functional changes were applied. Signed-off-by: Mario Six <mario.six@gdsys.cc>
* | rockchip: doc: clarify usage of CONFIG_SPL_ROCKCHIP_BACK_TO_BROMHeinrich Schuchardt2018-07-211-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | Change the description relating to CONFIG_SPL_ROCKCHIP_BACK_TO_BROM to clarify that both RK3288 and RK3036 use CONFIG_SPL_ROCKCHIP_BACK_TO_BROM=y Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Acked-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
* | spl: document 'chosen/u-boot, spl-boot-device'Philipp Tomsich2018-07-211-0/+10
|/ | | | | | | | | | | | | To let the full U-Boot know where it was booted from (i.e. which of the entries in /chosen/u-boot,spl-boot-order' contained a valid image), we define (and document) /chosen/u-boot,spl-boot-device as the property that could/should automatically be injected by SPL. This commit only contains a documentation change, which documents the new property and the intended usage. Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Tested-by: Klaus Goger <klaus.goger@theobroma-systems.com>
* stm32mp1: clk: support digital bypassPatrick Delaunay2018-07-201-1/+3
| | | | | | | | | HSE and LSE bypass shall support both analog and digital signals. This patch add a way to select digital bypas case in the device tree and set the associated bit DIGBYP in RCC_BDCR and RCC_OCEN register during clock tree initialization. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
* board: arm: Add support for Broadcom BCM7445Thomas Fitzsimmons2018-07-101-0/+150
| | | | | | | | | | | | Add support for loading U-Boot on the Broadcom 7445 SoC. This port assumes Broadcom's BOLT bootloader is acting as the second stage bootloader, and U-Boot is acting as the third stage bootloader, loaded as an ELF program by BOLT. Signed-off-by: Thomas Fitzsimmons <fitzsim@fitzsim.org> Cc: Stefan Roese <sr@denx.de> Cc: Tom Rini <trini@konsulko.com> Cc: Florian Fainelli <f.fainelli@gmail.com>
* fdt: Add device tree memory bindingsMichael Pratt2018-07-091-0/+67
| | | | | | | | | | | | | | Support a default memory bank, specified in reg, as well as board-specific memory banks in subtree board-id nodes. This allows memory information to be provided in the device tree, rather than hard-coded in, which will make it simpler to handle similar devices with different memory banks, as the board-id values or masks can be used to match devices. Signed-off-by: Michael Pratt <mpratt@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
* tegra: nyan-big: Update CONFIG_SYS_TEXT to the default in README.chromiumPeter Robinson2018-07-061-20/+7
| | | | | | | | | | | | To build U-Boot on a Nyan Big Chromebook the docs outline adjusting the Tegra124 defined CONFIG_SYS_TEXT_BASE but this has since been moved to individual config files. We should have the default required for U-Boot chain loading on the chromebook as the default CONFIG_SYS_TEXT_BASE and update the docs to remove this now non required step. Signed-off-by: Peter Robinson <pbrobinson@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Warren <twarren@nvidia.com>
* doc: vxworks: Mention chain-loading an x86 kernel via 'bootefi'Bin Meng2018-07-021-6/+12
| | | | | | | | | This updates the doc to mention chain-loading an x86 kernel via 'bootefi' command, along with several typos fix. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Alexander Graf <agraf@suse.de>
* x86: doc: Update EFI loader supportBin Meng2018-07-021-2/+27
| | | | | | | | CONFIG_EFI_LOADER is fully supported on x86 now. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Alexander Graf <agraf@suse.de>
* doc: avb2.0: add README about AVB2.0 integrationIgor Opaniuk2018-06-181-0/+97
| | | | | | | | | | | Contains: 1. Overview of Android Verified Boot 2.0 2. Description of avb subset of commands 3. Examples of errors when boot/vendor/system/vbmeta partitions are tampered 4. Examples of enabling AVB2.0 on your setup Signed-off-by: Igor Opaniuk <igor.opaniuk@linaro.org>
* x86: Rename efi-x86 target to efi-x86_appBin Meng2018-06-171-4/+4
| | | | | | | To avoid confusion, let's rename the efi-x86 target to efi-x86_app. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* x86: Add generic EFI payload supportBin Meng2018-06-171-10/+9
| | | | | | | | | | | It is possible to create a generic EFI payload for all x86 boards. The payload is configured to include as many generic drivers as possible. All stuff that touches low-level initialization are not allowed as such is the EFI BIOS's responsibility. Platform specific drivers (like gpio, spi, etc) are not included. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* x86: efi: Refactor the directory of EFI app and payload supportBin Meng2018-06-171-5/+1
| | | | | | | | | | | | | | At present the EFI application and payload support codes in the x86 directory is distributed in a hybrid way. For example, the Kconfig options for both app and payload are in arch/x86/lib/efi/Kconfig, but the source codes in the same directory get built only for CONFIG_EFI_STUB. This refactors the codes by consolidating all the EFI support codes into arch/x86/cpu/efi, just like other x86 targets. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
generated by cgit (git 2.34.1) at 2024-11-20 15:18:43 +0000