KSZ9897 kernel module - consider for addition?

Technical Support
, , ,
1

Hello,

I’m currently working on evaluating parts for a custom carrier board and one component of this is we would like to integrate a switch chip (KSZ9897) into the board on the secondary ethernet interface via RGMII to provide additional ethernet ports on the device.

The required drivers indrivers/net/dsa/microchip exist in the linux-toradex repository, but do not appear to be included/built with the default release. I’m currently in the process of trying to build them standalone for testing purposes (via TCB), but am curious whether it’d be possible to get these included by default in a future release if we do select this component. I expect additional ethernet ports with a direct switch bridge is not uncommon in the embedded world so this would be useful for others as well.

Thanks!

2

Greetings @bw908,

We certainly can add such a driver on request. Just to be sure do you know what specific kernel configuration options you need here?

Best Regards,
Jeremias

3

Thanks, I am trying to establish that now - pulled the kernel sources and am building the module(s) so I can side-load them and confirm.

However, I’m not having much luck finding the commit from which the kernel was built. Perhaps you can assist with that - My OS image is based on torizon-core-docker-apalis-imx8-Tezi_5.6.0+build.13.tar which reports apalis-imx8-02823896 5.4.161-5.60+git.0f0011824921

I followed the instructions on the Toradex dev site to set up the build environment and cross compilers, cloned /proc/config.gz as the starting config, added the desired options with values set to “m” and am able to build the modules, (make modules_prepare//make modules) but they will not load because the symbol versions don’t match.

I’ve tried:

  • Commit 0f0011824921
  • Head of toradex_5.4-2.3.x-imx
  • tag v5.4.161

No dice on any of them.

These are the changed configs I am trying to get built:

CONFIG_NET_DSA=m
CONFIG_NET_DSA_TAG_KSZ=m
CONFIG_NET_DSA_MICROCHIP_KSZ_COMMON=m
CONFIG_NET_DSA_MICROCHIP_KSZ9477=m
CONFIG_NET_DSA_MICROCHIP_KSZ9477_I2C=m
CONFIG_NET_DSA_MICROCHIP_KSZ9477_SPI=m
CONFIG_NET_DSA_MICROCHIP_KSZ8795=m
CONFIG_NET_DSA_MICROCHIP_KSZ8795_SPI=m
4

You seem to be using the wrong branch. When using an ARM32 based module on TorizonCore the kernel branch that is used is toradex_5.4.y. Using this branch I was able to find a matching commit with that hash: linux-toradex.git - Linux kernel for Apalis, Colibri and Verdin modules

As for the kernel configs. Do you need both the I2C and SPI related options? Or are you still testing/experimenting?

Best Regards,
Jeremias

5

Isn’t the Apalis IMX8 arm64?
FILE /lib/modules/[version]/[some random .ko] reports it is an AARCH64 binary.

As noted, I did try with that commit hash (git checkout [hash] on the torizon kernel sources) but the build also produces incompatible kernel modules. (dsa_core: disagrees about version of symbol phylink_connect_phy as an example, there are many)

I am still experimenting at this time, I’m attempting to build all of these modules for evaluation purposes.

6

Oh wait, you are using the Apalis i.MX8 then? In which case yes that is the correct branch.

Apologies I was confused what module you were working with since the question here has the “imx6” tag.

That said, it might just be less trouble to re-build the whole kernel or use Yocto to rebuild the image with your kernel modules for testing. Rather than trying to exactly match the kernel version/symbols.

Alternatively, there should be a compressed linux kernel source in the filesystem. In /usr/src/linux.tar.bz2 I believe. This source should match the exact kernel that the system is running and it may be enough for you to compile/test these kernel modules.

Best Regards,
Jeremias

7

Interesting, not sure how that happened. (sorry!) Thanks for the suggestions, I’ll continue having a go with the sources/kernel build tomorrow.

But you raise an interesting point - why is the commit mentioned in uname -a on a completely different branch?

Thanks!

8

Little bit off topic: but is the KSZ9897 not cancelled by manufacturer?

9

Not that I’m aware…

10

Ok, I found why I was having module issues despite being on the correct source. CONFIG_NET_DSA changes networking symbols and because the original kernel does not have it enabled, the resulting modules are not usable.

I’m now going down the path of building a custom TorizionCore image with the required kernel changes.

11

Good to hear you were able to make some progress.

Just let me know when you have a final list of kernel configurations you want me to request the team here to include.

Best Regards,
Jeremias

1 Like
12

@jeremias.tx Unfortunately I was not able to get it working with the eval boards. I suspect this is because the RGMII interface is somewhat sensitive to timing/trace length matching and flying leads just don’t cut it.

However, I did identify that the following kernel options are relevant to the KSZ9897:

CONFIG_NET_DSA=m
CONFIG_NET_DSA_TAG_KSZ=m
CONFIG_NET_DSA_MICROCHIP_KSZ_COMMON=m
CONFIG_NET_DSA_MICROCHIP_KSZ9477=m
CONFIG_NET_DSA_MICROCHIP_KSZ9477_I2C=m
CONFIG_NET_DSA_MICROCHIP_KSZ9477_SPI=m

It is structured as a main driver KSZ_9477 and two additional helper modules depending on whether SPI or I2C is selected for management. NET_DSA and NET_DSA_TAG_KSZ appear to be lower level modules just required to enable DSA support.

So if we could get these considered for inclusion that’d be great. Thanks!

13

Hi @bw908 ,

I’ve made the request to add these kernel configs to our next TorizonCore nightly releases and it should take a few days. I’ll update you when that’s done.

Let me know if you need any other help.

Best regards,
Lucas Akira

1 Like
14

Hi @bw908 ,

I have some news about the kernel configs:

The team plans to include your configs for the nightly builds of TorizonCore 6, our next major release, which is currently being worked on.

Because of this it can take longer than usual to include your module, given that the team is focused on core features of the OS.

Also, keep in mind that TorizonCore 6 is, as of this writing, in work-in-progress phase and therefore not very stable.

You can include these configs on a custom TorizonCore image using TorizonCore Builder if you need a faster alternative.

Best regards,
Lucas Akira

15

Thank you. If I may ask, what is the release timeline for v6?

16

Here’s the answer I got internally:

We don’t have an exact timeline, as our R&D teams are setting up the infrastructure, migrating to newer kernel and NXP releases.

We aim to provide nightly builds in the next 2 weeks, if everything goes well. Not all Toradex SoMs may be supported - or even boot - as of the first nightly releases, though.

I’ll let you know when the nightly builds are released.

Best regards,
Lucas Akira

1 Like
17

Hi @bw908,

Just to inform you we are now producing nightly builds for TorizonCore 6. However as previously stated these initial nightly builds are very much not fully operational when compared to our TorizonCore 5.X. Especially the Apalis i.MX8 where the bring-up and support is still very much “in-progress”. Though we expect this to improve as the team has more time to iterate and improve.

Keep an eye on the next quarter for the first quarterly release of TorizonCore 6 where the images are planned to be in a more stable state.

Best Regards,
Jeremias

1 Like