Janne Grunau <j@jannau.net> says:
Starting with v2024.10 dev_iommu_dma_unmap calls during device removal
trigger a NULL pointer dereference in the Apple dart iommu driver. The
iommu device is removed before its user. The sparsely used DM_FLAG_VITAL
flag is intended to describe this dependency. Add it to the driver.
Adding this flag is unfortunately not enough since the boot routines
except the arm one simply remove all drivers. Add and use a new function
which calls
dm_remove_devioce_flags(DM_REMOVE_ACTIVE_ALL | DM_REMOVE_NON_VITAL);
dm_remove_devices_flags(DM_REMOVE_ACTIVE_ALL);
to ensure this order dependency is head consistently.
Link: https://lore.kernel.org/r/20241123-iommu_apple_dart_ordering-v2-0-cc2ade6dde97@jannau.net
Avoids NULL pointer dereferences in apple_dart_unmap when the iommu
device is removed before its user. U-boot's device model does not track
dependencies between devices.
Observed on a M1 Ultra Mac Studio with v2024.10.
Acked-by: Mark Kettenis <kettenis@openbsd.org>
Signed-off-by: Janne Grunau <j@jannau.net>
We only need to configure the SMMU when running in EL1. In EL2 the
hypervisor isn't running so peripherals can just do DMA as they wish.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
It turns out this is a very real stream ID. Who woulda thought?
Drop the 0 check on the SID, there's no reason for it to be there in the first
place.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
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: ed17a33fed ("lmb: make LMB memory map persistent and global")
Signed-off-by: Janne Grunau <j@jannau.net>
This soc doesn't have the generic compatible.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
The sandbox iommu driver uses the LMB module to allocate a particular
range of memory for the device virtual address(DVA). This used to work
earlier since the LMB memory map was caller specific and not
global. But with the change to make the LMB allocations global and
persistent, adding this memory range has other side effects. On the
other hand, the sandbox iommu test expects to see this particular
value of the DVA. Use the DVA address directly, instead of mapping it
in the LMB memory map, and then have it allocated.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
The current LMB API's for allocating and reserving memory use a
per-caller based memory view. Memory allocated by a caller can then be
overwritten by another caller. Make these allocations and reservations
persistent using the alloced list data structure.
Two alloced lists are declared -- one for the available(free) memory,
and one for the used memory. Once full, the list can then be extended
at runtime.
[sjg: Use a stack to store pointer of lmb struct when running lmb tests]
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
[sjg: Optimise the logic to add a region in lmb_add_region_flags()]
As part of bringing the master branch back in to next, we need to allow
for all of these changes to exist here.
Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay
Ethernet"' I failed to notice that b4 noticed it was based on next and
so took that as the base commit and merged that part of next to master.
This reverts commit c8ffd1356d, reversing
changes made to 2ee6f3a5f7.
Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
With the exception of SDM845, most other Qualcomm SoCs have the Qualcomm
specific (but not SoC) specific SMMU compatible string. Add it here so
we can match those without having to add individual SoCs to the list
here.
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
When attempting to probe a device which has an associated IOMMU, if the
IOMMU device can't be found (no driver, disabled driver, driver failed
to probe, etc) then we currently fail to probe the device with no
discernable error.
If we fail to hook the device up to its IOMMU, we should make sure that
the user knows about it. Write some better error messages for
dev_iommu_enable() to facilitate this.
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
Add a basic implementation of the ARM SMMU. This driver is intended for
use on Qualcomm platforms where the SMMU has been configured by a previous
bootloader, cannot be turned off, and doesn't support BYPASS streams.
It keeps all existing stream mappings and only creates new ones for stream
ids that aren't already configured.
This driver is necessary to support peripherals that perform DMA which
weren't configured by the previous stage bootloader (for example USB).
It works by allocating a context bank using identity mapping (as U-Boot
doesn't use virtual addresses).
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
Add an optional iommu callback to be invoked before a device probes.
This can be used to configure the IOMMU in preparation for the device
(e.g. by allocating a context bank)
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
The dev_pci_iommu_enable() function is only available when CONFIG_PCI is
enabled, replace the runtime check with a preprocessor one to fix
compilation with pci disabled.
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
Systems such as Apple's M1 and M2 SoCs may have separate IOMMUs
for each PCIe root port. In this case the right IOMMU for a
PCI device behind a particular root port is described by an
"iommu-map" property in the device tree. Parse this property
and use it to find the right IOMMU device for PCI devices.
Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
Implement translation table support for all the variations of
Apple's DART IOMMU that can be found on Apple's M1 and M2 SoCs.
Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
Test that the map and unmap operations work for devices that
have DMA translated by an IOMMU and devices that don't have
DMA translated by an IOMMU.
Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
In order to support IOMMUs in non-bypass mode we need device ops
to map and unmap DMA memory. The map operation enters a mapping
for a region specified by CPU address and size into the translation
table of the IOMMU and returns a DMA address suitable for
programming the device to do DMA. The unmap operation removes
this mapping from the translation table of the IOMMU.
Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
"apple,t8112-dart" uses an incompatible register interface but still
offers the same functionality. This DART is found on the M2 and M1
Pro/Max/Ultra SoCs.
Signed-off-by: Janne Grunau <j@jannau.net>
Reviewed-by: Mark Kettenis <kettenis@openbsd.org>
For the purpose of this driver (activating bypass mode) t6000-dart
and t8103-dart are fully compatible.
Signed-off-by: Janne Grunau <j@jannau.net>
Reviewed-by: Mark Kettenis <kettenis@openbsd.org>
The DART is an IOMMU that is used on Apple's M1 SoC. This driver
configures the DART such that it operates in bypass mode which is
enough to support DMA for the USB3 ports integrated on the SoC.
Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
This uclass is intended to manage IOMMUs on systems where the
IOMMUs are not in bypass mode by default. In that case U-Boot
cannot ignore the IOMMUs if it wants to use devices that need
to do DMA and sit behind such an IOMMU.
This initial IOMMU uclass implementation does not implement and
device ops and is intended for IOMMUs that have a bypass mode
that does not require address translation. Support for IOMMUs
that do require address translation is planned and device ops
will be defined when support for such IOMMUs will be added.
Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
