Hi all, This patchset adds support for our (Traverse) Ten64 board, which is an ARM64 networking board using NXP's LS1088A SoC.
I have been intending to do this for a very long time but was waiting for the kernel version to be upgraded to 5.10 or above given the significant amount of work that has been done upstream for this hardware in recent times.
There are four components to this patch: 1: Enable the relevant kernel options for our box This follows our doc at https://ten64doc.traverse.com.au/kernel/
2: Add patches to fully support SFP+ One of these patches came in after 5.15+, while the other fixes a deadlock issue that occurs when detaching/unloading the SFP+ ports (such as rebooting the system). Unfortunately this issue has been stalled upstream without resolution for a while now.
3: Fix our real time clock (rtc-rx8025) not being modprobed I haven't been able to figure out why our RTC driver does not get loaded, given every other relevant module (like GPIO, I2C) does get loaded.
If there is a better way to do this, feel free to NAK and suggest a better method.
4: Bypass the u-boot bootscript on Ten64 The Ten64 uses u-boot which has both EFI and classic 'distroboot' support. We much prefer to boot EFI as this provides some benefits, such as not having to supply your own device tree.
A quirk of the Ten64 implementation (related to how the IOMMU hardware is configured) is that a "failed" bootscript will block the boot of other types (like EFI), so detect if we are on a Ten64 and jump straight to GRUB.
My intention is to prioritize EFI always in a future Ten64 firmware release so this doesn't happen, at which point this hack can be removed. (Removing boot.scr does the same thing, but I prefer that it will boot out of the box without modification)
Here is the fireinfo from a Ten64: https://fireinfo.ipfire.org/profile/97f7fd96a529ca2e5488ab095b7d9effe67d0ef3 (Note to self: I should figure out how to improve the fireinfo output on ARM platforms)
I have also tested this on an AWS Graviton (ARM64) instance to verify there are no regressions on other "standard" (EFI-capable) ARM64 systems.
Mathew McBride (4): linux: enable options for NXP Layerscape kernel: add patches for SFP support on NXP Layerscape/DPAA2 (arm64) config: u-boot: bypass the u-boot script on Traverse Ten64 initscripts: load RTC module (RX8025) for Ten64 board:w
config/kernel/kernel.config.aarch64-ipfire | 76 +++++++++++++---- config/u-boot/boot.cmd | 9 +++ lfs/linux | 3 + src/initscripts/system/setclock | 8 ++ ...rm64-dpaa2-add-support-for-10g-modes.patch | 39 +++++++++ ...inux-5.15-arm64-dpaa2-fix-lock-issue.patch | 81 +++++++++++++++++++ 6 files changed, 202 insertions(+), 14 deletions(-) create mode 100644 src/patches/linux/linux-5-15-arm64-dpaa2-add-support-for-10g-modes.patch create mode 100644 src/patches/linux/linux-5.15-arm64-dpaa2-fix-lock-issue.patch
This change enables support for NXP's QorIQ/Layerscape platforms, specifically the Traverse Technologies Ten64 (LS1088A).
Signed-off-by: Mathew McBride matt@traverse.com.au --- config/kernel/kernel.config.aarch64-ipfire | 76 ++++++++++++++++++---- 1 file changed, 62 insertions(+), 14 deletions(-)
diff --git a/config/kernel/kernel.config.aarch64-ipfire b/config/kernel/kernel.config.aarch64-ipfire index 836e2b15f..ea8c87c9c 100644 --- a/config/kernel/kernel.config.aarch64-ipfire +++ b/config/kernel/kernel.config.aarch64-ipfire @@ -297,7 +297,7 @@ CONFIG_ARCH_BERLIN=y # CONFIG_ARCH_EXYNOS is not set # CONFIG_ARCH_SPARX5 is not set # CONFIG_ARCH_K3 is not set -# CONFIG_ARCH_LAYERSCAPE is not set +CONFIG_ARCH_LAYERSCAPE=y # CONFIG_ARCH_LG1K is not set # CONFIG_ARCH_HISI is not set # CONFIG_ARCH_KEEMBAY is not set @@ -372,9 +372,9 @@ CONFIG_SOCIONEXT_SYNQUACER_PREITS=y CONFIG_ARM64_4K_PAGES=y # CONFIG_ARM64_16K_PAGES is not set # CONFIG_ARM64_64K_PAGES is not set -CONFIG_ARM64_VA_BITS_39=y -# CONFIG_ARM64_VA_BITS_48 is not set -CONFIG_ARM64_VA_BITS=39 +# CONFIG_ARM64_VA_BITS_39 is not set +CONFIG_ARM64_VA_BITS_48=y +CONFIG_ARM64_VA_BITS=48 CONFIG_ARM64_PA_BITS_48=y CONFIG_ARM64_PA_BITS=48 # CONFIG_CPU_BIG_ENDIAN is not set @@ -559,6 +559,7 @@ CONFIG_ARM_ARMADA_37XX_CPUFREQ=m CONFIG_ARM_ARMADA_8K_CPUFREQ=m CONFIG_ARM_IMX_CPUFREQ_DT=m CONFIG_ARM_SCMI_CPUFREQ=m +CONFIG_QORIQ_CPUFREQ=m # end of CPU Frequency scaling # end of CPU Power Management
@@ -1759,6 +1760,7 @@ CONFIG_PCIE_DW_HOST=y CONFIG_PCIE_DW_PLAT=y CONFIG_PCIE_DW_PLAT_HOST=y CONFIG_PCI_IMX6=y +CONFIG_PCI_LAYERSCAPE=y # CONFIG_PCI_HISI is not set # CONFIG_PCIE_ARMADA_8K is not set CONFIG_PCIE_ROCKCHIP_DW_HOST=y @@ -1770,6 +1772,7 @@ CONFIG_PCIE_AL=y # # Mobiveil PCIe Core Support # +# CONFIG_PCIE_LAYERSCAPE_GEN4 is not set # end of Mobiveil PCIe Core Support
# @@ -1846,6 +1849,8 @@ CONFIG_GENERIC_ARCH_TOPOLOGY=y CONFIG_SUN50I_DE2_BUS=y CONFIG_SUNXI_RSB=y CONFIG_VEXPRESS_CONFIG=y +CONFIG_FSL_MC_BUS=y +CONFIG_FSL_MC_UAPI_SUPPORT=y CONFIG_MHI_BUS=m # CONFIG_MHI_BUS_PCI_GENERIC is not set # end of Bus devices @@ -2596,9 +2601,14 @@ CONFIG_NET_VENDOR_EZCHIP=y CONFIG_EZCHIP_NPS_MANAGEMENT_ENET=m CONFIG_NET_VENDOR_FREESCALE=y CONFIG_FEC=m +CONFIG_FSL_FMAN=m +CONFIG_DPAA_ERRATUM_A050385=y CONFIG_FSL_PQ_MDIO=m CONFIG_FSL_XGMAC_MDIO=m CONFIG_GIANFAR=m +CONFIG_FSL_DPAA_ETH=m +CONFIG_FSL_DPAA2_ETH=m +# CONFIG_FSL_DPAA2_PTP_CLOCK is not set CONFIG_FSL_DPAA2_SWITCH=m CONFIG_FSL_ENETC=m CONFIG_FSL_ENETC_VF=m @@ -3597,7 +3607,7 @@ CONFIG_I2C_CBUS_GPIO=m CONFIG_I2C_GPIO=m # CONFIG_I2C_GPIO_FAULT_INJECTOR is not set CONFIG_I2C_HISI=m -# CONFIG_I2C_IMX is not set +CONFIG_I2C_IMX=m CONFIG_I2C_IMX_LPI2C=m CONFIG_I2C_MESON=m CONFIG_I2C_MV64XXX=y @@ -3759,6 +3769,7 @@ CONFIG_GPIO_SYSFS=y CONFIG_GPIO_CDEV=y CONFIG_GPIO_CDEV_V1=y CONFIG_GPIO_GENERIC=y +CONFIG_GPIO_REGMAP=m
# # Memory mapped GPIO drivers @@ -3777,6 +3788,7 @@ CONFIG_GPIO_GENERIC_PLATFORM=y # CONFIG_GPIO_HLWD is not set # CONFIG_GPIO_LOGICVC is not set # CONFIG_GPIO_MB86S7X is not set +CONFIG_GPIO_MPC8XXX=y CONFIG_GPIO_MVEBU=y CONFIG_GPIO_MXC=m CONFIG_GPIO_PL061=y @@ -3797,7 +3809,8 @@ CONFIG_GPIO_ADNP=m # CONFIG_GPIO_GW_PLD is not set # CONFIG_GPIO_MAX7300 is not set # CONFIG_GPIO_MAX732X is not set -# CONFIG_GPIO_PCA953X is not set +CONFIG_GPIO_PCA953X=m +CONFIG_GPIO_PCA953X_IRQ=y # CONFIG_GPIO_PCA9570 is not set # CONFIG_GPIO_PCF857X is not set # CONFIG_GPIO_TPIC2810 is not set @@ -4305,6 +4318,8 @@ CONFIG_MFD_RK808=y # CONFIG_MFD_RN5T618 is not set # CONFIG_MFD_SEC_CORE is not set # CONFIG_MFD_SI476X_CORE is not set +CONFIG_MFD_SIMPLE_MFD_I2C=m +# CONFIG_MFD_SL28CPLD is not set CONFIG_MFD_SM501=m CONFIG_MFD_SM501_GPIO=y # CONFIG_MFD_SKY81452 is not set @@ -6412,10 +6427,10 @@ CONFIG_MMC_SDHCI_PLTFM=y CONFIG_MMC_SDHCI_OF_ARASAN=m # CONFIG_MMC_SDHCI_OF_ASPEED is not set # CONFIG_MMC_SDHCI_OF_AT91 is not set -# CONFIG_MMC_SDHCI_OF_ESDHC is not set +CONFIG_MMC_SDHCI_OF_ESDHC=m # CONFIG_MMC_SDHCI_OF_DWCMSHC is not set # CONFIG_MMC_SDHCI_CADENCE is not set -# CONFIG_MMC_SDHCI_ESDHC_IMX is not set +CONFIG_MMC_SDHCI_ESDHC_IMX=m CONFIG_MMC_SDHCI_PXAV3=m # CONFIG_MMC_SDHCI_F_SDH30 is not set # CONFIG_MMC_SDHCI_MILBEAUT is not set @@ -6634,6 +6649,7 @@ CONFIG_RTC_DRV_V3020=m # on-CPU RTC drivers # # CONFIG_RTC_DRV_IMXDI is not set +# CONFIG_RTC_DRV_FSL_FTM_ALARM is not set CONFIG_RTC_DRV_MESON_VRTC=m CONFIG_RTC_DRV_PL030=m CONFIG_RTC_DRV_PL031=m @@ -6692,6 +6708,7 @@ CONFIG_DW_DMAC_PCI=m # CONFIG_DW_EDMA is not set # CONFIG_DW_EDMA_PCIE is not set # CONFIG_SF_PDMA is not set +# CONFIG_FSL_DPAA2_QDMA is not set
# # DMA Clients @@ -6734,6 +6751,7 @@ CONFIG_VFIO_PCI_INTX=y CONFIG_VFIO_PCI=m # CONFIG_VFIO_PLATFORM is not set # CONFIG_VFIO_MDEV is not set +# CONFIG_VFIO_FSL_MC is not set CONFIG_VIRT_DRIVERS=y CONFIG_VIRTIO=y CONFIG_VIRTIO_PCI_LIB=y @@ -6820,8 +6838,12 @@ CONFIG_COMMON_CLK_SI570=m # CONFIG_COMMON_CLK_CDCE706 is not set # CONFIG_COMMON_CLK_CDCE925 is not set # CONFIG_COMMON_CLK_CS2000_CP is not set +CONFIG_COMMON_CLK_FSL_FLEXSPI=m +# CONFIG_COMMON_CLK_FSL_SAI is not set CONFIG_CLK_TWL6040=m # CONFIG_COMMON_CLK_AXI_CLKGEN is not set +CONFIG_CLK_QORIQ=y +CONFIG_CLK_LS1028A_PLLDIG=m CONFIG_COMMON_CLK_XGENE=y # CONFIG_COMMON_CLK_PWM is not set # CONFIG_COMMON_CLK_VC5 is not set @@ -6933,13 +6955,16 @@ CONFIG_IOMMU_SUPPORT=y
CONFIG_IOMMU_DEFAULT_DMA_STRICT=y # CONFIG_IOMMU_DEFAULT_DMA_LAZY is not set -# CONFIG_IOMMU_DEFAULT_PASSTHROUGH is not set +CONFIG_IOMMU_DEFAULT_PASSTHROUGH=y CONFIG_OF_IOMMU=y CONFIG_IOMMU_DMA=y CONFIG_ROCKCHIP_IOMMU=y CONFIG_SUN50I_IOMMU=y -# CONFIG_ARM_SMMU is not set -# CONFIG_ARM_SMMU_V3 is not set +CONFIG_ARM_SMMU=y +# CONFIG_ARM_SMMU_LEGACY_DT_BINDINGS is not set +# CONFIG_ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT is not set +CONFIG_ARM_SMMU_V3=y +# CONFIG_ARM_SMMU_V3_SVA is not set # CONFIG_VIRTIO_IOMMU is not set
# @@ -6983,7 +7008,14 @@ CONFIG_RASPBERRYPI_POWER=y # # NXP/Freescale QorIQ SoC drivers # +CONFIG_FSL_DPAA=y +# CONFIG_FSL_DPAA_CHECKING is not set +# CONFIG_FSL_BMAN_TEST is not set +# CONFIG_FSL_QMAN_TEST is not set # CONFIG_QUICC_ENGINE is not set +CONFIG_FSL_GUTS=y +CONFIG_FSL_MC_DPIO=y +CONFIG_DPAA2_CONSOLE=y # end of NXP/Freescale QorIQ SoC drivers
# @@ -7084,6 +7116,7 @@ CONFIG_ARM_GIC_V2M=y CONFIG_ARM_GIC_V3=y CONFIG_ARM_GIC_V3_ITS=y CONFIG_ARM_GIC_V3_ITS_PCI=y +CONFIG_ARM_GIC_V3_ITS_FSL_MC=y # CONFIG_AL_FIC is not set CONFIG_BRCMSTB_L2_IRQ=y CONFIG_DW_APB_ICTL=y @@ -7093,6 +7126,8 @@ CONFIG_MVEBU_ICU=y CONFIG_MVEBU_ODMI=y CONFIG_MVEBU_PIC=y CONFIG_MVEBU_SEI=y +CONFIG_LS_EXTIRQ=y +CONFIG_LS_SCFG_MSI=y CONFIG_PARTITION_PERCPU=y CONFIG_MESON_IRQ_GPIO=y CONFIG_IMX_IRQSTEER=y @@ -7620,7 +7655,7 @@ CONFIG_CRYPTO_NULL=y CONFIG_CRYPTO_NULL2=y CONFIG_CRYPTO_PCRYPT=m CONFIG_CRYPTO_CRYPTD=y -CONFIG_CRYPTO_AUTHENC=m +CONFIG_CRYPTO_AUTHENC=y CONFIG_CRYPTO_TEST=m CONFIG_CRYPTO_SIMD=m CONFIG_CRYPTO_ENGINE=m @@ -7658,7 +7693,7 @@ CONFIG_CRYPTO_ECB=y CONFIG_CRYPTO_LRW=m # CONFIG_CRYPTO_OFB is not set CONFIG_CRYPTO_PCBC=m -CONFIG_CRYPTO_XTS=m +CONFIG_CRYPTO_XTS=y # CONFIG_CRYPTO_KEYWRAP is not set CONFIG_CRYPTO_NHPOLY1305=m # CONFIG_CRYPTO_ADIANTUM is not set @@ -7750,7 +7785,20 @@ CONFIG_CRYPTO_DEV_ALLWINNER=y # CONFIG_CRYPTO_DEV_SUN4I_SS is not set # CONFIG_CRYPTO_DEV_SUN8I_CE is not set # CONFIG_CRYPTO_DEV_SUN8I_SS is not set -# CONFIG_CRYPTO_DEV_FSL_CAAM is not set +CONFIG_CRYPTO_DEV_FSL_CAAM_COMMON=y +CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API_DESC=y +CONFIG_CRYPTO_DEV_FSL_CAAM_AHASH_API_DESC=y +CONFIG_CRYPTO_DEV_FSL_CAAM=m +# CONFIG_CRYPTO_DEV_FSL_CAAM_DEBUG is not set +CONFIG_CRYPTO_DEV_FSL_CAAM_JR=m +CONFIG_CRYPTO_DEV_FSL_CAAM_RINGSIZE=9 +# CONFIG_CRYPTO_DEV_FSL_CAAM_INTC is not set +CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API=y +CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API_QI=y +CONFIG_CRYPTO_DEV_FSL_CAAM_AHASH_API=y +CONFIG_CRYPTO_DEV_FSL_CAAM_PKC_API=y +CONFIG_CRYPTO_DEV_FSL_CAAM_RNG_API=y +CONFIG_CRYPTO_DEV_FSL_DPAA2_CAAM=y # CONFIG_CRYPTO_DEV_SAHARA is not set # CONFIG_CRYPTO_DEV_ATMEL_ECC is not set # CONFIG_CRYPTO_DEV_ATMEL_SHA204A is not set
Reviewed-by: Michael Tremer michael.tremer@ipfire.org
On 3 Oct 2022, at 07:20, Mathew McBride matt@traverse.com.au wrote:
This change enables support for NXP's QorIQ/Layerscape platforms, specifically the Traverse Technologies Ten64 (LS1088A).
Signed-off-by: Mathew McBride matt@traverse.com.au
config/kernel/kernel.config.aarch64-ipfire | 76 ++++++++++++++++++---- 1 file changed, 62 insertions(+), 14 deletions(-)
diff --git a/config/kernel/kernel.config.aarch64-ipfire b/config/kernel/kernel.config.aarch64-ipfire index 836e2b15f..ea8c87c9c 100644 --- a/config/kernel/kernel.config.aarch64-ipfire +++ b/config/kernel/kernel.config.aarch64-ipfire @@ -297,7 +297,7 @@ CONFIG_ARCH_BERLIN=y # CONFIG_ARCH_EXYNOS is not set # CONFIG_ARCH_SPARX5 is not set # CONFIG_ARCH_K3 is not set -# CONFIG_ARCH_LAYERSCAPE is not set +CONFIG_ARCH_LAYERSCAPE=y # CONFIG_ARCH_LG1K is not set # CONFIG_ARCH_HISI is not set # CONFIG_ARCH_KEEMBAY is not set @@ -372,9 +372,9 @@ CONFIG_SOCIONEXT_SYNQUACER_PREITS=y CONFIG_ARM64_4K_PAGES=y # CONFIG_ARM64_16K_PAGES is not set # CONFIG_ARM64_64K_PAGES is not set -CONFIG_ARM64_VA_BITS_39=y -# CONFIG_ARM64_VA_BITS_48 is not set -CONFIG_ARM64_VA_BITS=39 +# CONFIG_ARM64_VA_BITS_39 is not set +CONFIG_ARM64_VA_BITS_48=y +CONFIG_ARM64_VA_BITS=48 CONFIG_ARM64_PA_BITS_48=y CONFIG_ARM64_PA_BITS=48 # CONFIG_CPU_BIG_ENDIAN is not set @@ -559,6 +559,7 @@ CONFIG_ARM_ARMADA_37XX_CPUFREQ=m CONFIG_ARM_ARMADA_8K_CPUFREQ=m CONFIG_ARM_IMX_CPUFREQ_DT=m CONFIG_ARM_SCMI_CPUFREQ=m +CONFIG_QORIQ_CPUFREQ=m # end of CPU Frequency scaling # end of CPU Power Management
@@ -1759,6 +1760,7 @@ CONFIG_PCIE_DW_HOST=y CONFIG_PCIE_DW_PLAT=y CONFIG_PCIE_DW_PLAT_HOST=y CONFIG_PCI_IMX6=y +CONFIG_PCI_LAYERSCAPE=y # CONFIG_PCI_HISI is not set # CONFIG_PCIE_ARMADA_8K is not set CONFIG_PCIE_ROCKCHIP_DW_HOST=y @@ -1770,6 +1772,7 @@ CONFIG_PCIE_AL=y # # Mobiveil PCIe Core Support # +# CONFIG_PCIE_LAYERSCAPE_GEN4 is not set # end of Mobiveil PCIe Core Support
# @@ -1846,6 +1849,8 @@ CONFIG_GENERIC_ARCH_TOPOLOGY=y CONFIG_SUN50I_DE2_BUS=y CONFIG_SUNXI_RSB=y CONFIG_VEXPRESS_CONFIG=y +CONFIG_FSL_MC_BUS=y +CONFIG_FSL_MC_UAPI_SUPPORT=y CONFIG_MHI_BUS=m # CONFIG_MHI_BUS_PCI_GENERIC is not set # end of Bus devices @@ -2596,9 +2601,14 @@ CONFIG_NET_VENDOR_EZCHIP=y CONFIG_EZCHIP_NPS_MANAGEMENT_ENET=m CONFIG_NET_VENDOR_FREESCALE=y CONFIG_FEC=m +CONFIG_FSL_FMAN=m +CONFIG_DPAA_ERRATUM_A050385=y CONFIG_FSL_PQ_MDIO=m CONFIG_FSL_XGMAC_MDIO=m CONFIG_GIANFAR=m +CONFIG_FSL_DPAA_ETH=m +CONFIG_FSL_DPAA2_ETH=m +# CONFIG_FSL_DPAA2_PTP_CLOCK is not set CONFIG_FSL_DPAA2_SWITCH=m CONFIG_FSL_ENETC=m CONFIG_FSL_ENETC_VF=m @@ -3597,7 +3607,7 @@ CONFIG_I2C_CBUS_GPIO=m CONFIG_I2C_GPIO=m # CONFIG_I2C_GPIO_FAULT_INJECTOR is not set CONFIG_I2C_HISI=m -# CONFIG_I2C_IMX is not set +CONFIG_I2C_IMX=m CONFIG_I2C_IMX_LPI2C=m CONFIG_I2C_MESON=m CONFIG_I2C_MV64XXX=y @@ -3759,6 +3769,7 @@ CONFIG_GPIO_SYSFS=y CONFIG_GPIO_CDEV=y CONFIG_GPIO_CDEV_V1=y CONFIG_GPIO_GENERIC=y +CONFIG_GPIO_REGMAP=m
# # Memory mapped GPIO drivers @@ -3777,6 +3788,7 @@ CONFIG_GPIO_GENERIC_PLATFORM=y # CONFIG_GPIO_HLWD is not set # CONFIG_GPIO_LOGICVC is not set # CONFIG_GPIO_MB86S7X is not set +CONFIG_GPIO_MPC8XXX=y CONFIG_GPIO_MVEBU=y CONFIG_GPIO_MXC=m CONFIG_GPIO_PL061=y @@ -3797,7 +3809,8 @@ CONFIG_GPIO_ADNP=m # CONFIG_GPIO_GW_PLD is not set # CONFIG_GPIO_MAX7300 is not set # CONFIG_GPIO_MAX732X is not set -# CONFIG_GPIO_PCA953X is not set +CONFIG_GPIO_PCA953X=m +CONFIG_GPIO_PCA953X_IRQ=y # CONFIG_GPIO_PCA9570 is not set # CONFIG_GPIO_PCF857X is not set # CONFIG_GPIO_TPIC2810 is not set @@ -4305,6 +4318,8 @@ CONFIG_MFD_RK808=y # CONFIG_MFD_RN5T618 is not set # CONFIG_MFD_SEC_CORE is not set # CONFIG_MFD_SI476X_CORE is not set +CONFIG_MFD_SIMPLE_MFD_I2C=m +# CONFIG_MFD_SL28CPLD is not set CONFIG_MFD_SM501=m CONFIG_MFD_SM501_GPIO=y # CONFIG_MFD_SKY81452 is not set @@ -6412,10 +6427,10 @@ CONFIG_MMC_SDHCI_PLTFM=y CONFIG_MMC_SDHCI_OF_ARASAN=m # CONFIG_MMC_SDHCI_OF_ASPEED is not set # CONFIG_MMC_SDHCI_OF_AT91 is not set -# CONFIG_MMC_SDHCI_OF_ESDHC is not set +CONFIG_MMC_SDHCI_OF_ESDHC=m # CONFIG_MMC_SDHCI_OF_DWCMSHC is not set # CONFIG_MMC_SDHCI_CADENCE is not set -# CONFIG_MMC_SDHCI_ESDHC_IMX is not set +CONFIG_MMC_SDHCI_ESDHC_IMX=m CONFIG_MMC_SDHCI_PXAV3=m # CONFIG_MMC_SDHCI_F_SDH30 is not set # CONFIG_MMC_SDHCI_MILBEAUT is not set @@ -6634,6 +6649,7 @@ CONFIG_RTC_DRV_V3020=m # on-CPU RTC drivers # # CONFIG_RTC_DRV_IMXDI is not set +# CONFIG_RTC_DRV_FSL_FTM_ALARM is not set CONFIG_RTC_DRV_MESON_VRTC=m CONFIG_RTC_DRV_PL030=m CONFIG_RTC_DRV_PL031=m @@ -6692,6 +6708,7 @@ CONFIG_DW_DMAC_PCI=m # CONFIG_DW_EDMA is not set # CONFIG_DW_EDMA_PCIE is not set # CONFIG_SF_PDMA is not set +# CONFIG_FSL_DPAA2_QDMA is not set
# # DMA Clients @@ -6734,6 +6751,7 @@ CONFIG_VFIO_PCI_INTX=y CONFIG_VFIO_PCI=m # CONFIG_VFIO_PLATFORM is not set # CONFIG_VFIO_MDEV is not set +# CONFIG_VFIO_FSL_MC is not set CONFIG_VIRT_DRIVERS=y CONFIG_VIRTIO=y CONFIG_VIRTIO_PCI_LIB=y @@ -6820,8 +6838,12 @@ CONFIG_COMMON_CLK_SI570=m # CONFIG_COMMON_CLK_CDCE706 is not set # CONFIG_COMMON_CLK_CDCE925 is not set # CONFIG_COMMON_CLK_CS2000_CP is not set +CONFIG_COMMON_CLK_FSL_FLEXSPI=m +# CONFIG_COMMON_CLK_FSL_SAI is not set CONFIG_CLK_TWL6040=m # CONFIG_COMMON_CLK_AXI_CLKGEN is not set +CONFIG_CLK_QORIQ=y +CONFIG_CLK_LS1028A_PLLDIG=m CONFIG_COMMON_CLK_XGENE=y # CONFIG_COMMON_CLK_PWM is not set # CONFIG_COMMON_CLK_VC5 is not set @@ -6933,13 +6955,16 @@ CONFIG_IOMMU_SUPPORT=y
CONFIG_IOMMU_DEFAULT_DMA_STRICT=y # CONFIG_IOMMU_DEFAULT_DMA_LAZY is not set -# CONFIG_IOMMU_DEFAULT_PASSTHROUGH is not set +CONFIG_IOMMU_DEFAULT_PASSTHROUGH=y CONFIG_OF_IOMMU=y CONFIG_IOMMU_DMA=y CONFIG_ROCKCHIP_IOMMU=y CONFIG_SUN50I_IOMMU=y -# CONFIG_ARM_SMMU is not set -# CONFIG_ARM_SMMU_V3 is not set +CONFIG_ARM_SMMU=y +# CONFIG_ARM_SMMU_LEGACY_DT_BINDINGS is not set +# CONFIG_ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT is not set +CONFIG_ARM_SMMU_V3=y +# CONFIG_ARM_SMMU_V3_SVA is not set # CONFIG_VIRTIO_IOMMU is not set
# @@ -6983,7 +7008,14 @@ CONFIG_RASPBERRYPI_POWER=y # # NXP/Freescale QorIQ SoC drivers # +CONFIG_FSL_DPAA=y +# CONFIG_FSL_DPAA_CHECKING is not set +# CONFIG_FSL_BMAN_TEST is not set +# CONFIG_FSL_QMAN_TEST is not set # CONFIG_QUICC_ENGINE is not set +CONFIG_FSL_GUTS=y +CONFIG_FSL_MC_DPIO=y +CONFIG_DPAA2_CONSOLE=y # end of NXP/Freescale QorIQ SoC drivers
# @@ -7084,6 +7116,7 @@ CONFIG_ARM_GIC_V2M=y CONFIG_ARM_GIC_V3=y CONFIG_ARM_GIC_V3_ITS=y CONFIG_ARM_GIC_V3_ITS_PCI=y +CONFIG_ARM_GIC_V3_ITS_FSL_MC=y # CONFIG_AL_FIC is not set CONFIG_BRCMSTB_L2_IRQ=y CONFIG_DW_APB_ICTL=y @@ -7093,6 +7126,8 @@ CONFIG_MVEBU_ICU=y CONFIG_MVEBU_ODMI=y CONFIG_MVEBU_PIC=y CONFIG_MVEBU_SEI=y +CONFIG_LS_EXTIRQ=y +CONFIG_LS_SCFG_MSI=y CONFIG_PARTITION_PERCPU=y CONFIG_MESON_IRQ_GPIO=y CONFIG_IMX_IRQSTEER=y @@ -7620,7 +7655,7 @@ CONFIG_CRYPTO_NULL=y CONFIG_CRYPTO_NULL2=y CONFIG_CRYPTO_PCRYPT=m CONFIG_CRYPTO_CRYPTD=y -CONFIG_CRYPTO_AUTHENC=m +CONFIG_CRYPTO_AUTHENC=y CONFIG_CRYPTO_TEST=m CONFIG_CRYPTO_SIMD=m CONFIG_CRYPTO_ENGINE=m @@ -7658,7 +7693,7 @@ CONFIG_CRYPTO_ECB=y CONFIG_CRYPTO_LRW=m # CONFIG_CRYPTO_OFB is not set CONFIG_CRYPTO_PCBC=m -CONFIG_CRYPTO_XTS=m +CONFIG_CRYPTO_XTS=y # CONFIG_CRYPTO_KEYWRAP is not set CONFIG_CRYPTO_NHPOLY1305=m # CONFIG_CRYPTO_ADIANTUM is not set @@ -7750,7 +7785,20 @@ CONFIG_CRYPTO_DEV_ALLWINNER=y # CONFIG_CRYPTO_DEV_SUN4I_SS is not set # CONFIG_CRYPTO_DEV_SUN8I_CE is not set # CONFIG_CRYPTO_DEV_SUN8I_SS is not set -# CONFIG_CRYPTO_DEV_FSL_CAAM is not set +CONFIG_CRYPTO_DEV_FSL_CAAM_COMMON=y +CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API_DESC=y +CONFIG_CRYPTO_DEV_FSL_CAAM_AHASH_API_DESC=y +CONFIG_CRYPTO_DEV_FSL_CAAM=m +# CONFIG_CRYPTO_DEV_FSL_CAAM_DEBUG is not set +CONFIG_CRYPTO_DEV_FSL_CAAM_JR=m +CONFIG_CRYPTO_DEV_FSL_CAAM_RINGSIZE=9 +# CONFIG_CRYPTO_DEV_FSL_CAAM_INTC is not set +CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API=y +CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API_QI=y +CONFIG_CRYPTO_DEV_FSL_CAAM_AHASH_API=y +CONFIG_CRYPTO_DEV_FSL_CAAM_PKC_API=y +CONFIG_CRYPTO_DEV_FSL_CAAM_RNG_API=y +CONFIG_CRYPTO_DEV_FSL_DPAA2_CAAM=y # CONFIG_CRYPTO_DEV_SAHARA is not set # CONFIG_CRYPTO_DEV_ATMEL_ECC is not set
# CONFIG_CRYPTO_DEV_ATMEL_SHA204A is not set
2.30.1
These two patches are needed to support SFP's on NXP DPAA2 platforms (e.g Traverse Ten64).
The deadlock issue patch was submitted upstream a while ago and rejected, however I am not aware of any better solutions at present.
The 10G mode additions are part of mainline since 5.16.
These two .patches were sourced from our patchset over here: https://gitlab.com/traversetech/traverse-kernel-patches/-/tree/lts-5-15/patc...
Signed-off-by: Mathew McBride matt@traverse.com.au --- lfs/linux | 3 + ...rm64-dpaa2-add-support-for-10g-modes.patch | 39 +++++++++ ...inux-5.15-arm64-dpaa2-fix-lock-issue.patch | 81 +++++++++++++++++++ 3 files changed, 123 insertions(+) create mode 100644 src/patches/linux/linux-5-15-arm64-dpaa2-add-support-for-10g-modes.patch create mode 100644 src/patches/linux/linux-5.15-arm64-dpaa2-fix-lock-issue.patch
diff --git a/lfs/linux b/lfs/linux index a1b32cc25..3a7dbc91d 100644 --- a/lfs/linux +++ b/lfs/linux @@ -153,6 +153,9 @@ endif ifeq "$(BUILD_ARCH)" "aarch64" # Apply Arm-multiarch kernel patches. cd $(DIR_APP) && xzcat $(DIR_DL)/arm-multi-patches-$(ARM_PATCHES).patch.xz | patch -Np1 + # Apply NXP DPAA2 specific patches + cd $(DIR_APP) && patch -Np1 < $(DIR_SRC)/src/patches/linux/linux-5.15-arm64-dpaa2-fix-lock-issue.patch + cd $(DIR_APP) && patch -Np1 < $(DIR_SRC)/src/patches/linux/linux-5-15-arm64-dpaa2-add-support-for-10g-modes.patch endif cd $(DIR_APP) && patch -Np1 < $(DIR_SRC)/src/patches/linux/linux-3.14.79-amba-fix.patch
diff --git a/src/patches/linux/linux-5-15-arm64-dpaa2-add-support-for-10g-modes.patch b/src/patches/linux/linux-5-15-arm64-dpaa2-add-support-for-10g-modes.patch new file mode 100644 index 000000000..ef8d459b7 --- /dev/null +++ b/src/patches/linux/linux-5-15-arm64-dpaa2-add-support-for-10g-modes.patch @@ -0,0 +1,39 @@ +From c314138bd045e050432158ab021160de3ba51c5e Mon Sep 17 00:00:00 2001 +From: Russell King rmk+kernel@armlinux.org.uk +Date: Thu, 30 Jan 2020 22:42:38 +0000 +Subject: [PATCH 2/4] net: dpaa2-mac: add support for more 10G modes + +Phylink documentation says: + * Note that the PHY may be able to transform from one connection + * technology to another, so, eg, don't clear 1000BaseX just + * because the MAC is unable to BaseX mode. This is more about + * clearing unsupported speeds and duplex settings. The port modes + * should not be cleared; phylink_set_port_modes() will help with this. + +So add the missing 10G modes. + +Signed-off-by: Russell King rmk+kernel@armlinux.org.uk +--- + drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c | 6 ++++++ + 1 file changed, 6 insertions(+) + +diff --git a/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c b/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c +index 8fe32ed4f6dc..3be849cee47b 100644 +--- a/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c ++++ b/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c +@@ -140,6 +140,12 @@ static void dpaa2_mac_validate(struct phylink_config *config, + case PHY_INTERFACE_MODE_10GBASER: + case PHY_INTERFACE_MODE_USXGMII: + phylink_set(mask, 10000baseT_Full); ++ phylink_set(mask, 10000baseKR_Full); ++ phylink_set(mask, 10000baseCR_Full); ++ phylink_set(mask, 10000baseSR_Full); ++ phylink_set(mask, 10000baseLR_Full); ++ phylink_set(mask, 10000baseLRM_Full); ++ phylink_set(mask, 10000baseER_Full); + if (state->interface == PHY_INTERFACE_MODE_10GBASER) + break; + phylink_set(mask, 5000baseT_Full); +-- +2.30.1 + diff --git a/src/patches/linux/linux-5.15-arm64-dpaa2-fix-lock-issue.patch b/src/patches/linux/linux-5.15-arm64-dpaa2-fix-lock-issue.patch new file mode 100644 index 000000000..587821bac --- /dev/null +++ b/src/patches/linux/linux-5.15-arm64-dpaa2-fix-lock-issue.patch @@ -0,0 +1,81 @@ +From 3a39dbe0c0c41f8dba5246ce6e2c5c4bcd6ba661 Mon Sep 17 00:00:00 2001 +From: Ioana Ciornei ioana.ciornei@nxp.com +Date: Thu, 21 Nov 2019 21:15:25 +0200 +Subject: [PATCH 1/4] dpaa2-eth: do not hold rtnl_lock on phylink_create() or + _destroy() + +The rtnl_lock should not be held when calling phylink_create() or +phylink_destroy() since it leads to the deadlock listed below: + +[ 18.656576] rtnl_lock+0x18/0x20 +[ 18.659798] sfp_bus_add_upstream+0x28/0x90 +[ 18.663974] phylink_create+0x2cc/0x828 +[ 18.667803] dpaa2_mac_connect+0x14c/0x2a8 +[ 18.671890] dpaa2_eth_connect_mac+0x94/0xd8 + +Fix this by moving the _lock() and _unlock() calls just outside of +phylink_of_phy_connect() and phylink_disconnect_phy(). + +Fixes: 719479230893 ("dpaa2-eth: add MAC/PHY support through phylink") +Reported-by: Russell King linux@armlinux.org.uk +Signed-off-by: Ioana Ciornei ioana.ciornei@nxp.com +Signed-off-by: Russell King rmk+kernel@armlinux.org.uk +--- + drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c | 4 ---- + drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c | 4 ++++ + 2 files changed, 4 insertions(+), 4 deletions(-) + +diff --git a/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c b/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c +index 8b7a29e1e221..20e65053f036 100644 +--- a/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c ++++ b/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c +@@ -4214,12 +4214,10 @@ static irqreturn_t dpni_irq0_handler_thread(int irq_num, void *arg) + dpaa2_eth_set_mac_addr(netdev_priv(net_dev)); + dpaa2_eth_update_tx_fqids(priv); + +- rtnl_lock(); + if (dpaa2_eth_has_mac(priv)) + dpaa2_eth_disconnect_mac(priv); + else + dpaa2_eth_connect_mac(priv); +- rtnl_unlock(); + } + + return IRQ_HANDLED; +@@ -4513,9 +4511,7 @@ static int dpaa2_eth_remove(struct fsl_mc_device *ls_dev) + #endif + + unregister_netdev(net_dev); +- rtnl_lock(); + dpaa2_eth_disconnect_mac(priv); +- rtnl_unlock(); + + dpaa2_eth_dl_port_del(priv); + dpaa2_eth_dl_traps_unregister(priv); +diff --git a/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c b/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c +index ae6d382d8735..8fe32ed4f6dc 100644 +--- a/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c ++++ b/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c +@@ -351,7 +351,9 @@ int dpaa2_mac_connect(struct dpaa2_mac *mac) + if (mac->pcs) + phylink_set_pcs(mac->phylink, &mac->pcs->pcs); + ++ rtnl_lock(); + err = phylink_fwnode_phy_connect(mac->phylink, dpmac_node, 0); ++ rtnl_unlock(); + if (err) { + netdev_err(net_dev, "phylink_fwnode_phy_connect() = %d\n", err); + goto err_phylink_destroy; +@@ -372,7 +374,9 @@ void dpaa2_mac_disconnect(struct dpaa2_mac *mac) + if (!mac->phylink) + return; + ++ rtnl_lock(); + phylink_disconnect_phy(mac->phylink); ++ rtnl_unlock(); + phylink_destroy(mac->phylink); + dpaa2_pcs_destroy(mac); + } +-- +2.30.1 +
Reviewed-by: Michael Tremer michael.tremer@ipfire.org
On 3 Oct 2022, at 07:20, Mathew McBride matt@traverse.com.au wrote:
These two patches are needed to support SFP's on NXP DPAA2 platforms (e.g Traverse Ten64).
The deadlock issue patch was submitted upstream a while ago and rejected, however I am not aware of any better solutions at present.
The 10G mode additions are part of mainline since 5.16.
These two .patches were sourced from our patchset over here: https://gitlab.com/traversetech/traverse-kernel-patches/-/tree/lts-5-15/patc...
Signed-off-by: Mathew McBride matt@traverse.com.au
lfs/linux | 3 + ...rm64-dpaa2-add-support-for-10g-modes.patch | 39 +++++++++ ...inux-5.15-arm64-dpaa2-fix-lock-issue.patch | 81 +++++++++++++++++++ 3 files changed, 123 insertions(+) create mode 100644 src/patches/linux/linux-5-15-arm64-dpaa2-add-support-for-10g-modes.patch create mode 100644 src/patches/linux/linux-5.15-arm64-dpaa2-fix-lock-issue.patch
diff --git a/lfs/linux b/lfs/linux index a1b32cc25..3a7dbc91d 100644 --- a/lfs/linux +++ b/lfs/linux @@ -153,6 +153,9 @@ endif ifeq "$(BUILD_ARCH)" "aarch64" # Apply Arm-multiarch kernel patches. cd $(DIR_APP) && xzcat $(DIR_DL)/arm-multi-patches-$(ARM_PATCHES).patch.xz | patch -Np1
- # Apply NXP DPAA2 specific patches
- cd $(DIR_APP) && patch -Np1 < $(DIR_SRC)/src/patches/linux/linux-5.15-arm64-dpaa2-fix-lock-issue.patch
- cd $(DIR_APP) && patch -Np1 < $(DIR_SRC)/src/patches/linux/linux-5-15-arm64-dpaa2-add-support-for-10g-modes.patch
endif cd $(DIR_APP) && patch -Np1 < $(DIR_SRC)/src/patches/linux/linux-3.14.79-amba-fix.patch
diff --git a/src/patches/linux/linux-5-15-arm64-dpaa2-add-support-for-10g-modes.patch b/src/patches/linux/linux-5-15-arm64-dpaa2-add-support-for-10g-modes.patch new file mode 100644 index 000000000..ef8d459b7 --- /dev/null +++ b/src/patches/linux/linux-5-15-arm64-dpaa2-add-support-for-10g-modes.patch @@ -0,0 +1,39 @@ +From c314138bd045e050432158ab021160de3ba51c5e Mon Sep 17 00:00:00 2001 +From: Russell King rmk+kernel@armlinux.org.uk +Date: Thu, 30 Jan 2020 22:42:38 +0000 +Subject: [PATCH 2/4] net: dpaa2-mac: add support for more 10G modes
+Phylink documentation says:
- Note that the PHY may be able to transform from one connection
- technology to another, so, eg, don't clear 1000BaseX just
- because the MAC is unable to BaseX mode. This is more about
- clearing unsupported speeds and duplex settings. The port modes
- should not be cleared; phylink_set_port_modes() will help with this.
+So add the missing 10G modes.
+Signed-off-by: Russell King rmk+kernel@armlinux.org.uk +---
- drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c | 6 ++++++
- 1 file changed, 6 insertions(+)
+diff --git a/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c b/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c +index 8fe32ed4f6dc..3be849cee47b 100644 +--- a/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c ++++ b/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c +@@ -140,6 +140,12 @@ static void dpaa2_mac_validate(struct phylink_config *config,
- case PHY_INTERFACE_MODE_10GBASER:
- case PHY_INTERFACE_MODE_USXGMII:
phylink_set(mask, 10000baseT_Full);++ phylink_set(mask, 10000baseKR_Full); ++ phylink_set(mask, 10000baseCR_Full); ++ phylink_set(mask, 10000baseSR_Full); ++ phylink_set(mask, 10000baseLR_Full); ++ phylink_set(mask, 10000baseLRM_Full); ++ phylink_set(mask, 10000baseER_Full);
if (state->interface == PHY_INTERFACE_MODE_10GBASER)break;phylink_set(mask, 5000baseT_Full);+-- +2.30.1
diff --git a/src/patches/linux/linux-5.15-arm64-dpaa2-fix-lock-issue.patch b/src/patches/linux/linux-5.15-arm64-dpaa2-fix-lock-issue.patch new file mode 100644 index 000000000..587821bac --- /dev/null +++ b/src/patches/linux/linux-5.15-arm64-dpaa2-fix-lock-issue.patch @@ -0,0 +1,81 @@ +From 3a39dbe0c0c41f8dba5246ce6e2c5c4bcd6ba661 Mon Sep 17 00:00:00 2001 +From: Ioana Ciornei ioana.ciornei@nxp.com +Date: Thu, 21 Nov 2019 21:15:25 +0200 +Subject: [PATCH 1/4] dpaa2-eth: do not hold rtnl_lock on phylink_create() or
- _destroy()
+The rtnl_lock should not be held when calling phylink_create() or +phylink_destroy() since it leads to the deadlock listed below:
+[ 18.656576] rtnl_lock+0x18/0x20 +[ 18.659798] sfp_bus_add_upstream+0x28/0x90 +[ 18.663974] phylink_create+0x2cc/0x828 +[ 18.667803] dpaa2_mac_connect+0x14c/0x2a8 +[ 18.671890] dpaa2_eth_connect_mac+0x94/0xd8
+Fix this by moving the _lock() and _unlock() calls just outside of +phylink_of_phy_connect() and phylink_disconnect_phy().
+Fixes: 719479230893 ("dpaa2-eth: add MAC/PHY support through phylink") +Reported-by: Russell King linux@armlinux.org.uk +Signed-off-by: Ioana Ciornei ioana.ciornei@nxp.com +Signed-off-by: Russell King rmk+kernel@armlinux.org.uk +---
- drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c | 4 ----
- drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c | 4 ++++
- 2 files changed, 4 insertions(+), 4 deletions(-)
+diff --git a/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c b/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c +index 8b7a29e1e221..20e65053f036 100644 +--- a/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c ++++ b/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c +@@ -4214,12 +4214,10 @@ static irqreturn_t dpni_irq0_handler_thread(int irq_num, void *arg)
dpaa2_eth_set_mac_addr(netdev_priv(net_dev));dpaa2_eth_update_tx_fqids(priv);+- rtnl_lock();
if (dpaa2_eth_has_mac(priv))dpaa2_eth_disconnect_mac(priv);elsedpaa2_eth_connect_mac(priv);+- rtnl_unlock();
- }
- return IRQ_HANDLED;
+@@ -4513,9 +4511,7 @@ static int dpaa2_eth_remove(struct fsl_mc_device *ls_dev)
- #endif
- unregister_netdev(net_dev);
+- rtnl_lock();
- dpaa2_eth_disconnect_mac(priv);
+- rtnl_unlock();
- dpaa2_eth_dl_port_del(priv);
- dpaa2_eth_dl_traps_unregister(priv);
+diff --git a/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c b/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c +index ae6d382d8735..8fe32ed4f6dc 100644 +--- a/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c ++++ b/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c +@@ -351,7 +351,9 @@ int dpaa2_mac_connect(struct dpaa2_mac *mac)
- if (mac->pcs)
phylink_set_pcs(mac->phylink, &mac->pcs->pcs);++ rtnl_lock();
- err = phylink_fwnode_phy_connect(mac->phylink, dpmac_node, 0);
++ rtnl_unlock();
- if (err) {
netdev_err(net_dev, "phylink_fwnode_phy_connect() = %d\n", err);goto err_phylink_destroy;+@@ -372,7 +374,9 @@ void dpaa2_mac_disconnect(struct dpaa2_mac *mac)
- if (!mac->phylink)
return;++ rtnl_lock();
- phylink_disconnect_phy(mac->phylink);
++ rtnl_unlock();
- phylink_destroy(mac->phylink);
- dpaa2_pcs_destroy(mac);
- }
+-- +2.30.1
-- 2.30.1
The Ten64 board runs a U-Boot which works best directly booting EFI. Attempting to load your own DTB or other steps will cause issues. (see https://ten64doc.traverse.com.au/faq/#common-issues)
The current stable Ten64 firmware unfortunately searches for boot.scr before bootaa64.efi. So redirect it back to the EFI path.
A future Ten64 firmware package will prefer EFI first before any boot script avoiding this issue. I will provide a patch reversing this when that day comes.
Signed-off-by: Mathew McBride matt@traverse.com.au --- config/u-boot/boot.cmd | 9 +++++++++ 1 file changed, 9 insertions(+)
diff --git a/config/u-boot/boot.cmd b/config/u-boot/boot.cmd index 64e9c05bc..a27996780 100644 --- a/config/u-boot/boot.cmd +++ b/config/u-boot/boot.cmd @@ -1,3 +1,12 @@ +# Traverse Ten64 board can boot EFI directly +# Redirect it to the EFI process already in the +# bootloader +# (Remove on release of the 1.x Ten64 firmwire package) +if test "${board}" = "ten64"; then + load ${devtype} ${devnum}:2 ${kernel_addr_r} efi/boot/bootaa64.efi + bootefi ${kernel_addr_r} ${fdt_addr_r} +fi; + if test ${boot_dev} = ""; then setenv boot_dev mmc; setenv root_dev /dev/mmcblk0p3;
Reviewed-by: Michael Tremer michael.tremer@ipfire.org
On 3 Oct 2022, at 07:20, Mathew McBride matt@traverse.com.au wrote:
The Ten64 board runs a U-Boot which works best directly booting EFI. Attempting to load your own DTB or other steps will cause issues. (see https://ten64doc.traverse.com.au/faq/#common-issues)
The current stable Ten64 firmware unfortunately searches for boot.scr before bootaa64.efi. So redirect it back to the EFI path.
A future Ten64 firmware package will prefer EFI first before any boot script avoiding this issue. I will provide a patch reversing this when that day comes.
Signed-off-by: Mathew McBride matt@traverse.com.au
config/u-boot/boot.cmd | 9 +++++++++ 1 file changed, 9 insertions(+)
diff --git a/config/u-boot/boot.cmd b/config/u-boot/boot.cmd index 64e9c05bc..a27996780 100644 --- a/config/u-boot/boot.cmd +++ b/config/u-boot/boot.cmd @@ -1,3 +1,12 @@ +# Traverse Ten64 board can boot EFI directly +# Redirect it to the EFI process already in the +# bootloader +# (Remove on release of the 1.x Ten64 firmwire package) +if test "${board}" = "ten64"; then
- load ${devtype} ${devnum}:2 ${kernel_addr_r} efi/boot/bootaa64.efi
- bootefi ${kernel_addr_r} ${fdt_addr_r}
+fi;
if test ${boot_dev} = ""; then setenv boot_dev mmc; setenv root_dev /dev/mmcblk0p3; -- 2.30.1
Hi Michael,
I finally had time to test the official Core 171 build on the Ten64.
The compiled boot script (config/u-boot/boot.scr) needs to be updated (using config/u-boot/boot.mk) to take effect.
As boot.scr is a binary file it is best for someone with commit access to update it.
I'm not sure why the compiled boot.scr is in the tree, though I could try modifying the u-boot build script to compile it. Unless there is some reason that I'm not aware of?
Best Regards, Matt
On Tue, Oct 4, 2022, at 7:57 PM, Michael Tremer wrote:
Reviewed-by: Michael Tremer michael.tremer@ipfire.org
On 3 Oct 2022, at 07:20, Mathew McBride matt@traverse.com.au wrote:
The Ten64 board runs a U-Boot which works best directly booting EFI. Attempting to load your own DTB or other steps will cause issues. (see https://ten64doc.traverse.com.au/faq/#common-issues)
The current stable Ten64 firmware unfortunately searches for boot.scr before bootaa64.efi. So redirect it back to the EFI path.
A future Ten64 firmware package will prefer EFI first before any boot script avoiding this issue. I will provide a patch reversing this when that day comes.
Signed-off-by: Mathew McBride matt@traverse.com.au
config/u-boot/boot.cmd | 9 +++++++++ 1 file changed, 9 insertions(+)
diff --git a/config/u-boot/boot.cmd b/config/u-boot/boot.cmd index 64e9c05bc..a27996780 100644 --- a/config/u-boot/boot.cmd +++ b/config/u-boot/boot.cmd @@ -1,3 +1,12 @@ +# Traverse Ten64 board can boot EFI directly +# Redirect it to the EFI process already in the +# bootloader +# (Remove on release of the 1.x Ten64 firmwire package) +if test "${board}" = "ten64"; then
- load ${devtype} ${devnum}:2 ${kernel_addr_r} efi/boot/bootaa64.efi
- bootefi ${kernel_addr_r} ${fdt_addr_r}
+fi;
if test ${boot_dev} = ""; then setenv boot_dev mmc; setenv root_dev /dev/mmcblk0p3; -- 2.30.1
For reasons I have not been able to determine, the RTC module for the Ten64 board (rtc-rx8025) is not automatically loaded at startup, despite every other relevant modules being loaded.
modprobe it manually if we are on a Ten64 board.
Signed-off-by: Mathew McBride matt@traverse.com.au --- src/initscripts/system/setclock | 8 ++++++++ 1 file changed, 8 insertions(+)
diff --git a/src/initscripts/system/setclock b/src/initscripts/system/setclock index b566eb716..963507f9a 100644 --- a/src/initscripts/system/setclock +++ b/src/initscripts/system/setclock @@ -29,6 +29,14 @@ case ${1} in
boot_mesg "Setting system clock..."
+ FDT_COMPAT_FILE="/sys/firmware/devicetree/base/compatible" + # RTC may not be automatically loaded on some + # non-x86 machines + if [ -f "${FDT_COMPAT_FILE}" ] && \ + ( grep -q "traverse,ten64" "${FDT_COMPAT_FILE}" ); then + modprobe rtc-rx8025 + fi + # udev not create the rtc symlink if rtc is in the kernel if [ ! -e /dev/rtc ]; then if [ -e /dev/rtc0 ]; then
Reviewed-by: Michael Tremer michael.tremer@ipfire.org
On 3 Oct 2022, at 07:20, Mathew McBride matt@traverse.com.au wrote:
For reasons I have not been able to determine, the RTC module for the Ten64 board (rtc-rx8025) is not automatically loaded at startup, despite every other relevant modules being loaded.
modprobe it manually if we are on a Ten64 board.
Signed-off-by: Mathew McBride matt@traverse.com.au
src/initscripts/system/setclock | 8 ++++++++ 1 file changed, 8 insertions(+)
diff --git a/src/initscripts/system/setclock b/src/initscripts/system/setclock index b566eb716..963507f9a 100644 --- a/src/initscripts/system/setclock +++ b/src/initscripts/system/setclock @@ -29,6 +29,14 @@ case ${1} in
boot_mesg "Setting system clock..."
FDT_COMPAT_FILE="/sys/firmware/devicetree/base/compatible"# RTC may not be automatically loaded on some# non-x86 machinesif [ -f "${FDT_COMPAT_FILE}" ] && \( grep -q "traverse,ten64" "${FDT_COMPAT_FILE}" ); thenmodprobe rtc-rx8025fi- # udev not create the rtc symlink if rtc is in the kernel if [ ! -e /dev/rtc ]; then if [ -e /dev/rtc0 ]; then
-- 2.30.1
Hello Mathew,
Good to hear from you again...
On 3 Oct 2022, at 07:20, Mathew McBride matt@traverse.com.au wrote:
Hi all, This patchset adds support for our (Traverse) Ten64 board, which is an ARM64 networking board using NXP's LS1088A SoC.
Great!
I have been intending to do this for a very long time but was waiting for the kernel version to be upgraded to 5.10 or above given the significant amount of work that has been done upstream for this hardware in recent times.
We are on 5.15 for quite a while now and I have an experimental branch with 6.0 ready which I did not test on ARM, yet.
Will any of the changes in this patchset be incompatible with 6.0, or is it all in fact backported from mainline?
There are four components to this patch: 1: Enable the relevant kernel options for our box This follows our doc at https://ten64doc.traverse.com.au/kernel/
I assume that this is all part of the upstream kernel. So I have no problem with enabling this. It should be very unlikely to break anything.
2: Add patches to fully support SFP+ One of these patches came in after 5.15+, while the other fixes a deadlock issue that occurs when detaching/unloading the SFP+ ports (such as rebooting the system). Unfortunately this issue has been stalled upstream without resolution for a while now.
:(
3: Fix our real time clock (rtc-rx8025) not being modprobed I haven't been able to figure out why our RTC driver does not get loaded, given every other relevant module (like GPIO, I2C) does get loaded.
If there is a better way to do this, feel free to NAK and suggest a better method.
This is kind of ugly. But it is not as bad as trying to load the module on all machines. You have a good way to determine if there is at least a chance to be successful.
I can live with this for now, but maybe it is a good idea to file a bug upstream and have them work on the module being automatically loaded as all the others?
4: Bypass the u-boot bootscript on Ten64 The Ten64 uses u-boot which has both EFI and classic 'distroboot' support. We much prefer to boot EFI as this provides some benefits, such as not having to supply your own device tree.
A quirk of the Ten64 implementation (related to how the IOMMU hardware is configured) is that a "failed" bootscript will block the boot of other types (like EFI), so detect if we are on a Ten64 and jump straight to GRUB.
My intention is to prioritize EFI always in a future Ten64 firmware release so this doesn't happen, at which point this hack can be removed. (Removing boot.scr does the same thing, but I prefer that it will boot out of the box without modification)
Great that you are supporting EFI.
As bad as EFI is, it is the only scalable way to make IPFire boot on as many devices without any complicated quirks, tons of bootloaders that are 99% the same code, but then are not, and so on.
If I could I would only support EFI, but all the cheap single board computers do not really play ball, yet.
Here is the fireinfo from a Ten64: https://fireinfo.ipfire.org/profile/97f7fd96a529ca2e5488ab095b7d9effe67d0ef3 (Note to self: I should figure out how to improve the fireinfo output on ARM platforms)
Oh, this is indeed a little bit short. Are the network interfaces not connected using PCIe or some other bus that can be enumerated?
I have also tested this on an AWS Graviton (ARM64) instance to verify there are no regressions on other "standard" (EFI-capable) ARM64 systems.
That is very good to know. IPFire works like a charm on those :)
Mathew McBride (4): linux: enable options for NXP Layerscape kernel: add patches for SFP support on NXP Layerscape/DPAA2 (arm64) config: u-boot: bypass the u-boot script on Traverse Ten64 initscripts: load RTC module (RX8025) for Ten64 board:w
config/kernel/kernel.config.aarch64-ipfire | 76 +++++++++++++---- config/u-boot/boot.cmd | 9 +++ lfs/linux | 3 + src/initscripts/system/setclock | 8 ++ ...rm64-dpaa2-add-support-for-10g-modes.patch | 39 +++++++++ ...inux-5.15-arm64-dpaa2-fix-lock-issue.patch | 81 +++++++++++++++++++ 6 files changed, 202 insertions(+), 14 deletions(-) create mode 100644 src/patches/linux/linux-5-15-arm64-dpaa2-add-support-for-10g-modes.patch create mode 100644 src/patches/linux/linux-5.15-arm64-dpaa2-fix-lock-issue.patch
Core Update 171 is technically closed, but I would suggest to still merge those patches into it, since the big testing phase has not yet been started.
I do not want to ship another kernel in the next update if we don’t have to, so it makes sense to have this merged now. It is very unlikely to break anything else.
@Peter: Could you please merge this? I will submit my tags shortly.
-Michael
-- 2.30.1
Hi Michael,
Just to finally get back to your other questions/comments. Apart from the boot.scr issue (fixed by removing the boot.scr file), Core 171 is working well on the Ten64.
On Tue, Oct 4, 2022, at 7:56 PM, Michael Tremer wrote:
Hello Mathew,
Good to hear from you again... [snip]
Will any of the changes in this patchset be incompatible with 6.0, or is it all in fact backported from mainline?
It's all backported from mainline. I'm not aware of any upcoming changes that will break things.
There are four components to this patch: 1: Enable the relevant kernel options for our box This follows our doc at https://ten64doc.traverse.com.au/kernel/
I assume that this is all part of the upstream kernel. So I have no problem with enabling this. It should be very unlikely to break anything.
2: Add patches to fully support SFP+ One of these patches came in after 5.15+, while the other fixes a deadlock issue that occurs when detaching/unloading the SFP+ ports (such as rebooting the system). Unfortunately this issue has been stalled upstream without resolution for a while now.
:(
The upstream experience for this particular SoC has been better than previous ones, but there are novel parts of it that breaks assumptions kernel (and other) developers have about network hardware. It's those parts which have been stalled upstream.
The network complex is not a "fixed function" device, network interfaces and PHYs can be connected in arbitrary pairs (for example, I could change the PHY of a running interface from an SFP to a 1000Base-T port). It basically has a pool of resources across all the network ports which one then configures the way they want.
3: Fix our real time clock (rtc-rx8025) not being modprobed I haven't been able to figure out why our RTC driver does not get loaded, given every other relevant module (like GPIO, I2C) does get loaded.
If there is a better way to do this, feel free to NAK and suggest a better method.
This is kind of ugly. But it is not as bad as trying to load the module on all machines. You have a good way to determine if there is at least a chance to be successful.
I can live with this for now, but maybe it is a good idea to file a bug upstream and have them work on the module being automatically loaded as all the others?
I'm not sure if anything is broken with the upstream kernel, but I think I need to understand what causes a kernel module to be loaded without a modprobe first.
The bigger distributions deal with it by modprobing all the available *.ko's in initrd. In our own kernel configuration for testing we just set CONFIG_RTC_RX8035=y so it's built-in.
I could do the same if you're happy to have it as a builtin (like the x86 BIOS/CMOS rtc.)
[snip]
Here is the fireinfo from a Ten64: https://fireinfo.ipfire.org/profile/97f7fd96a529ca2e5488ab095b7d9effe67d0ef3 (Note to self: I should figure out how to improve the fireinfo output on ARM platforms)
Oh, this is indeed a little bit short. Are the network interfaces not connected using PCIe or some other bus that can be enumerated?
Indeed, they come from a special "fsl-mc-bus".
My suggestion would be to crawl through the [sysfs] device/ and device/driver for each net class device to identify the full device path and driver.
$ ls /sys/class/net/ eth0 eth1 eth2 eth3 eth4 eth5 eth6 eth7 eth8 eth9 lo
$ readlink -f /sys/class/net/eth0/device/ /sys/devices/platform/soc/80c000000.fsl-mc/dprc.1/dpni.9 $ readlink -f /sys/class/net/eth1/device/ /sys/devices/platform/soc/80c000000.fsl-mc/dprc.1/dpni.8 .. $ readlink -f /sys/class/net/eth9/device/ /sys/devices/platform/soc/80c000000.fsl-mc/dprc.1/dpni.0
$ readlink -f /sys/class/net/eth0/device/driver /sys/bus/fsl-mc/drivers/fsl_dpaa2_eth
$ ls -la /sys/bus/fsl-mc/drivers/fsl_dpaa2_eth/ drwxr-xr-x 2 root root 0 Oct 10 05:33 . drwxr-xr-x 8 root root 0 Oct 10 05:33 .. --w------- 1 root root 4096 Oct 10 05:33 bind lrwxrwxrwx 1 root root 0 Oct 10 05:33 dpni.0 -> ../../../../devices/platform/soc/80c000000.fsl-mc/dprc.1/dpni.0 lrwxrwxrwx 1 root root 0 Oct 10 05:33 dpni.1 -> ../../../../devices/platform/soc/80c000000.fsl-mc/dprc.1/dpni.1 lrwxrwxrwx 1 root root 0 Oct 10 05:33 dpni.2 -> ../../../../devices/platform/soc/80c000000.fsl-mc/dprc.1/dpni.2 lrwxrwxrwx 1 root root 0 Oct 10 05:33 dpni.3 -> ../../../../devices/platform/soc/80c000000.fsl-mc/dprc.1/dpni.3 lrwxrwxrwx 1 root root 0 Oct 10 05:33 dpni.4 -> ../../../../devices/platform/soc/80c000000.fsl-mc/dprc.1/dpni.4 lrwxrwxrwx 1 root root 0 Oct 10 05:33 dpni.5 -> ../../../../devices/platform/soc/80c000000.fsl-mc/dprc.1/dpni.5 lrwxrwxrwx 1 root root 0 Oct 10 05:33 dpni.6 -> ../../../../devices/platform/soc/80c000000.fsl-mc/dprc.1/dpni.6 lrwxrwxrwx 1 root root 0 Oct 10 05:33 dpni.7 -> ../../../../devices/platform/soc/80c000000.fsl-mc/dprc.1/dpni.7 lrwxrwxrwx 1 root root 0 Oct 10 05:33 dpni.8 -> ../../../../devices/platform/soc/80c000000.fsl-mc/dprc.1/dpni.8 lrwxrwxrwx 1 root root 0 Oct 10 05:33 dpni.9 -> ../../../../devices/platform/soc/80c000000.fsl-mc/dprc.1/dpni.9 --w------- 1 root root 4096 Oct 10 05:33 uevent --w------- 1 root root 4096 Oct 10 05:33 unbind
Regards, Matt
I have also tested this on an AWS Graviton (ARM64) instance to verify there are no regressions on other "standard" (EFI-capable) ARM64 systems.
That is very good to know. IPFire works like a charm on those :)
Mathew McBride (4): linux: enable options for NXP Layerscape kernel: add patches for SFP support on NXP Layerscape/DPAA2 (arm64) config: u-boot: bypass the u-boot script on Traverse Ten64 initscripts: load RTC module (RX8025) for Ten64 board:w
config/kernel/kernel.config.aarch64-ipfire | 76 +++++++++++++---- config/u-boot/boot.cmd | 9 +++ lfs/linux | 3 + src/initscripts/system/setclock | 8 ++ ...rm64-dpaa2-add-support-for-10g-modes.patch | 39 +++++++++ ...inux-5.15-arm64-dpaa2-fix-lock-issue.patch | 81 +++++++++++++++++++ 6 files changed, 202 insertions(+), 14 deletions(-) create mode 100644 src/patches/linux/linux-5-15-arm64-dpaa2-add-support-for-10g-modes.patch create mode 100644 src/patches/linux/linux-5.15-arm64-dpaa2-fix-lock-issue.patch
Core Update 171 is technically closed, but I would suggest to still merge those patches into it, since the big testing phase has not yet been started.
I do not want to ship another kernel in the next update if we don’t have to, so it makes sense to have this merged now. It is very unlikely to break anything else.
@Peter: Could you please merge this? I will submit my tags shortly.
-Michael
-- 2.30.1
Hello,
On 28 Oct 2022, at 06:11, Mathew McBride matt@traverse.com.au wrote:
Hi Michael,
Just to finally get back to your other questions/comments. Apart from the boot.scr issue (fixed by removing the boot.scr file), Core 171 is working well on the Ten64.
I raised this with Arne.
On Tue, Oct 4, 2022, at 7:56 PM, Michael Tremer wrote:
Hello Mathew,
Good to hear from you again... [snip]
Will any of the changes in this patchset be incompatible with 6.0, or is it all in fact backported from mainline?
It's all backported from mainline. I'm not aware of any upcoming changes that will break things.
Very good.
There are four components to this patch: 1: Enable the relevant kernel options for our box This follows our doc at https://ten64doc.traverse.com.au/kernel/
I assume that this is all part of the upstream kernel. So I have no problem with enabling this. It should be very unlikely to break anything.
2: Add patches to fully support SFP+ One of these patches came in after 5.15+, while the other fixes a deadlock issue that occurs when detaching/unloading the SFP+ ports (such as rebooting the system). Unfortunately this issue has been stalled upstream without resolution for a while now.
:(
The upstream experience for this particular SoC has been better than previous ones, but there are novel parts of it that breaks assumptions kernel (and other) developers have about network hardware. It's those parts which have been stalled upstream.
The network complex is not a "fixed function" device, network interfaces and PHYs can be connected in arbitrary pairs (for example, I could change the PHY of a running interface from an SFP to a 1000Base-T port). It basically has a pool of resources across all the network ports which one then configures the way they want.
Cool, but how are we supposed to put this into any kind of UI?
3: Fix our real time clock (rtc-rx8025) not being modprobed I haven't been able to figure out why our RTC driver does not get loaded, given every other relevant module (like GPIO, I2C) does get loaded.
If there is a better way to do this, feel free to NAK and suggest a better method.
This is kind of ugly. But it is not as bad as trying to load the module on all machines. You have a good way to determine if there is at least a chance to be successful.
I can live with this for now, but maybe it is a good idea to file a bug upstream and have them work on the module being automatically loaded as all the others?
I'm not sure if anything is broken with the upstream kernel, but I think I need to understand what causes a kernel module to be loaded without a modprobe first.
That depends. Either it is ACPI tables which you don’t have on ARM. It could be part of the device tree as well, or the system just enumerates any devices connected to a PCI bus.
The bigger distributions deal with it by modprobing all the available *.ko's in initrd. In our own kernel configuration for testing we just set CONFIG_RTC_RX8035=y so it's built-in.
I could do the same if you're happy to have it as a builtin (like the x86 BIOS/CMOS rtc.)
With an RTC I would be happy to have this built in. They are not very large normally and that is still better than calling mopdrobe a thousand times. We should already have lots of RTCs compiled into our kernel.
[snip]
Here is the fireinfo from a Ten64: https://fireinfo.ipfire.org/profile/97f7fd96a529ca2e5488ab095b7d9effe67d0ef3 (Note to self: I should figure out how to improve the fireinfo output on ARM platforms)
Oh, this is indeed a little bit short. Are the network interfaces not connected using PCIe or some other bus that can be enumerated?
Indeed, they come from a special "fsl-mc-bus".
My suggestion would be to crawl through the [sysfs] device/ and device/driver for each net class device to identify the full device path and driver.
And they don’t have any kind of PCI id or something? Probably because this is not using PCI :)
This makes this very complicated.
-Michael
$ ls /sys/class/net/ eth0 eth1 eth2 eth3 eth4 eth5 eth6 eth7 eth8 eth9 lo
$ readlink -f /sys/class/net/eth0/device/ /sys/devices/platform/soc/80c000000.fsl-mc/dprc.1/dpni.9 $ readlink -f /sys/class/net/eth1/device/ /sys/devices/platform/soc/80c000000.fsl-mc/dprc.1/dpni.8 .. $ readlink -f /sys/class/net/eth9/device/ /sys/devices/platform/soc/80c000000.fsl-mc/dprc.1/dpni.0
$ readlink -f /sys/class/net/eth0/device/driver /sys/bus/fsl-mc/drivers/fsl_dpaa2_eth
$ ls -la /sys/bus/fsl-mc/drivers/fsl_dpaa2_eth/ drwxr-xr-x 2 root root 0 Oct 10 05:33 . drwxr-xr-x 8 root root 0 Oct 10 05:33 .. --w------- 1 root root 4096 Oct 10 05:33 bind lrwxrwxrwx 1 root root 0 Oct 10 05:33 dpni.0 -> ../../../../devices/platform/soc/80c000000.fsl-mc/dprc.1/dpni.0 lrwxrwxrwx 1 root root 0 Oct 10 05:33 dpni.1 -> ../../../../devices/platform/soc/80c000000.fsl-mc/dprc.1/dpni.1 lrwxrwxrwx 1 root root 0 Oct 10 05:33 dpni.2 -> ../../../../devices/platform/soc/80c000000.fsl-mc/dprc.1/dpni.2 lrwxrwxrwx 1 root root 0 Oct 10 05:33 dpni.3 -> ../../../../devices/platform/soc/80c000000.fsl-mc/dprc.1/dpni.3 lrwxrwxrwx 1 root root 0 Oct 10 05:33 dpni.4 -> ../../../../devices/platform/soc/80c000000.fsl-mc/dprc.1/dpni.4 lrwxrwxrwx 1 root root 0 Oct 10 05:33 dpni.5 -> ../../../../devices/platform/soc/80c000000.fsl-mc/dprc.1/dpni.5 lrwxrwxrwx 1 root root 0 Oct 10 05:33 dpni.6 -> ../../../../devices/platform/soc/80c000000.fsl-mc/dprc.1/dpni.6 lrwxrwxrwx 1 root root 0 Oct 10 05:33 dpni.7 -> ../../../../devices/platform/soc/80c000000.fsl-mc/dprc.1/dpni.7 lrwxrwxrwx 1 root root 0 Oct 10 05:33 dpni.8 -> ../../../../devices/platform/soc/80c000000.fsl-mc/dprc.1/dpni.8 lrwxrwxrwx 1 root root 0 Oct 10 05:33 dpni.9 -> ../../../../devices/platform/soc/80c000000.fsl-mc/dprc.1/dpni.9 --w------- 1 root root 4096 Oct 10 05:33 uevent --w------- 1 root root 4096 Oct 10 05:33 unbind
Regards, Matt
I have also tested this on an AWS Graviton (ARM64) instance to verify there are no regressions on other "standard" (EFI-capable) ARM64 systems.
That is very good to know. IPFire works like a charm on those :)
Mathew McBride (4): linux: enable options for NXP Layerscape kernel: add patches for SFP support on NXP Layerscape/DPAA2 (arm64) config: u-boot: bypass the u-boot script on Traverse Ten64 initscripts: load RTC module (RX8025) for Ten64 board:w
config/kernel/kernel.config.aarch64-ipfire | 76 +++++++++++++---- config/u-boot/boot.cmd | 9 +++ lfs/linux | 3 + src/initscripts/system/setclock | 8 ++ ...rm64-dpaa2-add-support-for-10g-modes.patch | 39 +++++++++ ...inux-5.15-arm64-dpaa2-fix-lock-issue.patch | 81 +++++++++++++++++++ 6 files changed, 202 insertions(+), 14 deletions(-) create mode 100644 src/patches/linux/linux-5-15-arm64-dpaa2-add-support-for-10g-modes.patch create mode 100644 src/patches/linux/linux-5.15-arm64-dpaa2-fix-lock-issue.patch
Core Update 171 is technically closed, but I would suggest to still merge those patches into it, since the big testing phase has not yet been started.
I do not want to ship another kernel in the next update if we don’t have to, so it makes sense to have this merged now. It is very unlikely to break anything else.
@Peter: Could you please merge this? I will submit my tags shortly.
-Michael
-- 2.30.1
-
Mathew McBride -
Michael Tremer