HoneyComb and ClearFog systems booting with UEFI and ACPI are almost fully supported on any distribution that is using the 5.14 kernel and newer. There are a few quirks that are still needed while we work to mainline the patches needed for full support of the board. Current distros that work with a minimal set of quirks are, Fedora 35 and newer, Debian Bookworm, Ubuntu 22.04 Jammy JellyFish, Centos Stream 9, OpenSuse Leap 15.3.
Until the latest IORT RMR patches are accepted into the mainline kernel (this has been an ongoing process for over 14 months as of this writing) You will need to add the following bootargs to your linux kernel commandline, arm-smmu.disable_bypass=0 iommu.passthrough=1 This is especially important for installation as without it the LX2160a networking driver will produce excessive SMMU errors in the logs and slow the entire distribution down. With this option set networking will be fully functional.
If you are planning to use a GPU with your board we recommend an AMD Radeon GPU that is Polaris generation or older. For Nvidia GPUs only the GT 7xx series is supported well enough with OSS drivers to be useable. Following are useful GPU quirks.
AMD:
- There are some quirks with using the default mesa drivers and Xorg/Xwayland on HoneyComb. If your distro uses a graphical installer then I recommend you disable the amdgpu driver at installation time and use software rendering with the UEFI GOP framebuffer. This can be done by adding
modprobe.blacklist=amdgputo the kernel commandline. - After installation to fix the issues with Xorg/Xwayland there is a patch for the radeonsi driver that forces persistent storage buffers to GTT memory, Mesa corruption and performance fix for HoneyComb with Polaris graphics cards · GitHub This patch has been proposed to mainline mesa but there has been no movement on it. If you have a recent distro that has mesa 22.0 installed you can alternatively use a driconf file to work around this issue, Workaround X11 corruption with amdgpu on HoneyComb with mesa 22 · GitHub
- Other graphical artifacts can arise due to a write-combining hazard that occurs with glibc’s memcpy writing to memmapped PCIe memory. This can be worked around by using a ld’s preload mechanism with a modified memcpy implementation found here, GitHub - jnettlet/cortex_a72_memcpy: Simple patched glibc memcpy implementation to fix issues with Cortex-A72 and device memory.
NVIDIA
- Currently the Nvidia binary Aarch64 driver does not function with HoneyComb. The kernel module will build and load, however when you try to initialize the driver the binary code errors out.
- The in kernel nouveau driver does function properly if the edk2 firmware source is built with x86emu option. This is not built by default as the SystemReady spec does not allow driver emulation in the firmware.
- The downside of the nouveau driver is that it only supports clock control for the GT 7xx series graphics cards. Anything newer than that you will only get the base clock speed which tend to be quite slow.
- With the Nvidia GPUs we do also recommend to use the above cortex_a72_memcpy library.
Networking support
With kernel versions 5.14 and newer the 1Gbps RJ45 interface will work out of the box. If you would like to use the 10Gbps networking interfaces then you will need to install NXP’s restool utility to intialize the SFP+ interfaces. Fedora has this utility packaged and can be dnf installed, otherwise the source can be downloaded and compiled here, qoriq-components/restool - DPAA2 Resource Management Tool You can follow NXP’s documentation regarding configuration.
What doesn’t have mainline ACPI support yet
- SMMU support. The fsl-mc packet processor requires host DRAM to function so needs the SMMU configurated to allow it to access this address space. The spec for this is done in ACPI using the IORT table and specifically RMR’s (Reserved Memory Regions). Linux maintainer’s rejected Arm’s spec for this and over the past year the spec has been reworked so that hopefully this ACPI feature will be accepted into mainline and the above workarounds will no longer be needed.
- I2C clocking. While I2C is functional it is running at a very slow speed due to hard-coded values in the Linux kernel. Rather than an immediate fix Arm has again worked on another spec change for specifying simple device clocking via methods in AML. This spec has been approved however there is no code merged to take advantage of it yet.
- SDHC/MMC. This has the same issue as I2C and should be resolved when the same infrastructure code is merged.
Please feel free to post any distro specific questions, or hints below. We will be updating this thread as bugs are resolved, or new features are added.