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