arm64: versal: Enable soft reset support for xspi flashes
Activate the xSPI Software Reset support, which will be
utilized to transition from octal DTR mode to legacy
mode during shutdown and boot (if enabled).
arm64: versal: Enable defconfig for Micron octal flashes
The Micron MT35 series octal flashes can be activated
through the configuration option CONFIG_SPI_FLASH_MT35XU.
To ensure their detection, enable this option in the
default defconfig for octal flashes.
Moving the hw_reset function from the controller driver to
the NOR framework has caused the OSPI reset not to be triggered
in the Cadence driver's probe function. As a result, reading the
flash ID during SPI calibration is incorrect, and the
CQSPI_REG_RD_DATA_CAPTURE is set with an invalid value.This makes
it unable to read the flash ID properly.
To solve this problem, it's suggested to skip SPI calibration and
instead retrieve the read_delay directly from the device tree.
Skipping SPI calibration doesn't bring harm since there's no need
for the flash golden values stored during SPI calibration.
Instead, they are now read during the spi_nor_read_id call in the
NOR framework.
Caleb Connolly [Wed, 13 Nov 2024 05:05:59 +0000 (06:05 +0100)]
fastboot: properly handle unknown partition type
In getvar_partition_type() we attempt to find a filesystem driver for
the partition (of the list of driver enabled in U-Boot), on failure we
return the error to fastboot and completely bail out of the operation.
However, this should not be a failure, instead we should just default to
"raw". This allows commands like "fastboot format:ext4 userdata" to work
if userdata didn't already have an ext4 partition table (or if FS_EXT4
is disabled in U-Boot), as failing to determine the current partition
type is not an error in this case.
test: cmd/hash: check return value of ut_check_console_line
ut_check_console_line() does include an assert.
Pass the result to ut_assertok().
Addresses-Coverity-ID: 514958 Error handling issues Fixes: 7dfafcd65ef3 ("test: unit test for hash command") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Jerome Forissier [Tue, 12 Nov 2024 15:44:29 +0000 (16:44 +0100)]
Kconfig: describe NET, NO_NET, LWIP_DEBUG and LWIP_ASSERT
Some Kconfig symbols introduced in commit 8cb330355bd5 ("net: introduce
alternative implementation as net/lwip/") need a full description. The
NET symbol needs one, too.
- Prepare for implementing the EFI_HTTP_PROTOCOL:
- Make wget functionality callable even if the wget command is not
built (add CONFIG_WGET symbol).
- Ensure that wget_with_dns() works the same with the old network
stack and with lwIP.
- Put server_name and port into wget_ctx.
- Integrate struct wget_info into wget code.
- Move ip_to_string to lib/net_utils.c
Adriano Cordova [Mon, 11 Nov 2024 21:09:45 +0000 (18:09 -0300)]
net: net_utils: Move ip_to_string to lib/net_utils.c
The function string_to_ip is already in net_utils, which is
compiled unconditionally, but ip_to_string is currently only
accessible if the legacy network stack is selected. This
commit puts ip_to_string in net_utils.c and removes it from the
legacy network code.
Signed-off-by: Adriano Cordova <adrianox@gmail.com> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Tom Rini [Mon, 18 Nov 2024 14:24:06 +0000 (08:24 -0600)]
Merge patch series "Fix boot failure due to misaligned DMA buffer"
Nam Cao <namcao@linutronix.de> says:
We observed the following sporadic boot failure while booting from MMC
device:
=> boot
CACHE: Misaligned operation at range [9efa25f8, 9efa27f8]
CACHE: Misaligned operation at range [9efa25f8, 9efa27f8]
CACHE: Misaligned operation at range [9efa25f8, 9efa27f8]
CACHE: Misaligned operation at range [9efa25f8, 9efa27f8]
** Booting bootflow 'mmc@2194000.bootdev.part_1' with extlinux
Ignoring unknown command: �D���D��
Boot failed (err=-14)
The reason is because while allocating buffer to read a file from MMC,
alignment of 1 byte is used. Thus, the buffer doesn't work for performing
DMA, and garbage data is read.
While looking at this issue, I also noticed that if no alignment specified
(align=0) then fs_read_alloc() is documented to use the default. But the
default is no alignment. Therefore, other users of fs_read_alloc() which
specify align=0 may be broken as well.
The first patch changes extlinux_read_bootflow() to use proper buffer
alignment for DMA.
The second patch changes the default alignment of fs_read_alloc() to be
DMA-suitable, to fix other potential bugs.
Nam Cao [Thu, 7 Nov 2024 15:01:06 +0000 (16:01 +0100)]
fs: Use ARCH_DMA_MINALIGN as default alignment for fs_read_alloc()
The comment above fs_read_alloc() explains:
@align: Alignment to use for memory allocation (0 for default)
However, in the actual implementation, there is no alignment when @align is
zero.
This current default is probably fine for most cases. But for some block
devices which transfer data via DMA, ARCH_DMA_MINALIGN is needed.
Change the default alignment to ARCH_DMA_MINALIGN.
Fixes: de7b5a8a1ac0 ("fs: Create functions to load and allocate a file") Signed-off-by: Nam Cao <namcao@linutronix.de> Tested-by: Javier Fernandez Pastrana <javier.pastrana@linutronix.de>
Nam Cao [Thu, 7 Nov 2024 15:01:05 +0000 (16:01 +0100)]
boot: extlinux: Fix unaligned buffer for reading data from file system
extlinux_read_bootflow() allocates a buffer to read from file system
without any alignment.
But for some block devices which transfer data via DMA, ARCH_DMA_MINALIGN
alignment is required. For example, due to misaligned buffer, the below
boot failure is observed.
=> boot
CACHE: Misaligned operation at range [9efa25f8, 9efa27f8]
CACHE: Misaligned operation at range [9efa25f8, 9efa27f8]
CACHE: Misaligned operation at range [9efa25f8, 9efa27f8]
CACHE: Misaligned operation at range [9efa25f8, 9efa27f8]
** Booting bootflow 'mmc@2194000.bootdev.part_1' with extlinux
Ignoring unknown command: �D���D��
Boot failed (err=-14)
Change the buffer alignment to ARCH_DMA_MINALIGN.
Fixes: 31aefaf89a5b ("bootstd: Add an implementation of distro boot") Signed-off-by: Nam Cao <namcao@linutronix.de> Tested-by: Javier Fernandez Pastrana <javier.pastrana@linutronix.de>
'usb part' command shows the partition maps and shows the partition type
by displaying number such as 0c, 83 etc. Observed that ext2 and ext4
partitions shows the same number, i.e, 83, so, using the fstype command
to distiniguish between ext2 and ext4 partitions.
'mmc part' command shows the partition maps and shows the partition type
by displaying number such as 0c, 83 etc. Observed that ext2 and ext4
partitions shows the same number, i.e, 83, so, using the fstype command
to distiniguish between ext2 and ext4 partitions.
Sam Protsenko [Thu, 7 Nov 2024 02:58:31 +0000 (20:58 -0600)]
armv8: cpu: Implement allow_unaligned()
Usually ARMv8 platforms allow unaligned access for Normal memory. But
some chips might not allow it by default, having SCTLR.A bit set to 1
before U-Boot execution. One such example is Exynos850 SoC. As
allow_unaligned() is not implemented for ARMv8 at the moment, its __weak
implementation is used, which does nothing. That might lead to unaligned
access abort, for example when running EFI selftest. Fix that by
implementing allow_unaligned() for ARMv8.
The issue was found when running EFI selftest on E850-96 board
(Exynos850 based):
Unaligned abort happens in u16_strnlen(), which is called from
efi_hii_sibt_string_ucs2_block_next():
u16_strlen(blk->string_text)
where 'blk' type is struct efi_hii_sibt_string_ucs2_block. Because this
struct is packed, doing "->string_text" makes 'blk' address incremented
by 1 byte, which makes it unaligned. Although allow_unaligned() was
called in efi_init_early() before EFI selftest execution, it wasn't
implemented for ARMv8 CPUs, so data abort happened.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Andrew Goodbody [Wed, 6 Nov 2024 13:50:17 +0000 (13:50 +0000)]
test: bootm: Ensure tests can be run twice
Some of the bootm tests rely on state that is assumed to be
correct but is changed by the tests. This means that running
'ut bootm' twice will result in failures on the second run
as the state left by the first run is not what the tests
expect.
Fix this by ensuring the state is as expected by explicitly
setting that state.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org>
Simon Glass [Thu, 31 Oct 2024 17:50:23 +0000 (18:50 +0100)]
dm: sysinfo: Shorten the SYSINFO_ID prefix
We are about to add a large number of new entries. Update the prefix to
be a little shorter.
For SMBIOS items, use SYSID_SM_ (for System Management) which is enough
to distinguish it. For now at least, it seems that most items will be
for SMBIOS.
Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Raymond Mao <raymond.mao@linaro.org>
bios_emulator: for non-x86, print warnings if PM_{inp, outp}* access is attempted
Currently the PM_{inp,outp}* macros are completely broken on non-x86 architectures,
because they will essentially access random memory locations if called (and produce
a lot of rightful compilation warnings too). For now, replace those macros with
warnings (until the code is fixed), so the user at least knows that the emulator
attempted to access some x86 I/O port.
Tom Rini [Sat, 26 Oct 2024 14:09:00 +0000 (08:09 -0600)]
global: Remove bi_sramstart/bi_sramsize
These fields are currently set on exactly two platforms today, and used
by only one of them. Update pic32mzdask to use CFG_SYS_SRAM* in the one
location it needs it and otherwise drop this field from the bd_info
struct.
We don't have audio support in U-Boot, but we do have boot menus. Add an
option to re-map the volume and power buttons to up/down/enter so that
in situations where these are the only available buttons (such as on
mobile phones) it's still possible to navigate menus built in U-Boot or
an external EFI app like GRUB or systemd-boot.
Adriano Cordova [Mon, 11 Nov 2024 21:09:01 +0000 (18:09 -0300)]
net/lwip: wget: integrate struct wget_info into wget code
Each wget request now fills the struct wget_info. Also, the
efi bootdevice is now set conditionally to the set_bootdevice
variable in wget_info and a buffer size check is performed if
check_buffer_size is set.
Adriano Cordova [Mon, 11 Nov 2024 21:09:00 +0000 (18:09 -0300)]
net/lwip: wget: put server_name and port into wget_ctx
Currently server_name and port are local variables in wget_loop.
This commit puts them inside ctx, so that they are accessible
from the http callbacks.
Adriano Cordova [Mon, 11 Nov 2024 21:08:59 +0000 (18:08 -0300)]
net: wget: make wget_with_dns return value compatible with its lwip version
There are two wget_with_dns functions, one in the legacy network
stack and one in lwip, but the return values are not compatible.
This commit modifies the legacy version of wget_with_dns so that
the return values are compatible: 0 on success, otherwise a negative
error. This way wget_with_dns can be called in a network stack
agnostic way.
Adriano Cordova [Mon, 11 Nov 2024 21:08:58 +0000 (18:08 -0300)]
net: wget: integrate struct wget_info into legacy wget code
Each wget request now fills the struct wget_info. The efi
bootdevice is now set conditionally to the set_bootdevice
variable in wget_info, and the same holds for lmb memory check.
Adriano Cordova [Mon, 11 Nov 2024 21:08:57 +0000 (18:08 -0300)]
net: wget: Add interface to issue wget_requests using wget_http_info
Declare and define a global default struct wget_http_info
and an interface to issue wget requests providing a custom
struct wget_http_info. This code is common to legacy wget
and lwip wget. The idea is that the command wget should use
the default wget_http_info and other internal u-boot code
can call wget_request with their own wget_http_info struct.
Adriano Cordova [Mon, 11 Nov 2024 21:08:56 +0000 (18:08 -0300)]
net: wget: add definition of struct wget_http_info
The struct wget_http_info exposes the HTTP information of the last HTTP
request issued by wget, and it controls whether the efi bootdevice is set,
and whether the buffer size needs to be checked (lwip stack only). This
information is otherwise discarded. The wget_http_info struct can be used
by HTTP drivers to have more control over HTTP requests.
Signed-off-by: Adriano Cordova <adrianox@gmail.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Adriano Cordova [Mon, 11 Nov 2024 21:08:55 +0000 (18:08 -0300)]
net: Kconfig: add CONFIG_WGET symbol
Let net/wget.c and net/lwip/wget.c depend on CONFIG_WGET, and
cmd/wget.c depend on CONFIG_CMD_WGET. This way, the wget code
can be used regardless of whether the wget command is available.
Signed-off-by: Adriano Cordova <adrianox@gmail.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
- Two changes from Heinrich:
- One is adding some missing TPM files for proper maintenance.
- The second addresses Coverity-ID: 356664 replacing a mempcy() which
has undefined behavior with memmove()
Tom Rini [Fri, 15 Nov 2024 22:36:24 +0000 (16:36 -0600)]
Merge patch series "teach 'env default' to optionally keep runtime variables"
Rasmus Villemoes <ravi@prevas.dk> says:
Doing bringup of a board, part of my bootstrap logic is in U-Boot. So
when tweaking that logic, I was bitten by a previous completed
bootstrap having left a copy of the environment on the device, which
was imported and thus overrided the new logic.
So I thought, "ok, I'll just make sure to put 'env default -a' as the
first part of the bootstrap logic so I'm not bitten again". Alas, my
logic also relies on certain variables that are set by C code
(e.g. for detecting board variant), and doing 'env default -a' also
eliminates those.
Looking around, the hashtab code already supports a flag that does
exactly what I need, and exposing that is (morally) a one-liner.
Rasmus Villemoes [Wed, 30 Oct 2024 21:34:04 +0000 (22:34 +0100)]
test: env: add some test cases for new "env default -k" flag
Check that the new -k flag works as expected.
This also adds a test of the -a flag, which was previously missing,
and as the comment says, perhaps for a good reason. At least now we
have a test for it in combination with -k (and -f, because the ethaddr
variables otherwise cause complaining).
Rasmus Villemoes [Wed, 30 Oct 2024 21:34:03 +0000 (22:34 +0100)]
test: env: check that non-mentioned variables to "env default" are preserved
Instead of testing the same expected behaviour for both
non_default_varX, test that when var1 is not in the default env but is
mentioned in the "env default" cmdline, it is removed, while var2 is
untouched.
Rasmus Villemoes [Wed, 30 Oct 2024 21:34:02 +0000 (22:34 +0100)]
cmd/nvedit.c: teach 'env default' to optionally keep runtime variables
It can be useful to set all variables defined in the default
environment to the value they have there, but without removing
variables that are only defined at runtime. This can sort-of be done
today, by using the "env default var1 var2 ..." variant, but that
requires listing all variables defined in the default
environment. It's much more convenient to be able to say
env default -k -a
The -k flag is also meaningful in the other case: If var1 is not
defined in the default environment, but var2 is,
env default var1 var2
would emit a warning about var1 not being in the default env and thus
being deleted. With -k, there's no warning, and var1 is kept as-is.
fs: btrfs: hide duplicate 'Cannot lookup file' error on 'load'
Running commands such as 'load mmc 2:1 $addr $path' when path does not
exists will print an error twice if the file does not exist, e.g.:
```
Cannot lookup file boot/boot.scr
Failed to load 'boot/boot.scr'
```
(where the first line is printed by btrfs and the second by common fs
code)
Historically other filesystems such as ext4 or fat have not been
printing a message here, so do the same here to avoid duplicate.
The other error messages in this function are also somewhat redundant,
but bring useful diagnostics if they happen somewhere, so have been left
as printf.
Note that if a user wants no message to be printed for optional file
loads, they have to check for file existence first with other commands
such as 'size'.
Fix the critical thermal threshold for i.MX processors, this was changed
while moving the code from imx8m/imx9 directories into a shared place.
There is no need to keep the critical threshold 5 degrees less than the
SoC maximum temperature threshold, what is actually going to happen in
practice is that we are going to power-off the board when the SoC is
still within its working temperature range.
In addition to that this is a change in the actual behavior, that is
introducing a regression to users, and it was hidden within a software
refactoring.
Fixes: d0fe80890ab1 ("imx: Generalize fixup_thermal_trips") Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
drivers: bootcount: Add ZynqMP specific bootcount support
Add native support of the bootcount mechanism in the ZynqMP by
utilising internal PMU registers. The Persistent Global Storage
Registers of the Platform Management Unit can keep their value
during reboot cycles unless there is a POR reset, making them
appropriate for the bootcount mechanism.
Peter Korsgaard [Tue, 5 Nov 2024 16:21:36 +0000 (17:21 +0100)]
boot/image-board.c: boot_get_fpga(): pass compatible flag to fpga_load()
For E.G. signed FPGA bitstreams, similar to how it is done for the FPGA
loading from SPL since commit 71f1a5392aad ("spl: fit: pass real compatible
flags to fpga_load()").
Michal Simek [Fri, 25 Oct 2024 11:56:07 +0000 (13:56 +0200)]
arm64: versal: Do not define do_reset() if sysreset is enabled
If sysreset is enabled reset_cpu is defined in sysreset uclass that's why
it can't be in platform/board code.
The same change was done by commit f1bc214b0024 ("arm64: zynqmp: Do not
define do_reset() if sysreset is enabled").
Padmarao Begari [Mon, 4 Nov 2024 12:27:50 +0000 (17:57 +0530)]
arm64: zynqmp: Fix r5 mode for cpu release command
The cpu release command for r5 mode (lockstep/split) argument
accepts only string. But the zynqmp tcminit command accepts
string or number for r5 mode (lockstep/split or 0/1) argument.
To fix the r5 mode argument, the common argument (lockstep/split
or 0/1) is used across different u-boot commands. Use the strcmp()
instead of strncmp() to make uniform the r5 mode (lockstep/split
or 0/1) for the zynqmp tcminit and cpu release command.
Sughosh Ganu [Fri, 25 Oct 2024 17:27:24 +0000 (22:57 +0530)]
xilinx: use get_mem_top() to compute ram_top
Use the get_mem_top function to compute the value of ram_top. This was
earlier done through LMB API's, which are no longer available till
after relocation. Use get_mem_top() instead to compute the ram_top
value.
Sughosh Ganu [Fri, 25 Oct 2024 17:27:23 +0000 (22:57 +0530)]
common: memtop: add logic to detect ram_top
Add generic logic to determine the ram_top value for boards. Earlier,
this was achieved in an indirect manner through a set of LMB API's.
That has since changed so that the LMB code is available only after
relocation. Replace those LMB calls with a single call to
get_mem_top() to determine the value of ram_top.
In the message string " %s[%d]\t[0x%llx-0x%llx], 0x%08llx bytes flags: "
a comma is missing before flags.
To avoid increasing the code size replace '0x%' by '%#'.
Printing the size with leading zeros but not the addresses does not really
make sense. Remove the leading zeros from the size output.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
[trini: Fix test/cmd/bdinfo.c for these changes] Signed-off-by: Tom Rini <trini@konsulko.com>
When calling decode_addr_size() we must pass the size of the device-tree
property and not sizeof(void *).
Fixes: 90469da3da0d ("upl: Add support for reading a upl handoff")
Addresses-Coverity-ID: 510459 Wrong sizeof argument Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Loic Poulain [Thu, 31 Oct 2024 09:15:31 +0000 (10:15 +0100)]
lib: rsa: Set conventional salt length RSA-PSS parameter
RFC 3447 says that Typical salt length are either 0 or the length
of the output of the digest algorithm, RFC 4055 also recommends
hash value length as the salt length. Moreover, By convention,
most of the signing infrastructures/libraries use the length of
the digest algorithm (such as google cloud kms:
https://cloud.google.com/kms/docs/algorithms).
If the salt-length parameter is not set, openssl default to the
maximum allowed value, which is a openssl 'specificity', so this
works well for local signing, but restricts compatibility with
other engines (e.g pkcs11/libkmsp11):
```
returning 0x71 from C_SignInit due to status INVALID_ARGUMENT:
at rsassa_pss.cc:53: expected salt length for key XX is 32,
but 478 was supplied in the parameters
Could not obtain signature: error:41000070:PKCS#11 module::Mechanism invalid
```
To improve compatibility, we set the default RSA-PSS salt-length
value to the conventional one. A further improvement could consist
in making it configurable as signature FIT node attribute.
Quentin Schulz [Mon, 11 Nov 2024 13:20:49 +0000 (14:20 +0100)]
Makefile: fix empty MK_ARCH when using ccache
One can use ccache by prefixing the typical CROSS_COMPILE value with
"ccache " (e.g. "ccache aarch64-gnu-linux-" for Aarch64). This however
makes the MK_ARCH empty because sed won't find a match anymore since it
expects the CROSS_COMPILE value to start with the actual toolchain (with
an unlimited number of white spaces before).
This is failing builds since commit 7506c1566998 ("sandbox: Report host
default-filename in native mode").
Add "ccache" prefix to ignore but participate in the matching regex used
by sed to identify the target architecture.
examples: make glue and demo code compatible with 64-bit
Commit f9886bc60f42 ("Added arm64 assembly for examples/api crt0")
added a 64-bit target for the examples but did not adjust the demo
code to be 64-bit compatible.
Change variable size for pointers.
Use %p to print pointers.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Commit f9886bc60f42 ("Added arm64 assembly for examples/api crt0") tried to
add arm64 support to the examples but crt0.S does not even build for
qemu_arm64_defconfig with CONFIG_API=y, CONFIG_EXAMPLES=y:
examples/api/crt0.S: Assembler messages:
examples/api/crt0.S:32: Error:
expected a register at operand 1 -- `ldr ip,=search_hint'
examples/api/crt0.S:33: Error:
unexpected register type at operand 1 -- `str sp,[ip]'
make[2]: *** [scripts/Makefile.build:292: examples/api/crt0.o] Error 1
Do not define _start twice.
Use valid register names.
Move syscall_ptr and search_hint to the data section to avoid an invalid
relocation.
Fixes: f9886bc60f42 ("Added arm64 assembly for examples/api crt0") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Tom Rini [Thu, 14 Nov 2024 16:49:30 +0000 (10:49 -0600)]
Merge patch series "cmd: hash: correct parameter count check"
Heinrich Schuchardt <heinrich.schuchardt@canonical.com> says:
Since commit 348ea878508d ("cmd: hash: fix param count check") the hash
command cannot be used without the optional variable name parameter if
CONFIG_HASH_VERIFY=y. 'hash sha1 $loadaddr $filesize' returns
CMD_RET_USAGE.
The minimum number of arguments is four no matter if verification is
enabled or not.
Tom Rini [Thu, 14 Nov 2024 16:48:07 +0000 (10:48 -0600)]
Merge patch series "Apply SoM overlays on phyCORE-AM6xx SoMs"
Wadim Egorov <w.egorov@phytec.de> says:
Our SoMs are available in multiple configurations, managed via device
tree overlays. To determine the specific variant in use, we read the
EEPROM and apply the appropriate overlays during boot to the device tree
used by the OS.
Apply overlays for phyCORE-AM62x and phyCORE-AM64x SoMs.
Future K3 SoMs will be able to reuse this logic and overlays.
Since commit 348ea878508d ("cmd: hash: fix param count check") the hash
command cannot be used without the optional variable name parameter if
CONFIG_HASH_VERIFY=y. 'hash sha1 $loadaddr $filesize' returns
CMD_RET_USAGE.
The minimum number of arguments is four no matter if verification is
enabled or not.
Fixes: 348ea878508d ("cmd: hash: fix param count check") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Igor Opaniuk <igor.opaniuk@gmail.com>
Wadim Egorov [Wed, 30 Oct 2024 16:48:15 +0000 (17:48 +0100)]
board: phytec: common: k3: Apply SoM-specific overlays to OS device tree
Our SoMs are available in multiple configurations, managed via device
tree overlays. To determine the specific variant in use, we read the
EEPROM and apply the appropriate overlays during boot to the device tree
used by the OS.
Signed-off-by: Wadim Egorov <w.egorov@phytec.de> Acked-by: Neha Malcom Francis <n-francis@ti.com>
Tom Rini [Wed, 13 Nov 2024 18:05:00 +0000 (12:05 -0600)]
Merge patch series "labgrid: Provide an integration with Labgrid"
Simon Glass <sjg@chromium.org> says:
Labgrid provides access to a hardware lab in an automated way. It is
possible to boot U-Boot on boards in the lab without physically touching
them. It relies on relays, USB UARTs and SD muxes, among other things.
By way of background, about 4 years ago I wrong a thing called Labman[1]
which allowed my lab of about 30 devices to be operated remotely, using
tbot for the console and build integration. While it worked OK and I
used it for many bisects, I didn't take it any further.
It turns out that there was already an existing program, called Labgrid,
which I did not know about at time (thank you Tom for telling me). It is
more rounded than Labman and has a number of advantages:
- does not need udev rules, mostly
- has several existing users who rely on it
- supports multiple machines exporting their devices
It lacks a 'lab check' feature and a few other things, but these can be
remedied.
On and off over the past several weeks I have been experimenting with
Labgrid. I have managed to create an initial U-Boot integration (this
series) by adding various features to Labgrid[2] and the U-Boot test
hooks.
I hope that this might inspire others to set up boards and run tests
automatically, rather than relying on infrequent, manual test. Perhaps
it may even be possible to have a number of labs available.
Included in the integration are a number of simple scripts which make it
easy to connect to boards and run tests:
ub-int <target>
Build and boot on a target, starting an interactive session
ub-cli <target>
Build and boot on a target, ensure U-Boot starts and provide an interactive
session from there
ub-smoke <target>
Smoke test U-Boot to check that it boots to a prompt on a target
ub-bisect <target>
Bisect a git tree to locate a failure on a particular target
ub-pyt <target> <testspec>
Run U-Boot pytests on a target
Some of these help to provide the same tbot[4] workflow which I have
relied on for several years, albeit much simpler versions.
The goal here is to create some sort of script which can collect
patches from the mailing list, apply them and test them on a selection
of boards. I suspect that script already exists, so please let me know
what you suggest.
Simon Glass [Sat, 2 Nov 2024 19:36:11 +0000 (13:36 -0600)]
sandbox: Add a build without CMDLINE
Sometimes this breaks, so add a build to keep it working. Since sandbox
enables a lot of options, it is a good board to use. The new config is
created simply by copying the existing sandbox and turning off CMDLINE
Once we have tests for non-CMDLINE operation, this can be adjusted to
run those tests.
Create a new build which will be picked up by CI. Update the maintainer
entry as well.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
Simon Glass [Tue, 12 Nov 2024 14:13:26 +0000 (07:13 -0700)]
CI: Allow running tests on sjg lab
Add a way to run tests on a real hardware lab. This is in the very early
experimental stages. There are only 23 boards and 3 of those are broken!
(bob, ff3399, samus). A fourth fails due to problems with the TPM tests.
To try this, assuming you have gitlab access, set SJG_LAB=1, e.g.:
git push -o ci.variable="SJG_LAB=1" dm HEAD:try
This relies on the two previous series targeted at -next as well as the
bugfix series for -master
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Andrejs Cainikovs <andrejs.cainikovs@toradex.com>
Simon Glass [Tue, 12 Nov 2024 14:13:24 +0000 (07:13 -0700)]
test: Support testing with two board-builds
The Beagleplay board uses an SoC from the TI K3 family. This has both a
Cortex-R core and a Cortex-A core and the R core needs to come up before
the A core. In both cases we have U-Boot SPL then U-Boot proper being
used.
In practice this means we need two entirely separate builds to produce
an image.
Simon Glass [Tue, 12 Nov 2024 14:13:22 +0000 (07:13 -0700)]
test: Try to shut down the lab console gracefully
Send the Labgrid quit characters to ask it to exit gracefully. This
typically allows it to power off the board being used. Only do this when
labgrid is being used (detected with an env var).
If that doesn't work, try the less graceful approach.
The normal approach for pytest is to simply kill the child process. This
makes Labgrid exit immediately. Thus it does not get a chance to execute
the 'off' part of strategy (which may power it off) and release the
device.
Without this, every board disconnect leaves the board in a bad state,
requiring separate steps to recover the board, then power it off.
The action is conditional on since USE_LABGRID_SJG being set, so only
affects operation if the Labgrid-sjg integration is being used.
Simon Glass [Tue, 12 Nov 2024 14:13:21 +0000 (07:13 -0700)]
test: Avoid double echo when starting up
There is a very annoying bug at present where the terminal echos part
of the first command sent to the board. This happens because the
terminal is still set to echo for a period until Labgrid starts up and
can change this.
Fix this by disabling echo (and other terminal features) as soon as the
spawn happens.
Simon Glass [Tue, 12 Nov 2024 14:13:20 +0000 (07:13 -0700)]
test: Improve handling of sending commands
We expect commands to be echoed and this should happen quite quickly,
since U-Boot is sitting at the prompt waiting for a command.
Reduce the timeout for this situation. Try to produce a more useful
error message when something goes wrong. Also handle the case where the
connection has gone away since the last command was issued.
Simon Glass [Tue, 12 Nov 2024 14:13:19 +0000 (07:13 -0700)]
test: Introduce lab mode
There is quite a bit of code in pytest to try to start up U-Boot on a
board, with timeouts, expects, etc.
This is tedious to maintain and is peripheral to the test system's
purpose. It seems better to put this logic in the lab itself, where is
can provide such support.
With Labgrid we can use the UbootStrategy class to get the board into a
useful state, however it needs to do it. Then it can report to pytest
by writing a suitable string along with the U-Boot version it detected.
Add support for detecting 'lab mode' and simply assume that all is well
in that case. Collect the version string when Labgrid says it is ready.
This is only used with the Labgrid-sjg integration. When Labgrid starts
the UbootStrategy it checks if U_BOOT_SOURCE_DIR is set. If so it emits
a string '{lab mode}' that tells test.py to simply wait for an
indication that the board is ready. All banner-checking is skipped. The
indication comes in the form of another string 'Lab: Board is ready'
which Labgrid sends once the board is sitting at a prompt ready to run
tests. Then test.py emits 'U-Boot is ready' and continues with testing.
Note that Labgrid has the same kind of "check for a string" logic that
is in test.py, except it's not caring about the correct number / order
of banner prints. This checking could be added, however. If something
fails, the complete output is shown, so it is possible to see what went
wrong.
Simon Glass [Tue, 12 Nov 2024 14:13:18 +0000 (07:13 -0700)]
test: Introduce the concept of a role
In Labgrid there is the concept of a 'role', which is similar to the
U-Boot board ID in U-Boot's pytest subsystem.
The role indicates both the target and information about the U-Boot
build to use. It can also provide any amount of other configuration.
The information is obtained using the 'labgrid-client query' operation.
Using this role, all required configuration for the board is stored
within the Labgrid environment, with pytest simply querying it. This
allows connecting to boards using an interactive console, something that
isn't possible without some kind of mapping. It also means that we don't
need to replicate the pytest functionality in tbot, since Labgrid can
handle the console and kick off builds as needed.
Make use of this in tests, so that only the role is required in gitlab
and other situations. The board type and other things can be queried
as needed.
Use a new 'u-boot-test-getrole' script to obtain the requested
information.
With this it is possible to run lab tests in gitlab with just a single
'ROLE' variable for each board.
Note that, without this feature:
- interactive use of boards with Labgrid-sjg would require repeating the
id/board in a separate configuration file
- Gitlab yaml file would need to specify both the id and board
This feature is entirely optional, however, with the code gracefully
falling back to using a separate ID and board.
Simon Glass [Tue, 12 Nov 2024 14:13:17 +0000 (07:13 -0700)]
test: Allow connecting to a running board
Sometimes we know that the board is already running the right software,
so provide an option to allow running of tests directly, without first
resetting the board.
This saves time when re-running a test where only the Python code is
changing.
Note that this feature is open to errors, since the user must know that
the board is in a fit state to execute tests. It is useful for repeated
iteration on a particular test, where it can save quite a bit of time.
Simon Glass [Tue, 12 Nov 2024 14:13:16 +0000 (07:13 -0700)]
test: Release board after tests complete
When a board is finished with, the lab may want to power it off, or
perform some other function. Add a new script which is called when tests
are complete.
Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Tue, 12 Nov 2024 14:13:15 +0000 (07:13 -0700)]
test: Allow signaling that U-Boot is ready
When Labgrid is used, it can get U-Boot ready for running tests. It
prints a message when it has done so.
Add logic to detect this message and accept it.
Note that this does not change pytest, which still (also) looks for the
U-Boot banner. This change merely makes it possible for pytest to
believe Labgrid when it says that the board is ready for use.
In several cases, the board starts up and Labgrid receives some initial
output, then pytest starts and misses some of that output, because it
came in while Labgrid had the console open. Then pytest fails because
it doesn't see the expected banners.
With this change, Labgrid handles getting U-Boot to a prompt, in a
fully reliable manner. Then pytest starts up and can simply start
running its tests.
But, again, this does not prevent pytest from handling a banner if one
is provided (e.g. if not using the Labgrid integration).
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
projects / thirdparty / u-boot.git / log
