PROCESSOR-SDK-AM437X: Linux-RT Single PRU kernel problem

ccanberry

Part Number: PROCESSOR-SDK-AM437X
Other Parts Discussed in Thread: TLK105L, TLK105, USB-2-MDIO

Hi ,

I am working on a custom AM437x board where i obtained MYD_C437x module, and a simple PCB design that includes 1 CPSW and 1 PRU ethernet ports.
As i did my research, i found out that the single PRU is supported after Lİnux SDK 5.3 or later, so i decided to use latest Linux RT SDK 6.03 (with linux-rt-4.19.94) rather than the one provided by 3rd party(4.1).

Referencing the topic: "https://e2e.ti.com/support/processors/f/791/t/854235?tisearch=e2e-sitesearch&keymatch=single%20pru%20am437x

aliases {
	//ethernet2 = &pruss1_emac0;
	ethernet3 = &pruss1_emac1;
};



...


/* Dual-MAC Ethernet application node on PRU-ICSS1 */
	pruss1_eth: pruss1_eth {
		compatible = "ti,am4376-prueth";
		prus = <&pru1_0>, <&pru1_1>;
		firmware-name = "",
				"ti-pruss/am437x-pru1-prueth-fw.elf";
		sram = <&ocmcram>;
		interrupt-parent = <&pruss1_intc>;
		mii-rt = <&pruss1_mii_rt>;

		pinctrl-0 = <&pruss1_eth_default>;
		pinctrl-names = "default";
		interrupts = <20>, <21>;
		interrupt-names = "rx_red_hp", "rx_red_lp";

		/*
		pruss1_emac0: ethernet-mii0 {
			phy-handle = <&pruss1_eth0_phy>;
			phy-mode = "mii";
			interrupts = <20>, <22>, <23>, <26>;
			interrupt-names = "rx", "tx", "hsrprp_ptp_tx",
					  "emac_ptp_tx";
			
			local-mac-address = [00 00 00 00 00 00];
		};
		*/

		pruss1_emac1: ethernet-mii1 {
			phy-handle = <&pruss1_eth1_phy>;
			phy-mode = "mii";
			interrupts = <21>, <23>, <24>, <27>;
			interrupt-names = "rx", "tx", "hsrprp_ptp_tx",
					  "emac_ptp_tx";
			/* Filled in by bootloader */
			local-mac-address = [00 00 00 00 00 00];
		};
	};



...


&pruss_soc_bus {
	status = "okay";

	pruss1: pruss@54400000 {
		status = "okay";
	};

	pruss0: pruss@54440000 {
		status = "okay";
	};
};

&pruss1_mdio {
	pinctrl-0 = <&pruss1_mdio_default>;
	pinctrl-names = "default";
	status = "okay";

	reset-gpios = <&gpio4 20 GPIO_ACTIVE_LOW>;
	reset-delay-us = <2>;	/* PHY datasheet states 1uS min */

	pruss1_eth0_phy: ethernet-phy@0 {
		reg = <0>;
	}; /* tried also commenting out pruss1_eth0_phy node */

	pruss1_eth1_phy: ethernet-phy@1 {
		reg = <1>;
	};
};

However, although it succesfully probes, i keep getting kernel error after boot up, and it fails.

[    1.138111] libphy: Fixed MDIO Bus: probed
[    1.214208] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6, bus freq 1000000
[    1.221917] davinci_mdio 4a101000.mdio: detected phy mask ffffffef
[    1.229281] libphy: 4a101000.mdio: probed
[    1.233335] davinci_mdio 4a101000.mdio: phy[4]: device 4a101000.mdio:04, driver Atheros 8035 ethernet
[    1.243746] cpsw 4a100000.ethernet: No slave[1] phy_id, phy-handle, or fixed-link property
[    1.252147] cpsw 4a100000.ethernet: Detected MACID = 04:79:b7:e8:e5:42
[    1.258885] cpsw 4a100000.ethernet: initialized cpsw ale version 1.4
[    1.265304] cpsw 4a100000.ethernet: ALE Table size 1024
[    1.270600] cpsw 4a100000.ethernet: cpts: overflow check period 500 (jiffies)

...

