Tom Rini [Thu, 14 Nov 2024 16:49:30 +0000 (10:49 -0600)]
Merge patch series "cmd: hash: correct parameter count check"
Heinrich Schuchardt <heinrich.schuchardt@canonical.com> says:
Since commit 348ea878508d ("cmd: hash: fix param count check") the hash
command cannot be used without the optional variable name parameter if
CONFIG_HASH_VERIFY=y. 'hash sha1 $loadaddr $filesize' returns
CMD_RET_USAGE.
The minimum number of arguments is four no matter if verification is
enabled or not.
Tom Rini [Thu, 14 Nov 2024 16:48:07 +0000 (10:48 -0600)]
Merge patch series "Apply SoM overlays on phyCORE-AM6xx SoMs"
Wadim Egorov <w.egorov@phytec.de> says:
Our SoMs are available in multiple configurations, managed via device
tree overlays. To determine the specific variant in use, we read the
EEPROM and apply the appropriate overlays during boot to the device tree
used by the OS.
Apply overlays for phyCORE-AM62x and phyCORE-AM64x SoMs.
Future K3 SoMs will be able to reuse this logic and overlays.
Since commit 348ea878508d ("cmd: hash: fix param count check") the hash
command cannot be used without the optional variable name parameter if
CONFIG_HASH_VERIFY=y. 'hash sha1 $loadaddr $filesize' returns
CMD_RET_USAGE.
The minimum number of arguments is four no matter if verification is
enabled or not.
Fixes: 348ea878508d ("cmd: hash: fix param count check") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Igor Opaniuk <igor.opaniuk@gmail.com>
Wadim Egorov [Wed, 30 Oct 2024 16:48:15 +0000 (17:48 +0100)]
board: phytec: common: k3: Apply SoM-specific overlays to OS device tree
Our SoMs are available in multiple configurations, managed via device
tree overlays. To determine the specific variant in use, we read the
EEPROM and apply the appropriate overlays during boot to the device tree
used by the OS.
Signed-off-by: Wadim Egorov <w.egorov@phytec.de> Acked-by: Neha Malcom Francis <n-francis@ti.com>
Tom Rini [Wed, 13 Nov 2024 18:05:00 +0000 (12:05 -0600)]
Merge patch series "labgrid: Provide an integration with Labgrid"
Simon Glass <sjg@chromium.org> says:
Labgrid provides access to a hardware lab in an automated way. It is
possible to boot U-Boot on boards in the lab without physically touching
them. It relies on relays, USB UARTs and SD muxes, among other things.
By way of background, about 4 years ago I wrong a thing called Labman[1]
which allowed my lab of about 30 devices to be operated remotely, using
tbot for the console and build integration. While it worked OK and I
used it for many bisects, I didn't take it any further.
It turns out that there was already an existing program, called Labgrid,
which I did not know about at time (thank you Tom for telling me). It is
more rounded than Labman and has a number of advantages:
- does not need udev rules, mostly
- has several existing users who rely on it
- supports multiple machines exporting their devices
It lacks a 'lab check' feature and a few other things, but these can be
remedied.
On and off over the past several weeks I have been experimenting with
Labgrid. I have managed to create an initial U-Boot integration (this
series) by adding various features to Labgrid[2] and the U-Boot test
hooks.
I hope that this might inspire others to set up boards and run tests
automatically, rather than relying on infrequent, manual test. Perhaps
it may even be possible to have a number of labs available.
Included in the integration are a number of simple scripts which make it
easy to connect to boards and run tests:
ub-int <target>
Build and boot on a target, starting an interactive session
ub-cli <target>
Build and boot on a target, ensure U-Boot starts and provide an interactive
session from there
ub-smoke <target>
Smoke test U-Boot to check that it boots to a prompt on a target
ub-bisect <target>
Bisect a git tree to locate a failure on a particular target
ub-pyt <target> <testspec>
Run U-Boot pytests on a target
Some of these help to provide the same tbot[4] workflow which I have
relied on for several years, albeit much simpler versions.
The goal here is to create some sort of script which can collect
patches from the mailing list, apply them and test them on a selection
of boards. I suspect that script already exists, so please let me know
what you suggest.
Simon Glass [Sat, 2 Nov 2024 19:36:11 +0000 (13:36 -0600)]
sandbox: Add a build without CMDLINE
Sometimes this breaks, so add a build to keep it working. Since sandbox
enables a lot of options, it is a good board to use. The new config is
created simply by copying the existing sandbox and turning off CMDLINE
Once we have tests for non-CMDLINE operation, this can be adjusted to
run those tests.
Create a new build which will be picked up by CI. Update the maintainer
entry as well.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
Simon Glass [Tue, 12 Nov 2024 14:13:26 +0000 (07:13 -0700)]
CI: Allow running tests on sjg lab
Add a way to run tests on a real hardware lab. This is in the very early
experimental stages. There are only 23 boards and 3 of those are broken!
(bob, ff3399, samus). A fourth fails due to problems with the TPM tests.
To try this, assuming you have gitlab access, set SJG_LAB=1, e.g.:
git push -o ci.variable="SJG_LAB=1" dm HEAD:try
This relies on the two previous series targeted at -next as well as the
bugfix series for -master
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Andrejs Cainikovs <andrejs.cainikovs@toradex.com>
Simon Glass [Tue, 12 Nov 2024 14:13:24 +0000 (07:13 -0700)]
test: Support testing with two board-builds
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.
Simon Glass [Tue, 12 Nov 2024 14:13:22 +0000 (07:13 -0700)]
test: Try to shut down the lab console gracefully
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.
Simon Glass [Tue, 12 Nov 2024 14:13:21 +0000 (07:13 -0700)]
test: Avoid double echo when starting up
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.
Simon Glass [Tue, 12 Nov 2024 14:13:20 +0000 (07:13 -0700)]
test: Improve handling of sending commands
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.
Simon Glass [Tue, 12 Nov 2024 14:13:19 +0000 (07:13 -0700)]
test: Introduce lab mode
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.
Simon Glass [Tue, 12 Nov 2024 14:13:18 +0000 (07:13 -0700)]
test: Introduce the concept of a role
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.
Simon Glass [Tue, 12 Nov 2024 14:13:17 +0000 (07:13 -0700)]
test: Allow connecting to a running board
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.
Simon Glass [Tue, 12 Nov 2024 14:13:16 +0000 (07:13 -0700)]
test: Release board after tests complete
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>
Simon Glass [Tue, 12 Nov 2024 14:13:15 +0000 (07:13 -0700)]
test: Allow signaling that U-Boot is ready
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>
Simon Glass [Sat, 2 Nov 2024 19:36:57 +0000 (13:36 -0600)]
test: Move str_ut test into lib
This test doesn't belong at the top level. Move it into the lib/
directory, to match (most of) its implementation. Rename it to drop the
unnecessary _ut suffix.
Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Tom Rini <trini@konsulko.com> # rpi_3, rpi_4, rpi_arm64, am64x_evm_a53, am64-sk
Simon Glass [Sat, 2 Nov 2024 19:36:55 +0000 (13:36 -0600)]
test: Move print_ut test into common
This test doesn't belong at the top level. Move it into the common/
directory, to match its implementation. Rename it to drop the
unnecessary _ut suffix.
Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Tom Rini <trini@konsulko.com> # rpi_3, rpi_4, rpi_arm64, am64x_evm_a53, am64-sk
Simon Glass [Sat, 2 Nov 2024 19:36:52 +0000 (13:36 -0600)]
command: test: Move into the cmd suite
The command test was the very first test written in U-Boot, some 12
years ago. It predates the unit-test subsystem and was never converted
over.
There is no particular need for the command test to have its own
command. It is also confusing to have it separate from the normal test
suites. At present this test is not run in CI.
Move it into the cmd suite instead, updating it to become a unit test.
One of the checks is dropped to avoid an error.
Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Tom Rini <trini@konsulko.com> # rpi_3, rpi_4, rpi_arm64, am64x_evm_a53, am64-sk
Simon Glass [Sat, 2 Nov 2024 19:36:51 +0000 (13:36 -0600)]
command_ut: test: Move test into lib
This test doesn't belong at the top level. Move it into the lib/
directory, since that is where compression is implemented.
Rename it to just 'command', since it is obviously a unit test and the
_ut suffix does not add much except to make it different from the names
of other test files.
Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Tom Rini <trini@konsulko.com> # rpi_3, rpi_4, rpi_arm64, am64x_evm_a53, am64-sk
Simon Glass [Wed, 6 Nov 2024 15:35:43 +0000 (08:35 -0700)]
Makefile: Fake external blob with BINMAN_ALLOW_MISSING=1
This flag was lost by a previous change and has never been restored.
Without it, binman cannot fully handle missing blobs which are
themselves inputs to mkimage.
Discussion on this at [1] indicated that this was necessary but the
patch was not updated.
Restore the flag so that all missing blobs are reported.
Avoid a build failure when building with CONFIG_API=y, CONFIG_EXAMPLES=y:
lib/vsprintf.c:312:14: warning:
‘device_path_string’ defined but not used [-Wunused-function]
312 | static char *device_path_string(char *buf, char *end, void *dp, int field_width,
| ^~~~~~~~~~~~~~~~~~
Fixes: 64b5ba4d293a ("efi_loader: make device path to text protocol customizable") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tom Rini [Wed, 13 Nov 2024 14:14:29 +0000 (08:14 -0600)]
Merge patch series "lib: uuid: fix uuid_str_to_le_bin() on 32-bit"
Heinrich Schuchardt <heinrich.schuchardt@canonical.com> says:
The lib_test_uuid_to_le and lib lib_test_dynamic_uuid tests fail on
32-bit systems. But we never caught this in our CI because we never
ran any of our C unit tests on 32-bit.
Enable CONFIG_UNIT_TEST on qemu_arm_defconfig.
hextoul() cannot convert a string to a 64-bit number on a 32-bit system.
Use the new function hextoull() instead.
hextoul() cannot convert a string to a 64-bit number on a 32-bit system.
Use function hextoull() instead.
Reported-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Fixes: 22c48a92cdce ("lib: uuid: supporting building as part of host tools") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Tested-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
hextoul() cannot convert a string to a 64-bit number on a 32-bit system.
Use function hextoull() instead.
Reported-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Fixes: 22c48a92cdce ("lib: uuid: supporting building as part of host tools") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org> Tested-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
This is a respin of [1] adding https support to wget. In short
patch#1 enables the crypto algorithms we need in mbedTLS
patches#2, #3 enable anf fix the lwIP part we need
patch#4 is adding https:// parsing support in our wget
patch#5 is making https:// the default for QEMU lwip defconfig so
people can easily test
and finaly patch#6 updates our documentation
Ilias Apalodimas [Sun, 10 Nov 2024 08:28:41 +0000 (10:28 +0200)]
configs: Enable https for wget on qemu arm64
QEMU already has an lwip variant of a defconfig. That defconfig
is also configured with mbedTLS by default. So let's enable the
remaining config options to enable wget for https:// as well
and test that codepath in the CI
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org> Reviewed-by: Peter Robinson <pbrobinson@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Ilias Apalodimas [Sun, 10 Nov 2024 08:28:40 +0000 (10:28 +0200)]
net: lwip: Enable https:// support for wget
With the recent changes of lwip & mbedTLS we can now download from
https:// urls instead of just http://.
Adjust our wget lwip version parsing to support both URLs.
While at it adjust the default TCP window for QEMU since https seems to
require at least 16384
Javier Tia [Sun, 10 Nov 2024 08:28:39 +0000 (10:28 +0200)]
net: lwip: Add Support Server Name Indication support
SNI, or Server Name Indication, is an addition to the TLS encryption
protocol that enables a client device to specify the domain name it is
trying to reach in the first step of the TLS handshake, preventing
common name mismatch errors and not reaching to HTTPS server that
enforce this condition. Since most of the websites require it nowadays
add support for it.
It's worth noting that this is already sent to lwIP [0]
[0] https://github.com/lwip-tcpip/lwip/pull/47
Signed-off-by: Javier Tia <javier.tia@linaro.org> Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Javier Tia [Sun, 10 Nov 2024 08:28:38 +0000 (10:28 +0200)]
net: lwip: Update lwIP for mbedTLS > 3.0 support and enable https
The current code support mbedTLS 2.28. Since we are using a newer
version in U-Boot, update the necessary accessors and the lwIP codebase
to work with mbedTLS 3.6.0. It's worth noting that the patches are
already sent to lwIP [0]
While at it enable LWIP_ALTCP_TLS and enable TLS support in lwIP
[0] https://github.com/lwip-tcpip/lwip/pull/47
Signed-off-by: Javier Tia <javier.tia@linaro.org> Acked-by: Jerome Forissier <jerome.forissier@linaro.org> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Ilias Apalodimas [Sun, 10 Nov 2024 08:28:37 +0000 (10:28 +0200)]
mbedtls: Enable TLS 1.2 support
Since lwIP and mbedTLS have been merged we can tweak the config options
and enable TLS1.2 support. Add RSA and ECDSA by default and enable
enough block cipher modes of operation to be comatible with modern
TLS requirements and webservers
Reviewed-by: Raymond Mao <raymond.mao@linaro.org> Acked-by: Jerome Forissier <jerome.forissier@linaro.org> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
We don't do anything with Content-Length except a debug print, and the
strict_strtoul() call is incorrect (it always returns -EINVAL and leaves
content_length to zero due to the presence of trailing characters after
the decimal valuoe of Content-Length). So let's just drop this piece of
code.
- Deduplicate DH STM32MP1xx DHSOM and DHCOR defconfigs
- Fixes STM32MP1xx DHSOM and DHCOR device trees
- Add support of manufacturing environment to STM32MP15xx DHSOM
Marek Vasut [Wed, 6 Nov 2024 19:04:14 +0000 (20:04 +0100)]
ARM: stm32: Add optional manufacturing environment to DH STM32MP15xx DHSOM
Add manufacturing environment into STM32MP15xx DH electronics DHSOM
configuration. This environment is part of every board build, but only
takes effect on systems booted with the dh,stm32mp15xx-dhcor-testbench
device tree, i.e. systems populated with factory build of U-Boot.
Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Deduplicate defconfigs for all DH STM32MP1xx DHSOM systems by factoring
out the common parts into generic stm32mp_dhsom.config and including
those using the #include <configs/...> preprocessor macro in the current
set of board specific defconfigs. The preprocessor macro is applicable
to defconfigs as well.
This introduces no functional change, the resulting .config is identical
for all DH STM32MP1xx DHSOM systems.
Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Deduplicate defconfigs for all DH STM32MP15xx DHSOM systems by factoring
out the common parts into generic stm32mp15_dhsom.config and including
those using the #include <configs/...> preprocessor macro in the current
set of board specific defconfigs. The preprocessor macro is applicable
to defconfigs as well.
This introduces no functional change, the resulting .config is identical
for all DH STM32MP15xx DHSOM systems.
Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Marek Vasut [Mon, 21 Oct 2024 19:44:26 +0000 (21:44 +0200)]
ARM: dts: stm32: Drop duplicate pinmux on DH STM32 DHCOM
The ethernet0_rmii_pins_a pinmux change has no effect on any
DHSOM based hardware. The mco2_pins_a and mco2_sleep_pins_a
are both part of stm32mp15-pinctrl.dtsi . Drop both pinmux
changes.
Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Marek Vasut [Mon, 21 Oct 2024 19:34:57 +0000 (21:34 +0200)]
ARM: dts: stm32: Drop remnants of upstream DT switch on DH STM32 DHSOM
Remove unused local DT copies after the OF_UPSTREAM conversion.
Fixes: cccb29fc1270 ("ARM: dts: stm32: Switch to using upstream DT on DH STM32 DHSOM") Reported-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Tom Rini [Mon, 11 Nov 2024 13:26:50 +0000 (07:26 -0600)]
Merge patch series "Fix IOVA allocation in Apple dart iommu after global LMB mem map changes"
Janne Grunau <j@jannau.net> says:
The changes in "Make LMB memory map global and persistent" [1] break
mapping DMA memory in the USB xHCI driver when using the apple_dart
iommu present on Apple silicon systems.
The IOVA space used by the u-boot driver (low 4GB) and physical memory
do not overlap. The physical memory on this systems starts depending on
the SoC either at 0x10_0000_0000 or 0x100_0000_0000. It make no sense to
manage these distinct regions in a single LMB map. In addition every
device has its own iommu and IO address space so sharing a single memory
map between all iommu instances is not necessary.
To fix this issue restore the used subset (add, alloc and free) of the
previous pointer based LMB interface with "io_" as prefix.
To ensure that low level lmb functions do not use the global LMB
variable reorder lib/lmb.c so that the variable is not visible.
Tested with patches from my "Fix device removal order for Apple dart
iommu" series [2] to fix a separate issue.
The cosmetic commit has two checkpatch warnings in existing code which I
ignored.
Janne Grunau [Mon, 11 Nov 2024 06:56:34 +0000 (07:56 +0100)]
iommu: apple: Manage IOVA separately from global LMB mem map
There is no overlap between the IOVA space managed by the iommu (here
the 32-bit address space) and physical RAM on Apple silicon systems. The
RAM starts at 0x10_0000_0000 or 0x100_0000_0000 so it's not possible to
manage the IOVA with the global memory LMB and use 1:1 translation.
In addition each device has its own iommu and does not need to share the
address space with all other devices. This should not be problem for
u-boot's limited use and hardware support.
Restore the private per instance LMB IOVA map.
Fixes: ed17a33fed2 ("lmb: make LMB memory map persistent and global") Signed-off-by: Janne Grunau <j@jannau.net>
Janne Grunau [Mon, 11 Nov 2024 06:56:33 +0000 (07:56 +0100)]
lmb: Add basic io_lmb functionality
These functions can be used with struct lmb pointers and will be used to
manage IOVA space in the apple_dart iommu driver. This restores part of
the pointer base struct lmb API from before commit ed17a33fed29 ("lmb:
make LMB memory map persistent and global").
io_lmb_add() and io_lmb_free() can trivially reuse exisiting lmb
functions. io_lmb_setup() is separate for unique error log messages.
io_lmb_alloc() is a simplified copy of _lmb_alloc_base() since the
later has unused features and internal use of the global LMB memory map.
Janne Grunau [Mon, 11 Nov 2024 06:56:32 +0000 (07:56 +0100)]
lmb: cosmetic: reorder functions and global LMB variable
Low lovel LMB functionality will be used to manage IOVA space in the
Apple dart iommu driver. This reordering ensures that those function
can not access the global LMB memory map variable.
Quentin Schulz [Wed, 6 Nov 2024 11:29:44 +0000 (12:29 +0100)]
rockchip: rk3399: move sysreset-gpio logic to TPL
If TPL_GPIO and TPL_PINCTRL_ROCKCHIP are enabled and a sysreset-gpio is
provided in the TPL Device Tree, this will trigger a system reset
similar to what's currently been done in SPL whenever the RK3399 "warm"
boots. Because there's currently only one user of sysreset-gpio logic,
and TPL is enabled on that board, so let's migrate the logic and that
board to do it in TPL.
There are three reasons for moving this earlier:
- faster boot time as we don't need to reach SPL to be able to reset the
system on a condition we know is already met in TPL,
- have less code to be impacted by the issue this system reset works
around (that is, "unclean" SoC registers after a reboot),
- less confusion around the reason for restarting. Indeed when done from
SPL, the following log can be observed:
"""
U-Boot TPL 2025.01-rc1-00165-gd79216ca9878-dirty (Nov 05 2024 - 15:31:45)
Channel 0: DDR3, 666MHz
BW=32 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=2048MB
Channel 1: DDR3, 666MHz
BW=32 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=2048MB
256B stride
Trying to boot from BOOTROM
Returning to boot ROM...
Quentin Schulz [Wed, 6 Nov 2024 11:29:43 +0000 (12:29 +0100)]
rockchip: tpl: allow to call board/SoC-specific code before DRAM init
This defines a weak tpl_board_init function that can be used for running
board/SoC-specific code before the DRAM init happens, similarly to
spl_board_init() for SPL.
Reviewed-by: Paul Kocialkowski <paulk@sys-base.io> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Quentin Schulz [Wed, 6 Nov 2024 11:29:42 +0000 (12:29 +0100)]
rockchip: rk3399: merge CRU check within rk3399_force_power_on_reset
To prepare to support forcing power on reset from TPL which would have
the exact same logic, just in an earlier stage, let's merge the CRU
check that triggers the power on reset with the rest of the logic.
Reviewed-by: Paul Kocialkowski <paulk@sys-base.io> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Jonas Karlman [Fri, 1 Nov 2024 22:21:30 +0000 (22:21 +0000)]
board: rockchip: Add FriendlyElec NanoPi R2S Plus
The FriendlyElec NanoPi R2S Plus is a single-board computer based on
Rockchip RK3328 SoC. It features e.g. 1 GB DDR4 RAM, 32 GB eMMC,
SD-card, 2x GbE LAN, optional M.2 SDIO Wi-Fi and 2x USB 2.0 host.
Features tested on a NanoPi R2S Plus 2309:
- SD-card boot
- eMMC boot
- Ethernet
- USB gadget
- USB host
Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
arm64: dts: rockchip: Add DTS for FriendlyARM NanoPi R2S Plus
The R2S Plus is basically an R2S with additional eMMC.
The eMMC configuration for the DTS has been extracted and copied from
rk3328-nanopi-r2.dts, v2017.09 branch from the friendlyarm/uboot-rockchip
repository.
(cherry picked from commit c9bf98827964441f4dd16faa45bd4046f472e693) Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Andy Yan [Mon, 4 Nov 2024 12:23:00 +0000 (20:23 +0800)]
board: rockchip: Add support for rk3588 GenBook
Add support for Cool Pi GenBook, it works as a carrier board
connect with CM5 SOM.
Specification:
- Rockchip RK3588
- LPDDR5X 8/32 GB
- eMMC 64 GB
- HDMI Type A out x 1
- USB 3.0 Host x 1
- USB-C 3.0 with DisplayPort AltMode
- PCIE M.2 E Key for RTL8852BE Wireless connection
- PCIE M.2 M Key for NVME connection
- eDP panel with 1920x1080
Tested by Armbian boot on USB disk.
Change-Id: I4d9b8572dc7c400077dde666633f3fea1b47dd03 Signed-off-by: Andy Yan <andyshrk@163.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Andy Yan [Mon, 4 Nov 2024 12:22:59 +0000 (20:22 +0800)]
rockchip: Make it possible to define per board boot_targets
Some board may want to have a different boot priority(a laptop
may want to usb has the highest boot priority for third-part
os installation). So let the board can define it's own
boot_targets.
Signed-off-by: Andy Yan <andyshrk@163.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Andy Yan [Mon, 4 Nov 2024 12:22:58 +0000 (20:22 +0800)]
arm64: dts: rockchip: Add support for rk3588 based Cool Pi CM5 GenBook
Cool Pi CM5 GenBook works as a carrier board connect with CM5 [0].
Specification:
- Rockchip RK3588
- LPDDR5X 8/32 GB
- eMMC 64 GB
- HDMI Type A out x 1
- USB 3.0 Host x 1
- USB-C 3.0 with DisplayPort AltMode
- PCIE M.2 E Key for RTL8852BE Wireless connection
- PCIE M.2 M Key for NVME connection
- eDP panel with 1920x1080
This patch add basic support to bringup eMMC/USB HOST/WiFi/TouchPad/
Battery/PCIE NVME, and can also drive a HDMI output with out of tree
hdmi patches.
Heiko Stuebner [Mon, 28 Oct 2024 19:00:34 +0000 (20:00 +0100)]
board: rockchip: add support for Qnap TS433 devices
The Qnap TS433 is a 4-bay NAS based around the RK3568.
Two SATA bays are connected to the RK3568's own SATA controllers while
the other two are connected to a JMicron SATA controller living on the
PCIe bus.
It provides one 2.5Gb and one 1Gb ethernet port as well as 3 usb ports.
Signed-off-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Marek Vasut [Sat, 2 Nov 2024 23:57:31 +0000 (00:57 +0100)]
mtd: spi-nor: Fix integer overflow in stacked memories support
The 5d40b3d384dc ("mtd: spi-nor: Add parallel and stacked memories support")
adds new SPI bus flags, but also introduces a completely new set of
SPI bus flags in another location. The existing flags field is type
u8, while the new separate flags are BIT(8) and higher. Use of those
new flags triggers integer overflow.
Drop the newly introduced flags which were never used anywhere in the
code. Move the one remaining flag which was used in the correct place
and change it from BIT(8) to BIT(6) so it fits the u8 flags.
Fixes: 5d40b3d384dc ("mtd: spi-nor: Add parallel and stacked memories support")
Addresses-Coverity-ID: 510804 Extra high-order bits Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Lad Prabhakar [Mon, 4 Nov 2024 13:50:12 +0000 (13:50 +0000)]
board: hoperun: Switch to use complete DTS files from upstream DTS
For upstream Linux kernel we use below DTBs for HiHope boards:
- r8a774a1-hihope-rzg2m-ex.dtb
- r8a774e1-hihope-rzg2h-ex.dtb
- r8a774b1-hihope-rzg2n-ex.dtb
Update the CONFIG_OF_LIST to match the above. Now that we have switched
upstream DTS, drop deleting the nodes and also rename the
r8a774*-u-boot.dtsi files to r8a774*-ex-u-boot.dtsi to match the OF_LIST
files so that the `bootph-all` property gets applied to required nodes
in upstream DTS.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Signed-off-by: Chris Paterson <chris.paterson2@renesas.com>
Chris Paterson [Mon, 4 Nov 2024 13:50:11 +0000 (13:50 +0000)]
configs: hihope_rzg2: Set correct MMC device for U-Boot env
Currently we set CONFIG_SYS_MMC_ENV_DEV=1 which is wrong:
Loading Environment from MMC... MMC: no card present
*** Warning - No block device, using default environment
This issue was introduced when we switched to using upstream Linux device
trees for the hihope boards which named the MMC devices differently.
Correct to dev 0 so that the U-Boot environment can be loaded from the
correct storage device.
Fixes: 18fb23b13158 ("ARM: dts: renesas: Switch to using upstream DT on 64bit Renesas SoCs") Signed-off-by: Chris Paterson <chris.paterson2@renesas.com> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Paul Barker [Fri, 1 Nov 2024 14:20:16 +0000 (14:20 +0000)]
arm: renesas: Fix RZ/G2L GICR base address
When support for the Renesas RZ/G2L SoC was added, the GICR base address
for CPU1 was accidentally used. We should instead supply the GICR base
address for CPU0 so that interrupts are correctly configured for the
CPU core that U-Boot is actually using.
Fixes: 387d4275ab0e ("arm: rmobile: Add basic RZ/G2L family support") Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Paul Barker [Wed, 30 Oct 2024 10:35:43 +0000 (10:35 +0000)]
board: rzg2l: Update MAINTAINERS file to match dts/upstream paths
We are now using the dts/upstream subtree for the RZ/G2L SoC family, so
update the board MAINTAINERS file to match rz-smarc dtsi files in this
subtree.
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com> Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
- Improve imx9 boot medium autodection.
- Add possibility to skip DCD on i.MX8.
- Switch to using upstream DT on DH i.MX6 DHCOM.
- Add support for i.MX6DL DHCOM SoM on PDK2 carrier board.
- Handle FIELD_RETURN on i.MX HAB.
Tom Rini [Sat, 9 Nov 2024 14:05:41 +0000 (08:05 -0600)]
Merge tag 'efi-2025-01-rc2-2' of https://source.denx.de/u-boot/custodians/u-boot-efi
Pull request efi-2025-01-rc2-2
Documentation:
* correct title and author of rst2pdf generated pdf
* describe CONFIG_DEBUG_SBI_CONSOLE
* remove vile language
UEFI
* correct printf codes in mkeficapsule
* add an EFI test app
* move default filename to a function
* move get_efi_pxe_arch() to efi_helper
* allow reporting the host defaults in efidebug
* drop sandbox PXE architecture
Other:
* do not reserve extra 16 KiB of stack in lmb
* disable the sandbox virtio blk device
* provide -N command line flag to control EFI default boot file name
on the sandbox
* provide a unit test for the efi bootmeth
Ian Ray [Fri, 8 Nov 2024 14:03:55 +0000 (16:03 +0200)]
arm: mach-imx: imx8m: re-use SNVS init routine
Working with HAB on the i.MX8MP we've encountered a case where a board
that successfully authenticates u-boot when booting Linux subsequently
fails to properly bring up the RTC.
The RTC registers live in the low-power block of the Secure Non-Volatile
Storage (SNVS) block.
The root cause of the error has been traced to the HAB handing off the
SNVS-RTC in a state where HPCOMR::NPSWA_EN = 0 in other words where the
Non-Privileged Software Access Enable bit is zero.
Configure SNVS to allow unpriv access to SNVS LP for imx8m and imx8mp.
This commit generalizes 723f8359c1 ("imx: mx7: snvs: Add an SNVS init
routine") to also be used on i.MX8M SoCs, and was testeed on i.MX8MP.
projects / u-boot.git / log