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
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:
> (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
>