Add a unit test to verify that the SPI word length configuration is
correctly handled by the SPI uclass and successfully passed down to
the sandbox driver.
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Reviewed-by: Simon Glass <simon.glass@canonical.com>
Quentin Schulz <foss+uboot@0leil.net> says:
This migrates the net options away from the main Kconfig to net/Kconfig,
rename the current NET option to NET_LEGACY to really highlight what it
is and hopefully encourage more people to use lwIP, add a new NET
menuconfig (but keep NO_NET as an alias to NET=n for now) which then
allows us to replace all the "if legacy_stack || lwip_stack" checks with
"if net_support" which is easier to read and maintain.
The only doubt I have is wrt SYS_RX_ETH_BUFFER which seems to be needed
for now even when no network is configured? Likely due to
include/net-common.h with PKTBUFSRX?
No change in behavior is intended. Only change in defconfig including
other defconfigs where NO_NET=y or NET is not set, in which case NO_NET
is not set or NET=y should be set in the top defconfig. Similar change
required for config fragments. See commit log in patch adding NET
menuconfig for details.
This was tested based on 70fd0c3bb7c2 ("x86: there is no
CONFIG_UBOOT_ROMSIZE_KB_12288"), from within the GitLab CI container
trini/u-boot-gitlab-ci-runner:noble-20251013-23Jan2026 and set up
similarly as in "build all platforms in a single job" GitLab CI job.
#!/usr/bin/env bash
set -o pipefail
set -eux
ARGS="-BvelPEWM --reproducible-builds --step 0"
./tools/buildman/buildman -o ${O} --force-build $ARGS -CE $*
./tools/buildman/buildman -o ${O} $ARGS -Ssd $*
O=../build/u-boot/ ../u-boot.sh -b master^..b4/net-kconfig |& tee ../log.txt
I can't really decipher the log.txt, but there's no line starting with
+ which would be an error according to tools/buildman/builder.py help
text. Additionally, because I started the script with set -e set and
because buildman has an exit code != 0 when it fails to build a board,
and I have the summary printed (which is the second buildman call), I
believe it means all builds passed.
The summary is the following:
aarch64: (for 537/537 boards) all +0.0 rodata +0.0
uniphier_v8 : all +1 rodata +1
u-boot: add: 0/0, grow: 1/0 bytes: 1/0 (1)
function old new delta
data_gz 10640 10641 +1
arm: (for 733/733 boards) all -0.0 rodata -0.0
uniphier_v7 : all -1 rodata -1
u-boot: add: 0/0, grow: 0/-1 bytes: 0/-1 (-1)
function old new delta
data_gz 11919 11918 -1
opos6uldev : all -3 rodata -3
u-boot: add: 0/0, grow: 0/-1 bytes: 0/-3 (-3)
function old new delta
data_gz 18778 18775 -3
uniphier_ld4_sld8: all -3 rodata -3
u-boot: add: 0/0, grow: 0/-1 bytes: 0/-3 (-3)
function old new delta
data_gz 11276 11273 -3
stemmy : all -20 rodata -20
u-boot: add: 0/0, grow: 0/-1 bytes: 0/-20 (-20)
function old new delta
data_gz 15783 15763 -20
As far as I could tell this data_gz is an automatically generated array
when CONFIG_CMD_CONFIG is enabled. It is the compressed .config stored
in binary form. Because I'm changing the name of symbols, replacing a
menu with a menuconfig, additional text makes it to .config and the
"# Networking" section in .config disappears.
Here is the diff for the 5 defconfigs listed above, generated with:
for f in build/*-m; do
diff --unified=0 $f/.config $(dirname $f)/$(basename -a -s '-m' $f)/.config
done
(-m is the build directory for master, and without the suffix, it's the
top commit of this series)
"""
--- build/opos6uldev-m/.config 2026-04-20 10:53:49.804528526 +0200
+++ build/opos6uldev/.config 2026-04-20 11:03:37.430242767 +0200
@@ -970,4 +969,0 @@
-
-#
-# Networking
-#
@@ -975,0 +972 @@
+CONFIG_NET_LEGACY=y
--- build/stemmy-m/.config 2026-04-20 11:01:33.653698123 +0200
+++ build/stemmy/.config 2026-04-20 11:04:53.452577311 +0200
@@ -733,4 +732,0 @@
-
-#
-# Networking
-#
@@ -738,2 +733,0 @@
-# CONFIG_NET is not set
-# CONFIG_NET_LWIP is not set
--- build/uniphier_ld4_sld8-m/.config 2026-04-20 11:00:41.605469071 +0200
+++ build/uniphier_ld4_sld8/.config 2026-04-20 11:04:22.226439899 +0200
@@ -997,4 +996,0 @@
-
-#
-# Networking
-#
@@ -1002,0 +999 @@
+CONFIG_NET_LEGACY=y
--- build/uniphier_v7-m/.config 2026-04-20 10:53:04.019307319 +0200
+++ build/uniphier_v7/.config 2026-04-20 11:03:01.688085486 +0200
@@ -1004,4 +1003,0 @@
-
-#
-# Networking
-#
@@ -1009,0 +1006 @@
+CONFIG_NET_LEGACY=y
--- build/uniphier_v8-m/.config 2026-04-20 10:43:05.614441175 +0200
+++ build/uniphier_v8/.config 2026-04-20 10:41:03.214852130 +0200
@@ -875,4 +874,0 @@
-
-#
-# Networking
-#
@@ -880,0 +877 @@
+CONFIG_NET_LEGACY=y
"""
This is fine:
- Networking menu doesn't exist anymore so "#\n# Networking\n#\n" won't
be in .config anymore.
- opos6uldev, uniphier_ld4_sld8, uniphier_v7 and uniphier_v8 all have
(old) CONFIG_NET enabled, (new) CONFIG_NET will still be set but
CONFIG_NET_LEGACY also needs to be defined now to reflect the stack
choice (even if default),
- stemmy has CONFIG_NO_NET set, which means CONFIG_NET and
CONFIG_NET_LWIP are not reachable anymore hence why they don't need to
be part of .config,
GitLab CI was run on this series (well, not exactly, but it's only
changes to the git logs that were made):
https://source.denx.de/u-boot/contributors/qschulz/u-boot/-/pipelines/29849
It passes.
Link: https://lore.kernel.org/r/20260420-net-kconfig-v1-0-9900002d8e72@cherry.de
Highlight that NET really is the legacy networking stack by renaming the
option to NET_LEGACY.
This requires us to add an SPL_NET_LEGACY alias to SPL_NET as otherwise
CONFIG_IS_ENABLED(NET_LEGACY) will not work for SPL.
The "depends on !NET_LWIP" for SPL_NET clearly highlights that it is
using the legacy networking app so this seems fine to do.
This also has the benefit of removing potential confusion on NET being a
specific networking stack instead of "any" network stack.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Switch fwu_boottime_checks() from EVT_MAIN_LOOP to EVT_POST_PREBOOT
because there is no reason to call FWU so early. FWU triggers EFI
stack initialization before all devices are visible which prevents
the EFI stack from scanning these devices and adding them to EFI
variables.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
event_notify_null() returns int but its return value is not
checked in run_main_loop() and in fwu_mdata tests.
Add proper error checking to all unchecked call sites.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Rework dev_phys_to_bus() and dev_bus_to_phys() to respect the size
of the area specified in dma-ranges DT property. The area outside
of ranges is remapped 1:1, while the area in the ranges is remapped
according to the description in the dma-ranges property.
Adjust the test to test the area within the remapped range, not area
outside the remapped range, which was incorrect.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Markus Schneider-Pargmann <msp@baylibre.com>
The virtio spec clearly states in "3.1.1 Driver Requirements: Device
Initialization" the sequence a client has to follow after device reset.
Because u-boot resets here again, it also needs to set the "acknowledge"
bit again even if this was done in virtio_uclass_child_post_bind already
once before.
Signed-off-by: Christian Pötzsch <christian.poetzsch@kernkonzept.com>
Signed-off-by: Adam Lackorzynski <adam@l4re.org>
[trini: Add VIRTIO_CONFIG_S_ACKNOWLEDGE flag check to the test]
Signed-off-by: Tom Rini <trini@konsulko.com>
Meet Patel <meet.patel2@arm.com> says:
The virtio-rng test to verify effective handling of oversized return
buffers checks that an (undocumented) error is raised, instead of the
real concern, which is the surrounding buffer integrity following a rng
function call.
Update the test to check that the other contents of a buffer remain
unchanged instead of looking for an error code.
Link: https://lore.kernel.org/r/20260309165505.4001705-1-meet.patel2@arm.com
The virtio-rng test to verify effective handling of oversized return
buffers checks that an (undocumented) error is raised, instead of the
real concern, which is the surrounding buffer integrity following a rng
function call.
Update the test to check that the other contents of a buffer remain
unchanged instead of looking for an error code.
Signed-off-by: Kavin Gunasekara <kavin.gunasekara@arm.com>
Signed-off-by: Meet Patel <meet.patel2@arm.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Remove DECLARE_GLOBAL_DATA_PTR from files where gd is not used, and
drop the unnecessary inclusion of asm/global_data.h.
Headers should be included directly by the files that need them,
rather than indirectly via global_data.h.
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> #STMicroelectronics boards and STM32MP1 ram test driver
Tested-by: Anshul Dalal <anshuld@ti.com> #TI boards
Acked-by: Yao Zi <me@ziyao.cc> #TH1520
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Add a test for binding of multiple drivers with the same compatible. If
one of the drivers returns -ENODEV the other one needs to be bound.
Reviewed-by: Simon Glass <simon.glass@canonical.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Signed-off-by: Markus Schneider-Pargmann (TI.com) <msp@baylibre.com>
* Expected values must always be the first arguments.
* Long values on 64 bit systems require ut_asserteq_64() for checking
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
This pull request brings together a set of fixes and enhancements across
the SoCFPGA platform family, with a focus on MMC/SPL robustness, EFI
boot enablement, and Agilex5 SD/eMMC support.
CI: https://source.denx.de/u-boot/custodians/u-boot-socfpga/-/pipelines/28776
Highlights:
*
SPL / MMC:
o
Fix Kconfig handling for
SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE
o
Correct raw sector calculations and respect explicit sector values
when loading U-Boot from MMC in SPL
o
Adjust raw MMC loading logic for SoCFPGA platforms
*
EFI boot:
o
Permit EFI booting on SoCFPGA platforms
o
Disable mkeficapsule tool build for Arria 10 where unsupported
*
Agilex5:
o
Upgrade SDHCI controller from SD4HC to SD6HC
o
Enable MMC and Cadence SDHCI support in defconfig
o
Add dedicated eMMC device tree and defconfig for Agilex5 SoCDK
o
Revert incorrect GPIO configuration for SDIO_SEL
o
Refine U-Boot DT handling for SD and eMMC boot variants
*
SPI:
o
Allow disabling the DesignWare SPI driver in SPL via Kconfig
*
Board / configuration fixes:
o
Enable random MAC address generation for Cyclone V
o
Fix DE0-Nano-SoC boot configuration
o
Remove obsolete or conflicting options from multiple legacy
SoCFPGA defconfigs
While this change was intended to fix a mistake in the code, of calling
the ERR_PTR macro but not making use of the result, it seems that
functionally platforms depend on the loop not existing here. The TI K3
families of platforms for example were broken by this commit.
This reverts commit fe780310cfa8bf5a093894b5cd7fe85c6b02fd91.
Reported-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Reviewed-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
The current FDT decoding tests calculate the memory required
for FDT manipulation by directly adding a fixed margin to
fdt_totalsize(gd->fdt_blob). The static analyzer flagged
"gd->fdt_blob->totalsize" as a tainted value being passed
to fdt_open_into().
Ensure the size is validated by checking that the total size
is within a reasonable maximum FDT limit for unit tests.
Signed-off-by: Adriana Nicolae <adriana@arista.com>
Andrew Goodbody <andrew.goodbody@linaro.org> says:
Smatch reported an error where a value calculated by ERR_PTR was not
used. Fixing this to return the generated value led to a test failure
which meant updating the sandbox clock code so that it would still cause
the tests to pass with the above correction.
Debugging this problem led to a SIGSEGV which is addressed in 1/3.
Possible memory leaks noticed are addressed in 3/3.
Link: https://lore.kernel.org/r/20251121-clk_uclass_fix-v2-0-74f4ea10e194@linaro.org
In clk_set_default_get_by_id ret is passed to ERR_PTR but nothing is
done with the value that this calculates which is obviously not the
intention of the code. This is confirmed by the code around where this
function is called.
Instead return the value from ERR_PTR.
Then fixup the sandbox code so that the test dm_test_clk does not fail
as it relied on the broken behaviour.
Finally disable part of the test that does not work correctly with
CLK_AUTO_ID
This issue found by Smatch.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
The Linux kernel can discover SMBIOS tables through two primary methods:
1. Via EFI tables, when using EFI boot;
2. Via the 'smbios3-entrypoint' property in the /chosen node of the
device tree.
When U-Boot boots a Linux kernel using a non-EFI command ("bootm",
"bootz", or "booti"), the kernel relies on the device tree to detect
the hardware. If SMBIOS tables are available in U-Boot, they should
be passed to the kernel via this device tree property.
This patch modifies boot_fdt_prepare(), to inject the SMBIOSv3 table
address into the device tree if there is a table generated by U-boot.
The "board_fdt_chosen_smbios" is weak in order to leave the possibilty
for specific boards to select custom SMBIOS addresses.
The changes in this patch are added in the context of supporting this
device tree property in linux kernel:
https://lkml.org/lkml/2025/10/24/1393
Device tree schema was updated to include the "smbios3-entrypoint" node
in pull request: https://github.com/devicetree-org/dt-schema/pull/177
Signed-off-by: Adriana Nicolae <adriana@arista.com>
Trivially fix the following warnings in sandbox DTs, which show up with
DTC 1.7.2. Fill in the missing address and adjust emulated I2C address
to fit the 7bit address limit:
"
arch/sandbox/dts/sandbox.dtsi:138.30-140.5: Warning (i2c_bus_reg): /i2c@0/sandbox_pmic: I2C bus unit address format error, expected "40"
arch/sandbox/dts/sandbox.dtsi:146.18-161.5: Warning (i2c_bus_reg): /i2c@0/emul: I2C bus unit address format error, expected "ff"
arch/sandbox/dts/sandbox.dtsi:148.4-17: Warning (i2c_bus_reg): /i2c@0/emul:reg: I2C address must be less than 7-bits, got "0xff". Set I2C_TEN_BIT_ADDRESS for 10 bit addresses or fix the property
"
"
arch/sandbox/dts/.test.dtb.pre.tmp:912.18-926.5: Warning (i2c_bus_reg): /i2c@0/emul: I2C bus unit address format error, expected "ff"
arch/sandbox/dts/.test.dtb.pre.tmp:913.4-17: Warning (i2c_bus_reg): /i2c@0/emul:reg: I2C address must be less than 7-bits, got "0xff". Set I2C_TEN_BIT_ADDRESS for 10 bit addresses or fix the property
arch/sandbox/dts/.test.dtb.pre.tmp:928.30-931.5: Warning (i2c_bus_reg): /i2c@0/sandbox_pmic: I2C bus unit address format error, expected "40"
"
Fix up pmic test to match.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Heiko Schocher <hs@nabladev.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Add a test suite exercising the whole lifetime and callbacks
of interconnect with a fake 5 providers with a split node graph.
The test suite checks the calculus are right and goes to the correct
nodes, and the lifetime of the node is correct.
Link: https://patch.msgid.link/20251120-topic-interconnect-next-v5-2-e8a82720da5d@linaro.org
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Rasmus Villemoes <ravi@prevas.dk> says:
Hopefully third time's the charm.
I merely wanted to add support (mostly for use by the 'gpio' shell
command) for looking up a gpio via the gpio-line-names DT property. We
already have a "gpio_request_by_line_name()", but cmd/gpio.c does a
separate "lookup + request", so it felt more natural to teach the
lookup machinery this as well. That ran into
OF_CONTROL-but-not-OF_LIBFDT being a thing for SPL, so here's yet
another attempt.
Now, when trying to do my civic duty and add tests for this, I found
that test/dm/gpio.c has been defunct for a couple of years, and
reinstating it is not entirely trivial.
After a couple of rounds CI is now happy with this:
https://github.com/u-boot/u-boot/pull/828
Link: https://lore.kernel.org/r/20251104174458.3385564-1-ravi@prevas.dk
Commit ebaa3d053e5 ("test: fix CONFIG_ACPIGEN dependencies"), which
got into v2022.10-rc1, accidentally left out a $
before (CONFIG_DM_GPIO), with the effect that test/dm/gpio.c has not
been built for three years.
Unsurprisingly, the code in there has bit-rotted.
- There's a missing ; causing plain build fail.
That code was added in 9bf87e256c2 ("test: dm: update test for
open-drain/open-source emulation in gpio-uclass"), which was part of
v2020.07-rc3, i.e. long before the commit causing gpio.c to not be
built at all. It did build at that time, but also, the missing
semicolon wasn't found when fa847bb409d ("test: Wrap assert macros
in ({ ... }) and fix missing semicolons") happened in 2023.
- Commit 592b6f394ae ("led: add function naming option from linux")
bumped sandbox,gpio-count for bank gpio_a in test.dts to 25, but
didn't update the expected global gpio numbers accordingly.
- The "lookup by label" test likely worked when it was added, but then I
inadvertently broke it when I noticed that dm_gpio_lookup_label()
seemed to be broken in commit 10e66449d7e ("gpio-uclass: fix gpio
lookup by label") - which landed in v2023.01-rc1, so after gpio.c
was no longer being built.
The "label" (which is a u-boot concept) that a "hogged gpio" gets is
<gpio hog node name>.gpio-hog, which is why it used to work with the
strncmp() but doesn't with strcmp().
We can either revert 10e66449d7e or append the ".gpio-hog" suffix as
done below. I don't really have a dog in that race; when I did
10e66449d7e, it was because I thought the "lookup by label" was
actually about the standardized gpio-line-names property, but then I
learnt it was not, so is not at all useful to me.
- The leak check now fails.
Test: gpio_leak: gpio.c
test/dm/core.c:112, dm_leak_check_end(): uts->start.uordblks == end.uordblks: Expected 0x2a95b0 (2790832), got 0x2a9650 (2790992)
test/dm/gpio.c:328, dm_test_gpio_leak(): 0 == dm_leak_check_end(uts): Expected 0x0 (0), got 0x1 (1)
Test: gpio_leak: gpio.c (flat tree)
test/dm/core.c:112, dm_leak_check_end(): uts->start.uordblks == end.uordblks: Expected 0x2a9650 (2790992), got 0x2a9700 (2791168)
test/dm/gpio.c:328, dm_test_gpio_leak(): 0 == dm_leak_check_end(uts): Expected 0x0 (0), got 0x1 (1)
And it fails with the same differences (160/176) even if I
remove the three lines that actually exercise any of the gpio code,
i.e. make the whole function amount to
ut_assertok(dm_leak_check_end(uts));
Test: gpio_leak: gpio.c
test/dm/core.c:112, dm_leak_check_end(): uts->start.uordblks == end.uordblks: Expected 0x2a95b0 (2790832), got 0x2a9650 (2790992)
test/dm/gpio.c:325, dm_test_gpio_leak(): 0 == dm_leak_check_end(uts): Expected 0x0 (0), got 0x1 (1)
Test: gpio_leak: gpio.c (flat tree)
test/dm/core.c:112, dm_leak_check_end(): uts->start.uordblks == end.uordblks: Expected 0x2a9650 (2790992), got 0x2a9700 (2791168)
test/dm/gpio.c:325, dm_test_gpio_leak(): 0 == dm_leak_check_end(uts): Expected 0x0 (0), got 0x1 (1)
So I suspect that the leak is somewhere in the test framework
setup/teardown code - dm_leack_check_end() isn't really used
anywhere else except in a dm/core test. Bisecting to figure out
where that was introduced is somewhat of a hassle because of the
other bitrot, and because of the SWIG failure that makes it very
hard to build older U-Boots.
So since it's better to have most of the gpio tests actually
working instead of leaving all of gpio.c as dead code, #if 0 that
part out and leave it as an archeological exercise.
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Reviewed-by: Heiko Schocher <hs@nabladev.com>
The U-Boot project has been assigned the vendor ID 'UBOO' [1]. Use this
vendor ID and our release version in the ACPI table headers.
[1] ACPI ID Registry
https://uefi.org/ACPI_ID_List
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Some tests here had not been compile tested before submission and were
missing a ';' on the end of declaring struct udevice *dev. Add it.
Fixes: 9046279d92bb ("test: dm: Add tests for LED boot and activity")
Signed-off-by: Tom Rini <trini@konsulko.com>
The video test here is specific to the sandbox SDL video driver, so only
build it when that is enabled rather than VIDEO is enabled.
Reported-by: Alison Chaiken <alison@she-devel.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
uclass_find_next_device always returns 0, so instead make it a void and
update calling sites.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
In [0], Andrew noted a code quality issue in the implementation of
blk_find_first and blk_find_next. This led to the observation that the
logic of these functions was also likely incorrect, and based on a quick
check it seemed the functions were unused outside of test code, which
did not exercise the potential failure case, so we felt they should be
removed. In [1], a test patch which illustrates the failure in sandbox
is provided for reference.
Because a more thorough check agrees that these functions are unused,
they are currently incorrect, and fixed/removable flags on block devices
prior to probe are unreliable, just remove these functions instead of
fixing them. All potential users should have used blk_first_device_err
instead anyway.
CI results at [2].
[0] https://patchwork.ozlabs.org/project/uboot/patch/20250714-blk-uclass-v1-1-d21428c5f762@linaro.org/
[1] https://gist.github.com/gmalysa/b05e73a5c14bc18c5741a0e0e06a2992
[2] https://gitlab.com/gmalysa/lnxdsp-u-boot/-/pipelines/1931210857
Signed-off-by: Greg Malysa <malysagreg@gmail.com>
Reviewed-by: Andrew Goodbody <andrew.goodbody@linaro.org>
CI: https://source.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/26607
- Add clock and reset drivers support for STM32MP25
- Add STM32H747-Discovery board support
- Add tamp_nvram driver
- Add SPL support and clock tree init to STM32MP13 RCC driver
- Add STM32MP13xx ram support
- Add support for STM32 Image V2.0 for STM32MP13xx
- Fix SYSRAM size on STM32MP13xx
- Fix DBGMCU macro on STM32MP13xx
- Auto-detect ROM API table on STM32MP15xx
Update the existing test dm_test_clk_ccf() with new CLK_ID macro.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Cc: Lukasz Majewski <lukma@denx.de>
Cc: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Some of the Python tests are a pain because they don't reset the TPM
state before each test. Driver model tests do this, so convert the
tests to C.
This means that these tests won't run on real hardware, but we have
tests which do TPM init, so there is still enough coverage.
Rename and update the Python tpm_init test to use 'tpm autostart',
since this fully initializes the TPM and performs the self tests.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Now that env_get_ip() has been removed, the include file <net.h> does
not need anything from <env.h>. Furthermore, include/env.h itself
includes other headers which can lead to longer indirect inclusion
paths. To prepare to remove <env.h> from <net.h> fix all of the
remaining places which had relied on this indirect inclusion to instead
include <env.h> directly.
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org> # net/lwip
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
Reviewed-by: Martyn Welch <martyn.welch@collabora.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
The include file <command.h> does not need anything from <env.h>.
Furthermore, include/env.h itself includes other headers which can lead
to longer indirect inclusion paths. To prepare to remove <env.h> from
<command.h> fix all of the places which had relied on this indirect
inclusion to instead include <env.h> directly.
Signed-off-by: Tom Rini <trini@konsulko.com>
---
Cc: Anatolij Gustschin <agust@denx.de>
Cc: Bin Meng <bmeng.cn@gmail.com>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Cc: Jerome Forissier <jerome.forissier@linaro.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Lukasz Majewski <lukma@denx.de>
Cc: Marek Vasut <marex@denx.de>
Cc: Mark Kettenis <kettenis@openbsd.org>
Cc: Masahisa Kojima <kojima.masahisa@socionext.com>
Cc: Mattijs Korpershoek <mkorpershoek@kernel.org>
Cc: Patrice Chotard <patrice.chotard@foss.st.com>
Cc: Patrick Delaunay <patrick.delaunay@foss.st.com>
Cc: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Cc: Stefan Bosch <stefan_b@posteo.net>
Cc: Tien Fong Chee <tien.fong.chee@altera.com>
Cc: Tingting Meng <tingting.meng@altera.com>
Cc: Tobias Waldekranz <tobias@waldekranz.com>
Provide a way to draw an unfilled box of a certain width. This is useful
for grouping menu items together.
Add a comment showing how to see the copy-framebuffer, for testing.
Signed-off-by: Simon Glass <sjg@chromium.org>
When using expo we want to be able to control the information on the
display and avoid other messages (such as USB scanning) appearing.
Add a 'quiet' flag for the console, to help with this.
The test is a little messy since stdio is still using the original
vidconsole create on start-up. So take care to use the same.
Signed-off-by: Simon Glass <sjg@chromium.org>
We want to check the display contents in expo tests, so move the two
needed functions to a new header file.
Rename them to have a video_ prefix.
Signed-off-by: Simon Glass <sjg@chromium.org>
When writing multiple lines of text we need to be able to control which
text goes on each line. Add a new vidconsole_put_stringn() function to
help with this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Expo needs to be able to word-wrap lines so that they are displayed as
the user expects. Add a limit on the width of each line and support this
in the measurement algorithm.
Add a log category to truetype while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
It is useful to be able to embed newline characters in the string and
have the text measured into multiple lines. Add support for this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Update the vidconsole API so that measure() can measure multiple lines
of text. This will make it easier to implement multi-line fields in
expo.
Tidy up the function comments while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
CONFIG_VIDEO_COPY implemented a range-based copying mechanism: If we
print a single character, it will always copy the full range of bytes
from the top left corner of the character to the lower right onto the
uncached frame buffer. This includes pretty much the full line contents
of the printed character.
Since we now have proper damage tracking, let's make use of that to reduce
the amount of data we need to copy. With this patch applied, we will only
copy the tiny rectangle surrounding characters when we print them,
speeding up the video console.
After this, changes to the main frame buffer are not immediately copied
to the copy frame buffer, but postponed until the next video device
sync. So issue an explicit sync before inspecting the copy frame buffer
contents for the video tests.
Signed-off-by: Alexander Graf <agraf@csgraf.de>
[Alper: Rebase for fontdata->height/w, fill_part(), fix memmove(dev),
drop from defconfig, use damage.xstart/yend, use IS_ENABLED(),
call video_sync() before copy_fb check, update video_copy test]
Co-developed-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Link: https://lore.kernel.org/u-boot/20230821135111.3558478-12-alpernebiyasak@gmail.com/
With VIDEO_DAMAGE, the video uclass tracks updated regions of the frame
buffer in order to avoid unnecessary work during a video sync. Enable
the config in sandbox and add a test for it, by printing strings at a
few locations and checking the tracked region.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Adjust test avoid temporary failures in this patch:
Signed-off-by: Simon Glass <sjg@chromium.org>
Link: https://lore.kernel.org/u-boot/20230821135111.3558478-8-alpernebiyasak@gmail.com/
With VIDEO_COPY enabled, only the modified parts of the frame buffer are
intended to be copied to the hardware. Add a test that checks this, by
overwriting contents we prepared without telling the video uclass and
then checking if the overwritten contents have been redrawn on the next
sync.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Link: https://lore.kernel.org/u-boot/20230821135111.3558478-4-alpernebiyasak@gmail.com/
The video tests have a helper function to generate a pseudo-digest of
frame buffer contents, but it only does so for the main one. There is
another check that the copy frame buffer is the same as that. But
neither is enough to test if only the modified regions are copied to the
copy frame buffer, since we will want the two to be different in very
specific ways.
Add a boolean argument to the existing helper function to indicate which
frame buffer we want to inspect, and update the existing callers.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Link: https://lore.kernel.org/u-boot/20230821135111.3558478-3-alpernebiyasak@gmail.com/
While checking frame buffer contents, the video tests also check if the
copy frame buffer contents match the main frame buffer. To test if only
the modified regions are updated after a sync, we will need to create
situations where the two are mismatched. Split this check into another
function that we can skip calling, since we won't want it to error on
those mismatched cases.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Link: https://lore.kernel.org/u-boot/20230821135111.3558478-2-alpernebiyasak@gmail.com/
