Message ID | 20221003062019.19636-1-matt@traverse.com.au |
---|---|
Headers |
Return-Path: <development-bounces@lists.ipfire.org> Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) client-signature ECDSA (P-384)) (Client CN "mail01.haj.ipfire.org", Issuer "R3" (verified OK)) by web04.haj.ipfire.org (Postfix) with ESMTPS id 4MgrSV6vXvz3wgq for <patchwork@web04.haj.ipfire.org>; Mon, 3 Oct 2022 06:26:02 +0000 (UTC) Received: from mail02.haj.ipfire.org (mail02.haj.ipfire.org [172.28.1.201]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) client-signature ECDSA (P-384)) (Client CN "mail02.haj.ipfire.org", Issuer "R3" (verified OK)) by mail01.ipfire.org (Postfix) with ESMTPS id 4MgrSS2x7Qz2RQ; Mon, 3 Oct 2022 06:26:00 +0000 (UTC) Received: from mail02.haj.ipfire.org (localhost [127.0.0.1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4MgrSS0l4tz2ysT; Mon, 3 Oct 2022 06:26:00 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) client-signature ECDSA (P-384)) (Client CN "mail01.haj.ipfire.org", Issuer "R3" (verified OK)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4MgrSQ5Stkz2xHF for <development@lists.ipfire.org>; Mon, 3 Oct 2022 06:25:58 +0000 (UTC) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384)) (Client did not present a certificate) by mail01.ipfire.org (Postfix) with ESMTPS id 4MgrSP5vydzWy for <development@lists.ipfire.org>; Mon, 3 Oct 2022 06:25:57 +0000 (UTC) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 5D8B75C008F; Mon, 3 Oct 2022 02:20:28 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Mon, 03 Oct 2022 02:20:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=traverse.com.au; h=cc:cc:content-transfer-encoding:date:date:from:from :in-reply-to:message-id:mime-version:reply-to:sender:subject :subject:to:to; s=fm1; t=1664778028; x=1664864428; bh=f6v3lJSd1I zuioxSrK5Wkch2Tm96o+NigSV5XER7m38=; b=GflXtQ1DxOvN9YNeE86zffmTOB CnqRydxI9sDHzJS5Ad/XXeD+WnCdPRijzOAx1CIW9ZIyC/3oJl2Sy6LItdbATfly GgocQ8guCsi6Qj+aBEitFB23tuCpT/rGoz+Pa7lLE/tir5ScuxldH0GfKTVGsgUE F+wFwR8WEYLiYiB3ZQWXFjsRPOUwAawSd56lGUU8kGOvQgzVVlvNgy7GDIn4xPSf vrUEXdFWaHN9JceAmkfzwhRxx9n/WgwgtFgVW5oLKnd1mhYlZj6jjP3dDARsPxh1 bq1RjftUFL/8S8Px7MYVIEnh4lg46+9VTv7zYeWYQwkjiX46nFVXt83gYoSQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding:date:date :feedback-id:feedback-id:from:from:in-reply-to:message-id :mime-version:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1664778028; x=1664864428; bh=f6v3lJSd1IzuioxSrK5Wkch2Tm96o+NigSV 5XER7m38=; b=ayCSwSwpM7nnMWYA7Z7xCxzqSLNA9oPp3J9eic29LxL1mbq7c1u BMInl2wfKlDSNTonXQVVoTbZCIk/0NwpagQ6oTPWXndQcHmtKYKjIOmIyKy+3RtM Eungzo/Icj0kREKdV21+LBRjcPF+joRiYG9FR2bCMCIgUUMffWtutTogJjnyQ821 lQFhJR6xhLwE+GptsxV0d0/cND1t6E+Ct0MsIGyUMZlXHkllQvI0a4YxBRreRVPw J681rX3SFniDVfU5OFqG4RFKjvExHu6XnhydF6HuDwmuRmr7+i9rRnTbKeCLxMC3 272rlL7UC9OsYw9FqArtkaR9ACxe26voWEQ== X-ME-Sender: <xms:K386Y_4KYm5zHWxAFW93iKmM9PRebgYiPRPpwGOFL3W97SEtXHihUg> <xme:K386Y07-vMMZRUkbAKGCCPdWoUYCn0lX_39nQ_OU0Yz0OE3QEGkhjGQMGvtrqslOx Rk5UO6FXRdV7iSroR4> X-ME-Received: <xmr:K386Y2ezOi_9sZDlsDxKIZVCOY_dQgpQ4WwaZP3qOXNxnUt4Y13kss5SN-GjyF4Ix-gr_eEtZ1itCXg-Le9SolkxfWqaBB33RcZx0cbB1vcl92iT-bwKoen7uMkwPbQ> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeehkedguddtkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhephffvvefufffkofgggfestdekre dtredttdenucfhrhhomhepofgrthhhvgifucfotgeurhhiuggvuceomhgrthhtsehtrhgr vhgvrhhsvgdrtghomhdrrghuqeenucggtffrrghtthgvrhhnpedutdehvdehieeujedvud ekudegheelhedtudehfedtteevkeeiieeiteefffeiveenucffohhmrghinhepthhrrghv vghrshgvrdgtohhmrdgruhdpihhpfhhirhgvrdhorhhgnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrthhtsehtrhgrvhgvrhhsvgdrtgho mhdrrghu X-ME-Proxy: <xmx:K386YwJZBNMY6a2G_DCssrCy88wpC0Bs7eDDPRP-YOiSujAaAKP_kA> <xmx:K386YzJ27cZtD_UoaXlfLIDHAPAOwQkMUhhaOBX-Zm9dMhHTj-ARAA> <xmx:K386Y5zbSt7aAQu1lg7k1nuWfJvIPU0WnmMDZ1YDKpDp7QT-Fsc49g> <xmx:LH86Y1w2Lpt89mowTA8rVKorRHegSzZwLnAALK5iA8VFktufWz8oVA> Feedback-ID: i426947f3:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 3 Oct 2022 02:20:26 -0400 (EDT) From: Mathew McBride <matt@traverse.com.au> To: development@lists.ipfire.org Subject: [PATCH 0/4] kernel: aarch64: Add support for Traverse Ten64 board Date: Mon, 3 Oct 2022 06:20:15 +0000 Message-Id: <20221003062019.19636-1-matt@traverse.com.au> X-Mailer: git-send-email 2.30.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit ARC-Seal: i=1; s=202003rsa; d=lists.ipfire.org; t=1664778358; a=rsa-sha256; cv=none; b=MudybPsl9FLio7tso4qnzgst24nEY+q78jzX9K0wEVYbU1qkseHBbQyzeB8U9cgjNQElH2 BJjO8VsjHu6gov1FFlrw5/8HNP+d30ubFZ8lW+b/vcfJHg64DvsR2w5QM9wFYipybYl3Yo WqAJkENGyLk2GyCtcYHhN9NvsVvipFfS1tqyiB5T6X58F1PcdYXA8PBJ90ZjylsA5gWAQ7 fSOIx7wFZv3dPlczLaeTXRfPxnxpc0CNGv4yhaKfV8mUooM7hOie1xhFaCmWRa0rkgv6BG xqJ6hkFL3V7+otV66V4U8feGHSD6ilM41OpYr54xrwKuzI43jPPR2eLOTkP9xA== ARC-Authentication-Results: i=1; mail01.ipfire.org; dkim=pass header.d=traverse.com.au header.s=fm1 header.b=GflXtQ1D; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=ayCSwSwp; spf=pass (mail01.ipfire.org: domain of matt@traverse.com.au designates 66.111.4.28 as permitted sender) smtp.mailfrom=matt@traverse.com.au; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=lists.ipfire.org; s=202003rsa; t=1664778358; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding:dkim-signature; bh=f6v3lJSd1IzuioxSrK5Wkch2Tm96o+NigSV5XER7m38=; b=DB/pNrf0yBRURXe9GigjR2aQr5/eZara+TaYLDwfqy3v2dIGVzZOi14LGq5y6M/1CpKRKU ekI3XFaSpFE9VB2vETuw1Ykc/GSI72jvIdSgs90rHA9yY1HMPYGhbkSHuoWPWvWdE9ySWk bQkreVq4JPMbsrVpphLLmy01GDTPtOsU6si5phbPWC8ZWRKmuIfFLCt1e4/KqqFrZoNmeo L6tNswmA5HSlq4rFT9mQyWCh2NotXSWJQZ8EcsxTEk6XgYVkLoJhCtW5waFb4dD1WBXtWg zJbBuFhPU+fcCRRDLtNl0Y0z9aXWGBThhXe+PhOZPpeBniza9Iy1iKZuH47ZLg== Authentication-Results: mail01.ipfire.org; dkim=pass header.d=traverse.com.au header.s=fm1 header.b=GflXtQ1D; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=ayCSwSwp; spf=pass (mail01.ipfire.org: domain of matt@traverse.com.au designates 66.111.4.28 as permitted sender) smtp.mailfrom=matt@traverse.com.au; dmarc=none X-Rspamd-Server: mail01.haj.ipfire.org X-Spamd-Result: default: False [-2.06 / 11.00]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; MID_CONTAINS_FROM(1.00)[]; NEURAL_HAM(-1.00)[-0.998]; DKIM_REPUTATION(-0.93)[-0.92939736037945]; R_MISSING_CHARSET(0.50)[]; IP_REPUTATION_HAM(-0.38)[asn: 19151(-0.38), country: US(-0.01), ip: 66.111.4.28(0.00)]; R_DKIM_ALLOW(0.29)[traverse.com.au:s=fm1,messagingengine.com:s=fm2]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.28]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.28:from]; RWL_MAILSPIKE_GOOD(-0.10)[66.111.4.28:from]; BAYES_HAM(-0.03)[56.35%]; MX_GOOD(-0.01)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[traverse.com.au]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ARC_SIGNED(0.00)[lists.ipfire.org:s=202003rsa:i=1]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_COUNT_THREE(0.00)[4]; RCPT_COUNT_TWO(0.00)[2]; DKIM_TRACE(0.00)[traverse.com.au:+,messagingengine.com:+]; FROM_EQ_ENVFROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Rspamd-Queue-Id: 4MgrSP5vydzWy X-BeenThere: development@lists.ipfire.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPFire development talk <development.lists.ipfire.org> List-Unsubscribe: <https://lists.ipfire.org/mailman/options/development>, <mailto:development-request@lists.ipfire.org?subject=unsubscribe> List-Archive: <http://lists.ipfire.org/pipermail/development/> List-Post: <mailto:development@lists.ipfire.org> List-Help: <mailto:development-request@lists.ipfire.org?subject=help> List-Subscribe: <https://lists.ipfire.org/mailman/listinfo/development>, <mailto:development-request@lists.ipfire.org?subject=subscribe> Errors-To: development-bounces@lists.ipfire.org Sender: "Development" <development-bounces@lists.ipfire.org> |
Series |
kernel: aarch64: Add support for Traverse Ten64 board
|
|
Message
Mathew McBride
Oct. 3, 2022, 6:20 a.m. UTC
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
Comments
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 >> >