[   11.634844] davinci_mdio 54432400.mdio: davinci mdio revision 1.6, bus freq 1000000
[   11.642563] libphy: 54432400.mdio: probed
[   11.919187] davinci_mdio 54432400.mdio: phy[0]: device 54432400.mdio:00, driver unknown
[   12.048374] davinci_mdio 54432400.mdio: phy[1]: device 54432400.mdio:01, driver unknown
[   12.419793] remoteproc remoteproc1: 54434000.pru is available
[   12.551503] pru-rproc 54434000.pru: PRU rproc node pru@54434000 probed successfully
[   12.632842] remoteproc remoteproc2: 54438000.pru is available
[   12.754420] pru-rproc 54438000.pru: PRU rproc node pru@54438000 probed successfully
[   12.834908] remoteproc remoteproc3: 54474000.pru is available
[   12.840826] pru-rproc 54474000.pru: PRU rproc node pru@54474000 probed successfully
[   13.051221] remoteproc remoteproc4: 54478000.pru is available
[   13.093693] pru-rproc 54478000.pru: PRU rproc node pru@54478000 probed successfully
[   13.104547] net eth0: initializing cpsw version 1.15 (0)
[   13.205299] Atheros 8035 ethernet 4a101000.mdio:04: attached PHY driver [Atheros 8035 ethernet] (mii_bus:phy_addr=4a101000.mdio:04, irq=POLL)
[   13.205495] libphy: PHY  not found
[   13.205510] net eth0: phy "" not found on slave 1, err -19
[   13.225694] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   13.842386] prueth pruss1_eth: port 2: using random MAC addr: 4a:43:b8:50:65:33
[   14.015496] prueth pruss1_eth: pruss_fw_drop_untagged_vlan 0
[   14.021212] prueth pruss1_eth: pruss MC Mask (Port 1) ff:ff:ff:ff:ff:ff
[   14.234410] prueth pruss1_eth: TI PRU ethernet (type 0) driver initialized


 _____                    _____           _         _   
|  _  |___ ___ ___ ___   |  _  |___ ___  |_|___ ___| |_ 
|     |  _| .'| . | . |  |   __|  _| . | | | -_|  _|  _|
|__|__|_| |__,|_  |___|  |__|  |_| |___|_| |___|___|_|  
              |___|                    |___|            

Arago Project http://arago-project.org am437x-evm ttyS0

Arago 2019.11 am437x-evm ttyS0

am437x-evm login:

