summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-04-16cpu: Support querying the address widthSimon Glass
Different CPUs may support different address widths, meaning the amount of memory they can address. Add a property for this to the cpu_info struct. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2020-04-16x86: acpi: Let OS know that console already had been initializedAndy Shevchenko
SPCR has no clue if the UART base clock speed is different to the default one. However, the SPCR 1.04 defines baud rate 0 as a preconfigured state of UART and OS is supposed not to touch the configuration of the serial device. Linux kernel supports that starting from v5.0, see commit b413b1abeb21 ("ACPI: SPCR: Consider baud rate 0 as preconfigured state") for the details. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2020-04-16serial: ns16550: Provide UART base clock speed in ->getinfo()Andy Shevchenko
Some callers may need the UART base clock speed value. Provide it in the ->getinfo() callback. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2020-04-16dm: serial: Add clock member to struct serial_device_infoAndy Shevchenko
Some callers of serial_getinfo() would like to know the UART base clock speed in order to make decision what to pass to OS in some cases. In particular, ACPI SPCR table expects only certain base clock speed and thus we have to act accordingly. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2020-04-16efi_loader: add some description about UEFI secure bootAKASHI Takahiro
A small text in docs/uefi/uefi.rst was added to explain how we can configure and utilise UEFI secure boot feature on U-Boot. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2020-04-16travis: add packages for UEFI secure boot testAKASHI Takahiro
Pytest for UEFI secure boot will use several host commands. In particular, Test setup relies on efitools, whose version must be v1.5.2 or later. So fetch a new version of deb package directly. Please note it has a dependency on mtools, which must also be installed along wih efitools. In addition, the path, '/sbin', is added to PATH for use of sgdisk and mkfs. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Tom Rini <trini@konsulko.com>
2020-04-16sandbox: add extra configurations for UEFI and related testsAKASHI Takahiro
Adding those extra configurations allows us to successfully run UEFI secure boot pytest on Travis CI. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
2020-04-16efi_loader, pytest: add UEFI secure boot tests (image)AKASHI Takahiro
Provide test cases for * image authentication for signed images (test_efi_secboot/test_signed.py) * image authentication for unsigned images (test_efi_secboot/test_unsigned.py) Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
2020-04-16efi_loader, pytest: add UEFI secure boot tests (authenticated variables)AKASHI Takahiro
Provide a couple of test cases for variable authentication. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
2020-04-16efi_loader, pytest: set up secure boot environmentAKASHI Takahiro
A fixture for UEFI secure boot tests (image authentication and variable authentication) is defined. A small file system with test data in a single partition formatted in fat is created. This test requires efitools v1.5.2 or later. If the system's efitools is older, you have to build it on your own and define EFITOOLS_PATH. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
2020-04-16cmd: efidebug: add "test bootmgr" sub-commandAKASHI Takahiro
This sub-command will be used to test image authentication, in particular, a case where efi_load_image() failed with EFI_SECURITY_VIOLATION but we still want to try efi_start_image(). We won't run such a case under normal bootmgr because it simply refuses to call efi_start_image() if anything but EFI_SUCCESS is returned when loading an image. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
2020-04-16cmd: env: add "-at" option to "env set -e" commandAKASHI Takahiro
With "-at" option, EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS will be passed to SetVariable() to authenticate the variable. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
2020-04-16cmd: env: use appropriate guid for authenticated UEFI variableAKASHI Takahiro
A signature database variable is associated with a specific guid. For convenience, if user doesn't supply any guid info, "env set|print -e" should complement it. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
2020-04-16efi_loader: set up secure bootAKASHI Takahiro
The following variable is exported as UEFI specification defines: SignatureSupport: array of GUIDs representing the type of signatures supported by the platform firmware Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
2020-04-16efi_loader: image_loader: support image authenticationAKASHI Takahiro
With this commit, image validation can be enforced, as UEFI specification section 32.5 describes, if CONFIG_EFI_SECURE_BOOT is enabled. Currently we support * authentication based on db and dbx, so dbx-validated image will always be rejected. * following signature types: EFI_CERT_SHA256_GUID (SHA256 digest for unsigned images) EFI_CERT_X509_GUID (x509 certificate for signed images) Timestamp-based certificate revocation is not supported here. Internally, authentication data is stored in one of certificates tables of PE image (See efi_image_parse()) and will be verified by efi_image_authenticate() before loading a given image. It seems that UEFI specification defines the verification process in a bit ambiguous way. I tried to implement it as closely to as EDK2 does. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
2020-04-16efi_loader: variable: add VendorKeys variableAKASHI Takahiro
The following variable is exported as UEFI specification defines: VendorKeys: whether the system is configured to use only vendor-provided keys or not The value will have to be modified if a platform has its own way of initializing signature database, in particular, PK. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
2020-04-16efi_loader: variable: add secure boot state transitionAKASHI Takahiro
UEFI specification defines several global variables which are related to the current secure boot state. In this commit, those values will be maintained according to operations. Currently, AuditMode and DeployedMode are defined but not implemented. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
2020-04-16efi_loader: variable: support variable authenticationAKASHI Takahiro
With this commit, EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS is supported for authenticated variables and the system secure state will transfer between setup mode and user mode as UEFI specification section 32.3 describes. Internally, authentication data is stored as part of authenticated variable's value. It is nothing but a pkcs7 message (but we need some wrapper, see efi_variable_parse_signature()) and will be validated by efi_variable_authenticate(), hence efi_signature_verify_with_db(). Associated time value will be encoded in "{...,time=...}" along with other UEFI variable's attributes. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
2020-04-16efi_loader: add signature database parserAKASHI Takahiro
efi_signature_parse_sigdb() is a helper function will be used to parse signature database variable and instantiate a signature store structure in later patches. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
2020-04-16efi_loader: add signature verification functionsAKASHI Takahiro
In this commit, implemented are a couple of helper functions which will be used to materialize variable authentication as well as image authentication in later patches. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
2020-04-16efi_loader: add CONFIG_EFI_SECURE_BOOT config optionAKASHI Takahiro
Under this configuration, UEFI secure boot support will be added in later patches. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
2020-04-16drivers: crypto: rsa_mod_exp: avoid DM_FLAG_PRE_RELOCHeinrich Schuchardt
Function rsa_verify_key() is not called before relocation. So there is no need to load the UCLASS_MOD_EXP drivers before relocation. This avoid a failure to boot for pine64-lts_defconfig with CONFIG_RSA=y. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2020-04-16efi_loader: function descriptions efi_watchdog.cHeinrich Schuchardt
Correct function descriptions in efi_watchdog.c. Add the descriptions to the generated HTML documentation. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2020-04-16efi_loader: add missing doc comments in efi_disk.cHeinrich Schuchardt
Add missing descriptions for functions in efi_disk.c. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2020-04-16efi_loader: function descriptions efi_unicode_collation.cHeinrich Schuchardt
Correct function descriptions in efi_unicode_collation.c Add the Unicode collation protocol to the generated HTML documentation. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2020-04-16efi_loader: enable RNG if DM_RNG is enabledPeter Robinson
Enable EFI_RNG_PROTOCOL by default if DM_RNG is set. Signed-off-by: Peter Robinson <pbrobinson@gmail.com> Acked-by: Sughosh Ganu <sughosh.ganu@linaro.org> Remove superfluous 'if DM_RNG' Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2020-04-15Merge tag 'u-boot-stm32-20200415' of ↵Tom Rini
https://gitlab.denx.de/u-boot/custodians/u-boot-stm - Replace STM32MP1_TRUSTED by TFABOOT flag - Enable bootd, iminfo, imxtract on ST defconfig - Rename LEDs to match silkscreen on AV96 - Add KS8851-16MLL ethernet on FMC2 - Define FMC2 base address - net: dwc_eth_qos: implement reset-gpios for stm32 - net: dwc_eth_qos: implement phy reg and max-speed for stm32
2020-04-15Merge branch 'master' of git://git.denx.de/u-boot-marvellTom Rini
- Common: honour hw_margin_ms property (Rasmus) - sp805_wdt: get platform clock from dt (Rayagonda)
2020-04-15board: stm32mp1: correct CONFIG_IS_ENABLED usage for LEDPatrick Delaunay
Use the correct macro to test presence CONFIG_LED: replace CONFIG_IS_ENABLED(CONFIG_LED) by CONFIG_IS_ENABLED(LED) Issue see during review unrelated patch "board: stm32mp1: update management of boot-led" http://patchwork.ozlabs.org/patch/1264823/ Cc: Marek Vasut <marex@denx.de> Cc: Patrice Chotard <patrice.chotard@st.com> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Reviewed-by: Marek Vasut <marex@denx.de> Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
2020-04-15ARM: stm32: Enable bootd, iminfo, imxtract on ST defconfigPatrick Delaunay
Enable these standard U-Boot commands for image manipulation and for starting the default boot command using 'boot' command in U-Boot shell. Cc: Marek Vasut <marex@denx.de> Cc: Patrice Chotard <patrice.chotard@st.com> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
2020-04-15ARM: dts: stm32: Rename LEDs to match silkscreen on AV96Marek Vasut
The LED labels do not match the silkscreen on the board, fix it. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Cc: Patrick Delaunay <patrick.delaunay@st.com> Cc: Patrice Chotard <patrice.chotard@st.com> Cc: Tom Rini <trini@konsulko.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2020-04-15configs: stm32mp1: replace STM32MP1_TRUSTED by TFABOOTPatrick Delaunay
Activate ARCH_SUPPORT_TFABOOT and replace the arch stm32mp specific config CONFIG_STM32MP1_TRUSTED by the generic CONFIG_TFABOOT introduced by the commit 535d76a12150 ("armv8: layerscape: Add TFABOOT support"). This config CONFIG_TFABOOT is activated for the trusted boot chain, when U-Boot is loaded by TF-A. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
2020-04-15ARM: dts: stm32: Add KS8851-16MLL ethernet on FMC2Marek Vasut
Add DT entries, Kconfig entries and board-specific entries to configure FMC2 bus and make KS8851-16MLL on that bus accessible to U-Boot. 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-04-15ARM: dts: stm32: Define FMC2 base addressMarek Vasut
Define FMC2 base address, for use in board files, until there is an actual FMC2 bus driver. 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-04-15net: dwc_eth_qos: implement phy reg and max-speed for stm32Patrick Delaunay
Add management of property "reg" to configure @ of phy and also "max-speed" property to specify maximum speed in Mbit/s supported by the device Signed-off-by: Christophe Roullier <christophe.roullier@st.com> Reviewed-by: Patrick DELAUNAY <patrick.delaunay@st.com> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
2020-04-15net: dwc_eth_qos: implement reset-gpios for stm32Christophe Roullier
Add management of property "reset-gpios" in the node identified by "phy-handle" to configure any GPIO used to reset the PHY. Signed-off-by: Christophe Roullier <christophe.roullier@st.com> Reviewed-by: Patrice CHOTARD <patrice.chotard@st.com> Reviewed-by: Patrick DELAUNAY <patrick.delaunay@st.com> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
2020-04-15watchdog: sp805_wdt: get platform clock from dt fileRayagonda Kokatanur
Get the watchdog platform clock from the DTS file using clk subsystem and use the same for calculating ticks in msec. Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com> Signed-off-by: Bharat Kumar Reddy Gooty <bharat.gooty@broadcom.com> Reviewed-by: Stefan Roese <sr@denx.de>
2020-04-15watchdog: honour hw_margin_ms DT propertyRasmus Villemoes
Some watchdog devices, e.g. external gpio-triggered ones, must be reset more often than once per second, which means that the current rate-limiting logic in watchdog_reset() fails to keep the board alive. gpio-wdt.txt in the linux source tree defines a "hw_margin_ms" property used to specifiy the maximum time allowed between resetting the device. Allow any watchdog device to specify such a property, and then use a reset period of one quarter of that. We keep the current default of resetting once every 1000ms. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Reviewed-by: Stefan Roese <sr@denx.de>
2020-04-15watchdog: move initr_watchdog() to wdt-uclass.cRasmus Villemoes
This function is a bit large for an inline function, and for U-Boot proper, it is called via a function pointer anyway (in board_r.c), so cannot be inlined. It will shortly set a global variable to be used by the watchdog_reset() function in wdt-uclass.c, so this also allows making that variable local to wdt-uclass.c. The WATCHDOG_TIMEOUT_SECS define is not used elsewhere. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Reviewed-by: Stefan Roese <sr@denx.de>
2020-04-15watchdog: remove stale ifndef CONFIG_WATCHDOG_TIMEOUT_MSECS from wdt.hRasmus Villemoes
Since WATCHDOG_TIMEOUT_MSECS was converted to Kconfig (commit ca51ef7c0c), CONFIG_WATCHDOG_TIMEOUT_MSECS has been guaranteed to be defined. So remove the dead fallback ifdeffery. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Reviewed-by: Stefan Roese <sr@denx.de>
2020-04-14Merge branch 'master' of git://git.denx.de/u-boot-marvellTom Rini
- Misc enhancements to Clearfog, including board variant detection (Joel) - Misc enhancements to Turris Mox, including generalization of the ARMADA37xx DDR size detection (Marek)
2020-04-14arm: mvebu: turris_mox: fix PCIe ranges in device treeMarek Behún
Use the new a3700_fdt_fix_pcie_regions function in turris_mox.c so that MOX boards with 4 GB RAM are fully supported. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de>
2020-04-14arm64: mvebu: a37xx: add device-tree fixer for PCIe regionsMarek Behún
In case when ARM Trusted Firmware changes the default address of PCIe regions (which can be done for devices with 4 GB RAM to maximize the amount of RAM the device can use) we add code that looks at how ATF changed the PCIe windows in the CPU Address Decoder and changes given device-tree blob accordingly. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de>
2020-04-14arm: mvebu: turris_mox: support devices with RAM > 1 GBMarek Behún
In order to support MOX boards with 2 GB or 4 GB RAM, we use the new Armada-3700 generic code for memory information structures. This is done by removing dram_init and dram_init_banksize from turris_mox.c, in order for the generic, weak definitions to be used. Also for boards with 4 GB RAM it is needed to increase CONFIG_NR_DRAM_BANKS to 2 in turris_mox_defconfig. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de>
2020-04-14arm64: mvebu: a37xx: improve code determining memory info structuresMarek Behún
Currently on Armada-37xx the mem_map structure is statically defined to map first 2 GB of memory as RAM region, and system registers and PCIe region device region. This is insufficient for when there is more RAM or when for example the PCIe windows is mapped to another address by the CPU Address Decoder. In the case when the board has 4 GB RAM, on some boards the ARM Trusted Firmware can move the PCIe window to another address, in order to maximize possible usable RAM. Also the dram_init and dram_init_banksize looks for information in device-tree, and therefore different device trees are needed for boards with different RAM sizes. Therefore we add code that looks at how the ARM Trusted Firmware has configured the CPU Address Decoder windows, and then we update the mem_map structure and compute gd->ram_size and gd->bd->bi_dram bank base addresses and sizes accordingly. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de>
2020-04-14arm64: mvebu: armada-8k: move dram init codeMarek Behún
Move Armada-8k specific DRAM init code into armada-8k specific directory. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de>
2020-04-14arm: mvebu: turris_mox: sort headers alphabeticallyMarek Behún
Sort #includes alphabetically, the only exception is common.h, which is included first in most parts of U-Boot. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de>
2020-04-14arm: mvebu: turris_mox: don't use hardcoded addressesMarek Behún
Use macro MVEBU_REGISTER to access register addresses instead of hardcoded addresses. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de>
2020-04-14arm: mvebu: dts: turris_mox: fix USB3 regulatorMarek Behún
Commit e8e9715df2d4 requires the USB3 regulator node to have the enable-active-high property for the regulator to work properly. The GPIO_ACTIVE_HIGH constant is not enough anymore. Signed-off-by: Marek Behún <marek.behun@nic.cz> Fixes: e8e9715df2d4 ("regulator: fixed: Modify enable-active-high...") Reviewed-by: Stefan Roese <sr@denx.de>
2020-04-14arm: mvebu: turris_mox: Setup Linux's device tree before bootMarek Behún
Patch Linux's device tree according to which Mox modules are connected. Linux's device tree has all possible Mox module nodes preprogrammed, but in disabled state. If MOX B, MOX F or MOX G module is present, this code enables the PCI node. For the network modules (MOX C, MOX D and MOX E) are present, the code enables corresponding ethernet and swtich nodes and DSA connections. For the SFP cage the SFP GPIO controller node and SFP node are also enabled. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de>
generated by cgit (git 2.34.1) at 2024-12-26 03:14:45 +0000