We don't need the fallback anymore. As a first step to removing it,
drop the try...except clauses and unindent the code.
This produces a large diff but there are no other code changes.
Signed-off-by: Simon Glass <sjg@chromium.org>
Like for test_fs, no need to mess with loop mounts.
Tweaks to reduce diff (keep mnt variable):
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a parameter to indicate the size of the image to build.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Richard Weinberger <richard@nod.at>
Since no mounting happens anymore, rename the "mnt"
directory to "scratch" and the related variables.
Signed-off-by: Richard Weinberger <richard@nod.at>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
There is no need to mount the filesystem on the host side.
All filesystem tools offer some way to fill the fs without mounting.
So, create the content on the host side, create and fill the fs
without mounting.
No more sudo or guestmount needed.
This new approach works because the tests don't care about user IDs
and no device files are needed.
If user IDs start to matter it's still possible to use wrapper
tools like fakeroot in future while filling the fs.
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
We don't need the fallback anymore. Remove the code which uses these
files.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Richard Weinberger <richard@nod.at>
We don't need the fallback anymore. As a first step to removing it,
drop the try...except clauses and unindent the code.
This produces a large diff but there are no other code changes.
Signed-off-by: Simon Glass <sjg@chromium.org>
Like for test_fs, no need to mess with loop mounts.
Signed-off-by: Richard Weinberger <richard@nod.at>
Tweaks to reduce diff (keep mnt variable):
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a parameter to indicate the size of the image to build.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Richard Weinberger <richard@nod.at>
Since no mounting happens anymore, rename the "mnt"
directory to "scratch" and the related variables.
Signed-off-by: Richard Weinberger <richard@nod.at>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
There is no need to mount the filesystem on the host side.
All filesystem tools offer some way to fill the fs without mounting.
So, create the content on the host side, create and fill the fs
without mounting.
No more sudo or guestmount needed.
This new approach works because the tests don't care about user IDs
and no device files are needed.
If user IDs start to matter it's still possible to use wrapper
tools like fakeroot in future while filling the fs.
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Rename actual android bootmethod test to specify it's for boot image
version 4.
Add a unit test for testing the Android bootmethod with boot image
version 2.
This requires another mmc image (mmc8) to contain the following
partitions:
- misc: contains the Bootloader Control Block (BCB)
- boot_a: contains a fake generic kernel image
we can test this with:
$ ./test/py/test.py --bd sandbox --build -k test_ut # build the mmc8.img
$ ./test/py/test.py --bd sandbox --build -k bootflow_android
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Signed-off-by: Guillaume La Roque <glaroque@baylibre.com>
Link: https://lore.kernel.org/r/20241126-adnroidv2-v4-5-11636106dc69@baylibre.com
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Currently, MMC test runs on default mmc modes, adding a provision to
support multiple mmc modes through user defined parameters.
Signed-off-by: Love Kumar <love.kumar@amd.com>
'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.
Signed-off-by: Love Kumar <love.kumar@amd.com>
'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.
Signed-off-by: Love Kumar <love.kumar@amd.com>
Use an 'r' string to avoid a warning:
test/py/tests/test_spi.py:698: DeprecationWarning: invalid escape
sequence '\s'
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Love Kumar <love.kumar@amd.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
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.
Handle this in test.py by adding more parameters.
Signed-off-by: Simon Glass <sjg@chromium.org>
This can take a while and involve multiple steps (e.g. turning the board
back off). Add a section for it and show the output.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
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.
Signed-off-by: Simon Glass <sjg@chromium.org>
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.
Signed-off-by: Simon Glass <sjg@chromium.org>
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.
Signed-off-by: Simon Glass <sjg@chromium.org>
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.
Signed-off-by: Simon Glass <sjg@chromium.org>
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.
Link: https://tbot.tools
Signed-off-by: Simon Glass <sjg@chromium.org>
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.
Signed-off-by: Simon Glass <sjg@chromium.org>
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>
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>
Create a new disk for use with tests, which contains the new 'testapp'
EFI app specifically intended for testing the EFI loader.
Attach it to the USB device, since most testing is currently done with
mmc.
Initially this image will be used to test the EFI bootmeth.
Fix a stale comment in prep_mmc_bootdev() while we are here.
For now this uses sudo and a compressed fallback file, like all the
other bootstd tests. Once this series is in, the patch which moves
this to use user-space tools will be cleaned up and re-submitted.
Signed-off-by: Simon Glass <sjg@chromium.org>
The tests test_usb_ext4load_ext4write, test_usb_ext2load and
test_usb_load depend on the command ext4write being present not just
the feature of being able to write to an ext4 file system. So update
their dependencies to include the ext4write command itself. This will
prevent spurious test failures when running the USB tests against USB
storage with an ext2/ext4 partition but no ext4write command available.
Fixes: 1c5b6edad3 ("test/py: usb: Add tests for USB device")
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Reviewed-by: Love Kumar <love.kumar@amd.com>
When test_usb_load finds multiple partitions of the same type then
it will cause a test failure. The call to write the test file will
write a different test file to each partition but only return the
name and size of the last one written. So the test then fails to
load the test file from the first partition as it uses the name of
a file on a different partition.
Refactor the code so that only one test file is written at a time
and is written to only the partition being tested at that time. This
allows the correct file name to always be available to the code that
runs the load command. This reduces the number of files written and
also the number of calls to crc32 needed.
Fixes: 1c5b6edad3 ("test/py: usb: Add tests for USB device")
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Reviewed-by: Love Kumar <love.kumar@amd.com>
Heinrich Schuchardt <heinrich.schuchardt@canonical.com> says:
With this series opendir, readdir, closedir are implemented for ext4.
These functions are needed for the UEFI sub-system to interact with
the ext4 file system.
To reduce code growth the functions are reused to implement the ls
command for ext4.
A memory leak in ext4fs_exists is resolved.
ext4fs_iterate_dir is simplified by removing a redundant pointer copy.
Link: https://lore.kernel.org/r/20241026064048.370062-1-heinrich.schuchardt@canonical.com
Now that opendir, readir, closedir are implemented for ext4 we can use
fs_ls_generic() for implementing the ls command.
Adjust the unit tests:
* fs_ls_generic() produces more spaces between file size and name.
* The ext4 specific message "** Can not find directory. **\n" is not
written anymore.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Update spi negative test case to prevent SF command
from overwriting relocation memory area.
Signed-off-by: Padmarao Begari <padmarao.begari@amd.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Love Kumar <love.kumar@amd.com>
To conform with other messages capitalize the first letter:
%s/enter description/Enter description/g
Adjust the unit tests accordingly.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
The config setting CMD_BOOTEFI_HELLO_COMPILE was removed in favour
of BOOTEFI_HELLO_COMPILE but the dependency for
test_efi_helloworld_net_http was not updated and so is now incorrect
preventing the test from ever running. Fix it.
Fixes: 6fe80876dc ("efi_loader: Rename and move CMD_BOOTEFI_HELLO_COMPILE")
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Patrick Rudolph <patrick.rudolph@9elements.com> says:
Based on the existing work done by Simon Glass this series adds
support for booting aarch64 devices using ACPI only.
As first target QEMU SBSA support is added, which relies on ACPI
only to boot an OS. As secondary target the Raspberry Pi4 was used,
which is broadly available and allows easy testing of the proposed
solution.
The series is split into ACPI cleanups and code movements, adding
Arm specific ACPI tables and finally SoC and mainboard related
changes to boot a Linux on the QEMU SBSA and RPi4. Currently only the
mandatory ACPI tables are supported, allowing to boot into Linux
without errors.
The QEMU SBSA support is feature complete and provides the same
functionality as the EDK2 implementation.
The changes were tested on real hardware as well on QEMU v9.0:
qemu-system-aarch64 -machine sbsa-ref -nographic -cpu cortex-a57 \
-pflash secure-world.rom \
-pflash unsecure-world.rom
qemu-system-aarch64 -machine raspi4b -kernel u-boot.bin -cpu cortex-a72 \
-smp 4 -m 2G -drive file=raspbian.img,format=raw,index=0 \
-dtb bcm2711-rpi-4-b.dtb -nographic
Tested against FWTS V24.03.00.
Known issues:
- The QEMU rpi4 support is currently limited as it doesn't emulate PCI,
USB or ethernet devices!
- The SMP bringup doesn't work on RPi4, but works in QEMU (Possibly
cache related).
- PCI on RPI4 isn't working on real hardware since the pcie_brcmstb
Linux kernel module doesn't support ACPI yet.
Link: https://lore.kernel.org/r/20241023132116.970117-1-patrick.rudolph@9elements.com
Allocate memory for ACPI tables in generic acpi code. When ACPI wasn't
installed in other places, install the ACPI table using BLOBLISTs.
This allows non x86 platforms to boot using ACPI only in case the
EFI loader is being used, since EFI is necessary to advertise the location
of the ACPI tables in memory.
TEST: Booted QEMU SBSA (no QFW) using EFI and ACPI only.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
It's really helpful to have the ability to dump BCB block for debugging
A/B logic on the board supported this partition schema.
Command 'bcb ab_dump' prints all fields of bootloader_control struct
including slot_metadata for all presented slots.
Output example:
=====
> board# bcb ab_dump ubi 0#misc
> Read 512 bytes from volume misc to 000000000bf07580
> Read 512 bytes from volume misc to 000000000bf42f40
> Bootloader Control: [misc]
> Active Slot: _a
> Magic Number: 0x42414342
> Version: 1
> Number of Slots: 2
> Recovery Tries Remaining: 0
> CRC: 0x2c8b50bc (Valid)
>
> Slot[0] Metadata:
> - Priority: 15
> - Tries Remaining: 0
> - Successful Boot: 1
> - Verity Corrupted: 0
>
> Slot[1] Metadata:
> - Priority: 14
> - Tries Remaining: 7
> - Successful Boot: 0
> - Verity Corrupted: 0
====
The ab_dump command allows you to display ABC data directly on the
U-Boot console. During an A/B test execution, this test verifies the
accuracy of each field within the ABC data.
Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> # vim3_android
Link: https://lore.kernel.org/r/20241017-android_ab_master-v5-5-43bfcc096d95@salutedevices.com
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
To enhance code organization, it is beneficial to consolidate all A/B
BCB management routines into a single super-command.
The 'bcb' command is an excellent candidate for this purpose.
This patch integrates the separate 'ab_select' command into the 'bcb'
group as the 'ab_select' subcommand, maintaining the same parameter list
for consistency.
Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> # vim3_android
Link: https://lore.kernel.org/r/20241017-android_ab_master-v5-3-43bfcc096d95@salutedevices.com
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
When the config option CMD_MISC was renamed to CMD_SLEEP the check
in the test for the sleep command was not updated. Do that now.
Fixes: 1606085409 ("cmd: Rename CMD_MISC to CMD_SLEEP")
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
When the connection to a board dies, assume it is dead forever until
some user action is taken. Skip all remaining tests. This avoids CI
runs taking an hour, with hundreds of 30-second timeouts all to no
avail.
Signed-off-by: Simon Glass <sjg@chromium.org>
The tests currently catch a very broad Exception in each case. This is
thrown even in the event of a coding error.
We want to handle exceptions differently depending on their severity,
so that we can avoid hour-long delays waiting for a board that is
clearly broken.
As a first step, create some new exception types, separating out those
which are simply an unexpected result from executed a command, from
those which indicate some kind of hardware failure.
Signed-off-by: Simon Glass <sjg@chromium.org>
There is quite a bit of code to deal with receiving data from the target
so move it into its own receive() function.
Signed-off-by: Simon Glass <sjg@chromium.org>
The settings are decoded in two places. Combine them into a new
function, before (in a future patch) expanding the number of items.
Signed-off-by: Simon Glass <sjg@chromium.org>
Declare a constant rather than open-coding the same value twice.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Calling u_boot_console.restart_uboot() in
test_efi_selftest_watchdog_reboot() may lead to incorrect results.
While the watchdog triggered reboot is running thee test environment may
need some time before triggering a reboot itself. This may lead to
duplicate output of the U-Boot greeter which is recorded as an error.
Reported-by: Tom Rini <trini@konsulko.com>
Fixes: df172e117d ("test/py: test reboot by EFI watchdog")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
This is not actually a command so the name is confusing. Use
BOOTEFI_HELLO_COMPILE instead. Put it in the efi_loader directory
with the other such config options.
The link rule (for $(obj)/%_efi.so) in scripts/Makefile.lib handles
pulling in efi_crt0.o and efi_reloc.o so drop the 'extra' rules.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Jerome Forissier <jerome.forissier@linaro.org> says:
Miscellaneous fixes made when developing the lwIP series [1]. They are
posted separately since they make sense on their own. Subsequent
versions of the lwIP series will contain a squashed version of this one.
[1] http://patchwork.ozlabs.org/project/uboot/list/?series=420712&state=%2A&archive=both
Add a test to test_efi_loader.py similar to the TFTP test but for HTTP
with the wget command.
Suggested-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Tested-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
test_efi_helloworld_net() and test_efi_grub_net() depend on
cmd_tftpboot so add the missing annotations.
Reported-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
If env__pxe_boot_test_skip is not present, it defaults to True not
False. Therefore fix the comment.
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
When running the bootstage tests currently we get a warning like:
tests/test_bootstage.py::test_bootstage_stash
...PytestReturnNotNoneWarning: Expected None, but tests/test_bootstage.py::test_bootstage_stash returned (37748736, 4096), which will be an error in a future version of pytest. Did you mean to use `assert` in stead of `return`?
This is because the unstash test will run the stash test and fetch the
addr / size from that. Rework the test to be stash and unstash and then
run the unstash command at the end of the current stash test.
Acked-by: Michal Simek <michal.simek@amd.com>
Reviewed-by: Love Kumar <love.kumar@amd.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
Simon Glass <sjg@chromium.org> says:
This series includes the patches needed to make make the EFI 'boot' test
work. That test has now been split off into a separate series along with
the EFI patches.
This series fixes these problems:
- sandbox memory-mapping conflict with PCI
- the fix for that causes the mbr test to crash as it sets up pointers
instead of addresses for its 'mmc' commands
- the mmc and read commands which cast addresses to pointers
- a tricky bug to do with USB keyboard and stdio
- a few other minor things
Tidy up most of these warnings. Remaining are four of these:
R0914: Too many local variables
which can only by fixed by splitting things into functions, so that is
left for another time.
Part of this change was done by the flynt tool.
Signed-off-by: Simon Glass <sjg@chromium.org>
Migrate sandbox over to generating it's capsule update image GUIDs
dynamically from the namespace and board/image info. Update the
reference and tests to use the new GUIDs.
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
If erase/write/read size is 0 then it throws the mentioned error message
when debug message ie enabled as per 899fb5aa8b ("cmd: sf/nand: Print
and return failure when 0 length is passed"), setting it to None as
debug message is not enabled by default for testing.
Signed-off-by: Love Kumar <love.kumar@amd.com>
Add test cases for sf commands to verify various SPI flash operations
such as erase, write and read. It also adds qspi lock unlock cases.
This test relies on boardenv_* configurations to run it for different
SPI flash family such as single SPI, QSPI, and OSPI.
Signed-off-by: Love Kumar <love.kumar@amd.com>
In order to build the docker container, which contains a download cache
of python modules, we need to have our versions be in sync in each
requirements file. Update some of the cases where which are older than
the rest of the project.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
Now that sandbox_vpl supports UPL, add a test that checks that the
payload can be loaded by SPL and the handoff information passed through
to U-Boot proper.
Signed-off-by: Simon Glass <sjg@chromium.org>
Use the sandbox_vpl build to test UPL since it supports a real devicetree
in SPL. The sandbox_spl build uses OF_PLATDATA.
Enable writing the UPL handoff in SPL and reading it in U-Boot proper.
Provide a test to check that this handoff works.
Note that the test uses the standard devicetree rather than the test one,
since it is a lot smaller and fits in the existing bloblist.
Signed-off-by: Simon Glass <sjg@chromium.org>
There is some potential security issue resolved by upgrading to v70.0.0
here and the latest is now v70.3.0.
Reported-by: GitHub dependabot
Suggested-by: Sebastian Kropatsch <seb-dev@mail.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
Rasmus Villemoes <rasmus.villemoes@prevas.dk> says:
This is a followup to the patches that landed in 2024.01 and nearly
made sure that source files for producing .dtbo files use the .dtso
extension. In the same release, a few new .dts files snuck in, and
there was also some test code involving .dtbo -> .dtbo.S -> .dtbo.o I
didn't really know how to handle at the time. This should finish the
job, bring us in sync with linux (at least in this respect), and drop
the .dts -> .dtbo build rule.
Add a unit test for testing the Android bootmethod.
This requires another mmc image (mmc7) to contain the following partitions:
- misc: contains the Bootloader Control Block (BCB)
- boot_a: contains a fake generic kernel image
- vendor_boot_a: contains a fake vendor_boot image
Also add BOOTMETH_ANDROID as a dependency on sandbox so that we can test
this with:
$ ./test/py/test.py --bd sandbox --build -k test_ut # build the mmc7.img
$ ./test/py/test.py --bd sandbox --build -k bootflow_android
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Reviewed-by: Julien Masson <jmasson@baylibre.com>
Reviewed-by: Guillaume La Roque <glaroque@baylibre.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Distinguish more clearly between source files meant for producing .dtb
from those meant for producing .dtbo.
Note that in the linux tree, all device tree overlay sources have been
renamed to .dtso, and the .dts->.dtbo rule is gone since v6.5 (commit
81d362732bac). So this is also a step towards staying closer to linux
with respect to both Kbuild and device tree sources, and eventually
eliminating all .dts -> .dtbo instances.
This also matches the documentation update done in commit 4fb7e570d6.
Cc: Masahisa Kojima <kojima.masahisa@socionext.com>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
A security issue exists with zipp before v3.19.1, and the current
release is now v3.19.2. While the change in versions numbers is large, a
manual inspection of the changelog shows that it's not as big as might
be implied.
Reported-by: GitHub dependabot
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
The tests we currently have expect the firmware update to fail
when OsIndications is not set properly. However, we have a Kconfig flag
that explicitly ignores that variable. Adjust the tests accordingly
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
The build option to support images of type 'IMAGE_FORMAT_LEGACY' is
CONFIG_LEGACY_IMAGE_FORMAT so update the pytest to check for the correct
option.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
On tests which require "tftpboot" we need to depend not on cmd_net but
rather cmd_tftpboot. And on tests which require cmd_pxe we do not need
to also depend on cmd_net as this should be handled already via Kconfig
logic.
Signed-off-by: Tom Rini <trini@konsulko.com>
The current test doesn't check anything about the output. If a bug
results in junk before the output, this is not currently detected.
Add a check for the first line being the one expected.
Signed-off-by: Simon Glass <sjg@chromium.org>
When a real board fails we don't want to decode the exception. Reserve
that behaviour for sandbox. Also avoid raising a new exception on
failure - just re-raise the existing one.
Signed-off-by: Simon Glass <sjg@chromium.org>
When a driver is not registered properly it is not clear which one it
is. Adjust test_dm_compat() to show this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tests for standard boot need disks to be set up, which can only be done
on sandbox, since adjusting disks on real hardware is not currently
supported. Mark the init function as sandbox-only.
Signed-off-by: Simon Glass <sjg@chromium.org>
The relocation offset can change in some initcall sequences. Handle
this and make sure it is used for all debugging statements in
init_run_list()
Update the trace test to match.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org>
Add tests for booting image using tftpboot/pxe boot commands, tftpboot
boot case loads the FIT image into DDR and boots using bootm command
whereas pxe boot cases downloads the pxe configuration file from the
TFTP server and interprets it to boot the images mentioned in the pxe
configurations file.
This test relies on boardenv_* containing configuration values including
the parameter 'pattern'. tftpboot/pxe boot cases boots the Linux till the
boot log pattern value is matched. For example, if the parameter
'pattern' is defined as 'login:', it will boot till login prompt.
Signed-off-by: Love Kumar <love.kumar@amd.com>
Tested-by: Tom Rini <trini@konsulko.com>
Executing a u-boot command may raise an error or extra bad pattern,
beyond the default bad patterns. Providing a way to enable the console
output error check in test.
For example, description for OS boot test:
import re
check_type = 'kernel_boot_error'
check_pattern = re.compile('ERROR -2: can't get kernel image!')
with u_boot_console.enable_check(check_type, check_pattern):
u_boot_console.run_command('<boot command>')
Signed-off-by: Love Kumar <love.kumar@amd.com>
The issue described in https://github.com/psf/requests/pull/6655 has
been assigned as a security issue. While unlikely to be exploited in our
usage, update to the current release to fix it. Furthermore, upstream
has now moved on to v2.23.2 as the release to use which has all of the
issues resolved.
Reported-by: GitHub dependabot
Signed-off-by: Tom Rini <trini@konsulko.com>
According to UEFI v2.10 spec section 8.2.6, if a caller invokes the
SetVariables() service, it will produce a digest from hash(VariableName,
VendorGuid, Attributes, TimeStamp, DataNew_variable_content), then the
firmware that implements the SetVariable() service will compare the
digest with the result of applying the signer’s public key to the
signature. For EFI variable append write, efitools sign-efi-sig-list has
an option "-a" to add EFI_VARIABLE_APPEND_WRITE attr, and u-boot will
drop this attribute in efi_set_variable_int(). So if a caller uses
"sign-efi-sig-list -a" to create the authenticated variable, this append
write will fail in the u-boot due to "hash check failed".
This patch resumes writing the EFI_VARIABLE_APPEND_WRITE attr to ensure
that the hash check is correct. And also update the "test_efi_secboot"
test case to compliance with the change.
Signed-off-by: Weizhao Ouyang <o451686892@gmail.com>
For pcr_read and pcr_extend commands allow the digest algorithm to be
specified by an additional argument. If not specified it will default to
SHA256 for backwards compatibility.
Additionally update test_tpm2.py for the changes in output in pcr_read
which now shows the algo and algo length in the output.
A follow-on to this could be to extend all PCR banks with the detected
algo when the <digest_algo> argument is 'auto'.
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
As part of bringing the master branch back in to next, we need to allow
for all of these changes to exist here.
Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay
Ethernet"' I failed to notice that b4 noticed it was based on next and
so took that as the base commit and merged that part of next to master.
This reverts commit c8ffd1356d, reversing
changes made to 2ee6f3a5f7.
Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
Currently we have the option to tell the console code that we should
ignore the SPL banner. We also have an option to say that we can see it
a second time, and ignore it. However, some platforms such as TI AM64x
will have us see the SPL banner three times. Rather than add an
"spl3_skipped" option, rework the code. By default we expect to see the
banner once, but boards can specify seeing it as many times as they
expect to.
Signed-off-by: Tom Rini <trini@konsulko.com>
The image is not unloaded if a security violation occurs.
If efi_set_load_options() fails, we do not free the memory allocated for
the optional data. We do not unload the image.
* Unload the image if a security violation occurs.
* Free load_options if efi_set_load_options() fails.
* Unload the image if efi_set_load_options() fails.
Fixes: 53f6a5aa86 ("efi_loader: Replace config option for initrd loading")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Fix typos in test_eficonfig.py: %s/curren/current/
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Igor Opaniuk <igor.opaniuk@gmail.com>
Currently, all the capsules for the sandbox platform are generated at
the time of running the capsule tests. To showcase generation of
capsules through binman, generate all raw(non FIT payload) capsules
needed for the sandbox platform as part of the build. This acts as an
illustrative example for generating capsules as part of a platform's
build.
Make corresponding change in the capsule test's configuration to get
these capsules from the build directory.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
