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 [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.
Ian Ray [Fri, 8 Nov 2024 14:03:54 +0000 (16:03 +0200)]
arm: mach-imx: move snvs module
Commit 723f8359c1 ("imx: mx7: snvs: Add an SNVS init routine") noted
that the init_snvs() call likely applies to other i.MX processors, and
this has been found to be true for i.MX8MP.
Marek Vasut [Tue, 5 Nov 2024 23:06:53 +0000 (00:06 +0100)]
ARM: dts: imx: Switch to using upstream DT on DH i.MX6 DHCOM
Enable OF_UPSTREAM to use upstream DT and add nxp/imx/ prefix to the
DEFAULT_DEVICE_TREE. And thereby directly build DTB from dts/upstream/src/
including *-u-boot.dtsi files from arch/$(ARCH)/dts/ directory.
Marek Vasut [Tue, 5 Nov 2024 23:06:52 +0000 (00:06 +0100)]
ARM: dts: imx6dl: Add support for i.MX6DL DHCOM SoM on PDK2 carrier board
Add support for the DH electronics i.MX6DL DHCOM SoM and a PDK2 evaluation
board. The evaluation board features three serial ports, USB OTG, USB host
with an USB hub, Fast or Gigabit ethernet, eMMC, uSD, SD, analog audio,
PCIe and HDMI video output.
All of the aforementioned features except for mSATA are supported, mSATA
is not available on i.MX6DL and is only available on DHCOM populated with
i.MX6Q SoC which is already supported upstream.
Backport from linux-next commit c3f5d76a6e03 ("ARM: dts: imx6dl: Add support for i.MX6DL DHCOM SoM on PDK2 carrier board")
Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Christoph Niedermaier <cniedermaier@dh-electronics.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Heiko Schocher [Mon, 4 Nov 2024 18:02:03 +0000 (19:02 +0100)]
tools: imx8image: add possibility to skip dcd
Currently U-Boot always adds DCD Image to boot container.
On imx8qxp SoC it is possible to init RAM from within SCFW,
and adding a DCD image type to the boot container in this case
breaks booting (No debug output anymore from SCFW! Nor any
output from SPL), so we need to configure a dcd skip somehow.
This patch adds a new imx8image_cmd entry CMD_DCD_SKIP and a
new entry in imximage.cfg "DCD_SKIP". If set to "true"
no DCD image type will be added to the container.
Signed-off-by: Heiko Schocher <hs@denx.de> Reviewed-by: Peng Fan <peng.fan@nxp.com>
Benjamin Szőke [Fri, 1 Nov 2024 15:26:18 +0000 (16:26 +0100)]
imx9: Improve boot mode autodetection
Improve "mmcautodetect=yes" boot mode autodetection to able to use it
if CONFIG_ENV_IS_NOWHERE=y is used for i.MX9 SoCs and i.MX93 EVK board.
If both CONFIG_ENV_IS_IN_MMC=y and CONFIG_ENV_IS_NOWHERE=y are in the
defconfig, CONFIG_ENV_IS_IN_MMC=y will be overiden default
CONFIG_ENV_IS_NOWHERE settings.
Goal is in this patch to able to use the boot mode autodetection
if defconfig use only CONFIG_ENV_IS_NOWHERE=y option
(without CONFIG_ENV_IS_IN_MMC) for any i.MX9 SoC.
Signed-off-by: Benjamin Szőke <egyszeregy@freemail.hu>
Paul Geurts [Fri, 1 Nov 2024 08:49:21 +0000 (09:49 +0100)]
imx: hab: Make imx_hab_is_enabled dependent on FIELD_RETURN
The decision on whether HAB is enabled is solely based on the SEC_CONFIG
fuse. The HAB FIELD_RETURN feature is able to permanently disable HAB on
a CPU, after which it is able to boot unsigned firmware. U-Boot however
does not take into account the FIELD_RETURN mode, and refuses to boot
unsigned software when the feature is enabled.
Also take the FIELD_RETURN fuse into account when deciding whether HAB
is enabled. When The FIELD_RETURN fuse is blown, HAB is not enabled.
Tested on i.MX8M Mini, i.MX8M Plus, i.MX8M Nano and i.MX6ULL
Signed-off-by: Paul Geurts <paul.geurts@prodrive-technologies.com>
Simon Glass [Thu, 7 Nov 2024 21:31:50 +0000 (14:31 -0700)]
test: efi: boot: Add a test for the efi bootmeth
Add a simple test of booting with the EFI bootmeth, which runs the app
and checks that it can call 'exit boot-services' (to check that all the
device-removal code doesn't break anything) and then exit back to
U-Boot.
This uses a disk image containing the testapp, ready for execution by
sandbox when needed.
Simon Glass [Thu, 7 Nov 2024 21:31:49 +0000 (14:31 -0700)]
test: efi: boot: Set up an image suitable for EFI testing
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.
Simon Glass [Thu, 7 Nov 2024 21:31:48 +0000 (14:31 -0700)]
sandbox: virtio: Disable the sandbox virtio blk device
This is not implemented so cannot actually be used to read blocks.
Disable it until it is implemented, to avoid causing a hang with EFI,
which probes every available BLK device.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
Issue: https://source.denx.de/u-boot/u-boot/-/issues/37
Simon Glass [Thu, 7 Nov 2024 21:31:41 +0000 (14:31 -0700)]
efi_loader: Add a test app
Add a simple app to use for testing. This is intended to do whatever it
needs to for testing purposes. For now it just prints a message and
exits boot services.
There was a considerable amount of discussion about whether it is OK to
call exit-boot-services and then return to U-Boot. This is not normally
done in a real application, since exit-boot-services is used to
completely disconnect from U-Boot. For now, this part is skipped.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Moritz Fischer [Mon, 4 Nov 2024 01:49:34 +0000 (01:49 +0000)]
efi_loader: Change efi_dp_from_mem() to use size
All call sites are using size rather than end addresses,
so instead - as previously done - calculating an end address
everywhere, just modify the function to use size and internally
calculate the end address
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org> Cc: Patrick Wildt <pwildt@google.com> Signed-off-by: Moritz Fischer <moritzf@google.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Simon Glass [Mon, 28 Oct 2024 12:47:59 +0000 (13:47 +0100)]
lmb: Drop extra 16KB of stack space
There is already a defined stack-size which is used to reserve space for
the stack. It is confusing to add more in the lmb module, since then the
memory map (with meminfo command) seems to have a hole in it.
Heiko Stuebner [Mon, 28 Oct 2024 19:00:33 +0000 (20:00 +0100)]
arm64: dts: rockchip: add product-data eeproms to QNAP TS433
The device contains two i2c-connected eeproms holding some product-
specific values. One sitting on the mainboard and one on the statically
connected backplane.
While the eeprom chips themself have a size of 512 byte, the eeprom data
only uses 256 byte each, probably to stay compatible with other models.
Heiko Stuebner [Mon, 28 Oct 2024 19:00:32 +0000 (20:00 +0100)]
arm64: dts: rockchip: actually enable pmu-io-domains on qnap-ts433
Contrary to the vendor-kernel the pmu-io-domains are not enabled by
default. This resulted in the value not being set according to the
regulator, which in turn made the gmac0 interface that is connected
to the vccio4 supply inoperable.
Uwe Kleine-König [Mon, 28 Oct 2024 19:00:31 +0000 (20:00 +0100)]
arm64: dts: rockchip: Simplify network PHY connection on qnap-ts433
While it requires to have the right phy driver loaded (i.e. motorcomm)
to make the phy asserting the right delays, this is generally the
preferred way to define the MAC <-> PHY connection.
Heiko Stuebner [Mon, 28 Oct 2024 19:00:28 +0000 (20:00 +0100)]
arm64: dts: rockchip: add missing pmic information on Qnap-TS433
Fill in the missing pieces for RK809 pmic used on the TS433.
The regulator setup comes from the vendor-devicetree, so without proper
schematics its accuracy is somewhat unclear, but it looks really similar
to all the other rk3568 boards, so follows the reference design it seems.
The one caveat is related to vcc3v3_sd. This regulator needs to stay on.
When turned off because of no users, access to both PCIe controllers
will stall. Maybe this rail does supply the 100MHz refclk generation
or so.
Heiko Stuebner [Mon, 28 Oct 2024 19:00:27 +0000 (20:00 +0100)]
arm64: dts: rockchip: define cpu-supply on the Qnap-TS433
The TS433 seems to use a silergy,syr827 regulator for the cpu supply.
At least that is the compatible used in the vendor devicetree, though
it could very well also be another fan53555 clone.
Define the needed regulator node and hook up the cpu-supply to the
cpu cores.
Heiko Stuebner [Mon, 28 Oct 2024 19:00:26 +0000 (20:00 +0100)]
arm64: dts: rockchip: add gpio-keys to Qnap-TS433
The TS433 has 3 buttons, power and copy in the front as well as a reset
pinhole button on the back. The power-button is connected to the embedded
controller while the other two buttons are just gpio connected.
Add the gpio-keys definition for the two buttons we can handle right now.
Heiko Stuebner [Mon, 28 Oct 2024 19:00:23 +0000 (20:00 +0100)]
arm64: dts: rockchip: add board-aliases for Qnap-TS433
Add the aliases for the internal network interface as well as the emmc
on the board and make sure the dedicated RTC is always the first one.
The TS433 actually has two rtc devices. One coming from the rk809 pmic
without added functionality and also a dedicated RTC from Mycrocrystal
that is battery backed to keep the time.
Heiko Stuebner [Mon, 28 Oct 2024 19:00:22 +0000 (20:00 +0100)]
arm64: dts: rockchip: enable sata1+2 on Qnap-TS433
The TS433 has 4 bays. The last two are accessed via a pci-connected
sata controller, while the first two are accessed via the rk3568's
sata controllers. Enable these two now.
Heiko Stuebner [Mon, 28 Oct 2024 19:00:18 +0000 (20:00 +0100)]
arm64: dts: rockchip: enable second PCIe controller on the Qnap-TS433
The TS433 uses both pcie controllers for sata and the 2nd network
interface. Set the needed data-lanes in the pcie3 phy and enable
the second pcie controller, as well as remove the bifurcation comment.
Michal Simek [Fri, 1 Nov 2024 09:50:45 +0000 (10:50 +0100)]
riscv: Introduce configuration for 64bit version Microblaze V
The commit 7576ab2facae ("riscv: Add support for AMD/Xilinx MicroBlaze V")
added support for 32bit version. 64bit version is also available that's why
wire it up too.
DT is providing description for generic QEMU target.
Signed-off-by: Michal Simek <michal.simek@amd.com> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
projects / u-boot.git / log