[   27.114767] iep ptp bc clkid -1
[   27.118012] remoteproc remoteproc2: powering up 54438000.pru
[   27.164373] remoteproc remoteproc2: Booting fw image ti-pruss/am437x-pru1-prueth-fw.elf, size 7712
[   27.173559] pruss 54400000.pruss: configured system_events[63-0] = 00600000,08a00000
[   27.238011] pruss 54400000.pruss: configured intr_channels = 0x0000032a host_intr = 0x000002aa
[   27.267016] remoteproc remoteproc2: remote processor 54438000.pru is now up
[   27.286679] net eth1: started
[   27.296721] Unable to handle kernel NULL pointer dereference at virtual address 00000064
[   27.304874] pgd = 42842c44
[   27.307597] [00000064] *pgd=00000000
[   27.311198] Internal error: Oops: 5 [#1] PREEMPT ARM
[   27.311204] Modules linked in: ti_prueth pru_rproc pruss irq_pruss_intc pm33xx omap_des des_generic omap_aes_driver omap_sham crypto_engine omap_crypto pruss_soc_bus ti_emif_sram dwc3_omap wkup_m3_ipc wkup_m3_rproc remoteproc rtc_omap omap_wdt sch_fq_codel
[   27.311265] CPU: 0 PID: 10 Comm: ktimersoftd/0 Not tainted 4.19.94-rt39-ga242ccf3f1 #2
[   27.311269] Hardware name: Generic AM43 (Flattened Device Tree)
[   27.311417] PC is at prueth_timer+0x94/0x1d8 [ti_prueth]
[   27.311423] LR is at 0x6
[   27.311429] pc : [<bf0d062c>]    lr : [<00000006>]    psr: a00f0113
[   27.311434] sp : dc489e38  ip : 00000000  fp : dc489e6c
[   27.311438] r10: 600f0113  r9 : d91b68c4  r8 : 0000000c
[   27.311443] r7 : d91b68c0  r6 : 0000000a  r5 : d91b6900  r4 : 00000000
[   27.311447] r3 : 00000004  r2 : 00000006  r1 : 00000000  r0 : 00000001
[   27.311457] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
[   27.311463] Control: 10c53c7d  Table: 9bbf4059  DAC: 00000051
[   27.311470] Process ktimersoftd/0 (pid: 10, stack limit = 0xcbdea4eb)
[   27.311477] Stack: (0xdc489e38 to 0xdc48a000)
[   27.311484] 9e20:                                                       00989680 00000000
[   27.311496] 9e40: dc489e6c c0d1a570 d91b6900 c0d1a520 ffffe000 00000000 00000060 600f0113
[   27.311507] 9e60: dc489ec4 dc489e70 c0188448 bf0d05a4 c018cf8c c0ac5a00 c0d51b57 00000006
[   27.311518] 9e80: 5ac3d08f c0d1a480 5ac3d08f c0d1a584 5ac3d08f 00000006 00000000 e899c255
[   27.311529] 9ea0: 1607167d c0d1a480 600f0113 00000100 00000000 00000008 dc489ee4 dc489ec8
[   27.311540] 9ec0: c018873c c0188370 00000020 c0d10f54 ffffe000 04208140 dc489f2c dc489ee8
[   27.311551] 9ee0: c012fdf0 c01886c8 dc4452c0 c08d5690 c0902e20 c0d13c40 c0d52fbc c0d51880
[   27.311562] 9f00: c0d10f24 ffffe000 ffffe000 00000001 c0d10f24 c0d05888 00000000 dc469df0
[   27.311573] 9f20: dc489f44 dc489f30 c012fed8 c012fc34 dc445200 ffffe000 dc489f74 dc489f48
[   27.311584] 9f40: c014e85c c012feb0 dc489f74 b7d43b39 dc4452c0 dc445280 00000000 dc488000
[   27.311595] 9f60: dc445200 c014e59c dc489fac dc489f78 c014a490 c014e5a8 dc4452d8 dc4452d8
[   27.311605] 9f80: 00000000 dc445280 c014a338 00000000 00000000 00000000 00000000 00000000
[   27.311616] 9fa0: 00000000 dc489fb0 c01010f0 c014a344 00000000 00000000 00000000 00000000
[   27.311625] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[   27.311635] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[   27.311637] Backtrace: 
[   27.311707] [<bf0d0598>] (prueth_timer [ti_prueth]) from [<c0188448>] (__hrtimer_run_queues.constprop.3+0xe4/0x230)
[   27.311720]  r10:600f0113 r9:00000060 r8:00000000 r7:ffffe000 r6:c0d1a520 r5:d91b6900
[   27.311725]  r4:c0d1a570
[   27.311741] [<c0188364>] (__hrtimer_run_queues.constprop.3) from [<c018873c>] (hrtimer_run_softirq+0x80/0x10c)
[   27.311752]  r10:00000008 r9:00000000 r8:00000100 r7:600f0113 r6:c0d1a480 r5:1607167d
[   27.311756]  r4:e899c255
[   27.311777] [<c01886bc>] (hrtimer_run_softirq) from [<c012fdf0>] (do_current_softirqs+0x1c8/0x27c)
[   27.311786]  r7:04208140 r6:ffffe000 r5:c0d10f54 r4:00000020
[   27.311798] [<c012fc28>] (do_current_softirqs) from [<c012fed8>] (run_ksoftirqd+0x34/0x54)
[   27.311808]  r10:dc469df0 r9:00000000 r8:c0d05888 r7:c0d10f24 r6:00000001 r5:ffffe000
[   27.311812]  r4:ffffe000
[   27.311832] [<c012fea4>] (run_ksoftirqd) from [<c014e85c>] (smpboot_thread_fn+0x2c0/0x2ec)
[   27.311838]  r5:ffffe000 r4:dc445200
[   27.311858] [<c014e59c>] (smpboot_thread_fn) from [<c014a490>] (kthread+0x158/0x160)
[   27.311869]  r9:c014e59c r8:dc445200 r7:dc488000 r6:00000000 r5:dc445280 r4:dc4452c0
[   27.311884] [<c014a338>] (kthread) from [<c01010f0>] (ret_from_fork+0x14/0x24)
[   27.311890] Exception stack(0xdc489fb0 to 0xdc489ff8)
[   27.311897] 9fa0:                                     00000000 00000000 00000000 00000000
[   27.311908] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[   27.311916] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[   27.311926]  r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c014a338
[   27.311930]  r4:dc445280
[   27.311943] Code: e1590007 0a000027 e515301c e4974004 (e5942064) 
[   27.694639] ---[ end trace 0000000000000002 ]---
[   27.700802] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[   32.133710] NOHZ: local_softirq_pending 02
[   32.148646] NOHZ: local_softirq_pending 02
[   32.173370] NOHZ: local_softirq_pending 02
[   32.174163] NOHZ: local_softirq_pending 02
[   32.186483] NOHZ: local_softirq_pending 02
[   32.191312] NOHZ: local_softirq_pending 02
[   32.196782] NOHZ: local_softirq_pending 02
[   32.269381] NOHZ: local_softirq_pending 02
[   32.272665] NOHZ: local_softirq_pending 02
[   32.274157] NOHZ: local_softirq_pending 02
[   32.821220] EXT4-fs (mmcblk1p2): mounted filesystem with ordered data mode. Opts: (null)

What could be the reason for such error, i am using one TLK105L as PHY. (Same problem occurs when i work with idkam437, applied same dts changes in PRU-wise)

Thanks in advance!

[ 11.634844] davinci_mdio 54432400.mdio: davinci mdio revision 1.6, bus freq 1000000[ 11.642563] libphy: 54432400.mdio: probed[ 11.919187] davinci_mdio 54432400.mdio: phy[0]: device 54432400.mdio:00, driver unknown[ 12.048374] davinci_mdio 54432400.mdio: phy[1]: device 54432400.mdio:01, driver unknown[ 12.419793] remoteproc remoteproc1: 54434000.pru is available[ 12.551503] pru-rproc 54434000.pru: PRU rproc node pru@54434000 probed successfully[ 12.632842] remoteproc remoteproc2: 54438000.pru is available[ 12.754420] pru-rproc 54438000.pru: PRU rproc node pru@54438000 probed successfully[ 12.834908] remoteproc remoteproc3: 54474000.pru is available[ 12.840826] pru-rproc 54474000.pru: PRU rproc node pru@54474000 probed successfully[ 13.051221] remoteproc remoteproc4: 54478000.pru is available[ 13.093693] pru-rproc 54478000.pru: PRU rproc node pru@54478000 probed successfully[ 13.104547] net eth0: initializing cpsw version 1.15 (0)[ 13.205299] Atheros 8035 ethernet 4a101000.mdio:04: attached PHY driver [Atheros 8035 ethernet] (mii_bus:phy_addr=4a101000.mdio:04, irq=POLL)[ 13.205495] libphy: PHY not found[ 13.205510] net eth0: phy "" not found on slave 1, err -19[ 13.225694] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready[ 13.842386] prueth pruss1_eth: port 2: using random MAC addr: 4a:43:b8:50:65:33[ 14.015496] prueth pruss1_eth: pruss_fw_drop_untagged_vlan 0[ 14.021212] prueth pruss1_eth: pruss MC Mask (Port 1) ff:ff:ff:ff:ff:ff[ 14.234410] prueth pruss1_eth: TI PRU ethernet (type 0) driver initialized

_____ _____ _ _ | _ |___ ___ ___ ___ | _ |___ ___ |_|___ ___| |_ | | _| .'| . | . | | __| _| . | | | -_| _| _||__|__|_| |__,|_ |___| |__| |_| |___|_| |___|___|_| |___| |___|
Arago Project http://arago-project.org am437x-evm ttyS0
Arago 2019.11 am437x-evm ttyS0
am437x-evm login: [ 27.114767] iep ptp bc clkid -1[ 27.118012] remoteproc remoteproc2: powering up 54438000.pru[ 27.164373] remoteproc remoteproc2: Booting fw image ti-pruss/am437x-pru1-prueth-fw.elf, size 7712[ 27.173559] pruss 54400000.pruss: configured system_events[63-0] = 00600000,08a00000[ 27.238011] pruss 54400000.pruss: configured intr_channels = 0x0000032a host_intr = 0x000002aa[ 27.267016] remoteproc remoteproc2: remote processor 54438000.pru is now up[ 27.286679] net eth1: started[ 27.296721] Unable to handle kernel NULL pointer dereference at virtual address 00000064[ 27.304874] pgd = 42842c44[ 27.307597] [00000064] *pgd=00000000[ 27.311198] Internal error: Oops: 5 [#1] PREEMPT ARM[ 27.311204] Modules linked in: ti_prueth pru_rproc pruss irq_pruss_intc pm33xx omap_des des_generic omap_aes_driver omap_sham crypto_engine omap_crypto pruss_soc_bus ti_emif_sram dwc3_omap wkup_m3_ipc wkup_m3_rproc remoteproc rtc_omap omap_wdt sch_fq_codel[ 27.311265] CPU: 0 PID: 10 Comm: ktimersoftd/0 Not tainted 4.19.94-rt39-ga242ccf3f1 #2[ 27.311269] Hardware name: Generic AM43 (Flattened Device Tree)[ 27.311417] PC is at prueth_timer+0x94/0x1d8 [ti_prueth][ 27.311423] LR is at 0x6[ 27.311429] pc : [<bf0d062c>] lr : [<00000006>] psr: a00f0113[ 27.311434] sp : dc489e38 ip : 00000000 fp : dc489e6c[ 27.311438] r10: 600f0113 r9 : d91b68c4 r8 : 0000000c[ 27.311443] r7 : d91b68c0 r6 : 0000000a r5 : d91b6900 r4 : 00000000[ 27.311447] r3 : 00000004 r2 : 00000006 r1 : 00000000 r0 : 00000001[ 27.311457] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none[ 27.311463] Control: 10c53c7d Table: 9bbf4059 DAC: 00000051[ 27.311470] Process ktimersoftd/0 (pid: 10, stack limit = 0xcbdea4eb)[ 27.311477] Stack: (0xdc489e38 to 0xdc48a000)[ 27.311484] 9e20: 00989680 00000000[ 27.311496] 9e40: dc489e6c c0d1a570 d91b6900 c0d1a520 ffffe000 00000000 00000060 600f0113[ 27.311507] 9e60: dc489ec4 dc489e70 c0188448 bf0d05a4 c018cf8c c0ac5a00 c0d51b57 00000006[ 27.311518] 9e80: 5ac3d08f c0d1a480 5ac3d08f c0d1a584 5ac3d08f 00000006 00000000 e899c255[ 27.311529] 9ea0: 1607167d c0d1a480 600f0113 00000100 00000000 00000008 dc489ee4 dc489ec8[ 27.311540] 9ec0: c018873c c0188370 00000020 c0d10f54 ffffe000 04208140 dc489f2c dc489ee8[ 27.311551] 9ee0: c012fdf0 c01886c8 dc4452c0 c08d5690 c0902e20 c0d13c40 c0d52fbc c0d51880[ 27.311562] 9f00: c0d10f24 ffffe000 ffffe000 00000001 c0d10f24 c0d05888 00000000 dc469df0[ 27.311573] 9f20: dc489f44 dc489f30 c012fed8 c012fc34 dc445200 ffffe000 dc489f74 dc489f48[ 27.311584] 9f40: c014e85c c012feb0 dc489f74 b7d43b39 dc4452c0 dc445280 00000000 dc488000[ 27.311595] 9f60: dc445200 c014e59c dc489fac dc489f78 c014a490 c014e5a8 dc4452d8 dc4452d8[ 27.311605] 9f80: 00000000 dc445280 c014a338 00000000 00000000 00000000 00000000 00000000[ 27.311616] 9fa0: 00000000 dc489fb0 c01010f0 c014a344 00000000 00000000 00000000 00000000[ 27.311625] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000[ 27.311635] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000[ 27.311637] Backtrace: [ 27.311707] [<bf0d0598>] (prueth_timer [ti_prueth]) from [<c0188448>] (__hrtimer_run_queues.constprop.3+0xe4/0x230)[ 27.311720] r10:600f0113 r9:00000060 r8:00000000 r7:ffffe000 r6:c0d1a520 r5:d91b6900[ 27.311725] r4:c0d1a570[ 27.311741] [<c0188364>] (__hrtimer_run_queues.constprop.3) from [<c018873c>] (hrtimer_run_softirq+0x80/0x10c)[ 27.311752] r10:00000008 r9:00000000 r8:00000100 r7:600f0113 r6:c0d1a480 r5:1607167d[ 27.311756] r4:e899c255[ 27.311777] [<c01886bc>] (hrtimer_run_softirq) from [<c012fdf0>] (do_current_softirqs+0x1c8/0x27c)[ 27.311786] r7:04208140 r6:ffffe000 r5:c0d10f54 r4:00000020[ 27.311798] [<c012fc28>] (do_current_softirqs) from [<c012fed8>] (run_ksoftirqd+0x34/0x54)[ 27.311808] r10:dc469df0 r9:00000000 r8:c0d05888 r7:c0d10f24 r6:00000001 r5:ffffe000[ 27.311812] r4:ffffe000[ 27.311832] [<c012fea4>] (run_ksoftirqd) from [<c014e85c>] (smpboot_thread_fn+0x2c0/0x2ec)[ 27.311838] r5:ffffe000 r4:dc445200[ 27.311858] [<c014e59c>] (smpboot_thread_fn) from [<c014a490>] (kthread+0x158/0x160)[ 27.311869] r9:c014e59c r8:dc445200 r7:dc488000 r6:00000000 r5:dc445280 r4:dc4452c0[ 27.311884] [<c014a338>] (kthread) from [<c01010f0>] (ret_from_fork+0x14/0x24)[ 27.311890] Exception stack(0xdc489fb0 to 0xdc489ff8)[ 27.311897] 9fa0: 00000000 00000000 00000000 00000000[ 27.311908] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000[ 27.311916] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000[ 27.311926] r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c014a338[ 27.311930] r4:dc445280[ 27.311943] Code: e1590007 0a000027 e515301c e4974004 (e5942064) [ 27.694639] ---[ end trace 0000000000000002 ]---[ 27.700802] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready[ 32.133710] NOHZ: local_softirq_pending 02[ 32.148646] NOHZ: local_softirq_pending 02[ 32.173370] NOHZ: local_softirq_pending 02[ 32.174163] NOHZ: local_softirq_pending 02[ 32.186483] NOHZ: local_softirq_pending 02[ 32.191312] NOHZ: local_softirq_pending 02[ 32.196782] NOHZ: local_softirq_pending 02[ 32.269381] NOHZ: local_softirq_pending 02[ 32.272665] NOHZ: local_softirq_pending 02[ 32.274157] NOHZ: local_softirq_pending 02[ 32.821220] EXT4-fs (mmcblk1p2): mounted filesystem with ordered data mode. Opts: (null)

over 4 years ago

0 Bin Liu over 4 years ago

TI__Guru**** 167551 points

Hi,

Your query has been assigned to the expert. Due to US holidays, the response will be delayed.

0 Nick Saulnier over 4 years ago in reply to Bin Liu

TI__Guru** 100740 points

Hello,

Thank you for reaching out. There is a known bug for Single EMAC in our Linux 4.19 PRU Ethernet driver that will be fixed in the Linux 5.4 version. Please see my reply to post PRU Ethernet Issues for a summary of the issue and how to work around it.

Regards,

Nick

0 ccanberry over 4 years ago in reply to Nick Saulnier

Prodigy 175 points

Hi again,

I am currently working and trying to solve the problem for IDKAM437, then i will proceed with my custom board which has one TLK105.

With using linux-rt-4.19.94(Latest), applying the patch you provided:

diff --git a/drivers/net/ethernet/ti/prueth.c
b/drivers/net/ethernet/ti/prueth.c
index a3b596f746aa..38e8a2507cbf 100644
--- a/drivers/net/ethernet/ti/prueth.c
+++ b/drivers/net/ethernet/ti/prueth.c
@@ -1532,6 +1532,9 @@ static enum hrtimer_restart prueth_timer(struct hrtimer *timer)

         for (mac = PRUETH_MAC0; mac <= PRUETH_MAC1; mac++) {
                 emac = prueth->emac[mac];
+               if (!emac)
+                       continue;
+
                 if (!(prueth->emac_configured & BIT(emac->port_id)))
                         break; /* port not enabled */

has not solved my problem.

Seems like the customer was getting the error firstly in emac_ndo_open
i still get the same null pointer error from the kernel but at prueth_timer

I reinstalled 6.03 Linux RT SDK fresh, and only followed these steps:

1. changed the dts file (as i provided above)
2. applied the patch to the prueth.c file

(applied no change in defconfig file)

Can you confirm is that all it takes for rt-4.19.94,
Thanks,
Have a nice one!

0 Nick Saulnier over 4 years ago in reply to ccanberry

TI__Guru** 100740 points

Hello,

I have tested the workaround on regular Linux, but not RT Linux.

There were differences in the prueth driver for Linux and RT Linux on some older releases (I cannot remember the exact release I checked on). If I recall properly, non-RT was interrupting the ARM when an Ethernet packet was received, while in RT the ARM would poll for Ethernet packets to ensure packets were handled within a certain timeframe.

I need to check the driver in SDK 6.3 to see if we retained those differences between RT and non-RT, or if we decided on a unified approach. Give me a couple of days to test RT Linux single EMAC on my AM437x IDK and look at the driver. Go ahead and ping me if I have not replied by Friday.

Regards,

Nick

0 ccanberry over 4 years ago in reply to Nick Saulnier

Prodigy 175 points

Hi Nick,

Did you have a time to check it?
I have been also searching on e2e for a similar problem, yet could not find any related to the RT kernel.

Thanks!

0 Nick Saulnier over 4 years ago in reply to ccanberry

TI__Guru** 100740 points

Ok, spent some time playing with this today.

1) the prueth driver is the same for both Linux and RT Linux in Linux Processor SDK 6.3.

2) Double checking your device tree: changes look good other than not commenting the PHY (not sure if that would affect)

3) With the device tree set to single prueth and no modifications to the driver, I am able to replicate your kernel error

