| Age | Commit message (Collapse) | Author |
|---|
|
Implement do_tftpb(). This implementation of the tftp command
supports an optional port number. For example:
tftp 192.168.0.30:9069:file.bin
It also supports taking the server IP from ${tftpserverip} if
defined, before falling back to ${serverip}.
Signed-off-by: Jerome Forissier <[email protected]>
Acked-by: Ilias Apalodimas <[email protected]>
Tested-by: Ilias Apalodimas <[email protected]>
|
|
The TFTP app should not bind to the TFTP server port when configured as
a client. Instead, the local port should be chosen from the dynamic
range (49152 ~ 65535) so that if the application is stopped and started
again, the remote server will not consider the new packets as part of
the same context (which would cause an error since a new RRQ would be
unexpected).
Submitted upstream: https://savannah.nongnu.org/patch/?10480
Signed-off-by: Jerome Forissier <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
Add what it takes to enable NETDEVICES with NET_LWIP and enable DHCP as
well as the dhcp command. CMD_TFTPBOOT is selected by BOOTMETH_EFI due
to this code having an implicit dependency on do_tftpb().
Note that PXE is likely non-fonctional with NET_LWIP (or at least not
100% functional) because DHCP option 209 is not supported by the lwIP
library. Therefore, BOOTP_PXE_DHCP_OPTION cannot be enabled.
Signed-off-by: Jerome Forissier <[email protected]>
Tested-by: Ilias Apalodimas <[email protected]>
Acked-by: Ilias Apalodimas <[email protected]>
|
|
Build the lwIP library when NET_LWIP is enabled. The following files
are adaptation layers written specially for U-Boot:
lib/lwip/u-boot/arch/cc.h
lib/lwip/u-boot/arch/sys_arch.h (empty)
lib/lwip/u-boot/limits.h (empty)
lib/lwip/u-boot/lwipopts.h
They were initially contributed by Maxim in a previous RFC patch series.
The lwIP stack needs to be added as a Git subtree with the following
command:
$ git subtree add --squash --prefix lib/lwip/lwip \
https://github.com/lwip-tcpip/lwip.git STABLE-2_2_0_RELEASE
Signed-off-by: Jerome Forissier <[email protected]>
Co-developed-by: Maxim Uvarov <[email protected]>
Cc: Maxim Uvarov <[email protected]>
Acked-by: Ilias Apalodimas <[email protected]>
|
|
Add a function to start a given network device, and update eth_init()
to use it.
Signed-off-by: Jerome Forissier <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
Make net.h a wrapper which includes net-common.h and either
net-legacy.h or net-lwip.h based on NET_LWIP. The function
copy_filename() can be useful when NET_LWIP is enabled, therefore
move it out of net/net.c which is built only when networking choice
is NET and create a new file net/net-common.c.
Signed-off-by: Jerome Forissier <[email protected]>
Acked-by: Ilias Apalodimas <[email protected]>
|
|
Prepare the introduction of the lwIP (lightweight IP) TCP/IP stack by
adding a new net/lwip/ directory and the NET_LWIP symbol. Network
support is either NO_NET, NET (legacy stack) or NET_LWIP. Subsequent
commits will introduce the lwIP code, re-work the NETDEVICE integration
and port some of the NET commands and features to lwIP.
SPL_NET cannot be enabled when NET_LWIP=y. SPL_NET pulls some symbols
that are part of NET (such as arp_init(), arp_timeout_check(),
arp_receive(), net_arp_wait_packet_ip()). lwIP support in SPL may be
added later.
Similarly, DFU_TFTP and FASTBOOT are not compatible with NET_LWIP
because of dependencies on net_loop(), tftp_timeout_ms,
tftp_timeout_count_max and other NET things. Let's add a dependency on
!NET_LWIP for now.
SANDBOX can select NET_LWIP but doing so will currently disable the eth
dm tests as well as the wget tests which have strong dependencies on the
NET code.
Other adjustments to Kconfig files are made to fix "unmet direct
dependencies detected" for USB_FUNCTION_SDP and CMD_FASTBOOT when
the default networking stack is set to NET_LWIP ("default NET_LWIP"
instead of "default NET" in Kconfig).
The networking stack is now a choice between NO_NET,
NET and NET_LWIP. Therefore '# CONFIG_NET is not set' should be
'CONFIG_NO_NET=y'. Adjust the defconfigs accordingly.
Signed-off-by: Jerome Forissier <[email protected]>
Acked-by: Ilias Apalodimas <[email protected]>
|
|
The tools-only defconfig causes troubles on MacOSX due to the default
C compiler being Clang (LLVM) rather than GCC and more specifically
due to [1]. Therefore replace "# CONFIG_FOO is not set" with the
equivalent "CONFIG_FOO=n" using the following command:
$ sed -i -e 's/# \(CONFIG_[^ ]*\) is not set/\1=n/' \
configs/tools-only_defconfig
This fixes the tools_only_macOS CI job on GitHub [2].
[1] https://github.com/llvm/llvm-project/issues/78778
[2] https://dev.azure.com/u-boot/u-boot/_build/results?buildId=9105&view=results
Suggested-by: Tom Rini <[email protected]>
Signed-off-by: Jerome Forissier <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
|
|
git-subtree-dir: lib/lwip/lwip
git-subtree-split: 0a0452b2c39bdd91e252aef045c115f88f6ca773
|
|
Update e-mail address.
Signed-off-by: Eugen Hristev <[email protected]>
|
|
:hile we had hoped to be able to remove these options finally, it was
missed that zynq still requires these currently.
This reverts commit 5b9261fb0b1ed087387f2036d279fd3f4bb20a61 and
commit 099b6df556c95f5d06864612e9199eab7ba50ed3.
Reported-by: Jonas Karlman <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
|
|
Sughosh Ganu <[email protected]> says:
This is part two of the series to have the EFI and LMB modules have a
coherent view of memory. Part one of this goal was to change the LMB
module to have a global and persistent memory map. Those patches have
now been applied to the next branch.
These patches are changing the EFI memory allocation API's such that
they rely on the LMB module to allocate RAM memory. This fixes the
current scenario where the EFI memory module has no visibility of the
allocations/reservations made by the LMB module. One thing to note
here is that this is limited to the RAM memory region, i.e. the
EFI_CONVENTIONAL_MEMORY type. Any other memory type that is to be
added to the EFI memory map, still gets handled by the EFI memory
module.
Changes since V3:
* Add comments for the LMB_NOOVERWRITE and LMB_NONOTIFY flags
* Drop use of is_addr_in_ram() function
* Drop use of CONFIG_MEM_MAP_UPDATE_NOTIFY symbol to check if the
notification needs to be sent.
* s/lmb_notify/lmb_should_notify
* Put a check for EFI_LOADER in the lmb_should_notify() function
Some test logs to highlight the issue that is being fixed by the series.
Without patch series
--------------------
lmb_dump_all:
memory.count = 0x1
memory[0] [0x40000000-0x820fffff], 0x42100000 bytes flags: none
reserved.count = 0x3
reserved[0] [0xe100000-0xeffffff], 0x00f00000 bytes flags: no-map
reserved[1] [0x42000000-0x421fffff], 0x00200000 bytes flags: no-map
reserved[2] [0x7f77da00-0x820fffff], 0x02982600 bytes flags: no-overwrite
=> efidebug memmap -- does not show regions allocated by lmb
Missing TPMv2 device for EFI_TCG_PROTOCOL
Type Start End Attributes
================ ================ ================ ==========
CONVENTIONAL 0000000040000000-000000007f751000 WB
BOOT DATA 000000007f751000-000000007f756000 WB
RUNTIME DATA 000000007f756000-000000007f757000 WB|RT
BOOT DATA 000000007f757000-000000007f758000 WB
RUNTIME DATA 000000007f758000-000000007f77a000 WB|RT
BOOT DATA 000000007f77a000-000000007f781000 WB
BOOT CODE 000000007f781000-00000000807b5000 WB
RUNTIME DATA 00000000807b5000-00000000807b6000 WB|RT
BOOT CODE 00000000807b6000-00000000817c0000 WB
RUNTIME CODE 00000000817c0000-00000000817d0000 WB|RT
BOOT CODE 00000000817d0000-0000000082100000 WB
=>
Trying to allocate EFI memory with already allocated region succeeds(should fail)
---------------------------------------------------------------------------------
=> efi_mem alloc 2000 42000000
Address returned 0x42000000
=> efidebug memmap
Type Start End Attributes
================ ================ ================ ==========
CONVENTIONAL 0000000040000000-0000000042000000 WB
BOOT DATA 0000000042000000-0000000042002000 WB
CONVENTIONAL 0000000042002000-000000007f751000 WB
BOOT DATA 000000007f751000-000000007f756000 WB
RUNTIME DATA 000000007f756000-000000007f757000 WB|RT
BOOT DATA 000000007f757000-000000007f758000 WB
RUNTIME DATA 000000007f758000-000000007f77a000 WB|RT
BOOT DATA 000000007f77a000-000000007f781000 WB
BOOT CODE 000000007f781000-00000000807b5000 WB
RUNTIME DATA 00000000807b5000-00000000807b6000 WB|RT
BOOT CODE 00000000807b6000-00000000817c0000 WB
RUNTIME CODE 00000000817c0000-00000000817d0000 WB|RT
BOOT CODE 00000000817d0000-0000000082100000 WB
=>
With patch series
-----------------
lmb_dump_all:
memory.count = 0x1
memory[0] [0x40000000-0x820fffff], 0x42100000 bytes flags: none
reserved.count = 0x4
reserved[0] [0xe100000-0xeffffff], 0x00f00000 bytes flags: no-map
reserved[1] [0x42000000-0x421fffff], 0x00200000 bytes flags: no-map
reserved[2] [0x7f74f000-0x7f77dfff], 0x0002f000 bytes flags: no-notify, no-overwrite
reserved[3] [0x7f77ea00-0x820fffff], 0x02981600 bytes flags: no-overwrite
=> efidebug memmap
Type Start End Attributes
================ ================ ================ ==========
BOOT DATA 000000000e100000-000000000f000000 WB
CONVENTIONAL 0000000040000000-0000000042000000 WB
BOOT DATA 0000000042000000-0000000042200000 WB
CONVENTIONAL 0000000042200000-000000007f74e000 WB
BOOT DATA 000000007f74e000-000000007f753000 WB
RUNTIME DATA 000000007f753000-000000007f754000 WB|RT
BOOT DATA 000000007f754000-000000007f755000 WB
RUNTIME DATA 000000007f755000-000000007f777000 WB|RT
BOOT DATA 000000007f777000-00000000807b6000 WB
RUNTIME DATA 00000000807b6000-00000000807b7000 WB|RT
BOOT DATA 00000000807b7000-00000000817c0000 WB
RUNTIME CODE 00000000817c0000-00000000817d0000 WB|RT
BOOT DATA 00000000817d0000-0000000082100000 WB
Trying to allocate EFI memory with already allocated region fails
-----------------------------------------------------------------
=> efi_mem alloc 2000 42000000
efi_allocate_pages failed 800000000000000e
=>
Trying to allocate EFI memory with non-allocated region succeeds
----------------------------------------------------------------
=> efi_mem alloc 2000 42200000
Address returned 0x42200000
=> efidebug memmap
Type Start End Attributes
================ ================ ================ ==========
BOOT DATA 000000000e100000-000000000f000000 WB
CONVENTIONAL 0000000040000000-0000000042000000 WB
BOOT DATA 0000000042000000-0000000042202000 WB
CONVENTIONAL 0000000042202000-000000007f74d000 WB
BOOT DATA 000000007f74d000-000000007f752000 WB
RUNTIME DATA 000000007f752000-000000007f753000 WB|RT
BOOT DATA 000000007f753000-000000007f754000 WB
RUNTIME DATA 000000007f754000-000000007f776000 WB|RT
BOOT DATA 000000007f776000-00000000807b5000 WB
RUNTIME DATA 00000000807b5000-00000000807b6000 WB|RT
BOOT DATA 00000000807b6000-00000000817c0000 WB
RUNTIME CODE 00000000817c0000-00000000817d0000 WB|RT
BOOT DATA 00000000817d0000-0000000082100000 WB
=>
lmb_dump_all:
memory.count = 0x1
memory[0] [0x40000000-0x820fffff], 0x42100000 bytes flags: none
reserved.count = 0x5
reserved[0] [0xe100000-0xeffffff], 0x00f00000 bytes flags: no-map
reserved[1] [0x42000000-0x421fffff], 0x00200000 bytes flags: no-map
reserved[2] [0x42200000-0x42201fff], 0x00002000 bytes flags: no-notify, no-overwrite
reserved[3] [0x7f74e000-0x7f77cfff], 0x0002f000 bytes flags: no-notify, no-overwrite
reserved[4] [0x7f77da00-0x820fffff], 0x02982600 bytes flags: no-overwrite
Link: https://lore.kernel.org/r/[email protected]
|
|
A bunch of static functions in the LMB module have used a
double-undersore for the function names. It was suggested to use a
single-underscore instead, as the double-underscore is usually used
by library functions. Replace the double-underscore with
single-underscore for all functions.
Signed-off-by: Sughosh Ganu <[email protected]>
Suggested-by: Simon Glass <[email protected]>
|
|
The variable overlap_only_ram is used to specify that the new memory
region that is being created needs to come from the free memory pool
-- this is done by carving out the memory region from the free
memory. The name is a bit confusing though, as other allocated memory
regions, like boot-services code and data are also part of the RAM
memory. Rename the variable to overlap_conventional to highlight the
fact that it is the free/conventional memory that is being referred to
in this context.
Signed-off-by: Sughosh Ganu <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
The EFI memory allocations are now being done through the LMB
module. With this change, there is no need to get the EFI memory map
and set aside EFI allocated memory.
Signed-off-by: Sughosh Ganu <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
The EFI_CONVENTIONAL_MEMORY type, which is the usable RAM memory is
now being managed by the LMB module. Remove the addition of this
memory type to the EFI memory map. This memory now gets added to the
EFI memory map as part of the LMB memory map update event handler.
Signed-off-by: Sughosh Ganu <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
The EFI_CONVENTIONAL_MEMORY type is now being managed through the LMB
module. Add a separate function, lmb_arch_add_memory() to add the RAM
memory to the LMB memory map. The efi_add_known_memory() function is
now used for adding any other memory type to the EFI memory map.
Signed-off-by: Sughosh Ganu <[email protected]>
|
|
The EFI memory allocations are now being done through the LMB module,
and hence the memory map is maintained by the LMB module. Use the
lmb_arch_add_memory() API function to add the usable RAM memory to the
LMB's memory map.
Signed-off-by: Sughosh Ganu <[email protected]>
|
|
Some architectures have special or unique aspects which need
consideration when adding memory ranges to the list of available
memory map. Enable this config in such scenarios which allow
architectures and boards to define their own memory map.
Signed-off-by: Sughosh Ganu <[email protected]>
|
|
The efi_add_known_memory() function for the stm32mp platforms is adding
the EFI_CONVENTIONAL_MEMORY type. This memory is now being handled
through the LMB module -- the lmb_add_memory() adds this memory to the
memory map. Remove the definition of the now superfluous
efi_add_known_memory() function.
Signed-off-by: Sughosh Ganu <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
The efi_add_known_memory() function for the TI K3 platforms is adding
the EFI_CONVENTIONAL_MEMORY type. This memory is now being handled
through the LMB module -- the lmb_add_memory() adds this memory to the
memory map. Remove the definition of the now superfluous
efi_add_known_memory() function.
Signed-off-by: Sughosh Ganu <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
The memory region occupied by U-Boot is reserved by LMB, and gets
added to the EFI memory map through a call from the LMB module. Remove
this superfluous addition to the EFI memory map.
Signed-off-by: Sughosh Ganu <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
In U-Boot, LMB and EFI are two primary modules who provide memory
allocation and reservation API's. Both these modules operate with the
same regions of memory for allocations. Use the LMB memory map update
event to notify other interested listeners about a change in it's
memory map. This can then be used by the other module to keep track of
available and used memory.
There is no need to send these notifications when the LMB module is
being unit-tested. Add a flag to the lmb structure to indicate if the
memory map is being used for tests, and suppress sending any
notifications when running these unit tests.
Signed-off-by: Sughosh Ganu <[email protected]>
|
|
Use the LMB API's for allocating and freeing up memory. With this, the
LMB module becomes the common backend for managing non U-Boot image
memory that might be requested by other modules.
Signed-off-by: Sughosh Ganu <[email protected]>
|
|
U-Boot does not use memory above ram_top. However, this memory does
need to get registered as part of the memory map, so that subsystems
like EFI pass it on to the operating system as part of the EFI memory
map. Add memory above ram_top and reserve it with the LMB_NOOVERWRITE
flag so that it does not get allocated or re-used.
Signed-off-by: Sughosh Ganu <[email protected]>
Suggested-by: Mark Kettenis <[email protected]>
|
|
Add a flag LMB_NONOTIFY that can be passed to the LMB API's for
reserving memory. This will then result in no notification being sent
from the LMB module for the changes to the LMB's memory map.
While here, also add a description of the memory attributes that the
flags signify.
Signed-off-by: Sughosh Ganu <[email protected]>
|
|
The LMB module is to be used as a backend for allocating and freeing
up memory requested from other modules like EFI. These memory requests
are different from the typical LMB reservations in that memory
required by the EFI module cannot be overwritten, or re-requested. Add
versions of the LMB API functions with flags for allocating and
freeing up memory. The caller can then use these API's for specifying
the type of memory that is required. For now, these functions will be
used by the EFI memory module.
Signed-off-by: Sughosh Ganu <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
A comment in test-main.c was not updated with the recent rename. Fix it.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Mattijs Korpershoek <[email protected]>
|
|
The SPL_FIT_GENERATOR is long superseded by binman, drop SPL_FIT_GENERATOR
support as there are no more users.
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Peter Robinson <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
The SPL_FIT_SOURCE is long superseded by SPL_FIT_GENERATOR which
is long superseded by binman, drop SPL_FIT_SOURCE support as there
are no more users.
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Reviewed-by: Peter Robinson <[email protected]>
|
|
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: 16060854095 ("cmd: Rename CMD_MISC to CMD_SLEEP")
Signed-off-by: Andrew Goodbody <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
When we have platforms being emulated by QEMU we cannot rely on the
"sleep" command running for the expected wall-clock amount of time. Even
with our current allowance for deviation from expected time, it will
still fail from time to time. Exclude the sleep test here.
Signed-off-by: Tom Rini <[email protected]>
|
|
* Remove duplicate debug message in wget_connected()
* Correct typo 'Connctd'
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Peter Robinson <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
After downloading a file with wget the file size may be needed in follow up
actions, e.g.
* write file to device
* calculate hash
Let wget set the environment variable filesize.
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
The commit 0252924ac6d4 ("mmc: dw_mmc: Extract FIFO data transfer into a
separate routine") unintentionally changed behavior of the FIFO data
transfer routine.
When data is read and size reaches 0 the original loop would wait on
DWMCI_INTMSK_DTO or timeout. The remaining size to read and buf position
is no longer tracked across dwmci_data_transfer_fifo() calls and because
of this an extra call to fifo() and dwmci_fifo_ready() may now trigger a
FIFO underflow timeout error and slows down FIFO reading.
Buswidth = 4, clock: 50000000
Sending CMD16
Sending CMD17
dwmci_fifo_ready: FIFO underflow timeout
Sending CMD16
Sending CMD18
dwmci_fifo_ready: FIFO underflow timeout
Sending CMD12
## Checking hash(es) for config config-1 ... OK
This reverts commit 0252924ac6d4af69061bb9589d16b30c5bdb7178 to restore
the old working behavior.
Fixes: 0252924ac6d4 ("mmc: dw_mmc: Extract FIFO data transfer into a separate routine")
Signed-off-by: Jonas Karlman <[email protected]>
Tested-by: Quentin Schulz <[email protected]> # RK3588 Tiger
Reviewed-by: Simon Glass <[email protected]>
|
|
Simon Glass <[email protected]> says:
This series collects together the patches from the Labgrid series which
are not related to Labgrid, or at least can be applied independently of
using Labgrid to run the lab.
Link: https://lore.kernel.org/r/[email protected]
|
|
This series from Martyn Welch <[email protected]> adds the
ability to have a "fallback" option in extlinux.conf parsing, which can
be in turn used in A/B style update mechanisms.
Link: https://lore.kernel.org/u-boot/[email protected]/
|
|
We have added a "set" sub command to bootmeth, add some tests to check
it's operation.
Signed-off-by: Martyn Welch <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Fix a typo in a comment.
Signed-off-by: Simon Glass <[email protected]>
|
|
We have previously added logic to allow a "fallback" option to be
specified in the extlinux configuration. Provide a command that allows
us to set this as the preferred default option when booting.
Combined with the bootcount functionality, this allows the "altbootcmd"
to provide a means of falling back to a previously known good state
after a failed update. For example, if "bootcmd" is set to:
bootflow scan -lb
We would set "altbootcmd" to:
bootmeth set extlinux fallback 1; bootflow scan -lb
Causing the boot process to boot from the fallback option.
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Martyn Welch <[email protected]>
|
|
Use the new handle_exception() function from ConsoleBase also.
Signed-off-by: Simon Glass <[email protected]>
|
|
The "fallback" extlinux config option allows us to set an alternative
default boot option for when it has been detected that the default is
failing. Implement the logic required to boot from this option when
desired.
Signed-off-by: Martyn Welch <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
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 <[email protected]>
|
|
When configured correctly, we can detect when boot fails after the boot
process has been handed over to the kernel through the use of U-Boot's
bootcount support. In some instances, such as when we are performing
atomic updates via a system such as OSTree, it is desirable to provide a
fallback option so that we can return to a previous (hopefully working)
state.
Add a "fallback" option to the supported extlinux configuration options
that points to a label like "default" so that we can utilise this in
later commits.
Signed-off-by: Martyn Welch <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
|
|
When a test returns -EAGAIN this should not be considered a failure.
Fix what seems to be a problem case, where the pytests see a failure
when a test has merely been skipped.
We cannot squash the -EAGAIN error in ut_run_test() since the failure
count is incremented by its caller, ut_run_test_live_flat()
The specific example here is on snow, where a test is compiled into the
image but cannot run, so returns -EAGAIN to skip:
test/py/tests/test_ut.py sssnow # ut bdinfo bdinfo_test_eth
Test: bdinfo_test_eth: bdinfo.c
Skipping: Console recording disabled
test/test-main.c:486, ut_run_test_live_flat(): 0 == ut_run_test(uts,
test, test->name): Expected 0x0 (0), got 0xfffffff5 (-11)
Test bdinfo_test_eth failed 1 times
Skipped: 1, Failures: 1
snow # F+u-boot-test-reset snow snow
The fix is simply to respect the return code from ut_run_test(), so do
that.
Signed-off-by: Simon Glass <[email protected]>
|
