summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2020-10-05Merge branch 'next'Tom Rini256-566/+17862
Bring in the assorted changes that have been staged in the 'next' branch prior to release. Signed-off-by: Tom Rini <trini@konsulko.com>
2020-10-05Merge tag 'u-boot-atmel-2021.01-a' of ↵Tom Rini8-0/+1019
https://gitlab.denx.de/u-boot/custodians/u-boot-atmel into next First set of u-boot-atmel features for 2021.01 cycle: This feature set includes a new CPU driver for at91 family, new driver for PIT64B hardware timer, support for new at91 family SoC named sama7g5 which adds: clock support, including conversion of the clock tree to CCF; SoC support in mach-at91, pinctrl and mmc drivers update. The feature set also includes updates for mmc driver and some other minor fixes and features regarding building without the old Atmel PIT and the possibility to read a secondary MAC address from a second i2c EEPROM.
2020-10-02ARM: dts: stm32mp1: DT alignment with Linux kernel v5.9-rc4Patrick Delaunay7-19/+318
DT alignment with Linux kernel v5.9-rc4 for the STM32MP15x soc device tree files and the STMicroelectronics boards device tree files. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
2020-10-02ARM: dts: stm32: Add missing dm-spl props for SPI NOR on AV96Marek Vasut1-0/+21
The u-boot,dm-spl DT props are missing on AV96, hence the pinmux and flash0 nodes are not included in the reduced SPL DT. This prevents SPI NOR boot from working at all. Fix this by filling them in. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Patrick Delaunay <patrick.delaunay@st.com> Cc: Patrice Chotard <patrice.chotard@st.com> Reviewed-by: Patrice Chotard <patrice.chotard@st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@st.com>
2020-10-01Merge branch 'next' of git://git.denx.de/u-boot-sh into nextTom Rini14-7/+4354
2020-09-30firmware: smci: sandbox test for SCMI reset controllersEtienne Carriere2-0/+23
Add tests for SCMI reset controllers. A test device driver sandbox-scmi_devices.c is used to get reset resources, allowing further resets manipulation. Change sandbox-smci_agent to emulate 1 reset controller exposed through an agent. Add DM test scmi_resets to test this reset controller. Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org> Cc: Simon Glass <sjg@chromium.org> Cc: Peng Fan <peng.fan@nxp.com> Cc: Sudeep Holla <sudeep.holla@arm.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-30firmware: scmi: sandbox test for SCMI clocksEtienne Carriere2-0/+54
Add tests for SCMI clocks. A test device driver sandbox-scmi_devices.c is used to get clock resources, allowing further clock manipulation. Change sandbox-smci_agent to emulate 3 clocks exposed through 2 agents. Add DM test scmi_clocks to test these 3 clocks. Update DM test sandbox_scmi_agent with load/remove test sequences factorized by {load|remove}_sandbox_scmi_test_devices() helper functions. Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org> Cc: Simon Glass <sjg@chromium.org> Cc: Peng Fan <peng.fan@nxp.com> Cc: Sudeep Holla <sudeep.holla@arm.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-30firmware: add SCMI agent uclassEtienne Carriere2-0/+59
This change introduces SCMI agent uclass to interact with a firmware using the SCMI protocols [1]. SCMI agent uclass currently supports a single method to request processing of the SCMI message by an identified server. A SCMI message is made of a byte payload associated to a protocol ID and a message ID, all defined by the SCMI specification [1]. On return from process_msg() method, the caller gets the service response. SCMI agent uclass defines a post bind generic sequence for all devices. The sequence binds all the SCMI protocols listed in the FDT for that SCMI agent device. Currently none, but later change will introduce protocols. This change implements a simple sandbox device for the SCMI agent uclass. The sandbox nicely answers SCMI_NOT_SUPPORTED to SCMI messages. To prepare for further test support, the sandbox exposes a architecture function for test application to read the sandbox emulated devices state. Currently supports 2 SCMI agents, identified by an ID in the FDT device name. The simplistic DM test does nothing yet. SCMI agent uclass is designed for platforms that embed a SCMI server in a firmware hosted somewhere, for example in a companion co-processor or in the secure world of the executing processor. SCMI protocols allow an SCMI agent to discover and access external resources as clock, reset controllers and more. SCMI agent and server communicate following the SCMI specification [1]. This SCMI agent implementation complies with the DT bindings defined in the Linux kernel source tree regarding SCMI agent description since v5.8. Links: [1] https://developer.arm.com/architectures/system-architectures/software-standards/scmi Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org> Cc: Simon Glass <sjg@chromium.org> Cc: Peng Fan <peng.fan@nxp.com> Cc: Sudeep Holla <sudeep.holla@arm.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-30test: dm: Add tests for regmap managed API and regmap fieldsJean-Jacques Hiblot1-0/+13
The tests rely on a dummy driver to allocate and initialize the regmaps and the regmap fields using the managed API. The first test checks if the regmap config fields like width, reg_offset_shift, range specifiers, etc work. The second test checks if regmap fields behave properly (mask and shift are ok) by peeking into the regmap. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-30test: gpio: Add tests for the managed APIJean-Jacques Hiblot1-0/+10
Add a test to verify that GPIOs can be acquired/released using the managed API. Also check that the GPIOs are released when the consumer device is removed. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
2020-09-30test: reset: Add tests for the managed APIJean-Jacques Hiblot1-0/+3
The tests are basically the same as for the regular API. Except that the reset are initialized using the managed API, and no freed manually. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
2020-09-30riscv: Add some comments to start.SSean Anderson1-2/+17
This adds comments regarding the ordering and purpose of certain instructions as I understand them. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Rick Chen <rick@andestech.com> Reviewed-by: Leo Liang <ycliang@andestech.com>
2020-09-30riscv: Ensure gp is NULL or points to valid dataSean Anderson2-4/+27
This ensures constructs like `if (gd & gd->...) { ... }` work when accessing the global data pointer. Without this change, it was possible for a very early trap to cause _exit_trap to directly or indirectly (through printf) to read arbitrary memory. This could cause a second trap, preventing show_regs from being printed. printf (and specifically puts) uses gd to determine what function to print with. These functions in turn use gd to find the serial device, etc. However, before accessing gd, puts first checks to see if it is non-NULL. This indicates an existing (perhaps undocumented) assumption that either gd is NULL or it is completely valid. Before this patch, gd either points to unexpected data (because it retains the value it did from the prior-stage) or points to uninitialized data (because it has not yet been initialized by board_init_f_init_reserve) until the hart has acquired available_harts_lock. This can cause two problems, depending on the value of gd->flags. If GD_FLG_SERIAL_READY is unset, then some garbage data will be printed to stdout, but there will not be a second trap. However, if GD_FLG_SERIAL_READY is set, then puts will try to print with serial_puts, which will likely cause a second trap. After this patch, gd is zero up until either a hart has set it in wait_for_gd_init, or until it is set by arch_init_gd. This prevents its usage before its data is initialized because both handle_trap and puts ensure that gd is nonzero before using it. After gd has been set, it is OK to access it because its data has been cleared (and so flags is valid). XIP cannot use locks because flash is not writable. This leaves it vulnerable to the same class of bugs regarding already-pending IPIs as before this series. Fixing that would require finding another method of synchronization, which is outside the scope of this series. Fixes: 7c6ca03eae ("riscv: additional crash information") Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Rick Chen <rick@andestech.com>
2020-09-30riscv: Consolidate fences into AMOs for available_harts_lockSean Anderson1-6/+3
We can reduce the number of instructions needed to use available_harts_lock by using the aq and rl suffixes for AMOs. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Rick Chen <rick@andestech.com>
2020-09-30riscv: Clear pending IPIs on initializationSean Anderson1-0/+20
Even though we no longer call smp_function if an IPI was not sent by U-Boot, we still need to clear any IPIs which were pending from the execution environment. Otherwise, secondary harts will busy-wait in secondary_hart_loop, instead of relaxing. Along with the previous commit ("riscv: Use a valid bit to ignore already-pending IPIs"), this fixes SMP booting on the Kendryte K210. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Rick Chen <rick@andestech.com>
2020-09-30riscv: Use a valid bit to ignore already-pending IPIsSean Anderson2-2/+21
Some IPIs may already be pending when U-Boot is started. This could be a problem if a secondary hart tries to handle an IPI before the boot hart has initialized the IPI device. To be specific, the Kendryte K210 ROM-based bootloader does not clear IPIs before passing control to U-Boot. Without this patch, the secondary hart jumps to address 0x0 as soon as it enters secondary_hart_loop, and then hangs in its trap handler. This commit introduces a valid bit so secondary harts know when and IPI originates from U-Boot, and it is safe to use the IPI API. The valid bit is initialized to 0 by board_init_f_init_reserve. Before this, secondary harts wait in wait_for_gd_init. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Rick Chen <rick@andestech.com> Reviewed-by: Leo Liang <ycliang@andestech.com>
2020-09-30riscv: Match memory barriers between send_ipi_many and handle_ipiSean Anderson1-0/+2
Without a matching barrier on the write side, the barrier in handle_ipi does nothing. It was entirely possible for the boot hart to write to addr, arg0, and arg1 *after* sending the IPI, because there was no barrier on the sending side. Fixes: 90ae281437 ("riscv: add option to wait for ack from secondary harts in smp functions") Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Rick Chen <rick@andestech.com> Reviewed-by: Leo Liang <ycliang@andestech.com>
2020-09-30Revert "riscv: Clear pending interrupts before enabling IPIs"Sean Anderson1-2/+0
Clearing MIP.MSIP is not guaranteed to do anything by the spec. In addition, most existing RISC-V hardware does nothing when this bit is set. The following commits "riscv: Use a valid bit to ignore already-pending IPIs" and "riscv: Clear pending IPIs on initialization" should implement the original intent of the reverted commit in a more robust manner. This reverts commit 9472630337e7c4ac442066b5a752aaa8c3b4d4a6. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Rick Chen <rick@andestech.com>
2020-09-30riscv: Update SiFive device tree for new CLINT driverSean Anderson2-2/+10
We currently do this in a u-boot specific dts, but hopefully we can get these bindings added in Linux in the future. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Pragnesh Patel <pragnesh.patel@openfive.com> Reviewed-by: Bin Meng <bin.meng@windriver.com>
2020-09-30riscv: Update Kendryte device tree for new CLINT driverSean Anderson1-3/+4
The interrupt controller property is removed from the clint binding because the clint is not an interrupt-controller. That is, no other devices have an interrupt which is controlled by the clint. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Bin Meng <bin.meng@windriver.com>
2020-09-30riscv: Rework Sifive CLINT as UCLASS_TIMER driverSean Anderson2-32/+34
This converts the clint driver from the riscv-specific interface to be a DM-based UCLASS_TIMER driver. In addition, the SiFive DDR driver previously implicitly depended on the CLINT to select REGMAP. Unlike Andes's PLMT/PLIC (which AFAIK never have anything pass it a dtb), the SiFive CLINT is part of the device tree passed in by qemu. This device tree doesn't have a clocks or clock-frequency property on clint, so we need to fall back on the timebase-frequency property. Perhaps in the future we can get a clock-frequency property added to the qemu dtb. Unlike with the Andes PLMT, the Sifive CLINT is also an IPI controller. RISCV_SYSCON_CLINT is retained for this purpose. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Pragnesh Patel <pragnesh.patel@openfive.com>
2020-09-30riscv: Clean up initialization in Andes PLICSean Anderson1-33/+25
This merges the PLIC initialization code from two functions into one. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Bin Meng <bin.meng@windriver.com>
2020-09-30riscv: Rework Andes PLMT as a UCLASS_TIMER driverSean Anderson4-32/+23
This converts the PLMT driver from the riscv-specific timer interface to be a DM-based UCLASS_TIMER driver. The clock-frequency/clocks properties are preferred over timebase-frequency for two reasons. First, properties which affect a device should be located near its binding in the device tree. Using timebase-frequency only really makes sense when the cpu itself is the timer device. This is the case when we read the time from a CSR, but not when there is a separate device. Second, it lets the device use the clock subsystem which adds flexibility. If the device is configured for a different clock speed, the timer can adjust itself. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Rick Chen <rick@andestech.com>
2020-09-30timer: Add a test for timer_timebase_fallbackSean Anderson2-1/+19
To test this function, sandbox CPU must set cpu_platdata.timebase_freq on bind. It also needs to expose a method to set the current cpu. I also make some most members of cpu_sandbox_ops static. On the timer side, the device tree property sandbox,timebase-frequency-fallback controls whether sandbox_timer_probe falls back to time_timebase_fallback or to SANDBOX_TIMER_RATE. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-09-30riscv: Rework riscv timer driver to only support S-modeSean Anderson6-50/+3
The riscv-timer driver currently serves as a shim for several riscv timer drivers. This is not too desirable because it bypasses the usual timer selection via the driver model. There is no easy way to specify an alternate timing driver, or have the tick rate depend on the cpu's configured frequency. The timer drivers also do not have device structs, and so have to rely on storing parameters in gd_t. Lastly, there is no initialization call, so driver init is done in the same function which reads the time. This can result in confusing error messages. To a user, it looks like the driver failed when trying to read the time, whereas it may have failed while initializing. This patch removes the shim functionality from the riscv-timer driver, and has it instead implement the former rdtime.c timer driver. This is because existing u-boot users who pass in a device tree (e.g. qemu) do not create a timer device for S-mode u-boot. The existing behavior of creating the riscv-timer device in the riscv cpu driver must be kept. The actual reading of the CSRs has been redone in the style of Linux's get_cycles64. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Rick Chen <rick@andestech.com>
2020-09-28Merge tag 'efi-2020-10-rc6' of ↵Tom Rini1-0/+3
https://gitlab.denx.de/u-boot/custodians/u-boot-efi Pull request for UEFI sub-system for efi-2020-10-rc6 The following UEFI related issues are fixed: * restore the global data pointer in the RISC-V trap handler * install EFI_RNG_PROTOCOL only if we have a random number generator * display human readable string for EFI_RNG_PROTOCOL in efidebug command
2020-09-28riscv: restore global data pointer in trap handlerHeinrich Schuchardt1-0/+3
The gp register is used to store U-Boot's global data pointer. We should not assume that an UEFI application leaves the gp register unchanged as the UEFI specifications does not define who is the owner of the gp and tp registers. So the following sequence should be followed in the trap handler: * save the caller's gp register * restore the global data pointer * serve interrupts or print crash dump and reset * restore the caller's gp register Cc: Abner Chang <abner.chang@hpe.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Rick Chen <rick@andestech.com>
2020-09-26arm: rmobile: Use imply for BOARD_EARLY_INIT_FBiju Das1-1/+1
Use "imply" instead of "select" for BOARD_EARLY_INIT_F config option, and then disable it on boards which don't need it. Updated grpeach_defconfig to disable CONFIG_BOARD_EARLY_INIT_F option for RZA1. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
2020-09-26arm: mach-rmobile: Mark the default s_init function as weakBiju Das1-0/+6
Mark the default s_init function as weak, so that SoC's can override it if needed, and it will still be discarded if unused. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
2020-09-26arm: dts: r8a774e1: Import DTS from Linux 5.9-rc4Biju Das1-0/+1664
Import R8A774E1 (RZ/G2H) SoC DTSI and headers from upstream Linux kernel 5.9-rc4 commit f4d51dffc6c0 ("Linux 5.9-rc4") Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
2020-09-26arm: dts: r8a774b1: Import DTS from Linux 5.9-rc4Biju Das1-0/+2630
Import R8A774B1 (RZ/G2N) SoC DTSI and headers from upstream Linux kernel 5.9-rc4 commit f4d51dffc6c0 ("Linux 5.9-rc4") Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
2020-09-26arm: dts: r8a774a1: Import DTS from Linux 5.9-rc4Biju Das1-4/+6
Synchronize RZ/G2M SoC DTs with mainline Linux 5.9-rc4 commit f4d51dffc6c0 ("Linux 5.9-rc4") Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
2020-09-26arm: rmobile: Identify R8A7796 r1.3 SoCBiju Das1-2/+7
Add support to identify R8A7796 r1.3 SoC. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
2020-09-26ARM: rmobile: Enable RPC on Salvator-X, ULCB, EbisuMarek Vasut8-0/+40
Enable the RPC Hyperflash driver on R8A7795,R8A7796,R8A77965 Salvator-X,ULCB and R8A77990 Ebisu. Note that to make the HF accessible, mainline ATF is mandatory and must be built with RCAR_RPC_HYPERFLASH_LOCKED=0 . Note that this is intended for development and testing convenience only and must be disabled in deployment for platform security reasons. Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
2020-09-25Merge branch 'next' of https://gitlab.denx.de/u-boot/custodians/u-boot-x86 ↵Tom Rini97-177/+7682
into next - Enhance the 'zboot' command to be more like 'bootm' with sub-commands - The last series of ACPI core changes for programmatic generation of ACPI tables - Add all required ACPI tables for ApolloLake and enable ACPIGEN on Chromebook Coral - A feature minor enhancements to the 'hob' command - Intel edison: Support for writing an xFSTK image via binman
2020-09-25ARM: mach-at91: add support for new SoC sama7g5Eugen Hristev6-0/+1016
Add support for new SoC sama7g5 Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
2020-09-25x86: edison: Generate an image suitable for xFSTKSimon Glass2-0/+35
It is useful to be able to flash Edison directly without relying on the installed U-Boot being functional. Add a binman image for this. It includes a 'OSIP' header (which happens to look like an MBR / (Master-Boot Record), U-Boot binary and an environment. I am not able to find a specification for OSIP. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-09-25x86: Use multiple imagesSimon Glass3-21/+10
We already use binman's 'multiple-images' feature with Chrome OS and we want to use it for Edison. There is no real down-side. Adjust x86 to always use multiple-images. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2020-09-25x86: Add support for more than 8 MTRRsSimon Glass2-8/+19
At present the mtrr command only support 8 MTRRs. Some SoCs have more than that. Update the implementation to support up to 10. Read the number of MTRRs dynamically instead. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2020-09-25x86: hob: Try to show a name instead of a GUIDSimon Glass1-0/+25
GUIDs are one of the seven evils of the computer world. They obfuscate the meaning and require people to look up long hex strings to decode it. Luckily only a miniscule fraction of the 10^38 possible GUIDs are in use. Add a way to decode the GUIDs known to U-Boot. Add a few more to the list for good measure. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2020-09-25x86: coral: Update config and device tree for ACPISimon Glass1-14/+212
Enable new features and provide require device-tree config so that U-Boot produces the correct ACPI tables on Coral. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-09-25x86: Add a way to add to the e820 memory tableSimon Glass1-0/+17
Some boards want to reserve extra regions of memory. Add a 'chosen' property to support this. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2020-09-25x86: fsp: Show FSP-S or FSP-M address in fsp_get_header()Simon Glass1-8/+14
At present this function only supports FSP-M but it is also used to read FSP-S, in which case FSP-M may be zero. Add support for showing whichever address is present in the FSP binary. Also change the debug() statements to log_debug() while here. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2020-09-25x86: fsp: Add more debugging for silicon initSimon Glass1-1/+3
If locating the FSP header hangs for whatever reason it is useful to see where it got stuck. Add a debug print. Also show the address of the FSP-S entry point as a sanity check. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2020-09-25x86: apl: Check low-level init in FSP-S pre-initSimon Glass1-0/+2
If U-Boot is not running FSP-S it should not do the pre-init either. Add a condition to handle this. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-09-25x86: acpi: Set the log category for x86 table generationSimon Glass1-0/+2
This file doesn't currently have a log category. Add one so that items are logged correctly. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2020-09-25acpi: tpm: Add a TPM1 tableSimon Glass1-1/+53
This provides information about a v1 TPM in the system. Generate this table if the TPM is present. Add a required new bloblist type and correct the header order of one header file. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-09-25acpi: tpm: Add a TPM2 tableSimon Glass1-0/+74
This provides information about a v2 TPM in the system. Generate this table if the TPM is present. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-09-25x86: Correct handling of MADT table CPUsSimon Glass1-3/+6
At present if hyperthreading is disabled the CPU numbering is not sequential. Fix this. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-09-25x86: Add a header guard to asm/acpi_table.hSimon Glass1-0/+4
This file cannot currently be included in ASL files. Add a header guard to permit this. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
generated by cgit v1.2.3 (git 2.39.0) at 2024-10-07 14:15:12 +0300