I am still playing around with modifying the driver. Will have more information within another day or so.

Regards,

Nick

0 ccanberry over 4 years ago in reply to Nick Saulnier

Prodigy 175 points

Thank you for your interest Nick!

I tried both including and commenting out the unused PHY, also tried to use the dummy PHY solution and other solution links that i recursively found from the link you provided, but sadly none worked for my case.

Really looking forward for your feedback/patch.

My best regards,

Cansin

0 ccanberry over 4 years ago in reply to Nick Saulnier

Prodigy 175 points

Hi Nick,
Do you have any updates?
I am a bit of running out of time.

Thanks!

0 Nick Saulnier over 4 years ago in reply to ccanberry

TI__Guru** 100740 points

Thank you for the ping, and apologies for the delayed response.

The kernel driver patch worked for me on the AM437x IDK. Could you try going through these steps?

1) Get a baseline by testing with the Out of the Box files that are created from the bin/create-sdcard.sh script
* terminal output looks as expected on boot
* ifconfig -a shows eth0, eth1, eth2 as expected

2) make your changes above to am437x-id-evm.dts and drivers/net/ethernet/ti/prueth.c

3) build the dtb and the new kernel module. These were the steps I took (based on the Kernel User's Guide)

export PATH=<sdk path>/linux-devkit/sysroots/x86_64-arago-linux/usr/bin:$PATH
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- distclean
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- tisdk_am437x-evm-rt_defconfig
// note this is am437x-evm-rt, not am437x-evm
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- menuconfig
// menuconfig is probably not needed since we're not changing anything, I typically just save and close
make -j4 ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- zImage
// -j4, -j8 uses multithreading
// rebuilding zImage might not be needed as long as the modules match the kernel?
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- am437x-idk-evm.dtb
make -j4 ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- modules
// making all modules takes a while
// once you have built all the kernel modules once, you can build specific modules like this:
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -C . M=drivers/net/ethernet/ti
// in this case we are just rebuilding the prueth kernel modules

4) copy the files to the SD card.
I typically rename the "known good state" files on the SD card instead of deleting them. e.g. ti_prueth.ko --> ti_prueth.ko.orig
* Note that prueth driver is NOT builtin to the kernel. So you need to copy drivers/net/ethernet/ti/ti_prueth.ko over to /SDCard/lib/modules/4.19.xxx/kernel/drivers/net/ethernet/ti
* copy the dtb and zImage to /SDCard/boot

