Signed-off-by: Tom Rini <trini@konsulko.com>
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. [1] https://lore.kernel.org/u-boot/20240826115940.3233167-1-sughosh.ganu@linaro.org/ [2] https://lore.kernel.org/u-boot/20241031-iommu_apple_dart_ordering-v1-0-8a6877946d6b@jannau.net/ Link: https://lore.kernel.org/r/20241111-io_lmb_apple_dart_iommu-v3-0-32c05da51d72@jannau.net Signed-off-by: Tom Rini <trini@konsulko.com>
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>
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.
Signed-off-by: Janne Grunau <j@jannau.net>
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. Signed-off-by: Janne Grunau <j@jannau.net>
It will be re-used with a lmb list pointer as argument for IOVA allocations in the apple_dart iommu driver. Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Janne Grunau <j@jannau.net>
CI: https://source.denx.de/u-boot/custodians/u-boot-rockchip/-/pipelines/23280
- Add board:
rk3328: FriendlyElec NanoPi R2S Plus
rk3568: Qnap TS433
rk3588: Cool Pi CM5 GenBook
- Move rk3399_force_power_on_reset to TPL for puma board;
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... U-Boot SPL 2025.01-rc1-00165-gd79216ca9878-dirty (Nov 05 2024 - 15:31:45 +0100) Trying to boot from MMC2 U-Boot TPL 2025.01-rc1-00165-gd79216ca9878-dirty (Nov 05 2024 - 15:31:45) """ possibly hinting at an issue within the SPL when loading the fitImage from MMC2 instead of the normal course of events (a system reset). Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Paul Kocialkowski <paulk@sys-base.io> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
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>
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>