LS1048ardb SERDES Matched DPL File

brian-wood · ‎07-31-2025

Hello,

I'm new to NXP Layerscape hardware and am working with a LS1048ardb platform. I'd like to bring up the DPMAC2 ethernet device (which I believe is the general use 'eth0' for basic ethernet), but from reading various NXP forum posts I need to have a SERDES matched DPL file. Without the DPL file I get the expected uboot error:

"fsl-mc: DPL not deployed, DPAA2 ethernet not work"

I found a couple NXP forum posts for generating an 'empty' DPL file and with that dtb I get this error:

"fsl-mc: Deploying data path layout ... WARNING: Firmware returned an error (GSR: 0x3f)"

In some NXP technical support forum responses (for the ls1088ardb) Iby providing the SERDES values NXP engineers can generate an appropriate DPL file, is that possible in my case as I'm not having much luck trying to work on creating my own?

Here's some information I've gathered from mii/mdio and SERDES values if it helps:

=> mii device
MII devices: 'FSL_MDIO0' 'FSL_MDIO1'
Current device: 'FSL_MDIO0'

=> mii info
PHY 0x01: OUI = 0x80028, Model = 0x23, Rev = 0x01, 1000baseT, FDX

=> mdio list
FSL_MDIO0:
1 - TI DP83867 <--> DPMAC2@sgmii
FSL_MDIO1:

Uboot boot data that seems relevant:

Using SERDES1 Protocol: 18 (0x12)
Using SERDES2 Protocol: 13 (0xd)

Net: DPMAC2@sgmii [PRIME]

fsl-mc: Booting Management Complex ... SUCCESS
fsl-mc: Management Complex booted (version: 10.12.0, boot status: 0x1)
Enable 1000BT Full-Duplex/Half-Duplex Advertising

Any help would be greatly appreciated.

LFGP

Dear @brian-wood , I hope this message find you well.

I need some clarification about your custom board.

are you using the LS1048A in your custom board? or what is the Layerscape device you are using?

did you base your design in the LS1048ARDB? NXP doesn't has any LS1048ARDB.

On the other hand, you can find the DPL settings in the DPAA reference manual.

BR

LFGP

brian-wood

Hi LFGP,

I decided to try my DPL file along with switching from the upstream 6.14 Linux kernel to the NXP kernel 4.14 that matches the LSDK1812 (that was used when they setup this platform quite a few years back) and I'm able to bring up the DPMAC2 at eth0.

I do have an issue though, it seems the FSL management complex is attaching eth0 to PHY 0 instead of PHY 1 (which I believe I've set correctly in the DTS). As a sanity check (since I'm very new to using device trees) is everything setup correctly for my use of PHY 1:

&emdio1 {

status = "okay";

mcp_debug_phy: emdio1_phy@1 {

compatible = "ethernet-phy-ieee802.3-c22";

interrupts = <0 2 0x4>;

reg = <0x1>;

phy-connection-type = "sgmii";

};

&dpmac2 {

phy-handle = <&mcp_debug_phy>;

phy-connection-type = "sgmii";

};

But when I try and 'ping' after assigning an ip address to eth0 I get no errors or rx/tx count increases (checking with ifconfig). When I use 'ethtool eth0' I see that it's showing attached to PHYAD 0:

# ethtool eth0
Settings for eth0:
Supported ports: [ ]
Supported link modes: Not reported
Supported pause frame use: No
Supports auto-negotiation: No
Supported FEC modes: Not reported
Advertised link modes: Not reported
Advertised pause frame use: No
Advertised auto-negotiation: No
Advertised FEC modes: Not reported
Speed: Unknown!
Duplex: Full
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
Auto-negotiation: off
MDI-X: Unknown
Link detected: no
#

I didn't change the defaults for 'fsl-ls1088a.dtsi', but is this correct when expecting to use PHY 1?

/* TODO: WRIOP (CCSR?) */
emdio1: mdio@0x8B96000 { /* WRIOP0: 0x8B8_0000, * E-MDIO1: 0x1_6000*/

compatible = "fsl,fman-memac-mdio";
reg = <0x0 0x8B96000 0x0 0x1000>;
device_type = "mdio";
little-endian; /* force the driver in LE mode */

/* Not necessary on the QDS, but needed on the RDB */
#address-cells = <1>;
#size-cells = <0>;

};

Would there be anything in the DPL I'd need to maybe adjust so that the correct PHY is attached?

Thank you very much for the help.

LFGP

Dear @brian-wood,
the ''PHYAD:0" means that the PHY is not recognized.
Please use the next link to review the LS1088 RDB's DTS and DTSi.
https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts

https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi

also please the AN5125 intro DTS
https://www.nxp.com/docs/en/application-note/AN5125.pdf
If your custom board uses the SERDES to get the SGMII or RGMII, without external PHY, then your DTS will use the PCS nodes to set the MACx

brian-wood

Hi LFGP,

I wanted to thank you for your advice working through this issue. I found the problem; we're using the TI83867 phy and I needed to add 'ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;' to my phy device-tree node. I've now got the ethernet coming up but have a follow-up question.

Once everything boots I'm seeing an 'eth0' like I'd expect, but I'm also seeing a 'mac2' (I'm assuming this relates to how the FSL MC is brining up the networking). Is there an easy configuration change where I can have everything so it is 'eth0'? Or have just the 'mac2'?

I don't have access to making changes to the DPC file, so if there is something I can modify to the DPL file or elsewhere that would be helpful.

Thank you for the help.

LFGP

