VSC8514 Phy communication problem with Aquila AM69 SOM

My question is around getting that overlay correct from fragment 155 to 159 for the ETH1 to ETH4 ports. I am not getting traffic on these ports and something is amiss.

fragment@155 {
	target-path = "/bus@100000/ethernet@c000000/mdio@f00";
	__overlay__ {
		status = "okay";
		#address-cells = <1>;
		#size-cells = <0>;

		/* Shared VSC8514 reset drive on Aquila B46 / GPIO0_33. GPIO is active-high into MOSFET; MOSFET applies active-low nRESET to PHY.
		 * Datasheet requires >=2 ms assertion after power/clock stable
		 * and >=105 ms before SMI/MDIO access after de-assert.
		 * Use 200 ms margin for bring-up.
		 */
		reset-gpios = <&main_gpio0 33 GPIO_ACTIVE_HIGH>;
		/* This is a bus-level shared reset for all four VSC8514 PHY addresses. */
		/* Assert reset for 10 ms, then wait 200 ms after deassert before MDIO. */
		reset-delay-us = <10000>;
		reset-post-delay-us = <200000>;

		qsgmii_phy0: ethernet-phy@4 {
			compatible = "ethernet-phy-ieee802.3-c22";
			reg = <0x04>;
			#phy-cells = <0>;
			max-speed = <1000>;
		};

		qsgmii_phy1: ethernet-phy@5 {
			compatible = "ethernet-phy-ieee802.3-c22";
			reg = <0x05>;
			#phy-cells = <0>;
			max-speed = <1000>;
		};

		qsgmii_phy2: ethernet-phy@6 {
			compatible = "ethernet-phy-ieee802.3-c22";
			reg = <0x06>;
			#phy-cells = <0>;
			max-speed = <1000>;
		};

		qsgmii_phy3: ethernet-phy@7 {
			compatible = "ethernet-phy-ieee802.3-c22";
			reg = <0x07>;
			#phy-cells = <0>;
			max-speed = <1000>;
		};
	};
};
fragment@156 {
	target-path = "/bus@100000/ethernet@c000000/ethernet-ports/port@1";
	__overlay__ {
		status = "okay";
		label = "port1";
		reg = <0x01>;
		phy-mode = "qsgmii";
		phy-handle = <&qsgmii_phy0>;
		local-mac-address = [00 14 2d d0 2d c1];
		/* MAC mux plus shared SERDES2 lane 3 configured as QSGMII. */
		phys = <&cpsw0_phy_gmii_sel 1>, <&serdes2_qsgmii_link>;
		phy-names = "mac", "serdes";
	};
};

fragment@157 {
	target-path = "/bus@100000/ethernet@c000000/ethernet-ports/port@2";
	__overlay__ {
		status = "okay";
		label = "port2";
		reg = <0x02>;
		phy-mode = "qsgmii";
		phy-handle = <&qsgmii_phy1>;
		local-mac-address = [00 14 2d d0 2d c2];
		/* MAC mux plus shared SERDES2 lane 3 configured as QSGMII. */
		phys = <&cpsw0_phy_gmii_sel 2>, <&serdes2_qsgmii_link>;
		phy-names = "mac", "serdes";
	};
};

fragment@158 {
	target-path = "/bus@100000/ethernet@c000000/ethernet-ports/port@3";
	__overlay__ {
		status = "okay";
		label = "port3";
		reg = <0x03>;
		phy-mode = "qsgmii";
		phy-handle = <&qsgmii_phy2>;
		local-mac-address = [00 14 2d d0 2d c3];
		/* MAC mux plus shared SERDES2 lane 3 configured as QSGMII. */
		phys = <&cpsw0_phy_gmii_sel 3>, <&serdes2_qsgmii_link>;
		phy-names = "mac", "serdes";
	};
};

