Rename the misleading cmd "rx_training" to "mvebu_comphy_rx_training" to
avoid confusion and mixup with DDR3/4 training. This makes it clear,
that this command is platform specific and handles the COMPHY RX
training.
Also depend this cmd on ARMADA_8K and not TARGET_MVEBU_ARMADA_8K to make
is available for OcteonTX2 CN913x.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Pali Rohár <pali@kernel.org>
Cc: Marek Behun <marek.behun@nic.cz>
Cc: Kostya Porotchkin <kostap@marvell.com>
Cc: Nadav Haklai <nadavh@marvell.com>
Acked-by: Marek Behún <marek.behun@nic.cz>
Acked-by: Pali Rohár <pali@kernel.org>
This patch adds a new "extension" command, which aims at detecting
extension boards connected to the hardware platform, and apply the
Device Tree overlays that describe the hardware present on those
extension boards.
In order to enable this mechanism, board-specific code must implement
the extension_board_scan() function that fills in a linked list of
"struct extension", each describing one extension board. In addition,
the board-specific code must select the SUPPORT_EXTENSION_SCAN Kconfig
boolean.
Based on this:
- "extension scan" makes the generic code call the board-specific
extension_board_scan() function to retrieve the list of detected
extension boards.
- "extension list" allows to list the detected extension boards.
- "extension apply <number>|all" allows to apply the Device Tree
overlay(s) corresponding to one, or all, extension boards
The latter requires two environment variables to exist and set one variable
to run:
- extension_overlay_addr: the RAM address where to load the Device
Tree overlays
- extension_overlay_cmd: the U-Boot command to load one overlay.
Indeed, the location and mechanism to load DT overlays is very setup
specific.
- extension_overlay_name: set by the command: the name of the DT which
will be load during the execution.
When calling the command described in the extension_overlay_cmd
variable, the variable extension_overlay_name will be defined. So a
typical extension_overlay_cmd will look like this:
extension_overlay_cmd=load mmc 0:1 $extension_overlay_addr /boot/$extension_overlay_name
Here is an example on how to use it:
=> run loadfdt
=> fdt addr $fdtaddr
=> setenv extension_overlay_addr 0x1000
=> setenv extension_overlay_cmd 'load mmc 0:1 ${extension_overlay_addr} /boot/${extension_overlay_name}'
=> extension scan
Found 1 extension board(s).
=> extension apply 0
519 bytes read in 3 ms (168.9 KiB/s)
Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
Reviewed-by: Maxime Ripard <maxime@cerno.tech>
Move the fdt_valid function to fdt_support.
This changes allow to be able to test the validity of a devicetree in
other c files.
Update code syntax.
Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Maxime Ripard <maxime@cerno.tech>
The ebreak instruction should generate a breakpoint exception.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Rick Chen <rick@andestech.com>
This change would enhance the existing 'gpt read' command to allow
(optionally) writing of the read GPT partitions to an environment
variable in the UBOOT partitions layout format. This would allow users
to easily change the overall partition settings by editing said variable
and then using the variable in the 'gpt write' and 'gpt verify' commands.
Signed-off-by: Farhan Ali <farhan.ali@broadcom.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Corneliu Doban <cdoban@broadcom.com>
Cc: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
Cc: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>
This patch adds support for running RX training using new command called
"rx_training"
Usage:
rx_training - rx_training <cp id> <comphy id>
RX training allows to improve link quality (for SFI mode)
by running training sequence between us and the link partner,
this allows to reach better link quality then using static configuration.
Change-Id: I818fe67ccaf19a87af50d4c34a9db7d6802049a5
Signed-off-by: Igal Liberman <igall@marvell.com>
Signed-off-by: Marcin Wojtas <mw@semihalf.com>
- fix the dependency for MMC boot (add XENON to MVEBU_MMC)
- fix the bubt destination assignment (missing # in "else" case)
Signed-off-by: Konstantin Porotchkin <kostap@marvell.com>
Signed-off-by: Stefan Roese <sr@denx.de>
On systems without usb gadget dfu core fails which was reported by error
but command itself returns pass which breaks any usage in a script.
That's why propagate error from run_usb_dnl_gadget().
Fixes: 16297cfb2a ("usb: new board-specific USB init interface")
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Add support for stack protector for UBOOT, SPL, and TPL
as well as new pytest for stackprotector
Signed-off-by: Joel Peshkin <joel.peshkin@broadcom.com>
Adjust UEFI build flags.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Trying to compile with CONFIG_CMD_MMC=y and CONFIG_MMC=n leads to errors:
riscv64-linux-gnu-ld.bfd: cmd/built-in.o: in function `do_mmcops':
cmd/mmc.c:984: undefined reference to `get_mmc_num'
riscv64-linux-gnu-ld.bfd: cmd/built-in.o: in function `do_mmc_setdsr':
cmd/mmc.c:873: undefined reference to `find_mmc_device'
Add missing dependency.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
In case exit is called in a script without parameter, the command
returns -2 ; in case exit is called with a numerical parameter,
the command returns -2 and lower. This leads to the following problem:
=> setenv foo 'echo bar ; exit 1' ; run foo ; echo $?
bar
0
=> setenv foo 'echo bar ; exit 0' ; run foo ; echo $?
bar
0
=> setenv foo 'echo bar ; exit -2' ; run foo ; echo $?
bar
0
That is, no matter what the 'exit' command argument is, the return
value is always 0 and so it is not possible to use script return
value in subsequent tests.
Fix this and simplify the exit command such that if exit is called with
no argument, the command returns 0, just like 'true' in cmd/test.c. In
case the command is called with any argument that is positive integer,
the argument is set as return value.
=> setenv foo 'echo bar ; exit 1' ; run foo ; echo $?
bar
1
=> setenv foo 'echo bar ; exit 0' ; run foo ; echo $?
bar
0
=> setenv foo 'echo bar ; exit -2' ; run foo ; echo $?
bar
0
Note that this does change ABI established in 2004 , although it is
unclear whether that ABI was originally OK or not.
Fixes: c26e454dfc
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
Cc: Tom Rini <trini@konsulko.com>
We move qfw into its own uclass and split the PIO functions into a
specific driver for that uclass. The PIO driver is selected in the
qemu-x86 board config (this covers x86 and x86_64).
include/qfw.h is cleaned up and documentation added.
Signed-off-by: Asherah Connor <ashe@kivikakk.ee>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
serial_reinit_all() is only available if CONFIG_SERIAL is defined (i.e.
!CONFIG_DM_SERIAL).
Signed-off-by: Asherah Connor <ashe@kivikakk.ee>
Reviewed-by: Simon Glass <sjg@chromium.org>
stdio_dev methods have taken a pointer to themselves since 709ea543
(nearly 7 years ago).
Signed-off-by: Asherah Connor <ashe@kivikakk.ee>
Reviewed-by: Simon Glass <sjg@chromium.org>
Replace static function efi_get_device_handle_info() by a simplified
function efi_get_device_path_text() avoiding EFI_CALL().
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
U-Boot can instantiate CAAM RNG if needed by crypto operations.
Call sec_init() prior running a blob operation to ensure
RNG is correctly instantiated.
Make sure CAAM clock is enabled and check if a job ring is
available for that operation.
Signed-off-by: Breno Lima <breno.lima@nxp.com>
Reviewed-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
In order to build CMD_BLOB on i.MX CAAM supported devices it's
necessary to select IMX_HAB. Add IMX_HAB and CAAM supported
SoCs as dependency.
Signed-off-by: Breno Lima <breno.lima@nxp.com>
Reviewed-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
According to Specification, each bit have valid value.
But it doesn't check whether arguments is valid or not.
It has potential bug with arguments passed by wrong value.
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Modified more readable about hwpartition usage.
Because it's difficult to understand how to use its command.
The arguments didn't optional.
mmc hwpartition needs to pass <USER> <GP> <MODE> as arguments.
Description about each arguments what is required is the below:
USER - <user> <enh> <start> <cnt> <wrrel> <{on|off}>
GP - <{gp1|gp2|gp3|gp4}> <cnt> <enh> <wrrel> <{on|off}>
MODE - <{check|set|complete}>
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
The usb command cannot be compiled with CONFIG_USB=n:
ld.bfd: cmd/usb.c:660: undefined reference to `usb_stop'
ld.bfd: cmd/usb.c:663: undefined reference to `usb_started'
Reviewed-by: Marek Vasut <marex@denx.de>
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
At present when a file is bound to a host device it is always marked as
removeable. Arguably the device is removeable, since it can be unbound at
will. However while it is bound, it is not considered removable by the
user. Also it is useful to be able to model both fixed and removeable
devices for code that distinguishes them.
Add a -r flag to the 'host bind' command and plumb it through to provide
this feature.
Signed-off-by: Simon Glass <sjg@chromium.org>
Remove the 'bind' subcommand before processing the arguments. This will
make it easier to add an optional flag.
Signed-off-by: Simon Glass <sjg@chromium.org>
This function has a strange mix of declarations and argument parsing
which is a bit hard to follow and harder to modify. Separate out the
declarations at the start of the function and adjust the ordering of
the code slightly.
Signed-off-by: Simon Glass <sjg@chromium.org>
This information is interesting to look at and can be important for
debugging and inspection. Add a command to display it in a helpful
format.
Signed-off-by: Simon Glass <sjg@chromium.org>
It is possible to boot U-Boot for chromebook_coral either 'bare metal' or
from coreboot. In the latter case we want to provide access to the coreboot
sysinfo tables. Move the definitions into a file available to any x86
board.
Signed-off-by: Simon Glass <sjg@chromium.org>
This commit enables the ESRT printing from the u-boot shell by invoking:
- efidebug capsule esrt
CC: Heinrich Schuchardt <xypron.glpk@gmx.de>
CC: Sughosh Ganu <sughosh.ganu@linaro.org>
CC: AKASHI Takahiro <takahiro.akashi@linaro.org>
CC: Ilias Apalodimas <ilias.apalodimas@linaro.org>
CC: Andre Przywara <andre.przywara@arm.com>
CC: Alexander Graf <agraf@csgraf.de>
CC: nd@arm.com
Signed-off-by: Jose Marinho <jose.marinho@arm.com>
Reviwed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
The ESRT is initialised during efi_init_objlist after
efi_initialize_system_table().
The ESRT is recreated from scratch at the following events:
- successful UpdateCapsule;
- FMP instance install.
The code ensures that every ESRT entry has a unique fw_class value.
Limitations:
- The ESRT is not updated if an FMP instance is uninstalled;
- the fields image_type and flags are in the current implementation left
undefined. Setting these values will require a per-platform function
that returns the image_type/flags as a function of the image fw_class.
CC: Heinrich Schuchardt <xypron.glpk@gmx.de>
CC: Sughosh Ganu <sughosh.ganu@linaro.org>
CC: AKASHI Takahiro <takahiro.akashi@linaro.org>
CC: Ilias Apalodimas <ilias.apalodimas@linaro.org>
CC: Andre Przywara <andre.przywara@arm.com>
CC: Alexander Graf <agraf@csgraf.de>
CC: nd@arm.com
Signed-off-by: Jose Marinho <jose.marinho@arm.com>
Remove two EFI_CALL() indirections.
Move ESRT GUID in efidebug's list of GUIDs.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
The UEFI spec allows a packed array of UEFI device paths in the
FilePathList[] of an EFI_LOAD_OPTION. The first file path must
describe the loaded image but the rest are OS specific.
Previous patches parse the device path and try to use the second
member of the array as an initrd. So let's modify efidebug slightly
and install the second file described in the command line as the
initrd device path.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Up to now we install EFI_LOAD_FILE2_PROTOCOL to load an initrd
unconditionally. Although we correctly return various EFI exit codes
depending on the file status (i.e EFI_NO_MEDIA, EFI_NOT_FOUND etc), the
kernel loader, only falls back to the cmdline interpreted initrd if the
protocol is not installed.
This creates a problem for EFI installers, since they won't be able to
load their own initrd and continue the installation. It also makes the
feature hard to use, since we can either have a single initrd or we have
to recompile u-boot if the filename changes.
So let's introduce a different logic that will decouple the initrd
path from the config option we currently have.
When defining a UEFI BootXXXX we can use the filepathlist and store
a file path pointing to our initrd. Specifically the EFI spec describes:
"The first element of the array is a device path that describes the device
and location of the Image for this load option. Other device paths may
optionally exist in the FilePathList, but their usage is OSV specific"
When the EFI application is launched through the bootmgr, we'll try to
interpret the extra device path. If that points to a file that exists on
our disk, we'll now install the load_file2 and the efi-stub will be able
to use it.
This opens up another path using U-Boot and defines a new boot flow.
A user will be able to control the kernel/initrd pairs without explicit
cmdline args or GRUB.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
When uploading an EFI binary via the UART we have to call
efi_set_bootdev() or we won't be able to execute it.
Put the includes into alphabetic order.
Fixes: 5f59518a7b ("efi_loader: setting boot device")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
This occur when building on Raspberry Pi 400 (32-bit ARM). Fix them.
Examples:
cmd/efidebug.c: In function ‘do_efi_capsule_update’:
cmd/efidebug.c:75:49: warning: cast from pointer to integer of different
size [-Wpointer-to-int-cast]
ret = EFI_CALL(RT->update_capsule(&capsule, 1, (u64)NULL));
^
include/efi_loader.h:104:9: note: in definition of macro ‘EFI_CALL’
typeof(exp) _r = exp; \
^~~
cmd/efidebug.c:75:49: warning: cast from pointer to integer of different
size [-Wpointer-to-int-cast]
ret = EFI_CALL(RT->update_capsule(&capsule, 1, (u64)NULL));
^
include/efi_loader.h:104:19: note: in definition of macro ‘EFI_CALL’
typeof(exp) _r = exp; \
^~~
In file included from include/common.h:20,
from lib/efi_loader/efi_capsule.c:9:
lib/efi_loader/efi_capsule.c: In function ‘efi_update_capsule’:
include/efi_loader.h:83:8: warning: format ‘%lu’ expects argument of type
‘long unsigned int’, but argument 10 has type ‘size_t’
{aka ‘unsigned int’} [-Wformat=]
debug("%sEFI: Entry %s(" format ")\n", __efi_nesting_inc(), \
^~~~~~~~~~~~~~~~~~
include/linux/printk.h:37:21: note: in definition of macro ‘pr_fmt’
#define pr_fmt(fmt) fmt
^~~
include/log.h:229:2: note: in expansion of macro ‘log’
log(LOG_CATEGORY, LOGL_DEBUG, fmt, ##args); \
^~~
include/log.h:249:2: note: in expansion of macro ‘debug_cond’
debug_cond(_DEBUG, fmt, ##args)
^~~~~~~~~~
include/efi_loader.h:83:2: note: in expansion of macro ‘debug’
debug("%sEFI: Entry %s(" format ")\n", __efi_nesting_inc(), \
^~~~~
lib/efi_loader/efi_capsule.c:444:2: note: in expansion of macro ‘EFI_ENTRY’
EFI_ENTRY("%p, %lu, %llu\n", capsule_header_array, capsule_count,
^~~~~~~~~
lib/efi_loader/efi_capsule.c:444:19: note: format string is defined here
EFI_ENTRY("%p, %lu, %llu\n", capsule_header_array, capsule_count,
~~^
%u
Signed-off-by: Simon Glass <sjg@chromium.org>
Replace (uintptr_t)NULL by 0.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
When uploading an EFI binary via the UART we have to call
efi_set_bootdev() or we won't be able to execute it.
Put the includes into alphabetic order.
Fixes: 5f59518a7b ("efi_loader: setting boot device")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
This occur when building on Raspberry Pi 400 (32-bit ARM). Fix them.
Examples:
cmd/efidebug.c: In function ‘do_efi_capsule_update’:
cmd/efidebug.c:75:49: warning: cast from pointer to integer of different
size [-Wpointer-to-int-cast]
ret = EFI_CALL(RT->update_capsule(&capsule, 1, (u64)NULL));
^
include/efi_loader.h:104:9: note: in definition of macro ‘EFI_CALL’
typeof(exp) _r = exp; \
^~~
cmd/efidebug.c:75:49: warning: cast from pointer to integer of different
size [-Wpointer-to-int-cast]
ret = EFI_CALL(RT->update_capsule(&capsule, 1, (u64)NULL));
^
include/efi_loader.h:104:19: note: in definition of macro ‘EFI_CALL’
typeof(exp) _r = exp; \
^~~
In file included from include/common.h:20,
from lib/efi_loader/efi_capsule.c:9:
lib/efi_loader/efi_capsule.c: In function ‘efi_update_capsule’:
include/efi_loader.h:83:8: warning: format ‘%lu’ expects argument of type
‘long unsigned int’, but argument 10 has type ‘size_t’
{aka ‘unsigned int’} [-Wformat=]
debug("%sEFI: Entry %s(" format ")\n", __efi_nesting_inc(), \
^~~~~~~~~~~~~~~~~~
include/linux/printk.h:37:21: note: in definition of macro ‘pr_fmt’
#define pr_fmt(fmt) fmt
^~~
include/log.h:229:2: note: in expansion of macro ‘log’
log(LOG_CATEGORY, LOGL_DEBUG, fmt, ##args); \
^~~
include/log.h:249:2: note: in expansion of macro ‘debug_cond’
debug_cond(_DEBUG, fmt, ##args)
^~~~~~~~~~
include/efi_loader.h:83:2: note: in expansion of macro ‘debug’
debug("%sEFI: Entry %s(" format ")\n", __efi_nesting_inc(), \
^~~~~
lib/efi_loader/efi_capsule.c:444:2: note: in expansion of macro ‘EFI_ENTRY’
EFI_ENTRY("%p, %lu, %llu\n", capsule_header_array, capsule_count,
^~~~~~~~~
lib/efi_loader/efi_capsule.c:444:19: note: format string is defined here
EFI_ENTRY("%p, %lu, %llu\n", capsule_header_array, capsule_count,
~~^
%u
Signed-off-by: Simon Glass <sjg@chromium.org>
Replace (uintptr_t)NULL by 0.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Enable and provision the SCP03 keys on a TEE controlled secured elemt
from the U-Boot shell.
Executing this command will generate and program new SCP03 encryption
keys on the secure element NVM.
Depending on the TEE implementation, the keys would then be stored in
some persistent storage or better derived from some platform secret
(so they can't be lost).
Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Igor Opaniuk <igor.opaniuk@foundries.io>
We don't need to enable logging to run this command since the output will
still appear. Drop the 'select'.
Signed-off-by: Simon Glass <sjg@chromium.org>
The 'virtio' command calls blk_common_cmd() which is only available
when CONFIG_HAVE_BLOCK_DEVICE is on. Fix the Kconfig dependency.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
This adds a new command 'addrmap' to display the address map for
non-identity virtual-physical memory mappings.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
Take over the plain 'tpm_...' functions for use by the new TPM API. Rename
all the TPMv1 functions so they are called from the API.
Update the TPMv1 functions so that they are called from the API. Change
existing users to use the tpm1_ prefix so they don't need to go through
the API, which might introduce uncertainty.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Historically, the reset_cpu() function had an `addr` parameter which was
meant to pass in an address of the reset vector location, where the CPU
should reset to. This feature is no longer used anywhere in U-Boot as
all reset_cpu() implementations now ignore the passed value. Generic
code has been added which always calls reset_cpu() with `0` which means
this feature can no longer be used easily anyway.
Over time, many implementations seem to have "misunderstood" the
existence of this parameter as a way to customize/parameterize the reset
(e.g. COLD vs WARM resets). As this is not properly supported, the
code will almost always not do what it is intended to (because all
call-sites just call reset_cpu() with 0).
To avoid confusion and to clean up the codebase from unused left-overs
of the past, remove the `addr` parameter entirely. Code which intends
to support different kinds of resets should be rewritten as a sysreset
driver instead.
This transformation was done with the following coccinelle patch:
@@
expression argvalue;
@@
- reset_cpu(argvalue)
+ reset_cpu()
@@
identifier argname;
type argtype;
@@
- reset_cpu(argtype argname)
+ reset_cpu(void)
{ ... }
Signed-off-by: Harald Seiler <hws@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
