| Age | Commit message (Collapse) | Author |
|---|
|
It is very surprising that such an uclass, specifically designed to
handle resources that may be shared by different devices, is not keeping
the count of the number of times a power domain has been
enabled/disabled to avoid shutting it down unexpectedly or disabling it
several times.
Doing this causes troubles on eg. i.MX8MP because disabling power
domains can be done in recursive loops were the same power domain
disabled up to 4 times in a row. PGCs seem to have tight FSM internal
timings to respect and it is easy to produce a race condition that puts
the power domains in an unstable state, leading to ADB400 errors and
later crashes in Linux.
Some drivers implement their own mechanism for that, but it is probably
best to add this feature in the uclass and share the common code across
drivers. In order to avoid breaking existing drivers, refcounting is
only enabled if the number of subdomains a device node supports is
explicitly set in the probe function. ->xlate() callbacks will return
the power domain ID which is then being used as the array index to reach
the correct refcounter.
As we do not want to break existing users while stile getting
interesting error codes, the implementation is split between:
- a low-level helper reporting error codes if the requested transition
could not be operated,
- a higher-level helper ignoring the "non error" codes, like EALREADY and
EBUSY.
CI tests using power domains are slightly updated to make sure the count
of on/off calls is even and the results match what we *now* expect. They
are also extended to test the low-level functions.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
Update SPI negative tests to prevent SF command from overwriting the
reserved memory area.
Signed-off-by: Love Kumar <love.kumar@amd.com>
|
|
Jerome Forissier <jerome.forissier@linaro.org> says:
This series introduces threads and uses them to improve the performance
of the USB bus scanning code and to implement background jobs in the
shell via two new commands: 'spawn' and 'wait'.
The threading framework is called 'uthread' and is inspired from the
barebox threads [2]. setjmp() and longjmp() are used to save and
restore contexts, as well as a non-standard extension called initjmp().
This new function is added in several patches, one for each
architecture that supports HAVE_SETJMP. A new symbol is defined:
HAVE_INITJMP. Two tests, one for initjmp() and one for the uthread
scheduling, are added to the lib suite.
After introducing threads and making schedule() and udelay() a thread
re-scheduling point, the USB stack initialization is modified to benefit
from concurrency when UTHREAD is enabled, where uthreads are used in
usb_init() to initialize and scan multiple busses at the same time.
The code was tested on arm64 and arm QEMU with 4 simulated XHCI buses
and some devices. On this platform the USB scan takes 2.2 s instead of
5.6 s. Tested on i.MX93 EVK with two USB hubs, one ethernet adapter and
one webcam on each, "usb start" takes 2.4 s instead of 4.6 s.
Finally, the spawn and wait commands are introduced, allowing the use of
threads from the shell. Tested on the i.MX93 EVK with a spinning HDD
connected to USB1 and the network connected to ENET1. The USB plus DHCP
init sequence "spawn usb start; spawn dhcp; wait" takes 4.5 seconds
instead of 8 seconds for "usb start; dhcp".
[1] https://patchwork.ozlabs.org/project/uboot/list/?series=446674
[2] https://github.com/barebox/barebox/blob/master/common/bthread.c
Link: https://lore.kernel.org/r/20250418141114.2056981-1-jerome.forissier@linaro.org
|
|
Test the spawn and wait commands.
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
Use the uthread framework to initialize and scan USB buses in parallel
for better performance. The console output is slightly modified with a
final per-bus report of the number of devices found, common to UTHREAD
and !UTHREAD. The USB tests are updated accordingly.
Tested on two platforms:
1. arm64 QEMU on a somewhat contrived example (4 USB buses, each with
one audio device, one keyboard, one mouse and one tablet)
$ make qemu_arm64_defconfig
$ make -j$(nproc) CROSS_COMPILE="ccache aarch64-linux-gnu-"
$ qemu-system-aarch64 -M virt -nographic -cpu max -bios u-boot.bin \
$(for i in {1..4}; do echo -device qemu-xhci,id=xhci$i \
-device\ usb-{audio,kbd,mouse,tablet},bus=xhci$i.0; \
done)
2. i.MX93 EVK (imx93_11x11_evk_defconfig) with two USB hubs, each with
one webcam and one ethernet adapter, resulting in the following device
tree:
USB device tree:
1 Hub (480 Mb/s, 0mA)
| u-boot EHCI Host Controller
|
+-2 Hub (480 Mb/s, 100mA)
| GenesysLogic USB2.1 Hub
|
+-3 Vendor specific (480 Mb/s, 350mA)
| Realtek USB 10/100/1000 LAN 001000001
|
+-4 (480 Mb/s, 500mA)
HD Pro Webcam C920 8F7CD51F
1 Hub (480 Mb/s, 0mA)
| u-boot EHCI Host Controller
|
+-2 Hub (480 Mb/s, 100mA)
| USB 2.0 Hub
|
+-3 Vendor specific (480 Mb/s, 200mA)
| Realtek USB 10/100/1000 LAN 000001
|
+-4 (480 Mb/s, 500mA)
Generic OnLan-CS30 201801010008
Note that i.MX was tested on top of the downstream repository [1] since
USB doesn't work in the upstream master branch.
[1] https://github.com/nxp-imx/uboot-imx/tree/lf-6.6.52-2.2.0
commit 6c4545203d12 ("LF-13928 update key for capsule")
The time spent in usb_init() ("usb start" command) is reported on
the console. Here are the results:
| CONFIG_UTHREAD=n | CONFIG_UTHREAD=y
--------+------------------+-----------------
QEMU | 5628 ms | 2212 ms
i.MX93 | 4591 ms | 2441 ms
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
|
|
Add a test for uthread mutexes.
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
|
|
Add a thread framework test to the lib tests. Update the API
documentation to use the test as an example.
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
Test the initjmp() function when HAVE_INITJMP is set. Use the test as an
example in the API documentation.
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
Convert the tests to use the do_ping() interface which is now
common to NET and NET_LWIP. This allows running most network test with
SANDBOX and NET_LWIP. A few things to note though:
1. The ARP and IPv6 tests are enabled for NET only
2. The net_retry test is modified to use eth0 (eth@10002000) as the
active (but disabled) interface, and therefore we expect eth1
(eth@10003000) to be the fallback when "netretry" is "yes". This is in
replacement of eth7 (lan1) and eth0 (eth@10002000) respectively.
Indeed, it seems eth7 works with NET by chance and it certainly does not
work with NET_LWIP. I observed that even with NET,
sandbox_eth_disable_response(1, true) has no effect: remove it and
the test still passes. The interface ID is not correct to begin with; 1
corresponds to eth1 (eth@10003000) as shown by debug traces, it is not
eth7 (lan1). And using index 7 causes a SEGV. In fact, it is not the
call to sandbox_eth_disable_response() that prevents the stack from
processing the ICMP reply but the timeout caused by the call to
sandbox_eth_skip_timeout(). Here is what happens when trying to ping
using the eth7 (lan1) interface with NET:
do_ping(...)
net_loop(PING)
ping_start()
eth_rx()
sb_eth_recv()
time_test_add_offset(11000UL);
if (get_timer(0) - time_start > time_delta)
ping_timeout_handler() // ping error, as expected
And the same with NET_LWIP:
do_ping(...)
ping_loop(...)
sys_check_timeouts()
net_lwip_rx(...)
sb_eth_recv()
time_test_add_offset(11000UL);
netif->input(...) // the packet is processed succesfully
By choosing eth0 and sandbox_eth_disable_response(0, true), the incoming
packet is indeed discarded and things work as expected with both network
stacks.
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Jerome Forissier <jerome.forissier@linaro.org> says:
Enable CONFIG_UNIT_TEST in most of the configs/qemu*_defconfig files
to increase test coverage in CI, and fix what needs to be fixed.
Link: https://lore.kernel.org/r/20250416135744.1995084-1-jerome.forissier@linaro.org
|
|
Jerome Forissier <jerome.forissier@linaro.org> says:
There is a bug in the print_guid() unit test in test/common/print.c when
PARTITION_TYPE_GUID is not enabled but either CMD_EFIDEBUG or EFI are.
The first patch fixes the issue and the second one enables UNIT_TEST in
the qemu_arm64 defconfig so that the unit tests are run in CI (this
platform has CMD_EFIDEBUG so the bug applies).
Link: https://lore.kernel.org/r/20250416074839.1267396-1-jerome.forissier@linaro.org
|
|
The name defined for PARTITION_SYSTEM_GUID in list_guid[] depends on
configuration options. It is "system" if CONFIG_PARTITION_TYPE_GUID is
enabled or "System Partition" if CONFIG_CMD_EFIDEBUG or CONFIG_EFI are
enabled. In addition, the unit test in test/common/print.c is incorrect
because it expects only "system" (or a hex GUID).
Make things more consistent by using a clear and unique name: "EFI
System Partition" whatever the configuration, and update the unit test
accordingly.
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
Some test commands (such as "false", or the empty string) need
CONFIG_HUSH_PARSER=y. Fix test/cmd/command.c.
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
|
|
This series from Marek Vasut <marex@denx.de> includes a number of fixes
to the exFAT filesystem support that he recently added.
Link: https://lore.kernel.org/r/20250413085740.5953-1-marex@denx.de
|
|
Enable tests for the generic FS interface 'mv' command against
both exfat and fs_generic.
Signed-off-by: Marek Vasut <marex@denx.de>
|
|
Add test for the 'test -e' command to check for existence of files.
This exercises struct fstype_info .exists callback.
Signed-off-by: Marek Vasut <marex@denx.de>
|
|
Unfortunately this change breaks boot on K3 platform.
U-Boot will hang after:
U-Boot SPL 2025.04-01050-ga40fc5afaec0 (Apr 14 2025 - 07:31:32 +0000)
SYSFW ABI: 3.1 (firmware rev 0x0009 '9.2.7--v09.02.07 (Kool Koala)')
This reverts commit 197376fbf300e92afa0a1583815d9c9eb52d613a as
suggested in [1].
[1] https://lists.denx.de/pipermail/u-boot/2025-April/587032.html
Signed-off-by: Wadim Egorov <w.egorov@phytec.de>
Acked-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
Jerome Forissier <jerome.forissier@linaro.org> says:
This series replaces the dynamic initcalls (with function pointers) with
static calls, and gets rid of initcall_run_list(), init_sequence_f,
init_sequence_f_r and init_sequence_r. This makes the code simpler and the
binary slighlty smaller: -2281 bytes/-0.21 % with LTO enabled and -510
bytes/-0.05 % with LTO disabled (xilinx_zynqmp_kria_defconfig).
Execution time doesn't seem to change noticeably. There is no impact on
the SPL.
The inline assembly fixes, although they look unrelated, are triggered
on some platforms with LTO enabled. For example: kirkwood_defconfig.
CI: https://source.denx.de/u-boot/custodians/u-boot-net/-/pipelines/25514
Link: https://lore.kernel.org/r/20250404135038.2134570-1-jerome.forissier@linaro.org
|
|
Change board_init_f(), board_init_f_r() and board_init_r() to make
static calls instead of iterating over the init_sequence_f,
init_sequence_f_r and init_sequence_r arrays, respectively. This makes
the code a simpler (and even more so when initcall_run_list() is
later removed) and it reduces the binary size as well. Tested with
xilinx_zynqmp_kria_defconfig; bloat-o-meter results:
- With LTO
add/remove: 106/196 grow/shrink: 10/28 up/down: 31548/-33829 (-2281)
Total: Before=1070471, After=1068190, chg -0.21%
- Without LTO
add/remove: 0/54 grow/shrink: 3/0 up/down: 2322/-2832 (-510)
Total: Before=1121723, After=1121213, chg -0.05%
Execution time does not change in a noticeable way.
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
|
|
Tom Rini <trini@konsulko.com> says:
This series switches to always using $(PHASE_) in Makefiles when
building rather than $(PHASE_) or $(XPL_). It also starts on documenting
this part of the build, but as a follow-up we need to rename
doc/develop/spl.rst and expand on explaining things a bit.
Link: https://lore.kernel.org/r/20250401225851.1125678-1-trini@konsulko.com
|
|
It is confusing to have both "$(PHASE_)" and "$(XPL_)" be used in our
Makefiles as part of the macros to determine when to do something in our
Makefiles based on what phase of the build we are in. For consistency,
bring this down to a single macro and use "$(PHASE_)" only.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
It is very surprising that such an uclass, specifically designed to
handle resources that may be shared by different devices, is not keeping
the count of the number of times a power domain has been
enabled/disabled to avoid shutting it down unexpectedly or disabling it
several times.
Doing this causes troubles on eg. i.MX8MP because disabling power
domains can be done in recursive loops were the same power domain
disabled up to 4 times in a row. PGCs seem to have tight FSM internal
timings to respect and it is easy to produce a race condition that puts
the power domains in an unstable state, leading to ADB400 errors and
later crashes in Linux.
CI tests using power domains are slightly updated to make sure the count
of on/off calls is even and the results match what we *now* expect.
As we do not want to break existing users while stile getting
interesting error codes, the implementation is split between:
- a low-level helper reporting error codes if the requested transition
could not be operated,
- a higher-level helper ignoring the "non error" codes, like EALREADY and
EBUSY.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
This is a new DM core helper. There is now a graph endpoint
representation in the sandbox test DTS, so we can just use it to verify
the helper proper behavior.
Suggested-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
When using non-trivial values for parameters for this test it
will cause a spurious failure as the test passes a decimal value
to the mtest command which will interpret it as hexadecimal and
result in failure as below.
test/py/tests/test_memtest.py:66: in test_memtest_ddr
assert expected_response in response
E AssertionError: assert 'Tested 16 iteration(s) with 0 errors.' in 'Refusing to do empty test\r\nmtest - simple RAM read/write test\r\n\r\nUsage:\r\nmtest [start [end [pattern [iterations]]]]'
----------------------------- Captured stdout call -----------------------------
U-Boot> mtest 134217728 0x8001000 90 0x10
Refusing to do empty test
mtest - simple RAM read/write test
Usage:
mtest [start [end [pattern [iterations]]]]
The fix is to ensure that all the parameters to the mtest command are
passed as hexadecimal values.
Fixes: 22efc1cf276c ("test/py: memtest: Add tests for mtest command")
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Reviewed-by: Love Kumar <love.kumar@amd.com>
|
|
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>
|