fragment@159 {
	target-path = "/bus@100000/ethernet@c000000/ethernet-ports/port@4";
	__overlay__ {
		status = "okay";
		label = "port4";
		reg = <0x04>;
		phy-mode = "qsgmii";
		phy-handle = <&qsgmii_phy3>;
		local-mac-address = [00 14 2d d0 2d c4];
		/* MAC mux plus shared SERDES2 lane 3 configured as QSGMII. */
		phys = <&cpsw0_phy_gmii_sel 4>, <&serdes2_qsgmii_link>;
		phy-names = "mac", "serdes";
	};
};

fragment@160 {
	target-path = "/bus@100000/pinctrl@11c000";
	__overlay__ {
		bia5_v11_cpsw9g_mdio_pins: bia5-v11-cpsw9g-mdio-pins {
			pinctrl-single,pins = <
				/* MDIO */
				J784S4_IOPAD(0x5c, PIN_INPUT_PULLUP, 4)

				/* MDC */
				J784S4_IOPAD(0x58, PIN_OUTPUT, 4)
			>;
		};
	};
};

fragment@161 {
	target-path = "/bus@100000/ethernet@c000000/mdio@f00";
	__overlay__ {
		status = "okay";
		pinctrl-names = "default";
		pinctrl-0 = <
			&bia5_v11_cpsw9g_mdio_pins
		>;
	};
};

when I run “ip link” at the command line, it shows that the ports are there, but I am not seeing traffic on the ports at all. a connected laptop shows that there is a connection but no traffic.

Is this a configuration issue with the overlay, or should I be digging deeper into a hardware issue?