5) When I tested the new files, my boot log looked as expected. This time, ifconfig -a only returned eth0 and eth1.

Regards,

Nick

0 ccanberry over 4 years ago in reply to Nick Saulnier

Prodigy 175 points

Hi Nick,
Thank you, that solved the kernel problem, but i have a little issue here,
I followed the steps above, that worked for my idkam437x and custom board, my custom board has eth0 and eth1 active after booting.(ifconfig without -a)

However i get these problems:

while booting, seems like it cannot detect TLK105:

libphy: Fixed MDIO Bus: probed
[    1.276303] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6, bus freq 1000000
[    1.284014] davinci_mdio 4a101000.mdio: detected phy mask ffffffef
[    1.291358] libphy: 4a101000.mdio: probed
[    1.295408] davinci_mdio 4a101000.mdio: phy[4]: device 4a101000.mdio:04, driver Atheros 8035 ethernet
[    1.305823] cpsw 4a100000.ethernet: No slave[1] phy_id, phy-handle, or fixed-link property
[    1.314243] cpsw 4a100000.ethernet: Detected MACID = a8:1b:6a:56:bb:53
[    1.320990] cpsw 4a100000.ethernet: initialized cpsw ale version 1.4
[    1.327411] cpsw 4a100000.ethernet: ALE Table size 1024
[    1.332713] cpsw 4a100000.ethernet: cpts: overflow check period 500 (jiffies)

