efi_loader, pytest: set up secure boot environment
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.
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.
cmd: env: use appropriate guid for authenticated UEFI variable
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.
The following variable is exported as UEFI specification defines:
SignatureSupport: array of GUIDs representing the type of signatures
supported by the platform firmware
efi_loader: image_loader: support image authentication
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.
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.
efi_loader: variable: add secure boot state transition
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.
efi_loader: variable: support variable authentication
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.
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.
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.
Rasmus Villemoes [Fri, 13 Mar 2020 16:04:58 +0000 (17:04 +0100)]
watchdog: honour hw_margin_ms DT property
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>
Rasmus Villemoes [Fri, 13 Mar 2020 16:04:57 +0000 (17:04 +0100)]
watchdog: move initr_watchdog() to wdt-uclass.c
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>
Rasmus Villemoes [Fri, 13 Mar 2020 16:04:56 +0000 (17:04 +0100)]
watchdog: remove stale ifndef CONFIG_WATCHDOG_TIMEOUT_MSECS from wdt.h
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>
Tom Rini [Tue, 14 Apr 2020 12:47:07 +0000 (08:47 -0400)]
Merge branch 'master' of git://git.denx.de/u-boot-marvell
- Misc enhancements to Clearfog, including board variant detection
(Joel)
- Misc enhancements to Turris Mox, including generalization of the
ARMADA37xx DDR size detection (Marek)
Marek Behún [Wed, 8 Apr 2020 17:25:21 +0000 (19:25 +0200)]
arm64: mvebu: a37xx: add device-tree fixer for PCIe regions
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>
Marek Behún [Wed, 8 Apr 2020 17:25:20 +0000 (19:25 +0200)]
arm: mvebu: turris_mox: support devices with RAM > 1 GB
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>
Marek Behún [Wed, 8 Apr 2020 17:25:19 +0000 (19:25 +0200)]
arm64: mvebu: a37xx: improve code determining memory info structures
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>
Marek Behún [Wed, 8 Apr 2020 10:02:06 +0000 (12:02 +0200)]
arm: mvebu: dts: turris_mox: fix USB3 regulator
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>
Marek Behún [Wed, 8 Apr 2020 10:02:05 +0000 (12:02 +0200)]
arm: mvebu: turris_mox: Setup Linux's device tree before boot
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>
Marek Behún [Wed, 8 Apr 2020 10:02:03 +0000 (12:02 +0200)]
arm: mvebu: turris_mox: Fix early SPI communication
The SPI clock signal changes value when the SPI configuration register
is configured. This can sometimes lead to the device misinterpreting
the enablement of the SPI controller as actual clock tick.
This can be solved by first setting the SPI CS1 pin from GPIO to SPI mode,
and only after that writing the SPI configuration register.
Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de>
Joel Johnson [Mon, 23 Mar 2020 20:21:31 +0000 (14:21 -0600)]
arm: mvebu: clearfog: use Pro name by default
Make the board version printed indicate the Pro variant default.
Also adjust static name casing to match what is expected for
EEPROM product name to share string constants.
Signed-off-by: Joel Johnson <mrjoel@lixil.net> Reviewed-by: Stefan Roese <sr@denx.de>
Joel Johnson [Mon, 23 Mar 2020 20:21:30 +0000 (14:21 -0600)]
arm: mvebu: solidrun: remove hardcoded DTS MAC address
Using a consistent hardcoded MAC address from the DTS file causes
issues when using multiple devices on the same network segment.
Instead rely on environment configuration or random generation.
Signed-off-by: Joel Johnson <mrjoel@lixil.net> Reviewed-by: Stefan Roese <sr@denx.de>
Joel Johnson [Mon, 23 Mar 2020 17:26:31 +0000 (11:26 -0600)]
arm: mvebu: clearfog: add SCSI to distro bootcmd
Include attempting to boot from SCSI (SATA) devices within generated
board distro bootcmd environment. The reasoning for boot ordering is
that MMC and USB are external and removable, while when a case is in
use, replacing M.2 or mSATA drives requires disassembly. Therefore,
to boot SCSI, [bootable] external media must be removed. If SCSI were
placed before MMC or USB, then removing a bootable SCSI drive to
enable MMC or USB booting would be more difficult.
Signed-off-by: Joel Johnson <mrjoel@lixil.net> Reviewed-by: Stefan Roese <sr@denx.de>
Chris Packham [Wed, 26 Feb 2020 06:53:50 +0000 (19:53 +1300)]
arm: mvebu: update RTC values for PCIe memory wrappers
Update the RTC (Read Timing Control) values for PCIe memory wrappers
following an ERRATA (ERRATA# TDB). This means the PCIe accesses will
used slower memory Read Timing, to allow more efficient energy
consumption, in order to lower the minimum VDD of the memory. Will lead
to more robust memory when voltage drop occurs (VDDSEG)
The code is based on changes from Marvell's U-Boot, specifically:
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Signed-off-by: Chris Packham <judge.packham@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de>
Josua Mayer [Mon, 17 Feb 2020 18:37:28 +0000 (19:37 +0100)]
arm: mvebu: clearfog: add scsi target to distro-boot
Support for sata devices via the scsi command is available and already
enabled by default for the Clearfog Base and Pro. This change adds scsi
to the list of boot targets used by distro-boot.
Signed-off-by: Josua Mayer <josua@solid-run.com> Cc: Stefan Roese <sr@denx.de> Reviewed-by: Stefan Roese <sr@denx.de>
Chris Packham [Wed, 29 Jan 2020 23:50:44 +0000 (12:50 +1300)]
ddr: marvell: a38x: Allow boards to specify CK_DELAY parameter
For some layouts it is necessary to adjust the CK_DELAY parameter to
successfully complete DDR training. Add the ability to specify the
CK_DELAY in the mv_ddr_topology_map.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Tom Rini [Mon, 13 Apr 2020 15:27:00 +0000 (11:27 -0400)]
Merge branch 'next'
Pull in changes that have been pending in our 'next' branch. This
includes:
- A large number of CI improvements including moving to gcc-9.2 for all
platforms.
- amlogic, xilinx, stm32, TI SoC updates
- USB and i2c subsystem updtaes
- Re-sync Kbuild/etc logic with v4.19 of the Linux kernel.
- RSA key handling improvements
Update these 3 files from Linux:.
- socfpga_arria10.dtsi (Commit ID c1459a9d7e92)
- socfpga_arria10_socdk.dtsi (Commit ID d9b9f805ee2b)
- socfpga_arria10_socdk_sdmmc.dts (Commit ID 17808d445b6f)
Change in socfpga_arria10.dtsi:
- Add clkmgr label, so that can reference to it in u-boot.dtsi.
Change in socfpga_arria10-u-boot.dtsi:
- Add compatible and altr,sysmgr-syscon for uboot.
Signed-off-by: Ley Foon Tan <ley.foon.tan@intel.com>
Marek Vasut [Fri, 6 Mar 2020 20:52:21 +0000 (21:52 +0100)]
ARM: socfpga: Enable DM RTC bootcount on ABB SECU1
Add and enable RTC-backed boot counter on ABB SECU1 platform.
Signed-off-by: Marek Vasut <marex@denx.de> Cc: Ley Foon Tan <ley.foon.tan@intel.com> Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com> Reviewed-by: Ley Foon Tan <ley.foon.tan@intel.com>
Kever Yang [Wed, 4 Mar 2020 00:59:50 +0000 (08:59 +0800)]
usb: Migrate to support live DT for some driver
Use ofnode_ instead of fdt_ APIs so that the drivers can support live DT.
This patch updates usb_get_dr_mode() and usb_get_maximum_speed() to use
ofnode as parameter instead of fdt offset. And all the drivers who use
these APIs update to use live dt APIs at the same time.
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Simon Glass [Wed, 18 Mar 2020 15:43:01 +0000 (09:43 -0600)]
test/py: Allow using buildman to build U-Boot
It is a pain to have to set the CROSS_COMPILE environment variable when
using test.py's --build option. It is possible to get this using the -A
option from buildman. But it seems better to just use buildman to do the
build when it is available.
However using buildman adds a new dependency to the test system which we
want to avoid. So leave the default as is and add a flag to make it use
buildman.
Note that most of these changes relate to test.py and the parts of the
travis/gitlab/azure scripts which relate to running test and building a
suitable U-Boot to run the tests on.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
Simon Glass [Wed, 18 Mar 2020 15:43:00 +0000 (09:43 -0600)]
travis/gitlab/azure: Drop repeated buildman call with test.py
It does not seem to be necessary to run buildman again to show errors,
since any errors can be shown by the first invocation and there is only
a single board being built. Update this to simplify the code, using the
-e flag to make sure errors are shown.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
Simon Glass [Wed, 18 Mar 2020 15:42:57 +0000 (09:42 -0600)]
travis/gitlab/azure: Use -W to avoid warnings check
We can use the -W flag to tell buildman to ignore warnings. Since we also
have -E defined, compiler warnings are promoted to errors, so they will
still cause a failure. But migration warnings of the form:
===================== WARNING ======================
This board does not use CONFIG_DM. CONFIG_DM will be
compulsory starting with the v2020.01 release.
Failure to update may result in board removal.
See doc/driver-model/migration.rst for more info.
will now be ignored.
Signed-off-by: Simon Glass <sjg@chromium.org> Fixes: 329f5ef51d2 (travis.yml: run buildman with option -E) Reviewed-by: Tom Rini <trini@konsulko.com>
Simon Glass [Wed, 18 Mar 2020 15:42:51 +0000 (09:42 -0600)]
travis/gitlab/azure: Use --board buildman flag with test.py
The current method of selecting the board to build with test.py is a bit
error-prone, e.g. with "^sandbox$" it actually builds 5 boards (all of
those in the sandbox architecture).
Use the (newish) --board flag instead, to get the same result.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
Simon Glass [Wed, 18 Mar 2020 15:42:49 +0000 (09:42 -0600)]
travis: Split the building into two parts
Buildman is used in two ways:
- to build a selection of boards (with no testing)
- to build a single board (and run pytest)
The gitlab and azure scrips do this in separate places, but travis does
not. To aid the refactoring process and keep the following patches in sync
across all three environments, split the code out in travis as well.
Use the buildman -w option for the single board. It is easier to
understand since it specifies the output directory directly. Also it
avoids needing to look at the internal .bm-work directory.
This initially creates some duplicate code, but by the end of the series
we have two completely different build paths with different arguments.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
Simon Glass [Wed, 18 Mar 2020 15:42:48 +0000 (09:42 -0600)]
travis: Don't copy files into .bm-work/
At present if TEST_PY_BD is empty the script copies various files into a
directory, to no purpose. This happens because UBOOT_TRAVIS_BUILD_DIR is
set before TEST_PY_BD is tested.
Move the 'if' to fix this.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
Simon Glass [Wed, 18 Mar 2020 15:42:46 +0000 (09:42 -0600)]
buildman: Allow building within a subdir of the current dir
This is useful in some situations, in particular with -w and when building
in-tree. Now that we are more careful about what we remove in
_PrepareOutputSpace(), it should be safe to relax this restriction.
Update the progress information also so it is clear what buildman is
doing. Remove files can take a long time.
Simon Glass [Wed, 18 Mar 2020 15:42:45 +0000 (09:42 -0600)]
buildman: Be more selective about which directories to remove
At present buildman removes any directory it doesn't intend to write
output into. This is overly expansive since if the output directory
happens to be somewhere with existing files, they may be removed. Using
an existing directory for buildman is not a good practice, but since the
result might be catastrophic, it is best to guard against it.
A previous commit[1] fixed this by refusing to write to a subdirectory
of the current directory, assumed to have U-Boot source code. But we can
do better by only removing directories that look like the ones buildman
creates.
Update the code to do this and add a test.
Signed-off-by: Simon Glass <sjg@chromium.org>
[1] 409fc029c40 tools: buildman: Don't use the working dir as build dir
Simon Glass [Wed, 18 Mar 2020 15:42:44 +0000 (09:42 -0600)]
buildman: Allow ignoring warnings in the return code
Sometimes we don't want buildman to return failure if it seems warnings.
Add a -W option to support this. If buildman detects warnings (and no
errors) it will return an exit code of 0 (success).
Note that the definition of 'warnings' includes the migration warnings
produced by U-Boot, such as:
===================== WARNING ======================
This board does not use CONFIG_DM_MMC. Please update
...
====================================================
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
Bin Meng [Mon, 6 Apr 2020 13:06:58 +0000 (06:06 -0700)]
video: sunxi: Change sunxi_get_mon_desc() to not return NULL for the default case
When building with gcc 9.2.0, the following build warning was seen:
drivers/video/sunxi/sunxi_display.c: In function 'video_hw_init':
drivers/video/sunxi/sunxi_display.c:1217:2:
error: '%s' directive argument is null [-Werror=format-overflow=]
Change sunxi_get_mon_desc() to not return NULL for the default case,
to fix the compiler warning.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Tom Rini <trini@konsulko.com>
Bin Meng [Sat, 28 Mar 2020 14:25:29 +0000 (07:25 -0700)]
azure/gitlab/travis: Add RISC-V SPL testing
This adds QEMU RISC-V 32/64 SPL testing. Unlike QEMU RISC-V 32/64,
we test SPL running in M-mode and U-Boot proper running in S-mode,
with a 4-core SMP configuration.
Bin Meng [Sat, 28 Mar 2020 14:25:25 +0000 (07:25 -0700)]
travis: Replace pre-built ARM/ARM64 GRUB images with the one built from source
As of today travis uses the pre-built GRUB ARM/ARM64 images from
opensuse. But azure/gitlab are using images built from GRUB 2.04
source. This updates travis to build GRUB ARM/ARM64 UEFI targets
from source, to keep in sync with azure/gitlab.
projects / u-boot.git / log