Tom Rini [Mon, 13 Jul 2020 15:29:51 +0000 (11:29 -0400)]
Merge tag 'efi-2020-10-rc1-3' of https://gitlab.denx.de/u-boot/custodians/u-boot-efi
Pull request for UEFI sub-system for efi-2020-10-rc1 (3)
Up to now UEFI variables where stored in U-Boot environment variables.
Saving UEFI variables was not possible without saving the U-Boot
environment variables. With this patch series file ubootefi.var in the
EFI system partition is used for saving UEFI variables. Furthermore the
UEFI variables are exposed for reading at runtime.
Code corrections for UEFI secure boot are provided.
efi_loader: wrong printf format in efi_image_parse
Commit 1b6c08548c85 ("efi_loader: image_loader: replace debug to
EFI_PRINT") leads to a build warning on 32bit systems:
lib/efi_loader/efi_image_loader.c: In function ‘efi_image_parse’:
include/efi_loader.h:123:8: warning: format ‘%lu’ expects argument
of type ‘long unsigned int’, but argument 8 has
type ‘size_t’ {aka ‘unsigned int’} [-Wformat=]
Use %zu for printing size_t.
Fixes: 1b6c08548c85 ("efi_loader: image_loader: replace debug to
EFI_PRINT")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
There's 2 variables in efi_get_next_variable_name() checking the size of
the variable name. Let's get rid of the reduntant definition and
simplitfy the code a bit.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
AKASHI Takahiro [Tue, 16 Jun 2020 05:26:48 +0000 (14:26 +0900)]
lib: rsa: export rsa_verify_with_pkey()
This function will be used to implement public_key_verify_signature()
in a later patch. rsa_verify() is not suitable here because calculation
of message digest is not necessary.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
test/py: efi_secboot: add a test for verifying with digest of signed image
Signature database (db or dbx) may have not only certificates that contain
a public key for RSA decryption, but also digests of signed images.
In this test case, if database has an image's digest (EFI_CERT_SHA256_GUID)
and if the value matches to a hash value calculated from image's binary,
authentication should pass in case of db, and fail in case of dbx.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Use defined time stamps for sign-efi-sig-list. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
test/py: efi_secboot: add a test for multiple signatures
In this test case, an image is signed multiple times with different
keys. If any of signatures contained is not verified, the whole
authentication check should fail.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Provide a defined time stamp for dbx_hash1.auth. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
test/py: efi_secboot: add a test against certificate revocation
Revocation database (dbx) may have not only certificates, but also
message digests of certificates with revocation time
(EFI_CERT_X509_SHA256_GUILD).
In this test case, if the database has such a digest and if the value
matches to a certificate that created a given image's signature,
authentication should fail.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Set defined time stamp for dbx_hash.auth. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
efi_loader: image_loader: add digest-based verification for signed image
In case that a type of certificate in "db" or "dbx" is
EFI_CERT_X509_SHA256_GUID, it is actually not a certificate which contains
a public key for RSA decryption, but a digest of image to be loaded.
If the value matches to a value calculated from a given binary image, it is
granted for loading.
With this patch, common digest check code, which used to be used for
unsigned image verification, will be extracted from
efi_signature_verify_with_sigdb() into efi_signature_lookup_digest(), and
extra step for digest check will be added to efi_image_authenticate().
efi_loader: image_loader: verification for all signatures should pass
A signed image may have multiple signatures in
- each WIN_CERTIFICATE in authenticode, and/or
- each SignerInfo in pkcs7 SignedData (of WIN_CERTIFICATE)
In the initial implementation of efi_image_authenticate(), the criteria
of verification check for multiple signatures case is a bit ambiguous
and it may cause inconsistent result.
With this patch, we will make sure that verification check in
efi_image_authenticate() should pass against all the signatures.
The only exception would be
- the case where a digest algorithm used in signature is not supported by
U-Boot, or
- the case where parsing some portion of authenticode has failed
In those cases, we don't know how the signature be handled and should
just ignore them.
Please note that, due to this change, efi_signature_verify_with_sigdb()'s
function prototype will be modified, taking "dbx" as well as "db"
instead of outputing a "certificate." If "dbx" is null, the behavior would
be the exact same as before.
The function's name will be changed to efi_signature_verify() once
current efi_signature_verify() has gone due to further improvement
in intermediate certificates support.
efi_loader: signature: fix a size check against revocation list
Since the size check against an entry in efi_search_siglist() is
incorrect, this function will never find out a to-be-matched certificate
and its associated revocation time in the signature list.
efi_loader: image_loader: retrieve authenticode only if it exists
Since the certificate table, which is indexed by
IMAGE_DIRECTORY_ENTRY_SECURITY and contains authenticode in PE image,
doesn't always exist, we should make sure that we will retrieve its pointer
only if it exists.
efi_loader: image_loader: add a check against certificate type of authenticode
UEFI specification requires that we shall support three type of
certificates of authenticode in PE image:
WIN_CERT_TYPE_EFI_GUID with the guid, EFI_CERT_TYPE_PCKS7_GUID
WIN_CERT_TYPE_PKCS_SIGNED_DATA
WIN_CERT_TYPE_EFI_PKCS1_15
As EDK2 does, we will support the first two that are pkcs7 SignedData.
Now that commit 3e57f879eee6 ("mtd: nand: raw: denali: Assert reset
before deassert") added the reset assertion, this code in the board
file is unneeded.
serial: uniphier: flush transmitter before changing hardware settings
Ensure the transmitter is empty when chaining the baudrate or any
hardware settings. If a character is remaining in the transmitter,
the console will be garbled.
bus: uniphier-system-bus: add UniPhier System Bus driver
Since commit 1517126fdac2 ("ARM: uniphier: select DM_ETH"), DM-based
drivers/net/smc911x.c is compiled, but it is never probed because the
parent node lacks the DM-based driver.
I need a skeleton driver to populate child devices (but the next commit
will move more hardware settings to the this driver).
I put this to drivers/bus/uniphier-system-bus.c because this is the
same path as the driver in Linux kernel.
ARM: uniphier: increase CONFIG_SYS_MONITOR_LEN to 2MB
I increased the maximum U-Boot proper size from time to time, but
configs/uniphier_v7_defconfig hit the current limit 832KB.
Some historical info:
In the initial support, the max size was 512MB.
Commit 58d702274c09 ("ARM: uniphier: increase CONFIG_SYS_MONITOR_LEN")
increased it to 576KB, and commit 3ce5b1a8d86d ("ARM: uniphier: move
SPL stack address") moved the SPL stack location to avoid the memory
map conflict. It was the solution to increase the size without changing
the NOR boot image map.
commit 1a4bd3a095b2 ("ARM: uniphier: increase CONFIG_SYS_MONITOR_LEN
again") ended up with increasing the max size again, breaking the NOR
boot image map. The limit was set to 832KB, otherwise the SPL stack
would overwrite the U-Boot proper image:
CONFIG_SPL_STACK - CONFIG_SYS_UBOOT_BASE + sizeof(struct image_header) = 0xd0000
To increase CONFIG_SYS_MONITOR_LEN even more, the SPL stack must be
moved somewhere. I put it back to the original location prior to
commit 3ce5b1a8d86d.
With this change, there is no more practical size limit.
This weird workaround was the best I came up with at that time
to boot U-Boot from TF-A.
I noticed U-Boot successfully boots on LD20 (i.e. CA72 CPU) by using
the latest TF-A.
Specifically, since the following TF-A commit, U-Boot runs at EL2
instead of EL1, and this issue went away as a side-effect.
|commit f998a052fd94ea082833109f25b94ed5bfa24e8b
|Author: Masahiro Yamada <yamada.masahiro@socionext.com>
|Date: Thu Jul 25 10:57:38 2019 +0900
|
| uniphier: run BL33 at EL2
|
| All the SoCs in 64-bit UniPhier SoC family support EL2.
|
| Just hard-code MODE_EL2 instead of using el_implemented() helper.
|
| Change-Id: I7ab48002c5205bc8c013e1b46313b57d6c431db0
| Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
However, if I reverted that, this problem would come back, presumably
because some EL1 code in U-Boot triggers this issue.
Now that commit f8ddd8cbb513 ("arm64: issue ISB after updating system
registers") fixed this issue properly, this weird workaround is no
longer needed irrespective of the exception level at which U-Boot runs.
config: Enable support for the XHCI controller on RPI4 board
This requires enabling BRCMSTB PCIe and XHCI_PCI drivers as well as PCI
and USB commands. To get it working one has to call the following commands:
"pci enum; usb start;", thus such commands have been added to the default
"preboot" environment variable. One has to update their environment if it
is already configured to get this feature working out of the box.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
rpi4: add a mapping for the PCIe XHCI controller MMIO registers (ARM 32bit)
Create a non-cacheable mapping for the 0x600000000 physical memory region,
where MMIO registers for the PCIe XHCI controller are instantiated by the
PCIe bridge. Due to 32bit limit in the CPU virtual address space in ARM
32bit mode, this region is mapped at 0xff800000 CPU virtual address.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Move ADDR_MAP related config options from include/configs/*.h to the
proper place in lib/Kconfig. This has been done using
./tools/moveconfig.py and manual inspection of the generated changes.
This is a preparation to use ADDR_MAP helper on ARM 32bit Raspberry Pi4
board for mapping the PCIe XHCI MMIO, which is above the 4GiB identity
mapping limit.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Tom Rini <trini@konsulko.com>
Some atypical users of xhci might need to manually reset their xHCI
controller before starting the HCD setup. Check if a reset controller
device is available to the PCI bus and trigger a reset.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
[mb: squash fix to only build xhci_reset_hw() if CONFIG_DM_BUS] Signed-off-by: Matthias Brugger <mbrugger@suse.com>
reset: Add Raspberry Pi 4 firmware reset controller
Raspberry Pi 4's co-processor controls some of the board's HW
initialization process, but it's up to Linux to trigger it when
relevant. Introduce a reset controller capable of interfacing with
RPi4's co-processor that models these firmware initialization routines as
reset lines.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by: Matthias Brugger <mbrugger@suse.com>
arm: rpi: Add function to trigger VL805's firmware load
On the Raspberry Pi 4, after a PCI reset, VL805's (a xHCI chip) firmware
may either be loaded directly from an EEPROM or, if not present, by the
SoC's VideCore (the SoC's co-processor). Introduce the function that
informs VideCore that VL805 may need its firmware loaded.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by: Matthias Brugger <mbrugger@suse.com>
Marek Szyprowski [Mon, 25 May 2020 11:39:59 +0000 (13:39 +0200)]
configs: Enable support for the XHCI controller on RPI4 board (ARM 64-bit)
This requires enabling BRCMSTB PCIe and XHCI_PCI drivers as well as PCI
and USB commands. To get it working one has to call the following commands:
"pci enum; usb start;", thus such commands have been added to the default
"preboot" environment variable. One has to update their environment if it
is already configured to get this feature working out of the box.
pci: Add driver for Broadcom BCM2711 SoC PCIe controller
This patch adds basic driver PCI Express controller found on Broadcom
set-top-box SoCs, e.g. BCM2711.
The code is based on Linux upstream driver (pcie-brcmstb.c) with MSI
handling removed. The inbound access memory region is not currently
parsed from dma-ranges DT property and a fixed 3GB region is used.
The patch has been tested on RPI4 board, i.e. on BCM2711 SoC with VL805
USB Host Controller.
linux/bitfield.h: Add primitives for manipulating bitfields both in host- and fixed-endian
Imports Al Viro's original Linux commit 00b0c9b82663a, which contains
an in depth explanation and two fixes from Johannes Berg: e7d4a95da86e0 "bitfield: fix *_encode_bits()", 37a3862e12382 "bitfield: add u8 helpers".
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
[s.nawrocki: added empty lines between functions and macros] Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
[mb: squash fix including byteorder.h] Signed-off-by: Matthias Brugger <mbrugger@suse.com>
Walter Lozano [Thu, 25 Jun 2020 04:10:15 +0000 (01:10 -0300)]
arm: dts: include gpio nodes for card detect
Several MMC drivers use GPIO for card detection with cd-gpios property in
the MMC node pointing to a GPIO node. However, as U-Boot tries to save
space by keeping only required nodes using u-boot* properties, several
devices tree result in having only in the MMC node but not the GPIO node
associated to cd-gpios.
This patch, fixes several ocurrence of this issue.
Signed-off-by: Walter Lozano <walter.lozano@collabora.com> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Adam Ford <aford173@gmail.com> #da850-evm
Walter Lozano [Thu, 25 Jun 2020 04:10:14 +0000 (01:10 -0300)]
dm: doc: update of-plat with new phandle support
Update documentation to reflect the new phandle support when OF_PLATDATA
is used. Now phandles are implemented as pointers to U_BOOT_DEVICE,
which makes it possible to get a pointer to the actual device.
Signed-off-by: Walter Lozano <walter.lozano@collabora.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Walter Lozano [Thu, 25 Jun 2020 04:10:13 +0000 (01:10 -0300)]
dtoc: extend dtoc to use struct driver_info when linking nodes
In the current implementation, when dtoc parses a dtb to generate a struct
platdata it converts the information related to linked nodes as pointers
to struct platdata of destination nodes. By doing this, it makes
difficult to get pointer to udevices created based on these
information.
This patch extends dtoc to use struct driver_info when populating
information about linked nodes, which makes it easier to later get
the devices created. In this context, reimplement functions like
clk_get_by_index_platdata() which made use of the previous approach.
Signed-off-by: Walter Lozano <walter.lozano@collabora.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Walter Lozano [Thu, 25 Jun 2020 04:10:11 +0000 (01:10 -0300)]
core: extend struct driver_info to point to device
Currently when creating an U_BOOT_DEVICE entry a struct driver_info
is declared, which contains the data needed to instantiate the device.
However, the actual device is created at runtime and there is no proper
way to get the device based on its struct driver_info.
This patch extends struct driver_info adding a pointer to udevice which
is populated during the bind process, allowing to generate a set of
functions to get the device based on its struct driver_info.
Signed-off-by: Walter Lozano <walter.lozano@collabora.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Walter Lozano [Thu, 25 Jun 2020 04:10:10 +0000 (01:10 -0300)]
core: drop const for struct driver_info
In order to prepare for a new support of phandle when OF_PLATDATA is used
drop the const for struct driver_info as this struct will need to be
updated on runtime.
Signed-off-by: Walter Lozano <walter.lozano@collabora.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Walter Lozano [Fri, 3 Jul 2020 11:07:17 +0000 (08:07 -0300)]
dtoc: add support to scan drivers
Currently dtoc scans dtbs to convert them to struct platdata and
to generate U_BOOT_DEVICE entries. These entries need to be filled
with the driver name, but at this moment the information used is the
compatible name present in the dtb. This causes that only nodes with
a compatible name that matches a driver name generate a working
entry.
In order to improve this behaviour, this patch adds to dtoc the
capability of scan drivers source code to generate a list of valid driver
names and aliases. This allows to generate U_BOOT_DEVICE entries using
valid driver names and rise a warning in the case a name is not valid.
Signed-off-by: Walter Lozano <walter.lozano@collabora.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Open files in utf-8 mode: Signed-off-by: Simon Glass <sjg@chromium.org>
Walter Lozano [Thu, 25 Jun 2020 04:10:06 +0000 (01:10 -0300)]
core: add support for U_BOOT_DRIVER_ALIAS
Currently when using OF_PLATDATA the binding between devices and drivers
is done trying to match the compatible string in the node with a driver
name. However, usually a single driver supports multiple compatible strings
which causes that only devices which its compatible string matches a
driver name get bound.
To overcome this issue, this patch adds the U_BOOT_DRIVER_ALIAS macro,
which generates no code at all, but allows an easy way to declare driver
name aliases. Thanks to this, dtoc could be improve to look for the driver
name based on its alias when it populates the U_BOOT_DEVICE entry.
Signed-off-by: Walter Lozano <walter.lozano@collabora.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Walter Lozano [Thu, 25 Jun 2020 04:10:04 +0000 (01:10 -0300)]
drivers: rename drivers to match compatible string
When using OF_PLATDATA, the bind process between devices and drivers
is performed trying to match compatible string with driver names.
However driver names are not strictly defined, and also there are different
names used when declaring a driver with U_BOOT_DRIVER, the name of the
symbol used in the linker list and the used in the struct driver_info.
In order to make things a bit more clear, rename the drivers names. This
will also help for further OF_PLATDATA improvements, such as checking
for valid driver names.
Signed-off-by: Walter Lozano <walter.lozano@collabora.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Add a fix for sandbox of-platdata to avoid using an invalid ANSI colour: Signed-off-by: Simon Glass <sjg@chromium.org>
When printing the device tree we want to get an output that can be used as
input for the device tree compiler. This requires that we do not write
bogus lines like
For instance the QEMU virt device has a property interrupt-map with 640
bytes which exceeds CMD_FDT_MAX_DUMP=64.
So lets do away with the artificial limitation to 64 bytes.
As indicated in commit f0a29d43313c ("fdt: Limit printed hex in fdt print
and list commands") if a device tree contains binary blobs, it may still
be desirable to limit the output length. Provide environment variable
fdt_max_dump for this purpose.
Fixes: 5d927b428622 ("Kconfig: Drop CONFIG_CMD_FDT_MAX_DUMP") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
projects / u-boot.git / log