...

[   14.306372] davinci_mdio 54432400.mdio: davinci mdio revision 1.6, bus freq 1000000
[   14.392011] libphy: 54432400.mdio: probed
[[0;32m  OK  [0m] Started D-Bus System Message Bus.
[   14.612087] davinci_mdio 54432400.mdio: phy[1]: device 54432400.mdio:01, driver unknown
[   15.066562] remoteproc remoteproc1: 54434000.pru is available
[   15.072474] pru-rproc 54434000.pru: PRU rproc node pru@54434000 probed successfully
         Starting Lightning Fast Webserver With Light System Requirements...
[   15.349172] remoteproc remoteproc2: 54438000.pru is available
[   15.433860] pru-rproc 54438000.pru: PRU rproc node pru@54438000 probed successfully
[   15.447667] remoteproc remoteproc3: 54474000.pru is available
[   15.447794] pru-rproc 54474000.pru: PRU rproc node pru@54474000 probed successfully
[   15.448276] remoteproc remoteproc4: 54478000.pru is available
[   15.448375] pru-rproc 54478000.pru: PRU rproc node pru@54478000 probed successfully
[   15.544587] prueth pruss1_eth: port 2: using random MAC addr: 76:4f:57:ad:43:3a
[   15.677448] prueth pruss1_eth: pruss_fw_drop_untagged_vlan 0
[   15.677464] prueth pruss1_eth: pruss MC Mask (Port 1) ff:ff:ff:ff:ff:ff
[   15.896824] net eth0: initializing cpsw version 1.15 (0)
[   15.997409] Atheros 8035 ethernet 4a101000.mdio:04: attached PHY driver [Atheros 8035 ethernet] (mii_bus:phy_addr=4a101000.mdio:04, irq=POLL)
[   15.997565] libphy: PHY  not found
[   15.997580] net eth0: phy "" not found on slave 1, err -19
[   16.004473] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   16.006929] prueth pruss1_eth: TI PRU ethernet (type 0) driver initialized

when i run ethtool eth1 on my custom board, no supported link modes:

Settings for eth1:

Supported ports: [ TP AUI BNC MII FIBRE ] 
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: 10Mb/s
Duplex: Half 
Port: MII PHYAD: 1 
Transceiver: internal 
Auto-negotiation: on
Link detected: no

ethtool -i eth1
driver: PRUSS Ethernet driver
version: 0.2
firmware-version: 
expansion-rom-version: 
bus-info: 
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no

No yellow-led on on my prueth1 port, i can assign a static-ip for eth1 and connect it to my PC, but the link does not get detected.
Seems like the driver cannot detect the TLK105 for some reason, i double check the pin connections and they do seem fine, what can be the problem here given the symptoms above?

Thanks!

0 Nick Saulnier over 4 years ago in reply to ccanberry

TI__Guru** 100740 points

Hello,

Based on "davinci_mdio 54432400.mdio: phy[1]: device 54432400.mdio:01, driver unknown", it does not know what driver to use with the PHY. TLK10x PHY uses drivers/net/phy/dp83848.c (found using grep -r TLK1).

Could you compare the kernel .config file you are generating for the AM437x IDK and your custom board? is CONFIG_DP83848_PHY=y enabled?

Regards,

Nick

0 ccanberry over 4 years ago in reply to ccanberry

Prodigy 175 points

edited, PWRDNn/INTn problem is solved after replacing the TLK105L)