root@aquila-am69-12594628:~# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 00:14:2d:c0:2d:c4 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 00:14:2d:d0:2d:c1 brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 00:14:2d:d0:2d:c2 brd ff:ff:ff:ff:ff:ff
5: eth3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 00:14:2d:d0:2d:c3 brd ff:ff:ff:ff:ff:ff
6: eth4: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 00:14:2d:d0:2d:c4 brd ff:ff:ff:ff:ff:ff
root@aquila-am69-12594628:~# ethtool eth4
Settings for eth4:
Supported ports: [ MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: Symmetric
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: Unknown!
Duplex: Unknown! (255)
Auto-negotiation: on
Port: MII
PHYAD: 0
Transceiver: internal
Supports Wake-on: d
Wake-on: d
Current message level: 0x000020f7 (8439)
drv probe link ifdown ifup rx_err tx_err hw
Link detected: no
root@aquila-am69-12594628:~#

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.


I’d be glad to help troubleshoot your VSC8514 PHY communication issue! To provide the most accurate guidance, could you let me know which version of Torizon OS you’re running on your Aquila AM69? You can get this information by running:

tdx-info

Also, please let me know which carrier board you’re using with your Aquila AM69 module.

This will help me provide specific guidance for your hardware and software configuration. The device tree overlay structure you’ve shown appears to be for a custom carrier board implementation, and the exact configuration requirements can vary depending on your specific setup and OS version.

You can find more information about using the tdx-info command at: Getting Device Information with Tdx-Info | Toradex Developer Center

Common platforms to consider:

  • Hardware: Aquila AM69, various carrier boards
  • OS versions: Torizon OS 6, Torizon OS 7.x.x
  • Implementation details: Device tree overlays, Ethernet configuration

Best regards, Toradex AI Assistant.


Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

aquila-am69-12594628 login: root
root@aquila-am69-12594628:~# tdx-info

Software summary

Bootloader: U-Boot

Kernel version: 6.6.119-g8af7a2cb6a06-dirty #1 SMP PREEMPT Tue May 5 11:38:39 AEST 2026
Kernel command line: root=PARTUUID=5a1d15ea-02 ro rootwait console=tty1 console=ttyS2,115200
Distro name: NAME=“BIA5 RVH AM69A”
Distro version: VERSION_ID=7.5.0-devel-20260205045228-build.0
Distro variant: -
Hostname: aquila-am69-12594628

Hardware info

HW model: BIA5 RVH AM69A Embedded Platform

Toradex version: 0211 V1.1A
Serial number: 12594628
Processor arch: aarch64

(1)

Thank you for providing the system information! I can see you’re running a custom distribution based on Torizon OS 7.5.0-devel with an Aquila AM69 module (PID8: 0211 V1.1A) on what appears to be a custom BIA5 RVH carrier board.

Based on your device tree overlay configuration and the symptoms you’re describing, here are several areas to investigate:

Interface Configuration Analysis

Your ip link output shows that eth1-eth4 are in the DOWN state with qdisc noop, which indicates the interfaces aren’t being brought up properly. This could be due to several factors:

Potential Issues to Check

1. PHY Reset and Timing

Your reset configuration looks reasonable, but verify:

  • GPIO0_33 is correctly mapped and available
  • The MOSFET circuit is working as expected (active-high to MOSFET, MOSFET applies active-low to PHY)
  • The 200ms post-reset delay is sufficient for your specific VSC8514 variant

2. SERDES Configuration

Your overlay references &serdes2_qsgmii_link - ensure this SERDES link is properly configured in your base device tree for QSGMII mode.

3. Clock Configuration

QSGMII typically requires specific clock configurations. Verify that the reference clocks for the VSC8514 are properly configured.

4. Pin Multiplexing

Check that the MDIO pins (fragments 160-161) don’t conflict with other pin assignments.

Debugging Steps

  1. Check PHY Detection:
cat /sys/class/net/eth*/phydev/phy_id
  1. Manually Bring Up Interfaces:
ip link set eth1 up
ip link set eth2 up
ip link set eth3 up
ip link set eth4 up
  1. Check Kernel Messages:
dmesg | grep -i "phy\|eth\|mdio"
  1. Verify MDIO Communication:
ethtool --phy-statistics eth1

Device Tree Overlay Considerations

Based on the available Toradex documentation for device tree overlays (1), ensure your overlay structure follows the proper format and that all referenced nodes exist in the base device tree.

Since you’re using a custom carrier board with a custom distribution, you may need to verify that:

  • The base device tree properly defines the CPSW9G ethernet controller
  • The SERDES configuration matches your hardware
  • All GPIO and pin references are correct for your specific board design

The fact that ethtool eth4 shows “Link detected: no” suggests the PHY communication might be working but the physical link isn’t established, which could point to hardware-level issues or incorrect PHY configuration.

Best regards, Toradex AI Assistant.


Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

OK, I have run the command line arguments you suggested.

BIA5 - RVH AM69A Headless Image aquila-am69-12594628 ttyS2
Aquila-AM69_RVH-Embedded-Image

aquila-am69-12594628 login: root
root@aquila-am69-12594628:~# cat /sys/class/net/eth*/phydev/phy_id
0x2000a231
root@aquila-am69-12594628:~# ip link set eth1 up
RTNETLINK answers: Input/output error
root@aquila-am69-12594628:~# ip link set eth2 up
RTNETLINK answers: Input/output error
root@aquila-am69-12594628:~# ip link set eth3 up
RTNETLINK answers: Input/output error
root@aquila-am69-12594628:~# ip link set eth4 up
RTNETLINK answers: Input/output error
root@aquila-am69-12594628:~# dmesg | grep -i “phy|eth|mdio”
[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x411fd080]
[ 0.000000] psci: probing for conduit method from DT.
[ 0.000000] arch_timer: cp15 timer(s) running at 200.00MHz (phys).
[ 0.211105] hns3: Hisilicon Ethernet Network Driver for Hip08 Family - version
[ 0.211237] igb: Intel(R) Gigabit Ethernet Network Driver
[ 0.234445] optee: probing for conduit method.
[ 3.955980] am65-cpsw-nuss 46000000.ethernet: initializing am65 cpsw nuss version 0x6BA02102, cpsw version 0x6BA82102 Ports: 2 quirks:00000000
[ 4.005957] davinci_mdio 46000f00.mdio: davinci mdio revision 9.7, bus freq 1000000
[ 4.014848] am65-cpsw-nuss 46000000.ethernet: initialized cpsw ale version 1.4
[ 4.022065] am65-cpsw-nuss 46000000.ethernet: ALE Table size 64
[ 4.028386] am65-cpsw-nuss 46000000.ethernet: CPTS ver 0x4e8a010b, freq:500000000, add_val:1 pps:0
[ 4.038980] am65-cpsw-nuss c000000.ethernet: initializing am65 cpsw nuss version 0x6BA03102, cpsw version 0x6BA82902 Ports: 9 quirks:00000000
[ 6.017858] am65-cpsw-nuss 46000000.ethernet: initializing am65 cpsw nuss version 0x6BA02102, cpsw version 0x6BA82102 Ports: 2 quirks:00000000
[ 6.069949] davinci_mdio 46000f00.mdio: davinci mdio revision 9.7, bus freq 1000000
[ 6.081048] davinci_mdio 46000f00.mdio: phy[0]: device 46000f00.mdio:00, driver TI DP83867
[ 6.089358] am65-cpsw-nuss 46000000.ethernet: initialized cpsw ale version 1.4
[ 6.096598] am65-cpsw-nuss 46000000.ethernet: ALE Table size 64
[ 6.102941] am65-cpsw-nuss 46000000.ethernet: CPTS ver 0x4e8a010b, freq:500000000, add_val:1 pps:0
[ 6.117973] am65-cpsw-nuss 46000000.ethernet: set new flow-id-base 48
[ 6.128268] am65-cpsw-nuss c000000.ethernet: initializing am65 cpsw nuss version 0x6BA03102, cpsw version 0x6BA82902 Ports: 9 quirks:00000000
[ 6.409950] davinci_mdio c000f00.mdio: davinci mdio revision 9.7, bus freq 1000000
[ 6.432861] davinci_mdio c000f00.mdio: phy[4]: device c000f00.mdio:04, driver Microsemi GE VSC8514 RVH
[ 6.442168] davinci_mdio c000f00.mdio: phy[5]: device c000f00.mdio:05, driver Microsemi GE VSC8514 RVH
[ 6.451462] davinci_mdio c000f00.mdio: phy[6]: device c000f00.mdio:06, driver Microsemi GE VSC8514 RVH
[ 6.460755] davinci_mdio c000f00.mdio: phy[7]: device c000f00.mdio:07, driver Microsemi GE VSC8514 RVH
[ 6.470069] am65-cpsw-nuss c000000.ethernet: initialized cpsw ale version 1.5
[ 6.477197] am65-cpsw-nuss c000000.ethernet: ALE Table size 512
[ 6.483507] am65-cpsw-nuss c000000.ethernet: CPTS ver 0x4e8a010c, freq:250000000, add_val:3 pps:0
[ 6.499910] am65-cpsw-nuss c000000.ethernet: set new flow-id-base 82
[ 9.966165] am65-cpsw-nuss 46000000.ethernet eth0: PHY [46000f00.mdio:00] driver [TI DP83867] (irq=370)
[ 9.976788] am65-cpsw-nuss 46000000.ethernet eth0: configuring for phy/rgmii-rxid link mode
[ 13.233468] am65-cpsw-nuss 46000000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
root@aquila-am69-12594628:~# ethtool --phy-statistics eth1
no stats available
root@aquila-am69-12594628:~# ethtool --phy-statistics eth2
no stats available
root@aquila-am69-12594628:~# ethtool --phy-statistics eth3
no stats available
root@aquila-am69-12594628:~# ethtool --phy-statistics eth4
no stats available
root@aquila-am69-12594628:~#

Hello Robert,

In the previously shared schematic, Aquila B89, acting as MDIO0_MDIO, is connected to ETH2_QSGMII_MDC. And Aquila 90, acting as MDIO0_MDC, is connected to ETH2_QSGMII_MDIO. They should be switched. Is it corrected on your latest design?
image

You have migrated from Aquila AM69 V1.0 to V1.1 SoM, there are hardware changes between them. Parts of them affect your carrier design. For example, R171 and R172 voltage dividers are no longer needed. But this is not related to VSC8514 switch.

I am getting data on the MDC / MDIO lines and communicating with the VSC8514 on the SMI, however I am losing the comms at some point and I am trying to confirm I have the settings correct for the overlay and also looking into the kernel driver for the Microsemi VSC8514 mscc phy driver

This next fragment is from my live dts on the target mainboard that has the Toradex Aquila AM69 SOM that I am trying to get running with the VSC8514 Quad Phy to allow an extra 4 ethernet ports on the mainboard. I am not seeing the qsgmii traffic on the 5Ghz lanes, and would like to check I have the serdes settings correct:

	wiz@5020000 {
		#size-cells = <0x01>;
		clocks = <0x0f 0x196 0x02 0x0f 0x196 0x06 0x6c 0x0f 0x196 0x05>;
		#address-cells = <0x01>;
		assigned-clocks = <0x0f 0x196 0x06>;
		#clock-cells = <0x01>;
		power-domains = <0x10 0x196 0x01>;
		#reset-cells = <0x01>;
		assigned-clock-parents = <0x0f 0x196 0x0a>;
		status = "okay";
		compatible = "ti,j784s4-wiz-10g";
		ranges = <0x5020000 0x00 0x5020000 0x10000>;
		phandle = <0x6f>;
		clock-names = "fck\0core_ref_clk\0ext_ref_clk\0core_ref1_clk";
		num-lanes = <0x04>;

		serdes@5020000 {
			#size-cells = <0x00>;
			clocks = <0x6f 0x00 0x6f 0x10>;
			#address-cells = <0x01>;
			assigned-clocks = <0x6f 0x00 0x6f 0x01 0x6f 0x02>;
			#clock-cells = <0x01>;
			resets = <0x6f 0x00>;
			reg = <0x5020000 0x10000>;
			assigned-clock-parents = <0x0f 0x196 0x06 0x0f 0x196 0x06 0x0f 0x196 0x06>;
			reset-names = "torrent_reset";
			status = "okay";
			compatible = "ti,j721e-serdes-10g";
			phandle = <0x17b>;
			reg-names = "torrent_phy";
			clock-names = "refclk\0phy_en_refclk";

			phy@3 {
				resets = <0x6f 0x04>;
				cdns,phy-type = <0x09>;
				cdns,num-lanes = <0x01>;
				reg = <0x03>;
				status = "okay";
				phandle = <0x205>;
				#phy-cells = <0x00>;
			};
		};
	};

I meant to add in the port settings from the live dts as well:

	ethernet@c000000 {
		dmas = <0x3c 0xca00 0x3c 0xca01 0x3c 0xca02 0x3c 0xca03 0x3c 0xca04 0x3c 0xca05 0x3c 0xca06 0x3c 0xca07 0x3c 0x4a00>;
		#size-cells = <0x02>;
		clocks = <0x0f 0x40 0x00>;
		#address-cells = <0x02>;
		dma-names = "tx0\0tx1\0tx2\0tx3\0tx4\0tx5\0tx6\0tx7\0rx";
		reg = <0x00 0xc000000 0x00 0x200000>;
		power-domains = <0x10 0x40 0x01>;
		status = "okay";
		compatible = "ti,j784s4-cpswxg-nuss";
		ranges = <0x00 0x00 0x00 0xc000000 0x00 0x200000>;
		phandle = <0x192>;
		dma-coherent;
		reg-names = "cpsw_nuss";
		clock-names = "fck";

		mdio@f00 {
			#size-cells = <0x00>;
			clocks = <0x0f 0x40 0x00>;
			#address-cells = <0x01>;
			reg = <0x00 0xf00 0x00 0x100>;
			bus_freq = <0x3d090>;
			pinctrl-0 = <0x206>;
			pinctrl-names = "default";
			status = "okay";
			compatible = "ti,cpsw-mdio\0ti,davinci_mdio";
			phandle = <0x19b>;
			clock-names = "fck";

			ethernet-phy@5 {
				max-speed = <0x3e8>;
				reg = <0x05>;
				compatible = "ethernet-phy-id000f.0dc7";
				phandle = <0x202>;
				phy-mode = "qsgmii";
				#phy-cells = <0x00>;
			};

			ethernet-phy@7 {
				max-speed = <0x3e8>;
				reg = <0x07>;
				compatible = "ethernet-phy-id000f.0dc7";
				phandle = <0x204>;
				phy-mode = "qsgmii";
				#phy-cells = <0x00>;
			};

			ethernet-phy@4 {
				max-speed = <0x3e8>;
				interrupts = <0x2c 0x02>;
				coma-mode-gpios = <0x1c 0x10 0x00>;
				reg = <0x04>;
				rvh-reset-gpios = <0x1c 0x21 0x00>;
				pinctrl-0 = <0x77>;
				pinctrl-names = "default";
				compatible = "ethernet-phy-id000f.0dc7";
				interrupt-parent = <0x1c>;
				phandle = <0x201>;
				phy-mode = "qsgmii";
				#phy-cells = <0x00>;
			};

			ethernet-phy@6 {
				max-speed = <0x3e8>;
				reg = <0x06>;
				compatible = "ethernet-phy-id000f.0dc7";
				phandle = <0x203>;
				phy-mode = "qsgmii";
				#phy-cells = <0x00>;
			};
		};

		ethernet-ports {
			#size-cells = <0x00>;
			#address-cells = <0x01>;

			port@7 {
				local-mac-address = [00 14 2d d0 2d c3];
				reg = <0x07>;
				label = "port3";
				status = "okay";
				phandle = <0x199>;
				phy-mode = "qsgmii";
				phys = <0x73 0x07>;
				phy-handle = <0x203>;
				phy-names = "mac";
			};

			port@6 {
				local-mac-address = [00 14 2d d0 2d c2];
				reg = <0x06>;
				label = "port2";
				status = "okay";
				phandle = <0x198>;
				phy-mode = "qsgmii";
				phys = <0x73 0x06>;
				phy-handle = <0x202>;
				phy-names = "mac";
			};

			port@2 {
				reg = <0x02>;
				label = "port2";
				ti,mac-only;
				status = "disabled";
				phandle = <0x194>;
			};

			port@8 {
				local-mac-address = [00 14 2d d0 2d c4];
				reg = <0x08>;
				label = "port4";
				status = "okay";
				phandle = <0x19a>;
				phy-mode = "qsgmii";
				phys = <0x73 0x08 0x205>;
				phy-handle = <0x204>;
				phy-names = "mac\0serdes";
			};

			port@5 {
				local-mac-address = [00 14 2d d0 2d c1];
				reg = <0x05>;
				label = "port1";
				status = "okay";
				phandle = <0x197>;
				phy-mode = "qsgmii";
				phys = <0x73 0x05>;
				phy-handle = <0x201>;
				phy-names = "mac";
			};

			port@3 {
				reg = <0x03>;
				label = "port3";
				ti,mac-only;
				status = "disabled";
				phandle = <0x195>;
			};

			port@1 {
				reg = <0x01>;
				label = "port1";
				ti,mac-only;
				status = "disabled";
				phandle = <0x193>;
			};

			port@4 {
				reg = <0x04>;
				label = "port4";
				ti,mac-only;
				status = "disabled";
				phandle = <0x196>;
			};
		};

		cpts@3d000 {
			clocks = <0x0f 0x40 0x03>;
			ti,cpts-ext-ts-inputs = <0x04>;
			ti,cpts-periodic-outputs = <0x02>;
			reg = <0x00 0x3d000 0x00 0x400>;
			compatible = "ti,am65-cpts";
			clock-names = "cpts";
			interrupts-extended = <0x01 0x00 0x10 0x04>;
			interrupt-names = "cpts";
		};
	};