| Age | Commit message (Collapse) | Author |
|---|
|
Tom Rini <trini@konsulko.com> says:
One thing that Simon Glass has noted is that our pytest run time keeps
getting longer. Looking at:
https://source.denx.de/u-boot/u-boot/-/pipelines/25011/test_report?job_name=sandbox%20test.py%3A%20%5Bfast%20amd64%5D
we can see that some of the longest running tests are a little puzzling.
It turns out that we have two ways of making filesystem images without
requiring root access and one of them is significantly slower than the
other. This series changes us from using virt-make-fs to only using the
mk_fs helper that currently resides in test_ut.py which uses standard
userspace tools. The final result can be seen at:
https://source.denx.de/u-boot/u-boot/-/pipelines/25015/test_report?job_name=sandbox%20test.py%3A%20%5Bfast%20amd64%5D
and the tests changed here now run much quicker.
Link: https://lore.kernel.org/r/20250320140030.2052434-1-trini@konsulko.com
|
|
The problem with using "virt-make-fs" to make a filesystem image is that
it is extremely slow. Switch to using the fs_helper functions we have
instead from the filesystem tests as these can add files to images and
are significantly faster and still do not require root access.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
FIXME: Reword more
The problem with using "virt-make-fs" to make a filesystem image is that
it is extremely slow. Switch to using the fs_helper functions we have
instead from the filesystem tests as these can add files to images and
are significantly faster and still do not require root access.
The main change here is that our mount point directory has changed from
"test_efi_capsule" to "scratch" and so we need to update other functions
too. As the disk image that we get created doesn't have a GPT, invoke
sgdisk to do a conversion first.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
The problem with using "virt-make-fs" to make a filesystem image is that
it is extremely slow. Switch to using the fs_helper functions we have
instead from the filesystem tests as these can add files to images and
are significantly faster and still do not require root access.
As this test already had a number of internal functions, add a
prepare_image function to do this part of the test.
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
The problem with using "virt-make-fs" to make a filesystem image is that
it is extremely slow. Switch to using the fs_helper functions we have
instead from the filesystem tests as these can add files to images and
are significantly faster and still do not require root access.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
While we can be passed an image size to use, we always called qemu-img
with 20M as the size. Fix this by using the size parameter.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
The generic function in test_ut.py to create a disk image with partition
table can be useful outside of test_ut.py so move it to be available
more clearly.
To make this a bit more easily used library function, make use of
check_call directly rather than calling things though u_boot_utils. In
turn, to more easily handle stdin here, use the shell "printf" utility
to pass sfdisk the specification to create as we do not have an actual
file descriptor to use here.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
The problem with using "virt-make-fs" to make a filesystem image is that
it is extremely slow. Switch to using the fs_helper functions we have
instead from the filesystem tests as these can add files to images and
are significantly faster and still do not require root access.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
The problem with using "virt-make-fs" to make a filesystem image is that
it is extremely slow. Switch to using the fs_helper functions we have
instead from the filesystem tests as these can add files to images and
are significantly faster and still do not require root access.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
empty/full"
Simon Glass <sjg@chromium.org> says:
The membuff implementation curently has no tests. It also assumes that
head and tail can never correspond unless the buffer is empty.
This series provides a compile-time flag to support a 'full' flag. It
also adds some tests of the main routines.
The data structure is also renamed to membuf which fits better with
U-Boot.
There may be some cases in the code which could be optimised a little,
but the implementation is functional.
Link: https://lore.kernel.org/r/20250318152059.1464369-1-sjg@chromium.org
|
|
Add tests for the membuf implementation.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Simon Glass <sjg@chromium.org> says:
U-Boot can start and boot an OS in both qemu-x86 and qemu-x86_64 but it
is not perfect.
With both builds, executing the VESA ROM causes an intermittent hang, at
least on some AMD CPUs.
With qemu-x86_64 kvm cannot be used since the move to long mode (64-bit)
is done in a way that works on real hardware but not with QEMU. This
means that performance is 4-5x slower than it could be, at least on my
CPU.
We can work around the first problem by using Bochs, which is anyway a
better choice than VESA for QEMU. The second can be addressed by using
the same descriptor across the jump to long mode.
With an MTRR fix this allows booting into Ubuntu on qemu-x86_64
In v3 some e820 patches are included to make booting reliable and avoid
ACPI tables being dropped. Also, several MTTR problems are addressed, to
support memory sizes above 4GB reliably.
Link: https://lore.kernel.org/all/20250315142643.2600605-1-sjg@chromium.org/
|
|
Now that U-Boot can boot this quickly, using kvm, add a test that the
installer starts up correctly.
Use the qemu-x86_64 board in the SJG lab.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
When the ACPI tables come from an earlier bootloader it is helpful to
see whether the checksums are correct or not. Add a -c flag to the
'acpi list' command to support that.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Free the memory used in tests to avoid a leak. Also unmap the addresses
for sandbox.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
Any 'bootable' flag in a DOS partition causes boostd to only scan
bootable partitions for that media. This can mean that extlinux.conf
files on the root disk are missed.
Put this logic behind a flag and update the documentation.
For now, the flag is enabled, to preserve the existing behaviour of
bootstd which is to ignore non-bootable partitions so long as there is
at least one bootable partition on the disk. Future work may provide a
command (or some other mechanism) to control this.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Some test can only be run by a particular board in a lab, e.g. because
they are loaded with an OS image used by the test. Add a way to specify
this in tests.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
The existing run_command() method is not great for sending things other
than U-Boot commands. Add a helper for sending arbitrary strings as well
as control characters.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
At present the disks end up being 1MB shorter than they should be,
since dd truncates by default.
Move the code into a function and update it to avoid truncation.
This resolves various warnings when running sandbox tests, of the form:
mmc_bread() MMC: block number 0x9801 exceeds max(0x9800)
caused by the FAT partition being scanning.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
This series from Patrick Rudolph <patrick.rudolph@9elements.com> brings
in an assortment of ACPI related fixes.
Link: https://lore.kernel.org/r/20250316083300.2692377-1-patrick.rudolph@9elements.com
|
|
Add tests for IORT table generation:
- SMMU_V3 node
- RC node
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
|
|
Marek Vasut <marex@denx.de> says:
Import exfat-fuse libexfat, add U-Boot filesystem layer porting glue
code and wire exfat support into generic filesystem support code. This
adds exfat support to U-Boot.
Fill in generic filesystem interface for mkdir and rm commands.
Make filesystem tests test the generic interface as well as exfat,
to make sure this code does not fall apart.
Link: https://github.com/relan/exfat/commits/0b41c6d3560d ("CI: bump FreeBSD to 13.1.")
Link: https://lore.kernel.org/r/20250317031418.223019-1-marex@denx.de
|
|
Add tests for the exfat filesystem. These tests are largely an
extension of the FS_GENERIC tests with the following notable
exceptions.
The filesystem image for exfat tests is generated using combination
of exfatprogs mkfs.exfat and python fattools. The fattols are capable
of generating exfat filesystem images too, but this is not used, the
fattools are only used as a replacement for dosfstools 'mcopy' and
'mdir', which are used to insert files and directories into existing
fatfs images and list existing fatfs images respectively, without the
need for superuser access to mount such images.
The exfat filesystem has no filesystem specific command, there is only
the generic filesystem command interface, therefore check_ubconfig()
has to special case exfat and skip check for CONFIG_CMD_EXFAT and
instead check for CONFIG_FS_EXFAT.
Signed-off-by: Marek Vasut <marex@denx.de>
|
|
The generic filesystem interface was so far untested. The interface
is similar to the FS specific interfaces with FS specific prefixes,
like ext4ls, fatmkdir, ... but it does not have any prefixes, i.e.
it provides plain ls, mkdir, ... commands.
Extend the test parameters to include 'fs_cmd_prefix' and optionally
'fs_cmd_write' parameters. The 'fs_cmd_prefix' allow specifying the
filesystem specific command prefix, like 'ext4' in 'ext4ls'. The
'fs_cmd_write' allows selecting between 'write'/'save' command name
for storing files into the filesystem, see last paragraph.
Introduce new 'fs_generic' fs_type which is used to parametrize existing
tests and run them without any prefixes if detected, thus testing the
generic filesystem interface. Use the fatfs as the backing store for the
generic FS tests.
The check_ubconfig needs to be slightly adjusted to avoid test for
CMD_FS_GENERIC_WRITE which does not exist separately from CMD_FS_GENERIC.
The CMD_FS_GENERIC does not provide generic 'write' command, instead
the generic equivalent command is called 'save' . Add simple ternary
oeprator to use 'save' command for CMD_FS_GENERIC tests and '..write'
commands for filesystem specific tests.
Enable generic filesystem tests for basic/extended/mkdir/unlink tests.
Signed-off-by: Marek Vasut <marex@denx.de>
|
|
While the dd command actually writes to the block device the truncate
command only updates the metadata (at least on ext4). This is faster and
reduces wear on the block device.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
|
|
Commit 56f186a68b3 ("lmb: check if a region can be reserved by
lmb_reserve()") fixed the lmb_reserve() and lmb_alloc_addr() API's for
some corner case scenarios, and also added corresonding test cases for
these corner cases. These tests were checking, among other things, the
lmb_alloc_addr() API. The above commit was applied to the next branch.
Subsequently, there was commit 67be24906fe
("lmb: change the return code on lmb_alloc_addr()") which was first
applied on the master branch, and subsequently got merged to next as
part of the rebase. The second commit changes the return value of the
lmb_alloc_addr() API, which now results in some of the tests added as
part of the first commit to fail. Fix those test cases.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
|
|
Prepare v2025.04-rc5
|
|
Ben reports a failure to boot the kernel on hardware that starts its
physical memory from 0x0.
The reason is that lmb_alloc_addr(), which is supposed to reserve a
specific address, takes the address as the first argument, but then also
returns the address for success or failure and treats 0 as a failure.
Since we already know the address change the prototype to return an int.
Reported-by: Ben Schneider <ben@bens.haus>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: Ben Schneider <ben@bens.haus>
Reviewed-by: Sughosh Ganu <sughosh.ganu@linaro.org>
|
|
Sughosh Ganu <sughosh.ganu@linaro.org> says:
The patch series contains some fixes and improvements in the lmb
code, along with addition of corresponding test cases for the changes
made.
The lmb_reserve() function currently does not check if the requested
reservation would overlap with existing reserved regions. While some
scenarios are being handled, some corner cases still exist. These are
being handled by patch 1, along with adding test cases for these
scenarios.
Patch 2 is handling the case of reserving a new region of memory, but
that region overlaps with an existing region. The current code only
handles one particular scenario, but prints a message for the other
scenario of an encompassing overlap and returns back. The patch
handles the encompassing overlap.
Patch 3 is an improvement whereby we allow coalescing a newly reserved
region with an existing region. The current code exits this check
prematurely.
Patch 4 is removing a now superfluous check for overlapping regions
with flag other than LMB_NONE. This now gets handled at an earlier
point in lmb_reserve().
Patch 5 is clubbing the functionality to check if two regions are
adjacent, or overlap, allowing some code re-use.
Patch 6 is optimising the lmb_alloc() function by having it call
_lmb_alloc_base() directly.
Link: https://lore.kernel.org/r/20250303133231.405279-1-sughosh.ganu@linaro.org
|
|
The logic used in lmb_alloc() takes into consideration the existing
reserved regions, and ensures that the allocated region does not
overlap with any existing allocated regions. The lmb_reserve()
function is not doing any such checks -- the requested region might
overlap with an existing region. This also shows up with
lmb_alloc_addr() as this function ends up calling lmb_reserve().
Add a function which checks if the region requested is overlapping
with an existing reserved region, and allow for the reservation to
happen only if both the regions have LMB_NONE flag, which allows
re-requesting of the region. In any other scenario of an overlap, have
lmb_reserve() return -EEXIST, implying that the requested region is
already reserved.
Add corresponding test cases which check for overlapping reservation
requests made through lmb_reserve() and lmb_alloc_addr(). And while
here, fix some of the comments in the test function being touched.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
|
|
This fails on samus_tpl as there is no 'net' command.
=> net list
Unknown command 'net' - try 'help' !
Fix it by adding a condition for the test.
Add a blank line to keep pylint happy.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
It is sometimes tricky to figure out what modules test.py is loading
when it starts up. The result can be a silent failure with no clue as to
what when wrong.
Add a section which lists the modules loaded as well as those not
found.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Now that we have a shorter name, we don't need this sort of thing. Just
use ubman instead.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Now that we have a shorter name, we don't need this sort of thing.
Drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> # test_android
|
|
We know this is U-Boot so the prefix serves no purpose other than to
make things longer and harder to read. Drop it and rename the files.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> # test_android / test_dfu
|
|
This fixture name is quite long and results in lots of verbose code.
We know this is U-Boot so the 'u_boot_' part is not necessary.
But it is also a bit of a misnomer, since it provides access to all the
information available to tests. It is not just the console.
It would be too confusing to use con as it would be confused with
config and it is probably too short.
So shorten it to 'ubman'.
Signed-off-by: Simon Glass <sjg@chromium.org>
Link: https://lore.kernel.org/u-boot/CAFLszTgPa4aT_J9h9pqeTtLCVn4x2JvLWRcWRD8NaN3uoSAtyA@mail.gmail.com/
|
|
This file was using IS_ENABLED() to test for CONFIG flags but omitted
the CONFIG_ prefix and so did not work as expected.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
https://source.denx.de/u-boot/custodians/u-boot-tegra into next
|
|
Separate setjmp.h into an architecture independent part and an architecture
specific part. This simplifies moving from using struct jmp_buf_data
directly to using type jmp_buf in our code which is the C compliant way.
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
|
|
Add tests for video bridge ops.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Test suit for of_graph parsing helpers.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
|
|
The existing memory layout places the bloblist at 0xb000 and the fdt at
0x100, resulting in a 0xaf00 size constraint for the fdt. This constraint
has been reached. Lets modify the layout by moving the bloblist to 0x100,
device tree to 0x1000 and placing early memory allocation after pre-console
buffer at 0xf4000. This should guarantee sufficient memory allocation for
future expansion.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
|
|
EFI_FILE_PROTOCOL.SetInfo()."
Gabriel Dalimonte <gabriel.dalimonte@gmail.com> says:
This series adds support for file renaming to EFI_FILE_PROTOCOL.SetInfo().
One of the use cases for renaming in EFI is to facilitate boot loader
boot counting.
No existing filesystems in U-Boot currently include file renaming,
resulting in support for renaming at the filesystem level and a
concrete implementation for the FAT filesystem.
Link: https://lore.kernel.org/r/20250217182648.31294-1-gabriel.dalimonte@gmail.com
|
|
The implementation roughly follows the POSIX specification for
rename() [1]. The ordering of operations attempting to minimize the chance
for data loss in unexpected circumstances.
The 'mv' command was implemented as a front end for the rename operation
as that is what most users are likely familiar with in terms of behavior.
The 'FAT_RENAME' Kconfig option was added to prevent code size increase on
size-oriented builds like SPL.
[1] https://pubs.opengroup.org/onlinepubs/9799919799/functions/rename.html
Signed-off-by: Gabriel Dalimonte <gabriel.dalimonte@gmail.com>
|
|
Prepare v2025.04-rc3
|
|
With a newer pylint we get a warning about how offset could be used
before assigned. This is because when the underlying filesystem wasn't
one that is supported we would have runtime test failures. Address this
by raise'ing an Exception if fs is not supported.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
With a newer pylint version we get a warning about how mounted_test_fn
could be used before assignment. Evaluating the code, this can't happen
because we check for "not have_writable_fs_partition" and return before
moving to the part of the tests which use mounted_test_fn. However, we
should instead have this written so that we only try this part of the
test if have_writable_fs_partition is set, and this also fixes the
warning. As part of this we also move test_f and mounted_test_fn to the
section of code that already only does this if
have_writable_fs_partition is set.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
When running a newer version of pylint it will complain that page_size
may be used before being assignment. Looking deeper what is going on is
that we could run in to the case where the regex we run for any of the
flash information fails but since we don't have a result, we don't check
it either. In the case of the rest of the numerical values we then have
some assignment (multiplying by some value) and so pylint doesn't
complain. Rework things to assert that each regex has a result and so
failure will stop the test and we won't have any use before assignment.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
Up to now root has been the parent device for all block devices created via
calling ConnectController(). This does not work well together with the
implementation of bootstd.
Add a dummy parent device for all EFI block devices.
With this change EFI block devices are also accessible via commands like
'cat', 'load', and 'ls'.
=> dm tree
Class Seq Probed Driver Name
-----------------------------------------------------------
efi 0 [ + ] EFI block driver `-- efi
blk 3 [ + ] efi_blk `-- efi.efiblk#0
partition 0 [ + ] blk_partition `-- efi.efiblk#0:1
=> ls efiloader 0:1
13 hello.txt
7 u-boot.txt
2 file(s), 0 dir(s)
=> cat efiloader 0:1 hello.txt
Hello world!
=> efidebug dh
0000000018df1700 (efi.efiblk#0:1)
/VenHw(dbca4c98-6cb0-694d-0872-819c650cb7b8)/HD(1,MBR,0xd1535d21,0x1,0x7f)
Block IO
Simple File System
Adjust the event dump unit test to consider the new event spy.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
|
|
Tom Rini <trini@konsulko.com> says:
A challenge we've run in to is making it easier for more people to use
various python tools that we include in the tree. Part of the problem is
that when we have a requirements.txt file, aside from the doc one we
share with the kernel, I created it using "pip freeze". And while this
might have been a best (or at least OK) practice at the time, that's no
longer the case and is why our files have so many things in them. What
this series does is create multiple files, one per project/tool and then
has CI install them as needed. There's a few places here where this
means that we update the requirements as well, but we keep a few big
things where they are currently. This is because updating them
introduces problems of their own and delaing with that would best be a
follow up series. I've put this through GitLab and Azure to make sure
everything is still going fine on both platforms.
Link: https://lore.kernel.org/r/20250205000743.949790-1-trini@konsulko.com
|