Hi, i am a bit lost and in a hurry here, and really appreciate you help,i am using TLK105L in MII mode.

davinci_mdio 54432400.mdio: phy[1]: device 54432400.mdio:01, driver unknown problem persists.
In my design, every pin is identically connected as it was in idkam437, the only difference is that i am using a crystal for the TLK105L. I am not even using a custom defconfig, using the once i compiled with your assist just to see eth1 go up properly, because it's my main problem, and the same defconfig works just fine with the MYIR PRU board, which is almost identical to idkam437x, and mine PRU-connections-wise.

As i observed with an oscilloscope, the PWRDNn/INTn pin is always high and reset_n goes high during the boot-up, a square-wave on MDC, around 1MHz just as after reset_n goes high.

The pins values as follows:
PFBOUT : 1.68V
PFBIN: 0.44V
PFBIN2 : 0V
RBIAS : 1.22V

However there are anomalies such as:
- No signal on neither XI nor XO.(I am using a 10uW crystal, so i placed a 25 Ohms limiting resistor) (tried connecting a 25Mhz signal generator and the boot-log is the same btw, seems like "unknown driver" has nothing to do with tlk105l's clock)
- MDIO starts with the following signal (after reset_n goes high):

Then morphs into this interesting, noisy periodic signal:

I am not quiet sure the root of "unknown driver" error, the same zImage, same u-boot, and dts changes, works just fine both with idkam437x and myir's custom board, and my connections are identical.

When does this unknown driver warning occur?

Software: The only difference is that my board has just 1 PHY and it is connected to MDIO address 0x01, whereas other boards that i referenced has two PHYs valid, but using one, maybe there is another software problem that i am not aware of, requring another patch?

Hardware: I assume that the MDIO signal above is garbage, so it only makes sense that kernel cannot detect to whom it is dealing with, assigns a generic driver, and seems like a hardware problem, and i share my connections below, if you see anything suspicious...

Thanks!

0 Nick Saulnier over 4 years ago in reply to ccanberry

TI__Guru** 100740 points

I am reassigning this to a hardware engineer to take a look.

-Nick

0 ccanberry over 4 years ago in reply to Nick Saulnier

Prodigy 175 points

edited my last message after replacing TLK with a new one.
Thanks!

0 Justin Lazaruk over 4 years ago in reply to ccanberry

TI__Expert 7040 points

Hello,

Is the TLK105 device capable of establishing link with a link partner? I am wondering if the PHY can boot into the correct mode and establish link and the issue is local to MDC/MDIO pins or there is a more fundamental problem? Is the current consumption what is expected?

I do not see an issue with the schematic above. Another debugging step would be to use an external tool to access the PHY registers like an MSP430F5529LP launchpad and USB-2-MDIO tool and determine if the schematic and PHY can allow register access.

Regards,
Justin

0 ccanberry over 4 years ago in reply to Justin Lazaruk

Prodigy 175 points

Hi Justin/Nick,

First of all, thank you for your kind interest,

It is not capable of establishing any link, nor turn on any leds, it seems down, the only feedback i can get is that from boot screen that it is initialized and up but unknown driver, ethtool gives the results on eth1 after the boot, i shared in two messages before of above messages.

CONFIG_DP83848_PHY=y is enabled, the .config seems fine, i strongly believe that something wrong hardware-wise...

I don't posses the launchpad, so i want to debug the TLK105L thru u-boot/kernel space, is it possible, if so could you or Nick assist me on how?

The MCD/MDIO ways are around 8cm long, will it be a problem noise-wise, considering it's a problem, and MDIO line not working properly, how could the driver detect the PHY in the first place, it is sending some data and read back while detecting something connected to the given address, right, if there was a problem on MDC/MDIO lines, shouldn't the driver detect the device in the first place?

In a nutshell, I am kind of lost that the driver detects it but cannot get the info of which driver should it assign to, can you also kindly inform me the steps on how davinci_mdio detects a PHY and initializes it, does it even need a signal on XI during initialization and assigning the relevant driver, this way i can understand the problem better.

Thank you!

0 Justin Lazaruk over 4 years ago in reply to ccanberry

TI__Expert 7040 points

Hello,

I don't expect the 8cm trace of MDC/MDIO will cause any issues. My thought of connecting a launchpad directly to the MDC/MDIO pins of the PHY would be to narrow the root cause to a hardware or software issue using a known working tool to access the registers of the PHY. I am not familiar with the davinci_mdio initialization.

Can you measure the RX_CLK frequency and confirm the currents are in the expected range to confirm the device is powered on properly?

Nick,

Can you help to check the mdio driver initialization?

Regards,
Justin

0 ccanberry over 4 years ago in reply to Justin Lazaruk

Prodigy 175 points

Hi,
Turns out it was a schematics problem, where pins 13-15-24 should be short-circuited, changing it to DP83822 (where one can left them floating) should work.
(Where i am not quiet sure that one must PD the 24, as they stated in many posts but not in the transition manual nor DP's datasheet...)

Thanks,

0 Justin Lazaruk over 4 years ago in reply to ccanberry

TI__Expert 7040 points

Hi,

Does that resolve the issue and allow registers to be read properly?

Regards,
Justin

0 ccanberry over 4 years ago in reply to Justin Lazaruk

Prodigy 175 points

Hi Justin

Yes it does.

However i am not quiet sure if i need to PD(with 2.2kOhm) the pin on 24 when i switch the PHY to DP83822...

Datasheet states that it can be left floating if not used, however there are some posts that say one should pull it down otherwise it won't work: e2e.ti.com/.../748899
I just wonder why is that, should i revise my PCB accordingly (or just swap the capacitor on 24 with a 2.2k ohm resistor)

Thanks!

0 Justin Lazaruk over 4 years ago in reply to ccanberry

TI__Expert 7040 points

Hi,

The pin can be left floating if there are no external components connected to, e.g. it's not being used for an LED indicator. The internal pull-down of the pin will hold it in Mode 0 during bootstrapping. LED_1 needs to be either pulled up or down if there as the intermediate bootstrap threshold of Mode 1 or Mode 2 are internal test modes of the PHY. The safest thing would be to have an external strapping resistor connected to this pin.

Regards,
Justin

Processors

Processors forum

PROCESSOR-SDK-AM437X: Linux-RT Single PRU kernel problem