Some of the Python tests are a pain because they don't reset the TPM
state before each test. Driver model tests do this, so convert the
tests to C.
This means that these tests won't run on real hardware, but we have
tests which do TPM init, so there is still enough coverage.
Rename and update the Python tpm_init test to use 'tpm autostart',
since this fully initializes the TPM and performs the self tests.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Add support for the self-test continue command in the TPM v1.2 emulator,
to match the functionality in the TPM v2 emulator.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
This reverts commit 159b6f0e11.
Since commit 159b6f0e11 ("caam: Fix CAAM error on startup") the following
regression was reported by Tim Harvey:
"I've found that this patch causes a regression on an imx8mm board
(imx8mm_venice_defconfig) where the first call to caam_rng_read fails
here in jr_dequeue but if you call it again it works. With some
debugging added:
SEC0: RNG instantiated
...
Hit any key to stop autoboot: 0
u-boot=> rng list
RNG #0 - caam-rng
u-boot=> rng 0 10
caam_rng_read caam-rng len=16
run_descriptor_jr_idx idx=0
Error in SEC deq: -1
caam_rng_read_one run_descriptor_jr failed: -1
caam_rng_read caam-rng caam_rng_read_one failed: -5
Reading RNG failed
u-boot=> rng 0 10
caam_rng_read caam-rng len=16
run_descriptor_jr_idx idx=0
00000000: ad 2e ad c0 2a 12 27 c4 65 82 66 19 be ef f6 07 ....*.'.e.f.....
If I revert your patch caam_rng_read works initially and on subsequent
calls."
" I ran into this when I was testing
lwIP HTTPS as it causes anything that uses dm_rng to fail the first
time (such as HTTPS)."
Revert it for now to avoid the regression.
Reported-by: Tim Harvey <tharvey@gateworks.com>
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Acked-by: Peng Fan <peng.fan@nxp.com>
Add 'imply CONFIG_POSITION_INDEPENTDENT' for QEMU arm arch. This allows
qemu arm boards to load u-boot.bin at any address. It is skipped by
default when u-boot is loaded by either --bios or --kernel.
To load u-boot.bin at a different address, one can use u-boot
chain-loading or qemu loader device[1].
[1] https://www.qemu.org/docs/master/system/generic-loader.html
Signed-off-by: Yang Xiwen <forbidden405@outlook.com>
when CONFIG_BLOBLIST is enabled, the section is switched to .data but is
not switched back to .text. It makes all the code below placed in .data
section, also breaks CONFIG_POSITION_INDEPENDENT.
Fix it by adding `.section .text` to switch the section back to .text.
Fixes: 5103e69344 ("arm: armv7: save boot arguments")
Signed-off-by: Yang Xiwen <forbidden405@outlook.com>
Assign myself to develop U-Boot port of T-Head TH1520 SoC, and help
maintain related code and review patches.
Signed-off-by: Yao Zi <ziyao@disroot.org>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Proper U-Boot for Lichee Pi 4A now runs in S mode instead of M mode,
which means the extra firmware, OpenSBI, must be built and integrated
in the image, and the vendor U-Boot cannot chainload the result image
anymore as it runs in M mode.
Remove redundant information about chainloading and update build steps
to mention OpenSBI firmware.
Signed-off-by: Yao Zi <ziyao@disroot.org>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
RISC-V software usually expects S mode when leaving the firmware, e.g.
UEFI applications could only run in S mode. Let's convert proper U-Boot
of Lichee Pi 4A port to run in S mode.
Signed-off-by: Yao Zi <ziyao@disroot.org>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Add an OpenSBI entry to the FIT image. As it expects an FDT to be
passed, corresponding FDT entry is generated with of-list as well.
As SPL now passes a full FDT for following stages, proper U-Boot image
is packed into u-boot-with-spl.bin without a devicetree copy included.
Signed-off-by: Yao Zi <ziyao@disroot.org>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
These operations rely on a customized M-mode CSR, MHCR, which isn't
available when running in S mode.
Let's fallback to the generic weak stub when running in S mode to avoid
illegal accesses.
Signed-off-by: Yao Zi <ziyao@disroot.org>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Symbols in spl.c only function correctly in SPL stage. Build the file
for SPL only to avoid weak symbols in proper U-Boot being unexpectedly
reloaded.
Fixes: 5fe9ced355 ("riscv: cpu: Add TH1520 CPU support")
Signed-off-by: Yao Zi <ziyao@disroot.org>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
On several RISC-V boards we have seen that 1 MiB is a insufficient value
for CONFIG_SPL_SYS_MALLOC_SIZE.
For instance qemu-riscv32_spl_defconfig fails booting because u-boot.itb
exceeds 1 MiB.
8 MiB is a reasonable value that allows adding FPGA blobs or splash images
to main U-boot.
Reported-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Fix a typo error in gcc.rst, changing "out-out-tree" to
"out-of-tree" in the Out-of-tree section.
Signed-off-by: BehradElmi <behradelmi1@gmail.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
There are backslashes in some of the tags which seems to be unnecessary.
Remove then.
Change the word 'either' to 'any' since there are three options.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
The details of the sysfw.itb from the R5 build that
also needs to be copied as part of the target images
is missing, but is included in the image formats a
little further down, so add it to the instructions.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
%s/data that change/data that changes/
%s/cannot be used has/cannot be used for/
%s/Otherwise/Otherwise,/
%s/allows better measurement/allows for better measurement/
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
We have this file in both arch/arm/dts and
dts/upstream/src/arm64/freescale. This file is identical save for
changes which have been made upstream. Remove our local copy to get in
sync with upstream now.
Acked-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
We have these files in both arch/arm/dts and
dts/upstream/src/arm/microchip. These files are identical save for
changes which have been made upstream. Remove our local copy to get in
sync with upstream now.
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
As part of moving to using OF_UPSTREAM and so the upstream DT related
header files we have a header that is under the arch/arm/dts directory
and differ in being a strict subset of what is found upstream. We can
remove this now to prevent future conflicts.
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
As part of moving to using OF_UPSTREAM and so the upstream DT related
header files we have a number of these headers that are under the
arch/arm/dts directory and differ only in combinations of spacing
changes and/or switching to SPDX license tags. We can remove these now
to prevent future conflicts.
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
As part of moving to using OF_UPSTREAM and so the upstream DT related
header files we have a number of these headers that are under the
arch/arm/dts directory and are currently identical to the versions in
dts/upstream. We can remove these now to prevent future conflicts.
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
As part of moving to using OF_UPSTREAM and so the upstream DT related
header files we have a header that is under the arch/arm/dts directory
and now unused. We can remove this now to prevent any future conflicts.
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
A problem with the logic in upstream_dtsi_include currently is that it
does not list directories such as dts/upstream/src/arm/nxp/imx and so
will not findi "imx6ul-pinfunc.h" for example as it is normally and
correctly included without vendor sub-paths. Expand the current wildcard
glob to catch these directories too.
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
As part of moving to using OF_UPSTREAM and so the upstream dt-bindings
headers we have a number of these headers that are in our include
directory and while they are not a strict subset of the upstream version
of the headers, all platforms build with the new headers as well. We can
remove the copies under include/dt-bindings now to prevent future
conflicts.
Signed-off-by: Tom Rini <trini@konsulko.com>
Aside from SPDX tags, the only difference between our version of this
header and upstream is that BCM6318_RST_HOSTMIPS was defined to 11 (the
same as BCM6318_RST_PHYMIPS) and is now defined to 12.
Signed-off-by: Tom Rini <trini@konsulko.com>
As part of moving to using OF_UPSTREAM and so the upstream dt-bindings
headers we have a number of these headers that are in our include
directory and differ in being a strict subset of what is found upstream.
We can safely remove the copies under include/dt-bindings now to prevent
future conflicts.
Signed-off-by: Tom Rini <trini@konsulko.com>
As part of moving to using OF_UPSTREAM and so the upstream dt-bindings
headers we have a number of these headers that are in our include
directory and differ only in combinations of spacing changes and/or
switching to SPDX license tags. We can safely remove the copies under
include/dt-bindings now to prevent future conflicts.
Signed-off-by: Tom Rini <trini@konsulko.com>
As part of moving to using OF_UPSTREAM and so the upstream dt-bindings
headers we have a number of these headers that are in our include
directory and are currently identical to the versions in dts/upstream.
We can remove these now to prevent future conflicts.
Signed-off-by: Tom Rini <trini@konsulko.com>
As part of moving to using OF_UPSTREAM and so the upstream dt-bindings
headers we have a number of these headers that are in our include
directory and not referenced by any code outside of dts/upstream. We can
remove these now to prevent future conflicts.
Signed-off-by: Tom Rini <trini@konsulko.com>
The val (the bits to set) is the second member of the reg_data structure
and mask the third one. We obviously want to clear bits 6 and 7 in order
to only set bit 7 in there instead of only clearing bit 7 in order to
write bits 6 and 7 (which makes no sense).
Fortunately, according to the datasheet, bit 6 value doesn't matter when
bit 7 is set so this is essentially just a cosmetic change, no intended
change in behavior.
Fixes: f172575d92 ("power: rk8xx: add support for RK806")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The NanoPi RK3399 boards support UHS-I (up to SDR104) SD cards, however
using any of these 1.8v modes results in a boot failure in SPL upon soft
reboot.
The issue is that the "vcc_sdio" regulator is left at 1.8v on reboot
and the corresponding GPIO defaults to 3.3v. This prevents the SD card
from being reinitialized and read successfully.
This change enables the RK8XX regulators and Rockchip IO-domain drivers
in SPL, which initializes "vcc_sdio" regulator to 3.0v and configures
the GPIO for the correct level on boot.
Signed-off-by: Justin Klaassen <justin@tidylabs.net>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
This change removes the "regulator-always-on" property from the
"vcc3v0_sd" (vmmc-supply) and "vcc_sdio" (vqmmc-supply) regulators,
which otherwise prevents the MMC driver from being able to power cycle
the SD card as part of the initialization procedure.
It also removes the "regulator-boot-on" from the "vcc_sdio" regulator,
which could theoretically damage a SD card that is already initialized
in a low voltage mode.
Signed-off-by: Justin Klaassen <justin@tidylabs.net>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Allows use of the regulator functions of the RK8XX PMIC in SPL, which is
necessary to support the functionality of the Rockchip IO-domain driver
on relevant platforms.
Signed-off-by: Justin Klaassen <justin@tidylabs.net>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Allows use of the Rockchip IO-domain driver in SPL to configure
the GPIO to match the voltage supplied by specific regulators
(e.g. "vcc_sdio").
Signed-off-by: Justin Klaassen <justin@tidylabs.net>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Log the value of the regulators during initialization of the IO-domain
driver to aid in debugging GPIO voltage configuration problems.
Signed-off-by: Justin Klaassen <justin@tidylabs.net>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Our upcoming Mass Flasher solution will be storing boot artifacts on an
exFAT partition so enable its support.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Our upcoming Mass Flasher solution will be storing boot artifacts on an
exFAT partition so enable its support.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Our upcoming Mass Flasher solution will be storing boot artifacts on an
exFAT partition so enable its support.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Our upcoming Mass Flasher solution will be storing boot artifacts on an
exFAT partition so enable its support.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Because DEBUG_UART_BOARD_INIT depends on DEBUG_UART, hard dependency
to DEBUG_UART_BOARD_INIT in ROCKCHIP_PX30 can cause warnings if
DEBUG_UART is disabled.
The DEBUG_UART_BOARD_INIT is already implied by ARCH_ROCKCHIP entry.
Remove hard dependency from ROCKCHIP_PX30, so that it will be
consistent with other rockchip boards.
Signed-off-by: Lukasz Czechowski <lukasz.czechowski@thaumatec.com>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Simon GlassandIlias Apalodimas
Tom Rini
Heinrich SchuchardtandTom Rini
Fabio EstevamandTom Rini
Yang XiwenandTom Rini
Yao ZiandLeo Yu-Chi Liang
BehradElmiandHeinrich Schuchardt
Peter RobinsonandHeinrich Schuchardt
Quentin SchulzandKever Yang
Justin KlaassenandKever Yang
Lukasz CzechowskiandKever Yang