Hi @brian-wood
Thanks for share your findings, so you have added the next to your DTS, right?
>>>
&davinci_mdio {
phy0: ethernet-phy@0 { //PHY0 is defined and passed to phy-handle
reg = <0>;
ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
};
};
&cpsw_port1 {
phy-mode = "rgmii-rxid";
phy-handle = <&phy0>;
};
<<<
"I'm assuming this relates to how the FSL MC is brining up the networking)" not really, it is related to the ethernet memory map, but it is not something that we can modify.

Unfortunately, there isn't an easy way, 8( , you can omit the DPL only if you want, but isn't a good idea, becase the purpose of the DPL is not to describe hardware attributes, but rather to describe the initial topology and attributes of logical objects that the MC should create.

BR
LFGP

LFGP

Dear @brian-wood ,

To add a new DPNI the LS1088A and the LS1048A has the same procedure, please review the link in my previous post.

brian-wood

Hi LFGP,

Just as a quick check, this ls1048ardb platform is using a 2018.09 version of uboot and fsl_mc version 10.12.0, can I use a 6.14 Linux kernel with this? I'm just wondering if the NXP/FSL kernel driver error I'm encountering bringing up the DPL nodes with the FSL management complex is due to a mismatch for what fsl_mc supports (and is causing the mc_send_command() 'unsupported operation' failure)?

I've read that document link previously mentioned, but am not able to link to eth0 as I'm in a partial state (due to the 'unsupported operation' failure enabling the DPL file during Linux kernel boot). I do see these same 'unsupported operation' when running 'ls-listni, restool, etc...' after booting leading me to think there is a mismatch with my versions of fsl_mc, restool, and using a Linux kernel 6.14.

Here's additional uboot information if it helps:

U-Boot 2018.09 GPU_BL_01Feb2021 tf/CPSW-15234-BL-U-Boot a996f0a3 (Feb 01 2021 - 18:04:24 -0700)

SoC: LS1048A Rev1.0 (0x87032110)
Clock Configuration:
CPU0(A53):1200 MHz CPU1(A53):1200 MHz CPU2(A53):1200 MHz
CPU3(A53):1200 MHz
Bus: 500 MHz DDR: 1600 MT/s
Reset Configuration Word (RCW):
00000000: 30004014 00000030 00000000 00000000
00000010: 00000000 00090000 00200000 00000000
00000020: 02e12980 00002580 00000000 00000000
00000030: 00fff054 00000000 00000000 00000000
00000040: 00000000 00000000 00000000 00000000
00000050: 00000000 00000000 00000000 00000000
00000060: 00000000 00000000 01000009 00000000
00000070: 33330002 00009555
I2C: ready
DRAM: Initializing DDR per training values
Enabling DDR controller
Memory Init ok, no error on DDRC after check ERR_DETECT register
ERR_DETECT=0
3.9 GiB
DDR 3.9 GiB (DDR4, 64-bit, CL=12, ECC on)
WARN: pls set popts->cpo_sample = 0x4b in <board>/ddr.c to optimize cpo
**boot_all_cores env var=true...continuing
Waking secondary cores to start from fbd4b000
All (4) cores are up.
Using SERDES1 Protocol: 18 (0x12)
Using SERDES2 Protocol: 13 (0xd)
MMC: FSL_SDHC: 0
Loading Environment from Flash... OK
In: serial
Out: serial
Err: serial
Model: Boeing Dual MCP Green V0.2_1 (NXP Layerscape 1048a)
Net: DPMAC2@sgmii [PRIME]
Warning: DPMAC2@sgmii (eth0) using random MAC address - 16:af:d1:f3:8a:cf

crc32+
fsl-mc: Booting Management Complex ... SUCCESS
fsl-mc: Management Complex booted (version: 10.12.0, boot status: 0x1)
Enable 1000BT Full-Duplex/Half-Duplex Advertising
Hit any key to stop autoboot: 0

LFGP · ‎08-01-2025

dear @brian-wood,
I suppose you are meaning to the LS1088ARDB,
if you want to configure the DPMAC2 please follow the steps showed in the next link
https://community.nxp.com/t5/Layerscape-Knowledge-Base/LS1088ARDB-LS1088ARDB-PB-How-to-create-a-DPAA...

brian-wood

Thank you for the response, I've read through many of the NXP documents for this custom board based on the LS1048ardb (has four GPP cores so slightly different than the LS1088ardb I guess). This is a platform developed about 5 years ago and I've inherited it and using for a simple dpmac2 ethernet proof of concept.

I've added some driver debugging code and can see these dmesg (from the last successful fsl_mc call to the 'unsupported operation' failure) and think I might have something set incorrectly in my DPL file that is causing the failure (see attached DPL dts):

[ 14.200954] fsl_mc_dprc dprc.1: BJW: (mc_send_command) FSL MC response: 0, status: Command completed successfully (0x0)
[ 14.211772] fsl_mc_dprc dprc.1: BJW: (dpni_set_pools) FSL MC calling mc_send_command()
[ 14.226219] fsl_mc_dprc dprc.1: BJW: (mc_send_command) FSL MC response: 0, status: Unsupported operation (0xb)
[ 14.236254] fsl_dpaa2_eth dpni.1: dpni_set_pools() failed
[ 14.241672] fsl_dpaa2_eth dpni.1: BJW: (dpaa2_eth_bind_dpni) error: -524

I based my DPL file off examples I've seen and read from the NXP documents (like this one: https://docs.nxp.com/bundle/GUID-487B2E69-BB19-42CB-AC38-7EF18C0FE3AE/page/GUID-C254A494-0853-4C94-8...)

I'm not exactly sure what information I might need to provide that would help root cause this bring-up of DPMAC2@sgmii ethernet issue (I'm able to boot this platform and use the ethernet for uboot/tftp) but just not get things up and running in Linux. So if there is any other information needed I'm happy to supply.