Masami Hiramatsu [Wed, 16 Feb 2022 06:15:42 +0000 (15:15 +0900)]
efi_loader: use efi_update_capsule_firmware() for capsule on disk
Since the efi_update_capsule() represents the UpdateCapsule() runtime
service, it has to handle the capsule flags and update ESRT. However
the capsule-on-disk doesn't need to care about such things.
Thus, the capsule-on-disk should use the efi_capsule_update_firmware()
directly instead of calling efi_update_capsule().
This means the roles of the efi_update_capsule() and capsule-on-disk
are different. We have to keep the efi_update_capsule() for providing
runtime service API at boot time.
Ilias Apalodimas [Mon, 14 Feb 2022 09:14:22 +0000 (11:14 +0200)]
efi_loader: fix uefi secure boot with intermediate certs
The general rule of accepting or rejecting an image is
1. Is the sha256 of the image in dbx
2. Is the image signed with a certificate that's found in db and
not in dbx
3. The image carries a cert which is signed by a cert in db (and
not in dbx) and the image can be verified against the former
4. Is the sha256 of the image in db
For example SHIM is signed by "CN=Microsoft Windows UEFI Driver Publisher",
which is issued by "CN=Microsoft Corporation UEFI CA 2011", which in it's
turn is issued by "CN=Microsoft Corporation Third Party Marketplace Root".
The latter is a self-signed CA certificate and with our current implementation
allows shim to execute if we insert it in db.
However it's the CA cert in the middle of the chain which usually ends up
in the system's db. pkcs7_verify_one() might or might not return the root
certificate for a given chain. But when verifying executables in UEFI, the
trust anchor can be in the middle of the chain, as long as that certificate
is present in db. Currently we only allow this check on self-signed
certificates, so let's remove that check and allow all certs to try a
match an entry in db.
Open questions:
- Does this break any aspect of variable authentication since
efi_signature_verify() is used on those as well?
Philippe Reynes [Tue, 22 Feb 2022 13:54:39 +0000 (14:54 +0100)]
scripts: Makefile.lib: generate dsdt_generated.c instead of dsdt.c
There is a conflict between the static file
lib/acpi/dsdt.c and the file dsdt.c generated
dynamicaly by scripts/Makefile.lib. When a
mrproper is done, the static file dsdt.c is
removed. If a build with acpi enabled is
launched after, the following error is raised:
CC lib/acpi/acpi_table.o
make[2]: *** No rule to make target 'lib/acpi/dsdt.asl', needed by 'lib/acpi/dsdt.c'. Stop.
scripts/Makefile.build:394: recipe for target 'lib/acpi' failed
To avoid such error, the generated file is named
dsdt_generated.c instead of dstdt.c.
Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com> Tested-by: Heiko Thiery <heiko.thiery@gmail.com>
Patrick Delaunay [Mon, 31 Jan 2022 16:21:38 +0000 (17:21 +0100)]
cmd: clk: replace clk_lookup by uclass_get_device_by_name
The function clk_lookup can be replaced by a direct call
to uclass_get_device_by_name for UCLASS_CLK.
This patch removes duplicated codes by the generic DM API and avoids
issue in clk_lookup because result of uclass_get_device wasn't tested;
when ret < 0, dev = NULL and dev->name is invalid, the next function
call strcmp(name, dev->name) causes a crash.
Patrick Delaunay [Mon, 24 Jan 2022 13:17:14 +0000 (14:17 +0100)]
clk: ccf: correct the test on the parent uclass in clk_enable/clk_disable
It is safe to check if the uclass id on the device is UCLASS_CLK
before to call the clk_ functions, but today this comparison is
not done on the device used in API: clkp->dev->parent
but on the device himself: clkp->dev.
This patch corrects this behavior and tests if the parent device
is a clock device before to call the clock API, clk_enable or
clk_disable, on this device.
Fixes: 0520be0f67e3 ("clk: prograte clk enable/disable to parent") Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Sean Anderson <seanga2@gmail.com>
Sean Anderson [Sat, 15 Jan 2022 20:52:47 +0000 (15:52 -0500)]
clk: Add clk_get_by_name_optional
This adds a helper function for clk_get_by_name in cases where the clock is
optional. Hopefully this helps point driver writers in the right direction.
Also convert some existing users.
Sean Anderson [Wed, 22 Dec 2021 17:11:13 +0000 (12:11 -0500)]
clk: Add driver API to HTML docs
This converts the existing driver API docs (clk-uclass.h) to kernel doc
format and adds them to the HTML documentation. Because the kernel doc
sphinx converter does not handle functions in structs very well, the
individual methods are documented separately. This is primarily inspired by
the phylink documentation [1], which uses this trick extensively.
Sean Anderson [Wed, 22 Dec 2021 17:11:12 +0000 (12:11 -0500)]
clk: Add client API to HTML docs
This converts the existing client (aka clk.h) documentation to kernel doc
format, and adds it to the HTML docs. I have tried to preserve existing
comments as much as possible, refraining from semantic changes.
Signed-off-by: Sean Anderson <seanga2@gmail.com> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Link: https://lore.kernel.org/r/20211222171114.3091780-4-seanga2@gmail.com
[rebased onto u-boot/master and resolved conflicts] Signed-off-by: Sean Anderson <seanga2@gmail.com>
Sean Anderson [Wed, 22 Dec 2021 17:11:11 +0000 (12:11 -0500)]
clk: Inline clk_get_*_optional
The optional varients of clk_get_* functions are just simple wrappers.
Reduce code size a bit by inlining them. On platforms where it is not used
(most of them), it will not be compiled in any more. On platforms where
they are used, the inlined branch should not cause any significant growth.
Adam Ford [Sat, 19 Feb 2022 23:08:46 +0000 (17:08 -0600)]
usb: ehci-omap: Remove OMAP_EHCI_PHYx_RESET_GPIO from Kconfig
With the omap-ehci driver now using the phy subsystem to enable
and disable reset, the driver no longer needs to know which
GPIO's are used, and they can be removed from Kconfig.
Adam Ford [Sat, 19 Feb 2022 23:08:45 +0000 (17:08 -0600)]
usb: ehci-omap: Use PHY system to manage phy resets
There are a few boards that use hard-coded GPIO definitions in
their respective defconfig files. If the GPIO's are listed
in their device trees, the nop-phy can toggle the GPIO's,
so the EHCI driver does not need to know anything about the
GPIO's. Add functions for getting the phys and remove the GPIO
toggles since the phy will now do that.
Adam Ford [Sat, 19 Feb 2022 23:08:44 +0000 (17:08 -0600)]
usb: ehci-omap: Make Kconfig select PHY if USB_EHCI_OMAP
The USB_EHCI_OMAP driver currently has a series of Kconfig options
which let users specify a GPIO for the reset pin. Some devices
may have only one reset, while others might have more.
Since there is a nop phy driver, let's selct enable the PHY
system, and imply the nop phy driver. The nop phy driver can now
toggle the reset pins when putting the phy in and out of reset.
If the gpio is listed under the phy, it will get toggled and
the hard-coded config options specifying the GPIO numbers can
eventually go away.
Adam Ford [Sat, 19 Feb 2022 23:08:43 +0000 (17:08 -0600)]
phy: nop-phy: Fix enabling reset
The reset function should place the phy into reset, while the
init function should take the phy out of reset. Currently the
reset function takes it out of reset, and the init calls the
reset.
Adam Ford [Sat, 19 Feb 2022 23:08:42 +0000 (17:08 -0600)]
usb: ehci-omap: Move omap_ehci_hcd_init to omap_ehci_probe
The OMAP3 hierarchy has the ehci node as a sub-node of the
usbhshost. The usbhshost node contains an ohci and an ehci
subnode. The configuration of the ehci belongs in the
EHCI node and not its parent. Move it to the proper probe.
usb start
starting USB...
Bus ehci@48064800: USB EHCI 1.00
Bus usb_otg_hs@480ab000: Port not available.
scanning bus ehci@48064800 for devices... 3 USB Device(s) found
scanning usb for storage devices... 1 Storage Device(s) found
Adam Ford [Sat, 19 Feb 2022 23:08:41 +0000 (17:08 -0600)]
usb: ehci-omap: Drop dead code
omap_ehci_hcd_stop appears to be dead code, and omap_ehci_hcd_init
is only called by the probe function, so it can be static to that
function. Remove both from the header along with some additional
checking for DM_USB.
On some configs (like stm32mp15_dhcom_basic_defconfig), if configs
SPL_LOAD_FIT_FULL and SPL_FIT_FULL_CHECK are enabled. Then the compilatio
fails with the following error:
arm-linux-gnueabi-ld.bfd: boot/image-fit.o: in function `fit_check_format':
<PATH>/uboot/u-boot-stm/boot/image-fit.c:1641: undefined reference to `fdt_check_full'
scripts/Makefile.spl:509: recipe for target 'spl/u-boot-spl' failed
This issue happens because the function fdt_check_full is only defined if
"!defined(FDT_ASSUME_MASK) || FDT_ASSUME_MASK != 0xff". But this function
may be called even if this condition are not verified. To avoid this issue,
the function fdt_check_full is always defined.
Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Simon Glass [Tue, 8 Feb 2022 18:50:00 +0000 (11:50 -0700)]
binman: Move entry-data collection into a Entry method
Collecting the data from a list of entries and putting it in a file is
a useful operation that will be needed by other entry types. Put this into
a method in the Entry class.
Add some documentation about how to collect data for an entry type.
Simon Glass [Tue, 8 Feb 2022 18:49:58 +0000 (11:49 -0700)]
binman: Support a list of strings with the mkimage etype
At present the 'args' property of the mkimage entry type is a string. This
makes it difficult to include CONFIG options in that property. In
particular, this does not work:
args = "-n CONFIG_SYS_SOC -E"
since the preprocessor does not operate within strings, nor does this:
args = "-n" CONFIG_SYS_SOC" "-E"
since the device tree compiler does not understand string concatenation.
Roger Quadros [Sat, 19 Feb 2022 18:50:04 +0000 (20:50 +0200)]
binman: Add support for TEE BL32
Add an entry for OP-TEE Trusted OS 'BL32' payload.
This is required by platforms using Cortex-A cores with TrustZone
technology.
Signed-off-by: Roger Quadros <rogerq@kernel.org> Reviewed-by: Simon Glass <sjg@chromium.org>
Add missing-blob-help, renumber the test file, update entry-docs: Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Tue, 8 Feb 2022 18:49:52 +0000 (11:49 -0700)]
dtoc: Allow deleting nodes and adding them in the same sync
This does not work at present, since the current algorithm assumes that
either there are no nodes or all nodes have an offset. If a node is new,
but an old node is still in the tree, then syncing fails due to this
assumption.
Simon Glass [Tue, 8 Feb 2022 18:49:47 +0000 (11:49 -0700)]
spl: x86: Correct the binman symbols for SPL
These symbols are incorrect, meaning that binman cannot find the
associated entry. This leads to errors like:
binman: Section '/binman/simple-bin': Symbol '_binman_spl_prop_size'
in entry '/binman/simple-bin/u-boot-spl/u-boot-spl-nodtb':
Entry 'spl' not found in list (mkimage,u-boot-spl-nodtb,
u-boot-spl-bss-pad,u-boot-spl-dtb,u-boot-spl,u-boot-img,main-section)
Simon Glass [Tue, 8 Feb 2022 18:49:46 +0000 (11:49 -0700)]
moveconfig: Allow regex matches when finding combinations
It is useful to be able to search for CONFIG options that match a regex,
such as this, which lists boards which define SPL_FIT_GENERATOR and
anything not starting with ROCKCHIP:
Binman keeps track of positions of each entry in the final image, but
currently this data is wrong for things included in FIT entries,
especially since a previous patch makes FIT a subclass of Section and
inherit its implementation.
There are three ways to put data into a FIT image. It can be directly
included as a "data" property, or it can be external to the FIT image
represented by an offset-size pair of properties. This external offset
is either "data-position" from the start of the FIT or "data-offset"
from the end of the FIT, and the size is "data-size" for both. However,
binman doesn't use the "data-offset" method while building FIT entries.
According to the Section docstring, its subclasses should calculate and
set the correct offsets and sizes in SetImagePos() method. Do this for
FIT subentries for the three ways mentioned above, and add tests for the
two ways binman can pack them in.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
binman: Skip processing "hash" subnodes of FIT subsections
Binman's FIT entry type can have image subentries with "hash" subnodes
intended to be processed by mkimage, but not binman. However, the Entry
class and any subclass that reuses its implementation tries to process
these unconditionally. This can lead to an error when boards specify
hash algorithms that binman doesn't support, but mkimage supports.
Let entries skip processing these "hash" subnodes based on an instance
variable, and set this instance variable for FIT subsections. Also
re-enable processing of calculated and missing properties of FIT entries
which was disabled to mitigate this issue.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Neal Liu [Tue, 15 Feb 2022 10:14:40 +0000 (18:14 +0800)]
crypto: aspeed: fix polling RSA status wrong issue
Check interrupt status to see if RSA engine is completed. After completion
of the task, write-clear the status to finish operation.
Add missing register base for completion.
Fixes: 89c36cca0b6 ("crypto: aspeed: Add AST2600 ACRY support") Signed-off-by: Neal Liu <neal_liu@aspeedtech.com> Reviewed-by: Chia-Wei Wang <chiawei_wang@aspeedtech.com>
Suman Anna [Sun, 13 Feb 2022 18:48:48 +0000 (12:48 -0600)]
arm: dts: k3-j7200: Fix up MAIN R5FSS cluster mode back to Split-mode
The default U-Boot environment variables and design are all set up for
the MAIN R5FSS cluster to be in Split-mode. This is the setting used
when the dts nodes were originally added in v2021.01 U-Boot and the
dt nodes are synched with the kernel binding property names in
commit 468ec2f3ef8f ("remoteproc: k3_r5: Sync to upstreamed kernel DT
property names") merged in v2021.04-rc2.
The modes for the MAIN R5FSS cluster got switched back to LockStep mode
by mistake in commit fa09b12dc5f6 ("arm: ti: k3: Resync dts files and
bindings with Linux Kernel v5.14") in v2022.01-rc1. This throws the
following warning messages when early-booting the cores using default
env variables,
k3_r5f_rproc r5f@5d00000: Invalid op: Trying to start secondary core 7 in lockstep mode
Load Remote Processor 3 with data@addr=0x82000000 83148 bytes: Failed!
Fix this by switching back both the clusters to the expected Split-mode.
Make this mode change in the u-boot specific dtsi file to avoid such
sync overrides in the future until the kernel dts is also switched to
Split-mode by default.
Fixes: fa09b12dc5f6 ("arm: ti: k3: Resync dts files and bindings with Linux Kernel v5.14") Signed-off-by: Suman Anna <s-anna@ti.com>
Adam Ford [Sat, 12 Feb 2022 12:12:41 +0000 (06:12 -0600)]
arm: omap3: Make some memory functions static and clean headers
There are a few memory functions for both the emif4 (AM3517)
and sdrc (OMAP35/DM37) code that can be defined as static,
because those functions are not used externally. Make them
static and clean up some of the corresponding headers.
Adam Ford [Sat, 12 Feb 2022 12:12:40 +0000 (06:12 -0600)]
arm: omap3: Cleanup sys_info to fit OMAP3 booting with LTO
With LTO enabled, some functions appear to be optimized in a
way that causes hanging on some OMAP3 boards after some
unrelated patches were applied. The solution appears to make
several functions __used. There also appears be to be some
dead code, so remove it while cleaning this up.
This has been tested on a general purpose OMAP3530, DM3730,
and AM3517.
Mark Kettenis [Mon, 14 Feb 2022 21:09:26 +0000 (22:09 +0100)]
doc: board: apple: Update Apple M1 documentation
U-Boot now supports NVMe storage and on the laptop models, the
SPI keyboard. Since we now disable the debug console by default
provide instructions on how the enable the debug console including
a table listing the appropriate UART base address for each of the
supported SoCs.
Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
Mark Kettenis [Mon, 14 Feb 2022 21:09:25 +0000 (22:09 +0100)]
arm: apple: Disable debug UART
The address of the debug UART varies differs between the M1 and
the M1 Pro/Max SoCs. So we have to disable it to make a single
U-Boot binary that works on all SoC generations. Leave the
settings for the base address and clock rate of the M1 in place
to make it easier to re-enable the debug UART when needed.
Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
Mark Kettenis [Tue, 8 Feb 2022 21:00:09 +0000 (22:00 +0100)]
arm: apple: Add M1 Pro/Max support
Choose the memory map based on the compatible property from the
device tree passed to us by m1n1. Since DRAM on the M1 Pro/Max
starts at a different address avoid hardcoding the top of usable
memory. Also make sure that the addresses entered into the memory
map are page aligned such that we don't crash in dcache_enable().
Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
Tested on: Macbook M1 Max Tested-by: Janne Grunau <j@jannau.net>
Michal Simek [Thu, 17 Feb 2022 13:28:42 +0000 (14:28 +0100)]
arm64: zynqmp: Fix debug uart initialization
The commit 0dba45864b2a ("arm: Init the debug UART") calls
debug_uart_init() from crt0.S but it won't work because SOC is not
configured yet. That's why create board_debug_uart_init() which calls
psu_init() via new psu_uboot_init() earlier before the first access to UART
in SPL. In full U-Boot call psu_uboot_init() only when
CONFIG_ZYNQMP_PSU_INIT_ENABLED is enabled.
Michal Simek [Thu, 17 Feb 2022 13:28:41 +0000 (14:28 +0100)]
ARM: zynq: Fix debug uart initialization
The commit 0dba45864b2a ("arm: Init the debug UART") calls
debug_uart_init() from crt0.S but it won't work because SOC is not
configured yet. That's why create board_debug_uart_init() which calls
ps7_init() earlier before the first access to UART.
Michal Simek [Thu, 17 Feb 2022 13:28:40 +0000 (14:28 +0100)]
arm64: zynqmp: Fix dependencies around ZYNQMP_PSU_INIT_ENABLED
ZYNQMP_PSU_INIT_ENABLED is called only when BOARD_EARLY_INIT_F is defined
that's why cover this dependency in Kconfig.
board_early_init_f() is only part related to
CONFIG_ZYNQMP_PSU_INIT_ENABLED which is disabled now that's why disable
BOARD_EARLY_INIT_F and also build board_early_init_f() only when
CONFIG_BOARD_EARLY_INIT_F is enabled.
Michal Simek [Thu, 17 Feb 2022 13:28:39 +0000 (14:28 +0100)]
arm64: zynqmp: Build psu_spl_init for SPL all the time
ZYNQMP_PSU_INIT_ENABLED specifically saying that has connection to full
U-Boot not SPL that's why build psu_spl_init for SPL all the time.
Also disable ZYNQMP_PSU_INIT_ENABLED because it ends up in situation that
psu_init() is called twice which is wrong. By default only SPL should call
it.
Michal Simek [Thu, 17 Feb 2022 13:28:38 +0000 (14:28 +0100)]
xilinx: Enable OF_BOARD for zynq and zynqmp boards
The commit 985503439762 ("fdt: Don't call board_fdt_blob_setup() without
OF_BOARD") forced to enable OF_BOARD for platforms which provide DT
externally. Zynq/ZynqMP boards are using this feature for a long time
that's why there is a need to enable it by default.
Also code expects to return error in case of error that's why also fill it.
Heiko Thiery [Wed, 16 Feb 2022 14:58:10 +0000 (15:58 +0100)]
kontron-pitx-imx8m: fix board_mmc_getcd()
The function wrongly will return the card detection status of the SD card
(USDHC2) for the eMMC (USDHC1). Thus booting from eMMC without an inserted
SD card will fail.
Currently the space between kernel_addr_r and the fdt_addr_r is only 32MB.
To have enought space to load kernel images bigger than 32MB change the
variables to a feasible value.
The new environment variables layout is based on the scheme from
"include/configs/ti_armv7_common.h".
The CONFIG_SYS_LOAD_ADDR value is set to 0x42000000. With that we have
the same value as for the kernel_addr_r.
Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com> Reviewed-by: Michael Walle <michael@walle.cc>
Use the complete 512kb (4 blocks) nand partition reserved for u-boot
environment instead of just the first block, this allows the module to
have a working environment even if 3 blocks are bad.
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Tim Harvey [Fri, 11 Feb 2022 18:48:56 +0000 (10:48 -0800)]
board: gateworks: venice: add imx8mn-gw7902 support
The GW7902 is based on the i.MX 8M Mini / Nano SoC featuring:
- LPDDR4 DRAM
- eMMC FLASH
- Gateworks System Controller
- LTE CAT M1 modem
- USB 2.0 HUB
- M.2 Socket with USB2.0, PCIe, and dual-SIM
- IMX8M FEC
- PCIe based GbE
- RS232/RS485/RS422 serial transceiver
- GPS
- CAN bus
- WiFi / Bluetooth
- MIPI header (DSI/CSI/GPIO/PWM/I2S)
- PMIC
To add support for the i.MX8M Nano GW7902:
- Add imx8mn-venice dts/defconfig/include
- Add imx8mn-gw7902 dts
- Add imx8mn-2gb lpddr4 dram configs
- Add misc support for IMX8M Nano SoC
- rename imx8mm-venice.c to venice.c as it is no longer imx8mm specific
- update README with differences for IMX8MN vs IMX8MM
Signed-off-by: Tim Harvey <tharvey@gateworks.com> Reviewed-by: Fabio Estevam <festevam@gmail.com>
With binman generating flash.bin, it's not longer necessary to
specify either the location of ATF nor is it necessary to
specify building flash.bin, so let's update the build instructions
to remove those. While in here, update the revision of ATF and
DDR firmware so both Mini and Nano reference the same revision.
Signed-off-by: Adam Ford <aford173@gmail.com> Reviewed-by: Fabio Estevam <festevam@gmail.com>
Adam Ford [Wed, 12 Jan 2022 13:53:56 +0000 (07:53 -0600)]
mmc: fsl_esdhc_imx: Use esdhc_soc_data flags to set host caps
The Linux driver automatically can detect and enable UHS, HS200, HS400
and HS400_ES automatically without extra flags being placed into the
device tree.
Right now, for U-Boot to use UHS, HS200 or HS400, the extra flags are
needed in the device tree. Instead, go through the esdhc_soc_data
flags and enable the host caps where applicable to automatically
enable higher speeds.
Suggested-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Adam Ford <aford173@gmail.com>
- a37xx: pci: Cleanup and minor fix for root port check (Pali)
- pci: mvebu: Ensure that root port is always on root zero bus (Pali)
- kwbimage: Fix dumping DATA registers for v0 images (Pali)
- kwbimage: Support for parsing extended v0 format (Pali)
- a37xx: Fix code and update DTS files to upstream version (Pali)
- a37xx: Fix and extend building memory map (Pali)
- ddr: marvell: a38x: fix BYTE_HOMOGENEOUS_SPLIT_OUT decision (Marek)
- mvebu: Optionally reset board on DDR training failure (Marek)
Marek Behún [Thu, 17 Feb 2022 12:54:43 +0000 (13:54 +0100)]
arm: mvebu: turris_omnia: Reset the board immediately on DDR training failure
The state of the current DDR training code for Armada 38x is such that
we cannot be sure it will always train successfully - although after the
last change we were yet unable to find a board that failed DDR training,
from experience in the last 2 years we know that it is possible.
The experience also tells us that in many cases the board fails training
only sometimes, and after a reset the training is successful.
Enable the new option that makes the board reset itself on DDR training
failure immediately. Until now we called hang() in such a case, which
meant that the board was reset by the MCU after 120 seconds.
Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de> Reviewed-by: Pali Rohár <pali@kernel.org>
Marek Behún [Thu, 17 Feb 2022 12:54:42 +0000 (13:54 +0100)]
arm: mvebu: spl: Add option to reset the board on DDR training failure
Some boards may occacionally fail DDR training. Currently we hang() in
this case. Add an option that makes the board do an immediate reset in
such a case, so that a new training is tried as soon as possible,
instead of hanging and possibly waiting for watchdog to reset the board.
(If the DDR training fails while booting the image via UART, we will
still hang - it doesn't make sense to reset in such a case, because
after reset the board will try booting from another medium, and the
UART booting utility does not expect that.)
Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Pali Rohár <pali@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de>
projects / u-boot.git / log