Some DPAA2 questions

In order to boot with a minimal DPL and then dynamically provision DPNIs/DPMUXes/DPMACs, can I just compile eg. eth-dpl-eth0-only.dts to a dtb, stick that somewhere u-boot can read it, then fsl_mc lazyapply that instead of the one read from flash? Or is the object at 0x580000 not just the dtb?

As I understand it, to do the dynamic configuration I need restool, which needs kernel support only present in the LSDK-derived kernels you ship with openwrt/muvirt/recovery. It looks like there’s previously been an attempt to mainline the required kernel support but it hasn’t moved in a few years. Is that correct?

Thanks

Yes, doing fsl_mc lazyapply on your own dpl blob will work.

To make it ‘permanent’ you can write over the “dpl” partition, like this (from recovery):

mtd erase dpl && mtd write eth-dpl-eth0-only.dtb dtb

The good news is that restool support is now in mainline kernels (since 5.12 IIRC, see this patch)!

You may need to use “legacy” network mode as it appears phylink and dynamically created DPAA2 objects don’t interact too well at the moment.

Cool, thanks for that. Good news about mainline, it’s been a while since I extracted a driver from a vendor kernel and I’m very happy to not have to bother with that this time :slight_smile:

With the copper ports in legacy mode only reporting link up, is there any way at all to find the true link status?

Also, is there any way (in either managed or legacy mode) to get link status on a DPMAC that’s not connected to a DPNI but is the upstream port on a DPDMUX? I guess both these questions feel sorta like they’ll have “crack out the Layerscape SDK” for an answer.

Unfortunately I’m not aware of any way one can get link status indicators for copper ports in “legacy” mode. The MC firmware purely works on the “physical” link status which doesn’t change between the PHY and SoC (in the case of QSGMII).

Prior to the phy driver in mainline there was no method to get copper link status in Linux.

(And my recollection is that NXP wanted to do a implementation in firmware so use cases like this were covered, but there was a lot of pushback from the kernel devs)

I suspect you could talk to the MII/MDIO controller directly (since nothing else will be) and/or find a way to register the PHYs with Linux but not have them attached to an Ethernet MAC.

fair enough. kernel 5.13 just landed in Debian experimental but doesn’t boot in my setup, so I’ll look at the link stuff once I’m able to even boot a system that’ll support restool.

Funnily enough - I had to take a look at this today for someone working with DPDK.

“Managed” mode is the correct mode to use for this, as long as the host OS reports the link status back to the MC firmware then the DPNI and even DPDMUX link statuses will report correctly (the same way SFP ones are).

The specific issue with newer kernels is that phylink doesn’t (currently) work well with DPNI’s being created and destroyed at runtime. If all you need is link status reporting, I think we can just disable phylink by removing the MAC<->PHY links from the device tree. I’ll take a look at that next week.

Regarding the kernel, I do build ‘mainline’ kernel packages over here, and you can add our apt repo to use them:

deb [trusted=yes] https://archive.traverse.com.au/pub/traverse/debian-experimental/ torvalds main
apt-get update
apt-get install linux-image-traverse

I don’t advertise them much as generally it’s only me and a few specific customers using them (usually for network-related development) They don’t have many of the drivers and features enabled in a typical distribution kernel.

FWIW, Debian’s 5.13 kernel (currently in experimental) built with CONFIG_FSL_MC_UAPI_SUPPORT=y set seems fine, and restool passes a smoketest.
I’ve opened https://bugs.debian.org/992988 to get that enabled in their shipping kernels.

1 Like

A couple of tips in case anyone is watching down the end of this thread and finds them useful…

To optionally load a DPL from disk otherwise using the one in flash, put the compiled DPL as eth-dpl.dtb in the root of the boot partition and then update setup_distroboot_efi in u-boot

setenv setup_distroboot_efi 'if load ${devtype} ${devnum}:${distro_bootpart} 0x80001000 eth-dpl.dtb; then echo Loaded dpl from ${devtype} ${devnum}:${distro_bootpart} eth-dpl.dtb; else sf read 0x80001000 0x580000 0x40000; echo Loaded dpl from sf; fi && fsl_mc lazyapply dpl 0x80001000; sf read $fdt_addr_r 0x600000 0x40000 && fdt addr $fdt_addr_r && fdt resize 10000 && fdt set "/soc/spi@20c0000" "status" "disabled" && fdt boardsetup'

And to build a Debian kernel with support for restool (and DPAA2 VFIO, though I haven’t tried that myself), build a debian kernel for ten64 · GitHub is a short script to

  1. grab the current kernel sources from experimental
  2. configure to not build docs/source/debug/flavours/variants
  3. patch to enable some fsl-mc bits
  4. build

It takes ~25 minutes to build on the ten64 once ccache is primed, and the need for all this part should go away once https://bugs.debian.org/992988 and https://bugs.debian.org/993000 are done.