aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2024-01-09Merge branch 'master' of https://gitlab.denx.de/u-boot/custodians/u-boot-samsungWIP/09Jan2024Tom Rini6-56/+136
2024-01-09Merge tag 'rng-2024-04-rc1' of ↵Tom Rini2-11/+29
https://gitlab.denx.de/u-boot/custodians/u-boot-efi Pull request rng-2024-04-rc1 QEMU does not provide information in the device-tree if the ARMv8.5 RNDR or the RISC-V Zkr RNG have been enabled on the command line. In different parts of our code we assume that the first RNG device is the one to be used. Therefore it is preferable to detect the availability of said devices already in the bind method. There has been a related discussion if the U_BOOT_DRVINFO() macro should be used for architectural devices (https://lore.kernel.org/u-boot/20231031125552.26698-1-heinrich.schuchardt@canonical.com/). This aspect is not touched by this series.
2024-01-09rng: detect RISC-V Zkr RNG device in bind methodHeinrich Schuchardt1-8/+26
The existence of devices should be checked in the bind method and not in the probe method. Adjust the RISC-V Zkr RNG driver accordingly. Use ENOENT (and not ENODEV) to signal that the device is not available. Fixes: ceec977ba1a9 ("rng: Provide a RNG based on the RISC-V Zkr ISA extension") Reported-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2024-01-09rng: fix ARMv8.5 RNDR driverHeinrich Schuchardt1-3/+3
In different parts of our code we assume that the first RNG device is the one to be used. Therefore it is preferable to detect the availability of the RNDR register already in the bind method. For signaling the non-existence of a device the driver model requires using ENOENT (and not ENODEV). Fixes: 31565bb0aa2d ("driver: rng: Add DM_RNG interface for ARMv8.5 RNDR registers") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Tested-by: Andre Przywara <andre.przywara@arm.com>
2024-01-08Merge tag 'u-boot-imx-master-20240108' of ↵WIP/08Jan2024Tom Rini41-12/+3585
https://gitlab.denx.de/u-boot/custodians/u-boot-imx - Removed fdt_addr from verdin-imx8mm to fix booting via bootefi. - Support Ethernet PHY autodection on Data Modul i.MX8M Mini/Plus eDM SBC - Add i.MX93 binman support - Add support for imx93-var-som
2024-01-08Add imx93-var-som supportMathieu Othacehe22-1/+3247
Add support for the Variscite VAR-SOM-IMX93 evaluation kit. The SoM consists of an NXP iMX93 dual A55 CPU. The SoM is mounted on a Variscite Symphony SBC. Signed-off-by: Mathieu Othacehe <m.othacehe@gmail.com>
2024-01-08imx9: imx93_evk: Add binman support.Mathieu Othacehe6-0/+76
Signed-off-by: Mathieu Othacehe <m.othacehe@gmail.com>
2024-01-08mach-imx: Add i.MX93 binman support.Mathieu Othacehe5-1/+165
Add dedicated Makefile targets for the i.MX93 and a new imx93-u-boot.dtsi device-tree to create binman images. Signed-off-by: Mathieu Othacehe <m.othacehe@gmail.com>
2024-01-08spl: binman: Disable u_boot_any symbols for i.MX93 boardsMathieu Othacehe3-3/+3
This is extending commit 6516c9b349b3 ("spl: binman: Disable u_boot_any symbols for i.MX8M boards") to i.MX93 boards. Signed-off-by: Mathieu Othacehe <m.othacehe@gmail.com>
2024-01-08verdin-imx8mm: Remove stale fdt_addr env variableFrancesco Dolcini1-1/+0
fdt_addr variable is the location in flash of the device tree blob [1], it does not exist for verdin-imx8mm. Because of this the bootefi command fails unless the optional `[fdt address]` parameter is passed on the command line, bootefi.c:efi_install_fdt() assumes that `fdt_addr` is valid when present. Fix this removing fdt_addr from the U-Boot environment. [1] doc/usage/environment.rst Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Reviewed-by: Fabio Estevam <festevam@gmail.com>
2024-01-08ARM: imx: Auto-detect PHY on Data Modul i.MX8M Mini/Plus eDM SBCMarek Vasut5-6/+94
Implement fdtdec_board_setup() auto-detection of ethernet PHY. This uses properties of the hardware and pull resistor placement. If GPIO1_16 RGMII_MDC is HIGH, then R530 (MX8MM eDM SBC) or R390 (MX8MP eDM SBC) is populated. R530 or R390 is populated only on boards with AR8031 PHY. If GPIO1_16 RGMII_MDC is LOW, then the in-SoM pull down is the dominant pull resistor. This is the case on boards with BCM54213PE PHY. In case AR8031 PHY is populated, the PHY MDIO address is 0, in case BCM54213PE PHY is populated, the PHY MDIO address is 1, the fdtdec_board_setup() is used to patch the correct address into the U-Boot control DT. Enable broadcom PHY support to support both PHYs. Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Fabio Estevam <festevam@gmail.com>
2024-01-08Merge branch 'next'Tom Rini2238-19662/+62842
2024-01-08Prepare v2024.01v2024.01Tom Rini3-14/+859
Signed-off-by: Tom Rini <trini@konsulko.com>
2024-01-08Merge tag 'dm-next-7jan23' of ↵WIP/08Jan2024-nextTom Rini35-372/+556
https://source.denx.de/u-boot/custodians/u-boot-dm into next switch to SMBIOS3 tables allow devicetree from bloblist ACPI support for ARM and RISC-V
2024-01-07arm: enable support for QEMU firmware tablesHeinrich Schuchardt1-0/+1
Enable the QEMU firmware interface if ACPI tables are to be supported on the QEMU platform. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2024-01-07configs: qemu: add config fragment for ACPIHeinrich Schuchardt4-0/+28
Provide a configuration fragment to enable ACPI on QEMU. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org>
2024-01-07riscv: allow usage of ACPIHeinrich Schuchardt1-0/+1
Select CONFIG_SUPPORT_ACPI to allow usage of ACPI tables with RISC-V. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2024-01-07riscv: add support for QEMU firmware tablesHeinrich Schuchardt1-0/+2
Enable the QEMU firmware interface if ACPI tables are to be supported on the QEMU platform. Enable the QFW MMIO interface if the QEMU firmware interface is enabled. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2024-01-07acpi: enable writing ACPI tables on QEMUHeinrich Schuchardt1-0/+25
Invoke write_acpi_tables() via EVT_LAST_STAGE_INIT on QEMU except on X86. X86 calls write_acpi_tables() in write_tables(). Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2024-01-07riscv: add ACPI fields to global dataHeinrich Schuchardt1-0/+6
Add fields for the location of ACPI tables to the global data. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2024-01-07arm: add ACPI fields to global dataHeinrich Schuchardt1-1/+6
Add fields for the location of ACPI tables to the global data. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org>
2024-01-07acpi: carve out qfw_acpi.cHeinrich Schuchardt3-240/+257
Move the code related to copying tables from QEMU to a separate code module. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2024-01-07acpi: Kconfig symbol CONFIG_QFW_ACPIHeinrich Schuchardt4-5/+12
We have two implementations of write_acpi_tables(). One for writing ACPI tables based on ACPI_WRITER() entries another based on copying tables from QEMU. Create a symbol CONFIG_QFW_ACPI that signifies copying ACPI tables from QEMU and use it consistently. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2024-01-07acpi: support 64bit in acpi_find_table for DSDT and FACSHeinrich Schuchardt1-5/+24
Use X_DSDT and X_FIRMWARE_CTRL if available. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Simon Glass <sjg@chromium.org> Rebased on -next to use nomap: Signed-off-by: Simon Glass <sjg@chromium.org>
2024-01-07cmd: acpi: check HW reduced flag in acpi listHeinrich Schuchardt1-0/+4
On non x86 platforms the hardware reduce flag must be set in the FADT table. Write an error message if the flag is missing. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Simon Glass <sjg@chromium.org> Rebased on -next to use nomap, add hyphens: Signed-off-by: Simon Glass <sjg@chromium.org>
2024-01-07cmd: acpi: fix listing DSDT and FACSHeinrich Schuchardt1-2/+6
If field X_FIRMWARE_CTRL is filled, field FIRMWARE must be ignored. If field X_DSDT is filled, field DSDT must be ignored. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Simon Glass <sjg@chromium.org> Rebased on -next to use nomap: Signed-off-by: Simon Glass <sjg@chromium.org>
2024-01-07acpi: use 64-bit addresses in FADT tableHeinrich Schuchardt5-29/+13
Fields X_FIRMWAE_CTRL and X_DSDT must be 64bit wide. Convert pointers to to uintptr_t to fill these. If field X_FIRMWARE_CTRL is filled, field FIRMWARE must be ignored. If field X_DSDT is filled, field DSDT must be ignored. We should not fill unused fields. See the field definitions in chapter "5.2.9 Fixed ACPI Description Table (FADT)" of the ACPI Specification 6.5. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2024-01-07fdt: Allow the devicetree to come from a bloblistSimon Glass3-12/+41
Standard passage provides for a bloblist to be passed from one firmware phase to the next. That can be used to pass the devicetree along as well. Add an option to support this. Tests for this will be added as part of the Universal Payload work. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2024-01-07efi: Correct smbios-table installationSimon Glass1-9/+7
At present this code allocates memory when writing the tables and then unnecessarily adds another memory map when installing it. Adjust the code to allocate the tables using the normal U-Boot mechanism. This avoids doing an EFI memory allocation early in U-Boot, which may use memory that would be overwritten by a 'load' command, for example. Signed-off-by: Simon Glass <sjg@chromium.org>
2024-01-07acpi: Write pointers to tables instead of addressesSimon Glass8-24/+58
Sandbox uses an API to map between addresses and pointers. This allows it to have (emulated) memory at zero and avoid arch-specific addressing details. It also allows memory-mapped peripherals to work. As an example, on many machines sandbox maps address 100 to pointer value 10000000. However this is not correct for ACPI, if sandbox starts another program (e.g EFI app) and passes it the tables. That app has no knowledge of sandbox's address mapping. So to make this work we want to store 10000000 as the value in the table. Add two new 'nomap' functions which clearly make this exeption to how sandbox works. This should allow EFI apps to access ACPI tables with sandbox, e.g. for testing purposes. Signed-off-by: Simon Glass <sjg@chromium.org> Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2024-01-07acpi: Rename test dm_test_setup_ctx_and_base_tables()Simon Glass1-2/+2
Use the word 'acpi' in this test so that it runs along with all the other ACPI tests. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2024-01-07efi: smbios: Drop support for SMBIOS2 tablesSimon Glass1-3/+1
Only the v3 table is supported now, so always use this when installing the EFI table. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2024-01-07smbios: Drop support for SMBIOS2 tablesSimon Glass1-59/+17
These tables are a pain since there is no way to handle memory above 4GB. Use SMBIOS3 always. This should hopefully not create problems on x86 devices, since SMBIOS3 was released seven years ago (2015). Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
2024-01-07smbios: Require the caller to align the SMBIOS tableSimon Glass2-6/+5
All callers handle this alignment, so drop the unnecessary code. This simplifies things a little. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2024-01-07efi: Use the correct GUID for the SMBIOS tableSimon Glass2-2/+14
EFI does not use the 'anchor string' to determine the SMBIOS table version, instead preferring to have two separate GUIDs. Use the correct one, depending on the table version. Call unmap_system() to balance to the use of map_sysmem() Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2024-01-07smbios: Correct gd_smbios_start()Simon Glass2-2/+2
This should access arch-specific properties. Fix it and update the existing usage. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2024-01-07smbios: Use SMBIOS 3.0 to support an address above 4GBSimon Glass2-6/+30
When the SMBIOS table is written to an address above 4GB a 32-bit table address is not large enough. Use an SMBIOS3 table in that case. Note that we cannot use efi_allocate_pages() since this function has nothing to do with EFI. There is no equivalent function to allocate memory below 4GB in U-Boot. One solution would be to create a separate malloc() pool, or just always put the malloc() pool below 4GB. - Use log_debug() for warning - Rebase on Heinrich's smbios.h patch - Set the checksum for SMBIOS3 Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2024-01-07smbios: SMBIOS 3.0 (64-bit) Entry Point structureHeinrich Schuchardt1-0/+26
Add definition of the SMBIOS 3.0 (64-bit) Entry Point structure. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Simon Glass <sjg@chromium.org>
2024-01-07smbios: Move the rest of the SMBIOS2 codeSimon Glass1-8/+7
Move all of this logic into the else clause, since it will not be used for SMBIOS3 Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2024-01-07smbios: Refactor 32-bit code into an else statementSimon Glass1-17/+21
In preparation for adding support for SMBIOS3 move this code into an else statement. There is no functional change. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2024-01-06Merge branch 'staging' of ↵WIP/06Jan2024-nextTom Rini11-211/+436
https://source.denx.de/u-boot/custodians/u-boot-tegra into next Documentation updates for endeavoru, lg_x3, grouper and transformers, addition of MIPI calibration clock name for T114 (inline with T124+), conversion of TEGRA_SUPPORT_NON_SECURE into Kconfig and endeavoru stability improvements.
2024-01-06Merge branch '2024-01-05-fw_env-fixes' into nextTom Rini2-46/+59
- A few fw_env fixes
2024-01-06arm: dts: iot2050: Fix by syncing from LinuxJan Kiszka5-134/+123
This restores support for IOT2050 by widely synchronizing its DT files with the Linux kernel. We additionally need to add the alias restoration that is still waiting for its upstream merge and the not-yet-upstreamed bits needed for watchdog reboot detection. Fixes: 4dbdc84754ea ("arm: dts: k3-am654: pull in dtb update from Linux") Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
2024-01-05fw_env: autodetect NAND erase size and env sectorsWIP/2024-01-05-fw_env-fixesAnthony Loiseau2-2/+12
As already done for NOR chips, if device ESIZE and ENVSECTORS static configurations are both zero, then autodetect them at runtime. Cc: Joe Hershberger <joe.hershberger@ni.com> cc: Stefan Agner <stefan@agner.ch> cc: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Signed-off-by: Anthony Loiseau <anthony.loiseau@allcircuits.com>
2024-01-05fw_env: keep calling read() until whole flash block is readRafał Miłecki1-19/+15
It's totally valid for read() to provide less bytes than requested maximum. It may happen if there is no more data available yet or source pushes data in small chunks. This actually happens when trying to read env data from NVMEM device. Kernel may provide NVMEM content in page size parts (like 4096 B). This fixes warnings like: Warning on /sys/bus/nvmem/devices/u-boot-env0/nvmem: Attempted to read 16384 bytes but got 4096 Warning on /sys/bus/nvmem/devices/u-boot-env0/nvmem: Attempted to read 12288 bytes but got 4096 Warning on /sys/bus/nvmem/devices/u-boot-env0/nvmem: Attempted to read 8192 bytes but got 4096 Since the main loop in flash_read_buf() is used to read blocks this patch adds a new nested one. Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
2024-01-05fw_env: rename variables holding env data contentRafał Miłecki1-21/+18
Rename "addr0" and "addr1" to "buf0" and "buf1" accordingly. Name "addr" suggests that variable contains a numeric value being some kind of address. Name "buf" is de facto a standard name for pointer to allocated memory for reading data to. While at it drop redundant checks for NULL before calling free(). Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
2024-01-05fw_env: fix reading NVMEM device's "compatible" valueRafał Miłecki1-4/+14
Call to fread() was changed to check for return value. The problem is it can't be checked for returning 1 (as it is) to determine success. We call fread() with buffer size as "size" argument. Reading any "compatible" value shorter than buffer size will result in returning 0 even on success. Modify code to use fstat() to determine expected read length. This fixes regression that broke using fw_env with NVMEM devices. Fixes: c059a22b7776 ("tools: env: fw_env: Fix unused-result warning") Cc: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
2024-01-05board: htc: endeavoru: add an early SPL RCM hookSvyatoslav Ryhel1-0/+56
Unlike all other supported Tegra devices and most known Tegra devices, the HTC One X has no hardware way to enter APX/RCM mode, which may lead to a dangerous situation when, if BCT is set correctly and the bootloader is faulty, the device will hang in a permanent brick state. Exiting from this state can be done only by disassembling the device and shortening the testpad to the ground. To prevent this or to minimize the probability of such an accident, it was proposed to add the RCM rebooting hook as early into SPL as possible since SPL is much more robust and has minimal changes that can break bootflow. gpio_early_init_uart() function was chosen as it is the earliest function exposed for setup by the device. Hook performs a check for volume up button state and triggers RCM if it is pressed. Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
2024-01-04Merge patch series "ATF and OP-TEE Firewalling for K3 devices."WIP/04Jan2024-nextTom Rini13-103/+842
Manorit Chawdhry <m-chawdhry@ti.com> says: K3 devices have firewalls that are used to prevent illegal accesses to memory regions that are deemed secure. The series prevents the illegal accesses to ATF and OP-TEE regions that are present in different K3 devices. AM62X, AM62AX and AM64X are currently in hold due to some firewall configurations that our System Controller (TIFS) needs to handle. The devices that are not configured with the firewalling nodes will not be affected and can continue to work fine until the firewall nodes are added so will be a non-blocking merge. Test Logs: https://gist.github.com/manorit2001/4cead2fb3a19eb5d19005b3f54682627 CICD Run: https://github.com/u-boot/u-boot/pull/442
2024-01-04docs: board: ti: k3: Add secure booting documentationManorit Chawdhry1-0/+43
This commit adds a general flow to explain the usage of firewalls and the chain of trust in K3 devices. Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
generated by cgit v1.1 at 2024-11-17 13:07:18 +0000