AM4378: Ethernet Initialization

Hi Tanner,

Yes, you’re right. In the latest SDK 6.3, networking driver is based on “Driver Model” via “CONFIG_DM_ETH=y”.

So board_eth_init() in board.c (board/ti/am43xx/) is not used. 

1. Have you looked over Ethernet configuration setup in device tree files (/arch/arm/dts/)?

For example, am4372.dtsi, am437x-gp-evm.dts for AM437x EVMs.

&cpsw_emac0 {
	phy_id = <&davinci_mdio>, <0>;
	phy-mode = "rgmii";
};

2. Have you tried any PHY related operations at u-boot prompt to get PHY driver “probed”? i.e. “mii” “dhcp”. 

Best,

-Hong

Hong,

I have the Ethernet configuration setup the same as when using the previous SDK, it is setup in the device tree as follows:

&cpsw_emac0 {
phy_id = <&davinci_mdio>, <1>;
phy-mode = "mii";
};

I'm not sure how to use the "mii" or "dhcp" commands to probe the PHY driver.

Basically, with the old U-boot, at the end of the board_eth_init() function we had to add the following lines:

writel(MII_MODE_ENABLE, &cdev->miisel);
cpsw_slaves[0].phy_if = PHY_INTERFACE_MODE_MII;
cpsw_slaves[0].phy_addr = 1;

How would I do the equivalent with the new Driver Model?

Hi Tanner,

It looks to me that your modified device tree is matching what was configured in board.c file in old u-boot.
There’re few options to check PHY setup. I’m using SDK 6.3 on TI GP EVM as an example, where

&cpsw_emac0 {
	phy_id = <&davinci_mdio>, <0>;
	phy-mode = "rgmii";
};

1. At u-boot prompt:

=> mii info
PHY 0x00: OUI = 0x0885, Model = 0x22, Rev = 0x02, 1000baseT, FDX
=> mii device
MII devices: 'ethernet@4a100000' 
Current device: 'ethernet@4a100000'
=> mii dump
0.     (1140)                 -- PHY control register --
  (8000:0000) 0.15    =     0    reset
  (4000:0000) 0.14    =     0    loopback
  (2040:0040) 0. 6,13 =   b10    speed selection = 1000 Mbps
  (1000:1000) 0.12    =     1    A/N enable
  (0800:0000) 0.11    =     0    power-down
  (0400:0000) 0.10    =     0    isolate
  (0200:0000) 0. 9    =     0    restart A/N
  (0100:0100) 0. 8    =     1    duplex = full
  (0080:0000) 0. 7    =     0    collision test enable
  (003f:0000) 0. 5- 0 =     0    (reserved)
=> setenv autoload n
=> dhcp
link up on port 0, speed 1000, full duplex
BOOTP broadcast 1

2. kernel log file

[    1.059237] libphy: Fixed MDIO Bus: probed
[    1.139335] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6, bus freq 1000000
[    1.147034] davinci_mdio 4a101000.mdio: detected phy mask fffffffe
[    1.154296] libphy: 4a101000.mdio: probed
[    1.158342] davinci_mdio 4a101000.mdio: phy[0]: device 4a101000.mdio:00, driver Micrel KSZ9031 Gigabit PHY
[    1.168986] cpsw 4a100000.ethernet: Detected MACID = 60:64:05:66:30:64
[    1.175770] cpsw 4a100000.ethernet: initialized cpsw ale version 1.4
[    1.182237] cpsw 4a100000.ethernet: ALE Table size 1024
[    1.187523] cpsw 4a100000.ethernet: cpts: overflow check period 500 (jiffies)

I'm assuming different PHY (mii; addr=1). Hopefully these steps help you check your PHY on your setup.

Best,

-Hong

Yes, we are using mii and PHY address 1. But in the old U-boot, we made those changes in the board_eth_init() function as I stated above. The default is to use rgmii and address 0, and since boarth_eth_init() isn't called anymore, I am wondering how we make those changes with the new U-boot. I tried running the commands that you recommended, and as you can see, the PHY is not being set up correctly:

=> mii info
=> mii device
MII devices: 'ethernet@4a100000'
Current device: 'ethernet@4a100000'
=> mii dump
Error reading from the PHY addr=00 reg=00

=> setenv autoload n
=> dhcp
=> boot

[ 1.059024] libphy: Fixed MDIO Bus: probed
[ 1.079100] mdio_bus 4a101000.mdio: mii_bus 4a101000.mdio couldn't get reset GPIO
[ 1.087405] cpsw 4a100000.ethernet: Detected MACID = f0:b5:d1:3e:8c:7d
[ 1.094103] cpsw 4a100000.ethernet: initialized cpsw ale version 1.4
[ 1.100507] cpsw 4a100000.ethernet: ALE Table size 1024
[ 1.105782] cpsw 4a100000.ethernet: cpts: overflow check period 500 (jiffies)

we are using MII on EMAC 1 and phy address 1 as well. when the kernel runs it crashes every time when the following ethernet drivers are included in the dts file:

&mac {
slaves = <1>;
pinctrl-names = "default", "sleep";
pinctrl-0 = <&mii_1_pins_default>;
pinctrl-1 = <&mii_1_pins_sleep>;
status = "okay";
};

&davinci_mdio {
pinctrl-names = "default", "sleep";
pinctrl-0 = <&mdio_1_pins_default>;
pinctrl-1 = <&mdio_1_pins_sleep>;
status = "okay";

reset-gpios = <&gpio3 22 GPIO_ACTIVE_LOW>;
reset-delay-us = <2>; //1us reset time
};

&cpsw_emac0 {
phy_id = <&davinci_mdio>, <1>;
phy-mode = "mii";
};

i have tried to turn off CONFIG_DM_ETH ( and the config SPL define as well) so make it call the legacy code and that did not work. apparently the drivers that are loaded for the EVM do not apply to our board and something isn't getting configured properly

we have a GPIO line that controls the reset to the phy to ensure proper reset, and that GPIO is pulled low to ensure it is reset when the processor is booting up. does your driver do a sweep for phy addresses and then configures all the ones it finds? if so, could the problem be the phy is in reset during this time so it defaults to something invalid or doesn't default to anything at all? what do we have to do differently to get the SPL drivers to be able to access the GPIO line that controls the phy reset?

so i set our GPIO line to come out of reset in the scale vcores routine (which i imagine happens a lot sooner than the eth setup) and i got this:

Net:
Warning: ethernet@4a100000 using MAC address from ROM
eth0: ethernet@4a100000

and doing the dump:

=> mii info
PHY 0x01: OUI = 0x80017, Model = 0x09, Rev = 0x00, 100baseT, FDX
=> mii device
MII devices: 'ethernet@4a100000'
Current device: 'ethernet@4a100000'
=> mii dump
Error reading from the PHY addr=00 reg=00

so based on the mii dump i would assume your drivers start at addr 0 and it gives up if nothing is found. here is the full log of the boot failure of the kernel:

=> boot
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
** Unable to read file boot.scr **
717 bytes read in 2 ms (349.6 KiB/s)
Loaded env from uEnv.txt
Importing environment from mmc0 ...
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
4297216 bytes read in 226 ms (18.1 MiB/s)
53261 bytes read in 6 ms (8.5 MiB/s)
## Flattened Device Tree blob at 88000000
Booting using the fdt blob at 0x88000000
Loading Device Tree to 8ffef000, end 8ffff00c ... OK

Starting kernel ...

[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 4.19.94-gbe5389fd85 (michael_j@UTI-CPELNX-03) (gcc version 8.3.0 (GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36))) #1 PREEMPT Fri Sep 4 14:31:13 CDT 2020
[ 0.000000] CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c53c7d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[ 0.000000] OF: fdt: Machine model: TI AM437x UTI BOARD
[ 0.000000] Memory policy: Data cache writeback
[ 0.000000] efi: Getting EFI parameters from FDT:
[ 0.000000] efi: UEFI not found.
[ 0.000000] cma: Reserved 48 MiB at 0x9d000000
[ 0.000000] CPU: All CPU(s) started in SVC mode.
[ 0.000000] AM437x ES1.2 (sgx neon)
[ 0.000000] random: get_random_bytes called from start_kernel+0xa4/0x434 with crng_init=0
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 129920
[ 0.000000] Kernel command line: console=ttyO0,115200n8 video=HDMI-A-1:800x600 consoleblank=0 root=PARTUUID=528d24f4-02 rw rootfstype=ext4 rootwait
[ 0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
[ 0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
[ 0.000000] Memory: 455884K/524288K available (9216K kernel code, 316K rwdata, 2736K rodata, 1024K init, 254K bss, 19252K reserved, 49152K cma-reserved, 0K highmem)
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
[ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
[ 0.000000] vmalloc : 0xe0800000 - 0xff800000 ( 496 MB)
[ 0.000000] lowmem : 0xc0000000 - 0xe0000000 ( 512 MB)
[ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
[ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB)
[ 0.000000] .text : 0x(ptrval) - 0x(ptrval) (10208 kB)
[ 0.000000] .init : 0x(ptrval) - 0x(ptrval) (1024 kB)
[ 0.000000] .data : 0x(ptrval) - 0x(ptrval) ( 317 kB)
[ 0.000000] .bss : 0x(ptrval) - 0x(ptrval) ( 255 kB)
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[ 0.000000] rcu: Preemptible hierarchical RCU implementation.
[ 0.000000] Tasks RCU enabled.
[ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[ 0.000000] L2C: platform modifies aux control register: 0x0e030000 -> 0x3e430000
[ 0.000000] L2C: DT/platform modifies aux control register: 0x0e030000 -> 0x3e430000
[ 0.000000] L2C-310 enabling early BRESP for Cortex-A9
[ 0.000000] OMAP L2C310: ROM does not support power control setting
[ 0.000000] L2C-310 dynamic clock gating disabled, standby mode disabled
[ 0.000000] L2C-310 cache controller enabled, 16 ways, 256 kB
[ 0.000000] L2C-310: CACHE_ID 0x410000c9, AUX_CTRL 0x4e430000
[ 0.000000] OMAP clockevent source: timer2 at 24000000 Hz
[ 0.000012] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 89478484971ns
[ 0.000030] clocksource: timer1: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 79635851949 ns
[ 0.000038] OMAP clocksource: timer1 at 24000000 Hz
[ 0.000444] clocksource: 32k_counter: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 58327039986419 ns
[ 0.000455] OMAP clocksource: 32k_counter at 32768 Hz
[ 0.000858] Console: colour dummy device 80x30
[ 0.000887] WARNING: Your 'console=ttyO0' has been replaced by 'ttyS0'
[ 0.000892] This ensures that you still see kernel messages. Please
[ 0.000897] update your kernel commandline.
[ 0.000936] Calibrating delay loop... 1987.37 BogoMIPS (lpj=9936896)
[ 0.060186] pid_max: default: 32768 minimum: 301
[ 0.060353] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.060371] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.061107] CPU: Testing write buffer coherency: ok
[ 0.061161] CPU0: Spectre v2: using BPIALL workaround
[ 0.062034] Setting up static identity map for 0x80100000 - 0x80100060
[ 0.062181] rcu: Hierarchical SRCU implementation.
[ 0.062512] EFI services will not be available.
[ 0.063342] devtmpfs: initialized
[ 0.072403] VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4
[ 0.072782] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[ 0.072805] futex hash table entries: 256 (order: -1, 3072 bytes)
[ 0.075896] pinctrl core: initialized pinctrl subsystem
[ 0.076590] DMI not present or invalid.
[ 0.076984] NET: Registered protocol family 16
[ 0.078717] DMA: preallocated 256 KiB pool for atomic coherent allocations
[ 0.152252] cpuidle: using governor ladder
[ 0.152290] cpuidle: using governor menu
[ 0.154003] omap_l3_noc 44000000.ocp: L3 debug error: target 8 mod:0 (unclearable)
[ 0.154075] omap_l3_noc 44000000.ocp: L3 application error: target 8 mod:0 (unclearable)
[ 0.159117] OMAP GPIO hardware version 0.1
[ 0.167421] No ATAGs?
[ 0.167442] hw-breakpoint: found 5 (+1 reserved) breakpoint and 1 watchpoint registers.
[ 0.167461] hw-breakpoint: maximum watchpoint size is 4 bytes.
[ 0.181064] edma 49000000.edma: TI EDMA DMA engine driver
[ 0.185758] SCSI subsystem initialized
[ 0.186266] media: Linux media interface: v0.10
[ 0.186304] videodev: Linux video capture interface: v2.00
[ 0.186398] pps_core: LinuxPPS API ver. 1 registered
[ 0.186406] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[ 0.186427] PTP clock support registered
[ 0.186461] EDAC MC: Ver: 3.0.0
[ 0.187414] omap-mailbox 480c8000.mailbox: omap mailbox rev 0x400
[ 0.188057] Advanced Linux Sound Architecture Driver Initialized.
[ 0.189165] clocksource: Switched to clocksource timer1
[ 0.196779] NET: Registered protocol family 2
[ 0.197497] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 4096 bytes)
[ 0.197530] TCP established hash table entries: 4096 (order: 2, 16384 bytes)
[ 0.197566] TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
[ 0.197606] TCP: Hash tables configured (established 4096 bind 4096)
[ 0.197726] UDP hash table entries: 256 (order: 0, 4096 bytes)
[ 0.197744] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
[ 0.197882] NET: Registered protocol family 1
[ 0.198431] RPC: Registered named UNIX socket transport module.
[ 0.198444] RPC: Registered udp transport module.
[ 0.198450] RPC: Registered tcp transport module.
[ 0.198455] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 0.200417] Initialise system trusted keyrings
[ 0.200721] workingset: timestamp_bits=14 max_order=17 bucket_order=3
[ 0.204764] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[ 0.205492] NFS: Registering the id_resolver key type
[ 0.205526] Key type id_resolver registered
[ 0.205533] Key type id_legacy registered
[ 0.205572] ntfs: driver 2.1.32 [Flags: R/O].
[ 0.207785] Key type asymmetric registered
[ 0.207802] Asymmetric key parser 'x509' registered
[ 0.207872] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 245)
[ 0.207883] io scheduler noop registered
[ 0.207889] io scheduler deadline registered
[ 0.208130] io scheduler cfq registered (default)
[ 0.208141] io scheduler mq-deadline registered
[ 0.208148] io scheduler kyber registered
[ 0.210634] pinctrl-single 44e10800.pinmux: 199 pins, size 796
[ 0.214085] pwm-backlight backlight: backlight supply power not found, using dummy regulator
[ 0.214163] pwm-backlight backlight: Linked as a consumer to regulator.0
[ 0.257034] Serial: 8250/16550 driver, 10 ports, IRQ sharing enabled
[ 0.260323] omap8250 44e09000.serial: No clock speed specified: using default: 48000000
[ 0.261017] 44e09000.serial: ttyS0 at MMIO 0x44e09000 (irq = 31, base_baud = 3000000) is a 8250
[ 0.964799] console [ttyS0] enabled
[ 0.968924] omap8250 481a6000.serial: No clock speed specified: using default: 48000000
[ 0.977685] 481a6000.serial: ttyS3 at MMIO 0x481a6000 (irq = 32, base_baud = 3000000) is a 8250
[ 0.988509] omap_rng 48310000.rng: Random Number Generator ver. 20
[ 0.994949] random: fast init done
[ 0.998564] random: crng init done
[ 1.003325] omapdss_dss 4832a000.dss: 4832a000.dss supply vdda_video not found, using dummy regulator
[ 1.013370] omapdss_dss 4832a000.dss: Linked as a consumer to regulator.0
[ 1.020324] omapdss_dss 4832a000.dss: Dropping the link to regulator.0
[ 1.040648] brd: module loaded
[ 1.052356] loop: module loaded
[ 1.059543] libphy: Fixed MDIO Bus: probed
[ 1.079536] mdio_bus 4a101000.mdio: mii_bus 4a101000.mdio couldn't get reset GPIO
[ 1.087755] cpsw 4a100000.ethernet: Detected MACID = f0:b5:d1:3e:99:bb
[ 1.094456] cpsw 4a100000.ethernet: initialized cpsw ale version 1.4
[ 1.100863] cpsw 4a100000.ethernet: ALE Table size 1024
[ 1.106141] cpsw 4a100000.ethernet: cpts: overflow check period 500 (jiffies)
[ 1.114748] i2c /dev entries driver
[ 1.120339] cpuidle: enable-method property 'ti,am4372' found operations
[ 1.127518] sdhci: Secure Digital Host Controller Interface driver
[ 1.133775] sdhci: Copyright(c) Pierre Ossman
[ 1.139220] omap_hsmmc 48060000.mmc: Linked as a consumer to regulator.1
[ 1.172418] omap_hsmmc 47810000.mmc: Linked as a consumer to regulator.6
[ 1.207265] mmc0: host does not support reading read-only switch, assuming write-enable
[ 1.218381] mmc0: new high speed SDHC card at address 0007
[ 1.225084] mmcblk0: mmc0:0007 SDCIT 14.6 GiB
[ 1.231389] mmcblk0: p1 p2
[ 1.954736] sdhci-pltfm: SDHCI platform and OF driver helper
[ 1.961984] ledtrig-cpu: registered to indicate activity on CPUs
[ 1.971421] omap_hsmmc 47810000.mmc: card claims to support voltages below defined range
[ 1.981942] NET: Registered protocol family 10
[ 1.987661] Segment Routing with IPv6
[ 1.991554] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
[ 1.998263] NET: Registered protocol family 17
[ 2.003180] Key type dns_resolver registered
[ 2.007739] omap_voltage_late_init: Voltage driver support not added
[ 2.015144] Loading compiled-in X.509 certificates
[ 2.027103] mmc1: new high speed SDIO card at address 0001
[ 2.040691] GPIO line 147 (AVDD_EN) hogged as output/high
[ 2.048378] ------------[ cut here ]------------
[ 2.053230] WARNING: CPU: 0 PID: 16 at drivers/irqchip/irq-gic.c:1016 gic_irq_domain_translate+0xdc/0xe4
[ 2.062781] Modules linked in:
[ 2.065859] CPU: 0 PID: 16 Comm: kworker/0:1 Not tainted 4.19.94-gbe5389fd85 #1
[ 2.073211] Hardware name: Generic AM43 (Flattened Device Tree)
[ 2.079179] Workqueue: events deferred_probe_work_func
[ 2.084337] Backtrace:
[ 2.086803] [<c010cb64>] (dump_backtrace) from [<c010ced4>] (show_stack+0x18/0x1c)
[ 2.094421] r7:00000009 r6:00000000 r5:c0bf273c r4:00000000
[ 2.100122] [<c010cebc>] (show_stack) from [<c0915c6c>] (dump_stack+0x24/0x28)
[ 2.107381] [<c0915c48>] (dump_stack) from [<c012d628>] (__warn+0xe0/0xf8)
[ 2.114299] [<c012d548>] (__warn) from [<c012d688>] (warn_slowpath_null+0x48/0x50)
[ 2.121914] r9:c0e087f0 r8:c0e03048 r7:00000060 r6:c04578a8 r5:000003f8 r4:c0bf273c
[ 2.129705] [<c012d640>] (warn_slowpath_null) from [<c04578a8>] (gic_irq_domain_translate+0xdc/0xe4)
[ 2.138875] r6:dc408000 r5:00000001 r4:00000000
[ 2.143523] [<c04577cc>] (gic_irq_domain_translate) from [<c04578f4>] (gic_irq_domain_alloc+0x44/0xa8)
[ 2.152877] r5:00000001 r4:c04578b0
[ 2.156479] [<c04578b0>] (gic_irq_domain_alloc) from [<c01782ac>] (irq_domain_alloc_irqs_parent+0x24/0x30)
[ 2.166190] r9:c0e087f0 r8:00000061 r7:dc40c000 r6:ffffffa7 r5:00000000 r4:c04578b0
[ 2.173989] [<c0178288>] (irq_domain_alloc_irqs_parent) from [<c011fde4>] (wakeupgen_domain_alloc+0xc4/0xf0)
[ 2.183868] r5:00000000 r4:00000061
[ 2.187466] [<c011fd20>] (wakeupgen_domain_alloc) from [<c0179b3c>] (__irq_domain_alloc_irqs+0x130/0x2b4)
[ 2.197085] r10:00000000 r9:006080c0 r8:dbf11b80 r7:00000060 r6:00000060 r5:c011fd20
[ 2.204955] r4:00000001
[ 2.207502] [<c0179a0c>] (__irq_domain_alloc_irqs) from [<c017a0f8>] (irq_create_fwspec_mapping+0x270/0x338)
[ 2.217382] r10:00000006 r9:c0e35830 r8:00000000 r7:00000000 r6:dc541944 r5:dc40c000
[ 2.225253] r4:c0e03048
[ 2.227799] [<c0179e88>] (irq_create_fwspec_mapping) from [<c017a224>] (irq_create_of_mapping+0x64/0x80)
[ 2.237330] r8:00000000 r7:dbf0fc00 r6:00000000 r5:dcb3e214 r4:c0e03048
[ 2.244073] [<c017a1c0>] (irq_create_of_mapping) from [<c075c588>] (of_irq_get+0x6c/0xb8)
[ 2.252296] r4:c0e03048
[ 2.254855] [<c075c51c>] (of_irq_get) from [<c06bc84c>] (i2c_device_probe+0x260/0x26c)
[ 2.262817] r6:c0e35830 r5:00000000 r4:dbf0fc20
[ 2.267460] [<c06bc5ec>] (i2c_device_probe) from [<c05b8a88>] (really_probe+0x204/0x2c0)
[ 2.275598] r9:c0e35830 r8:00000000 r7:00000000 r6:c0e85a00 r5:dbf0fc20 r4:c0e859fc
[ 2.283386] [<c05b8884>] (really_probe) from [<c05b8ce8>] (driver_probe_device+0x68/0x180)
[ 2.291696] r10:00000000 r9:c0e859d8 r8:00000001 r7:c05b8ef8 r6:dbf0fc20 r5:c0e35830
[ 2.299567] r4:dbf0fc20 r3:00000000
[ 2.303160] [<c05b8c80>] (driver_probe_device) from [<c05b8f9c>] (__device_attach_driver+0xa4/0xc8)
[ 2.312255] r9:c0e859d8 r8:00000001 r7:c05b8ef8 r6:dbf0fc20 r5:dc541b44 r4:c0e35830
[ 2.320044] [<c05b8ef8>] (__device_attach_driver) from [<c05b6aa4>] (bus_for_each_drv+0x88/0xcc)
[ 2.328865] r7:c05b8ef8 r6:dc541b44 r5:c0e03048 r4:00000000
[ 2.334559] [<c05b6a1c>] (bus_for_each_drv) from [<c05b8804>] (__device_attach+0xd8/0x140)
[ 2.342868] r7:dbec7cb8 r6:dbf0fc54 r5:c0e03048 r4:dbf0fc20
[ 2.348553] [<c05b872c>] (__device_attach) from [<c05b900c>] (device_initial_probe+0x14/0x18)
[ 2.357123] r8:dbf0fc20 r7:dbec7cb8 r6:c0e3e798 r5:dbf0fc20 r4:dbf0fc28
[ 2.363863] [<c05b8ff8>] (device_initial_probe) from [<c05b7b6c>] (bus_probe_device+0x8c/0x94)
[ 2.372533] [<c05b7ae0>] (bus_probe_device) from [<c05b45e8>] (device_add+0x37c/0x620)
[ 2.380494] r7:dbec7cb8 r6:00000000 r5:c0e03048 r4:dbf0fc28
[ 2.386180] [<c05b426c>] (device_add) from [<c05b48a8>] (device_register+0x1c/0x20)
[ 2.393881] r10:00000000 r9:dbf0fc20 r8:00000000 r7:dbf0fc04 r6:dbec7c80 r5:dc541c44
[ 2.401751] r4:dbf0fc20
[ 2.404300] [<c05b488c>] (device_register) from [<c06bacd8>] (i2c_new_device+0x148/0x2d4)
[ 2.412521] r5:dc541c44 r4:dbf0fc00
[ 2.416115] [<c06bab90>] (i2c_new_device) from [<c06be594>] (of_i2c_register_device+0x64/0x8c)
[ 2.424773] r9:0000000c r8:dbec7cb8 r7:dcb52758 r6:dbec7cb8 r5:dbec7c80 r4:c0e03048
[ 2.432561] [<c06be530>] (of_i2c_register_device) from [<c06be910>] (of_i2c_register_devices+0x94/0xe4)
[ 2.442003] r7:c0c2f98c r6:dcb524dc r5:dbec7c80 r4:dcb52758
[ 2.447688] [<c06be87c>] (of_i2c_register_devices) from [<c06bbcdc>] (i2c_register_adapter+0x174/0x3f8)
[ 2.457132] r9:0000000c r8:0000000b r7:00000000 r6:c0e3e9a4 r5:dbec7cb8 r4:dbec7c80
[ 2.464922] [<c06bbb68>] (i2c_register_adapter) from [<c06bbfb8>] (__i2c_add_numbered_adapter+0x58/0x94)
[ 2.474453] r9:0000000c r8:0000000b r7:dc559e10 r6:c0e03048 r5:dbec7c80 r4:00000000
[ 2.482242] [<c06bbf60>] (__i2c_add_numbered_adapter) from [<c06bc094>] (i2c_add_adapter+0xa0/0xd4)
[ 2.491334] r5:dc559e00 r4:dbec7c80
[ 2.494927] [<c06bbff4>] (i2c_add_adapter) from [<c06bc0ec>] (i2c_add_numbered_adapter+0x24/0x28)
[ 2.503843] r5:dc559e00 r4:dbec7c40
[ 2.507440] [<c06bc0c8>] (i2c_add_numbered_adapter) from [<c06c19fc>] (omap_i2c_probe+0x4ec/0x710)
[ 2.516453] [<c06c1510>] (omap_i2c_probe) from [<c05baa90>] (platform_drv_probe+0x50/0xa0)
[ 2.524765] r10:00000006 r9:c0e3e958 r8:00000000 r7:00000000 r6:c0e3e958 r5:00000000
[ 2.532635] r4:dc559e10
[ 2.535181] [<c05baa40>] (platform_drv_probe) from [<c05b8a88>] (really_probe+0x204/0x2c0)
[ 2.543490] r7:00000000 r6:c0e85a00 r5:dc559e10 r4:c0e859fc
[ 2.549183] [<c05b8884>] (really_probe) from [<c05b8ce8>] (driver_probe_device+0x68/0x180)
[ 2.557483] r10:c0e33e7c r9:00000000 r8:00000001 r7:c05b8ef8 r6:dc559e10 r5:c0e3e958
[ 2.565353] r4:dc559e10 r3:00000000
[ 2.568945] [<c05b8c80>] (driver_probe_device) from [<c05b8f9c>] (__device_attach_driver+0xa4/0xc8)
[ 2.578040] r9:00000000 r8:00000001 r7:c05b8ef8 r6:dc559e10 r5:dc541e74 r4:c0e3e958
[ 2.585828] [<c05b8ef8>] (__device_attach_driver) from [<c05b6aa4>] (bus_for_each_drv+0x88/0xcc)
[ 2.594660] r7:c05b8ef8 r6:dc541e74 r5:c0e03048 r4:00000000
[ 2.600354] [<c05b6a1c>] (bus_for_each_drv) from [<c05b8804>] (__device_attach+0xd8/0x140)
[ 2.608652] r7:c0e33e5c r6:dc559e44 r5:c0e03048 r4:dc559e10
[ 2.614346] [<c05b872c>] (__device_attach) from [<c05b900c>] (device_initial_probe+0x14/0x18)
[ 2.622918] r8:c0e0f884 r7:c0e33e5c r6:c0e34070 r5:dc559e10 r4:dc559e10
[ 2.629658] [<c05b8ff8>] (device_initial_probe) from [<c05b7b6c>] (bus_probe_device+0x8c/0x94)
[ 2.638307] [<c05b7ae0>] (bus_probe_device) from [<c05b802c>] (deferred_probe_work_func+0x68/0x94)
[ 2.647313] r7:c0e33e5c r6:c0e33e48 r5:c0e33e48 r4:dc559e10
[ 2.653010] [<c05b7fc4>] (deferred_probe_work_func) from [<c01453e8>] (process_one_work+0x210/0x430)
[ 2.662190] r7:00000000 r6:dcb33100 r5:dc446600 r4:c0e33e78
[ 2.667874] [<c01451d8>] (process_one_work) from [<c0145900>] (worker_thread+0x2f8/0x674)
[ 2.676096] r10:c0e0f884 r9:c0e0f898 r8:ffffe000 r7:c0e16320 r6:dc446614 r5:c0e0f884
[ 2.683966] r4:dc446600
[ 2.686518] [<c0145608>] (worker_thread) from [<c014b774>] (kthread+0x158/0x160)
[ 2.693956] r10:dc477e78 r9:c0145608 r8:dc446600 r7:dc540000 r6:00000000 r5:dc529400
[ 2.701827] r4:dc529440
[ 2.704374] [<c014b61c>] (kthread) from [<c01010e8>] (ret_from_fork+0x14/0x2c)
[ 2.711635] Exception stack(0xdc541fb0 to 0xdc541ff8)
[ 2.716706] 1fa0: 00000000 00000000 00000000 00000000
[ 2.724929] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 2.733149] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[ 2.739802] r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c014b61c
[ 2.747662] r4:dc529400
[ 2.750211] ---[ end trace 7d6f134b2b19fcc9 ]---
[ 2.794871] omap_i2c 44e0b000.i2c: bus 0 rev0.12 at 100 kHz
[ 2.801957] omap_i2c 4802a000.i2c: bus 1 rev0.12 at 100 kHz
[ 2.808111] omapdss_dss 4832a000.dss: 4832a000.dss supply vdda_video not found, using dummy regulator
[ 2.817530] omapdss_dss 4832a000.dss: Linked as a consumer to regulator.0
[ 2.824472] omapdss_dss 4832a000.dss: Dropping the link to regulator.0
[ 2.831428] Unable to handle kernel NULL pointer dereference at virtual address 00000008
[ 2.839631] pgd = e1d0441e
[ 2.842350] [00000008] *pgd=00000000
[ 2.845945] Internal error: Oops: 5 [#1] PREEMPT ARM
[ 2.850927] Modules linked in:
[ 2.854000] CPU: 0 PID: 16 Comm: kworker/0:1 Tainted: G W 4.19.94-gbe5389fd85 #1
[ 2.862732] Hardware name: Generic AM43 (Flattened Device Tree)
[ 2.868692] Workqueue: events deferred_probe_work_func
[ 2.873854] PC is at device_reorder_to_tail+0x50/0x90
[ 2.878924] LR is at device_reorder_to_tail+0x40/0x90
[ 2.883993] pc : [<c05b5848>] lr : [<c05b5838>] psr: a0000013
[ 2.890283] sp : dc541e58 ip : dc541e58 fp : dc541e6c
[ 2.895525] r10: c0e33e7c r9 : 00000000 r8 : c0e0f884
[ 2.900769] r7 : c05b57f8 r6 : 00000000 r5 : dbdfd4c8 r4 : fffffffc
[ 2.907320] r3 : f66c35bc r2 : f66c35bc r1 : 00000000 r0 : 00000000
[ 2.913875] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
[ 2.921038] Control: 10c53c7d Table: 80004059 DAC: 00000051
[ 2.926806] Process kworker/0:1 (pid: 16, stack limit = 0xd3347655)
[ 2.933097] Stack: (0xdc541e58 to 0xdc542000)
[ 2.937471] 1e40: dbdf2690 c0e03048
[ 2.945684] 1e60: dc541e9c dc541e70 c05b360c c05b5804 60000013 dbdefb80 dbdf2690 f66c35bc
[ 2.953897] 1e80: dbde9210 dbde9210 dbde9210 c0e33e5c dc541eb4 dc541ea0 c05b5838 c05b35b4
[ 2.962110] 1ea0: c0e33c60 00000001 dc541ed4 dc541eb8 c05b58b8 c05b5804 dbde9210 c0e33e48
[ 2.970323] 1ec0: c0e33e48 c0e33e5c dc541ef4 dc541ed8 c05b8024 c05b5894 c0e33e78 dc446600
[ 2.978535] 1ee0: dcb33100 00000000 dc541f2c dc541ef8 c01453e8 c05b7fd0 c0e16320 ffffe000
[ 2.986747] 1f00: c0e0f898 dc446600 c0e0f884 dc446614 c0e16320 ffffe000 c0e0f898 c0e0f884
[ 2.994961] 1f20: dc541f74 dc541f30 c0145900 c01451e4 c092b200 c0bc799c dc529400 00000000
[ 3.003173] 1f40: c0e4dbae c0e16320 c0145608 dc529440 dc529400 00000000 dc540000 dc446600
[ 3.011387] 1f60: c0145608 dc477e78 dc541fac dc541f78 c014b774 c0145614 dc529458 dc529458
[ 3.019599] 1f80: 00000000 dc529400 c014b61c 00000000 00000000 00000000 00000000 00000000
[ 3.027812] 1fa0: 00000000 dc541fb0 c01010e8 c014b628 00000000 00000000 00000000 00000000
[ 3.036024] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 3.044234] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[ 3.052441] Backtrace:
[ 3.054912] [<c05b57f8>] (device_reorder_to_tail) from [<c05b360c>] (device_for_each_child+0x64/0x9c)
[ 3.064169] r5:c0e03048 r4:dbdf2690
[ 3.067761] [<c05b35a8>] (device_for_each_child) from [<c05b5838>] (device_reorder_to_tail+0x40/0x90)
[ 3.077018] r7:c0e33e5c r6:dbde9210 r5:dbde9210 r4:dbde9210
[ 3.082701] [<c05b57f8>] (device_reorder_to_tail) from [<c05b58b8>] (device_pm_move_to_tail+0x30/0x48)
[ 3.092043] r5:00000001 r4:c0e33c60
[ 3.095635] [<c05b5888>] (device_pm_move_to_tail) from [<c05b8024>] (deferred_probe_work_func+0x60/0x94)
[ 3.105153] r7:c0e33e5c r6:c0e33e48 r5:c0e33e48 r4:dbde9210
[ 3.110841] [<c05b7fc4>] (deferred_probe_work_func) from [<c01453e8>] (process_one_work+0x210/0x430)
[ 3.120010] r7:00000000 r6:dcb33100 r5:dc446600 r4:c0e33e78
[ 3.125693] [<c01451d8>] (process_one_work) from [<c0145900>] (worker_thread+0x2f8/0x674)
[ 3.133907] r10:c0e0f884 r9:c0e0f898 r8:ffffe000 r7:c0e16320 r6:dc446614 r5:c0e0f884
[ 3.141766] r4:dc446600
[ 3.144317] [<c0145608>] (worker_thread) from [<c014b774>] (kthread+0x158/0x160)
[ 3.151745] r10:dc477e78 r9:c0145608 r8:dc446600 r7:dc540000 r6:00000000 r5:dc529400
[ 3.159605] r4:dc529440
[ 3.162151] [<c014b61c>] (kthread) from [<c01010e8>] (ret_from_fork+0x14/0x2c)
[ 3.169401] Exception stack(0xdc541fb0 to 0xdc541ff8)
[ 3.174470] 1fa0: 00000000 00000000 00000000 00000000
[ 3.182681] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 3.190893] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[ 3.197535] r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c014b61c
[ 3.205394] r4:dc529400
[ 3.207938] Code: e5b54058 e1550004 e2444004 0a000006 (e594000c)
[ 3.214145] ---[ end trace 7d6f134b2b19fcca ]---

Hong,

Any ideas about what we need to do to get this issue resolved?

it would be nice to know if this is being actively worked on or sitting on the back burner because until this gets fixed development is halted on this project

Yes, we’re looking at the issue, and I’ll discuss with my colleague on possible cause of “mii dump” error, and get back.

=> mii info
PHY 0x01: OUI = 0x80017, Model = 0x09, Rev = 0x00, 100baseT, FDX
=> mii device
MII devices: 'ethernet@4a100000' 
Current device: 'ethernet@4a100000'
=> mii dump
Error reading from the PHY addr=00 reg=00

Best,

-Hong

Hi,

Please note that mii dump is a single register read, it does not scan the MDIO bus and read every PHY and register in the PHY. The app defaults to address 0 and reg 0 and since it looks like there is not a PHY at address 0 the dump returns an error. Try mii dump 1 0 since your that is where your PHY is located. Also take a look at mii ? to get a help listing of the mii commands in u-boot.

Changing SDK versions can be a challenge, usually there are several DTS construct changes due to different ways the community likes to define nodes. More than likely the DTS from the earlier SDK will not run with the later kernel. That may explain the several kernel faults in the boot log. One suggestion I would recommend is reviewing the DTS file against the latest DTS file of the EVM you based the design on. You might also consider falling back to minimal DTS of processor, console UART and add the nodes back in one at time.

With regards to the PHY is please the am437x gp evm DTS file located in the kernel source tree, arch/arm/boot/dts/am437x-gp-evm.dts. Looking at the snippet above please compare to the davinci-mdio and the cpsw_emac0 in the SDK evm DTS file. Note that the PHY definition has been moved from inside the cpsw_emac0 to the davinci-mdio node. 

Best Regards,

Schuyler

looking at the uboot dts file between 4.03 and 6.03 there are no dts changes

looking at the kernel dts is a little harder because we had to change things to turn on the wifi/BT module, but there are no changes between the 4.03 and 6.03 in terms of the ethernet. we followed the evm pretty closely except adding gpio reset, the phy-mode, and address. the phy definition appears to be in cpsw_emac0 in the sdk version that i have. if there is a newer version that has this patched that would be good to know.

from the 6.03 SDK kernel dts file:

&mac {
slaves = <1>;
pinctrl-names = "default", "sleep";
pinctrl-0 = <&cpsw_default>;
pinctrl-1 = <&cpsw_sleep>;
status = "okay";
};

&davinci_mdio {
pinctrl-names = "default", "sleep";
pinctrl-0 = <&davinci_mdio_default>;
pinctrl-1 = <&davinci_mdio_sleep>;
status = "okay";
};

&cpsw_emac0 {
phy_id = <&davinci_mdio>, <0>;
phy-mode = "rgmii";
};

from our dts file:

&mac {
slaves = <1>;
pinctrl-names = "default", "sleep";
pinctrl-0 = <&mii_1_pins_default>;
pinctrl-1 = <&mii_1_pins_sleep>;
status = "okay";
};

&davinci_mdio {
pinctrl-names = "default", "sleep";
pinctrl-0 = <&mdio_1_pins_default>;
pinctrl-1 = <&mdio_1_pins_sleep>;
status = "okay";

reset-gpios = <&gpio3 22 GPIO_ACTIVE_LOW>;
reset-delay-us = <2>; //1us reset time
};

&cpsw_emac0 {
phy_id = <&davinci_mdio>, <1>;
phy-mode = "mii";
};

if there is something wrong with the dts file here (and this is the snippet that causes it to crash in the kernel) then that would be great to know. we are not linux experts. we got our board working with the 4.03 SDK and have not moved up until now and a lot has changed. this is our first linux project so we are a bit in the dark as to how to solve this issue.

Hi,

You are correct, I was looking at the wrong kernel version. I was looking at an unreleased 5.4 kernel. So your ethernet nodes look correct. What I am suggesting though may still be correct as there are a few other nodes that may have changed that could be causing the kernel WARN and OOPS. 

I need to catch up to where you have debugged to. What is leading you to think the network is the issue? I am seeing some fundamental system fails in the boot log that at moment don't look to be network related.

I would recommend treating the kernel upgrade here like a new board bring-up. By this I mean you need to strip the DTS down to a couple of components that gets you to a shell prompt. Here is a link to a presentation that explains a Hello World concept to bring up the new board. This is about creating a minimal DTS file that gets to a kernel prompt, nothing else is enabled. After you get that working you will add the nodes back in. 

Link to presentation

Link to example am335x minimal DTS

Before we go too much down that road could you describe what was done if anything to the DTS to prepare it for the newer kernel?

Best Regards,

Schuyler

i don't believe anything was done to change the DTS file to go from the previous kernel to this one. what i HAVE done is comment out every item and one-by-one reintroduce them and the only block that doesn't allow me to get to the command prompt is the ethernet portion of the DTS file. if i take those 3 sections out, i can get to the command prompt, if i leave them in i get stuck on a fail

is there a central location for every kernel build that states what DTS items have changed and what you need to do to those items to get them to pass? if i do have something fundamentally wrong what resource do i use to correct it? sure, i go minimal and "add" it back in, but when i "add" it back from my old DTS how do i know what change when it fails?

Hi,

Unfortunately there are not any resources that I am aware of that help with this version change. An upgrade between kernel versions is worth the effort but getting there is somewhat trial and error because some of the DTS differences can be subtle, a nesting change for where a node property is defined.  

You have already done the work to isolate the problem to the three nodes you mentioned. As a test could you comment out the 2 lines that get reset the PHY and see if you get to a prompt? The gp-evm does not use a reset line on the CPSW PHY. This is only the difference between your DTS file and the TI DTS from a structure perspective.

Best Regards,

Schuyler

that's kind of my point, if there is no information as to how the DTS formatting has changed how are we supposed to know what to change or what resource to look at to know if we follow the standards that the new kernel uses? i am fine going through each driver item with a fine tooth comb but i need something to base my information on. is there a resource for the current DTS formatting the current kernel was based on?

i will try to remove the reset line and report back

Hi,

I agree this is one reason that upgrading can be a frustrating due to the fine tooth nature of the process as you say. My belief is that there is recognition in the community that upgrading can be irritating but still a very worthy effort even with upgrading headache. 

I will wait for your report. 

Best Regards,

Schuyler

yes, i agree it's worth upgrading but my ultimate question is HOW do you know how to change the things that need to change? if YOU had a board where the dts file neeed changes for the latest kernel what resource do YOU use to know what changes the DTS file needs once you identify what needs to change?

i took out the code for the gpio reset and it got to the command prompt. ethernet still doesn't work. i get this message in the boot log:

[ 12.869464] net eth0: initializing cpsw version 1.15 (0)
[ 12.870591] libphy: PHY 4a101000.mdio:01 not found
[ 12.870599] net eth0: phy "4a101000.mdio:01" not found on slave 0, err -19
[ 12.902325] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready

when i do a mii dump 1:

=> mii dump 1
0. (3100) -- PHY control register --
(8000:0000) 0.15 = 0 reset
(4000:0000) 0.14 = 0 loopback
(2040:2000) 0. 6,13 = b01 speed selection = 100 Mbps
(1000:1000) 0.12 = 1 A/N enable
(0800:0000) 0.11 = 0 power-down
(0400:0000) 0.10 = 0 isolate
(0200:0000) 0. 9 = 0 restart A/N
(0100:0100) 0. 8 = 1 duplex = full
(0080:0000) 0. 7 = 0 collision test enable
(003f:0000) 0. 5- 0 = 0 (reserved)

the phy is out of reset and the lights are on. when the kernel runs, however, it gets shut down again. i remember this issue from having the gpios reset, and we had to include "ti,no-reset-on-init" for the whole bank, thing is we don't really want to do that because we have a lot of control lines coming out of that gpio bank and i DO want it reset for their sake. i know i could make a new pin group, probably, to encompass just the PHY reset but i'd hate to have to mess up the dts file for what seems to be a broken driver. SO what options do i have for the gpio reset driver? should i hog tie that line high as a solution?

Hi,

Thanks for performing that test. This indicates to me that the issue you are facing is how the reset line is defined in the MDIO node. The err -19 essentially translates to "no such device" btw. The error would make sense since I asked you to remove the reset and now that the PHY did not get a good reset. The PHY is most likely in an unknown state and not responding to MDIO messages.

So based on this I looked through other TI boards that use PHY resets which on most if not all of the IDK boards for the PRU eth module, not the CPSW. The common element that the same MDIO IP is used for both the PRU eth and the CPSW which means this could be used as a reference. Could you please attach the pin mux for the gpio reset line is? Are the gpio pins defined in the same pin definition as the MDIO used the CPSW?

Regarding a central resource for DTS changes there is not one to my knowledge. Perhaps it has something to do with how changes are individually added and not as single integration. The board level integrator such as yourself bears the brunt of the many changes that have occurred.

Best Regards,

Schuyler

pinmux/DTS clippings:

mdio_1_pins_default: mdio_1_pins_default {
pinctrl-single,pins = <
AM4372_IOPAD(0x94c, PIN_OUTPUT_PULLUP | MUX_MODE0) /* (B17) mdio_clk.mdio_clk */
AM4372_IOPAD(0x948, PIN_INPUT_PULLUP | MUX_MODE0) /* (A17) mdio_data.mdio_data */
>;
};

/* Optional sleep pin settings. Must manually enter values in the below skeleton. */
mdio_1_pins_sleep: mdio_1_pins_sleep {
pinctrl-single,pins = <
AM4372_IOPAD(0x94c, PIN_INPUT_PULLDOWN | MUX_MODE0) /* (B17) mdio_clk.mdio_clk */
AM4372_IOPAD(0x948, PIN_INPUT_PULLDOWN | MUX_MODE0) /* (A17) mdio_data.mdio_data */
>;
};

gpio_3_pins_default: gpio_3_pins_default {
pinctrl-single,pins = <
AM4372_IOPAD(0x990, PIN_OUTPUT_PULLUP | MUX_MODE7) /* (N24) mcasp0_aclkx.gpio3[14] TP49 */
AM4372_IOPAD(0x994, PIN_OUTPUT_PULLUP | MUX_MODE7) /* (N22) mcasp0_fsx.gpio3[15] offhook line 1 */
AM4372_IOPAD(0x998, PIN_OUTPUT_PULLUP | MUX_MODE7) /* (H23) mcasp0_axr0.gpio3[16] */
AM4372_IOPAD(0x99c, PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* (M24) mcasp0_ahclkr.gpio3[17] codec reset */
AM4372_IOPAD(0xa64, PIN_OUTPUT_PULLUP | MUX_MODE7) /* (P22) spi2_d0.gpio3[22] emac reset */
AM4372_IOPAD(0xa68, PIN_OUTPUT_PULLUP | MUX_MODE7) /* (P20) spi2_d1.gpio3[23] */
>;
};

/* Optional sleep pin settings. Must manually enter values in the below skeleton. */
gpio_3_pins_sleep: gpio_3_pins_sleep {
pinctrl-single,pins = <
AM4372_IOPAD(0x990, PIN_OUTPUT_PULLUP | MUX_MODE7) /* (N24) mcasp0_aclkx.gpio3[14] */
AM4372_IOPAD(0x994, PIN_OUTPUT_PULLUP | MUX_MODE7) /* (N22) mcasp0_fsx.gpio3[15] */
AM4372_IOPAD(0x998, PIN_OUTPUT_PULLUP | MUX_MODE7) /* (H23) mcasp0_axr0.gpio3[16] */
AM4372_IOPAD(0x99c, PIN_OUTPUT_PULLUP | MUX_MODE7) /* (M24) mcasp0_ahclkr.gpio3[17] */
AM4372_IOPAD(0xa64, PIN_OUTPUT_PULLUP | MUX_MODE7) /* (P22) spi2_d0.gpio3[22] */
AM4372_IOPAD(0xa68, PIN_OUTPUT_PULLUP | MUX_MODE7) /* (P20) spi2_d1.gpio3[23] */
>;
};

&gpio3 {
pinctrl-names = "default";
pinctrl-0 = <&gpio_3_pins_default>;
status = "okay";
ti,no-reset-on-init;
};

reset-gpios = <&gpio3 22 GPIO_ACTIVE_LOW>;
reset-delay-us = <2>; //1us reset time

looking at what i think is a resource for this (since nobody can seem to give me one): kernel.org/doc/Documentation/devicetree/bindings/ it would appear that gpio reset is not an option for the mac, davinci_mdio, or the cpsw_emac0. i do see an option for it in "ethernet-phy.yaml" but i am not completely sure how to set that up right at the moment. does this seem right?

can "ti,no-reset-on-init;" go inside a block like this in the gpio setting (i can't find a declaration of the gpios like the ti boards have them in the webspage above):

p22 {
gpio-hog;
gpios = <22 GPIO_ACTIVE_HIGH>;
output-high;
line-name = "PHY_RESET";

ti,no-reset-on-init;
};

Hi,

Please move this line from the gpio_3_pins_default node to the mdio_1_pins_default node in the pin mux area of the DTS.

AM4372_IOPAD(0xa64, PIN_OUTPUT_PULLUP | MUX_MODE7) /* (P22) spi2_d0.gpio3[22] emac reset */

The issue could be that since the kernel tends to try to get the network interfaces going fairly soon the network support maybe coming up faster than the gpio support. When the network tries to reset the PHY the gpio reset pin is not enabled yet. By moving the gpio pin enablement into mdio node that is trying to use it then all the pins are ready for use when the network tries to initialize. 

Best Regards,

Schuyler

nope, kernel still crashes and uboot can't see the phy

mdio_1_pins_default: mdio_1_pins_default {
pinctrl-single,pins = <
AM4372_IOPAD(0x94c, PIN_OUTPUT_PULLUP | MUX_MODE0) /* (B17) mdio_clk.mdio_clk */
AM4372_IOPAD(0x948, PIN_INPUT_PULLUP | MUX_MODE0) /* (A17) mdio_data.mdio_data */
AM4372_IOPAD(0xa64, PIN_OUTPUT_PULLUP | MUX_MODE7) /* (P22) spi2_d0.gpio3[22] emac reset */
>;
};

it's not a problem, i don't think, that the ethernet isn't found, as it will still load the kernel and go to command prompt if we simply leave the phy in reset, but the fact that the gpio reset command is present at all.

from my previous post:

looking at what i think is a resource for this (since nobody can seem to give me one): kernel.org/doc/Documentation/devicetree/bindings/ it would appear that gpio reset is not an option for the mac, davinci_mdio, or the cpsw_emac0. i do see an option for it in "ethernet-phy.yaml" but i am not completely sure how to set that up right at the moment

Hi,

I would like you to please try this setup in the DTS, the changes are in bold. This is based on the example that is Documentation/devicetree/bindings/net/mdio.txt. This is also how the AM335x-icev2 board is setup. 

&cpsw_emac0 {

phy_id = <&ethphy0>;
phy-mode = "rgmii";

};

&davinci_mdio {

pinctrl-names = "default", "sleep";
pinctrl-0 = <&mdio_1_pins_default>;
pinctrl-1 = <&mdio_1_pins_sleep>;
status = "okay";

reset-gpios = <&gpio3 22 GPIO_ACTIVE_LOW>;
reset-delay-us = <2>; //1us reset time

ethphy0: ethernet-phy@1 {

reg = <1>;

};

};

Best Regards,

Schuyler

still crashes. no change

i don't think the gpio reset is supported anymore

&davinci_mdio {
pinctrl-names = "default", "sleep";
pinctrl-0 = <&mdio_1_pins_default>;
pinctrl-1 = <&mdio_1_pins_sleep>;
status = "okay";

reset-gpios = <&gpio3 22 GPIO_ACTIVE_LOW>;
reset-delay-us = <2>; //1us reset time

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

&cpsw_emac0 {
//phy_id = <&davinci_mdio>, <1>;
phy_id = <&ethphy0>;
phy-mode = "mii";
};

rebuilt both u-boot and kernel and loaded to the SDCard

Hi,

Thanks for trying the suggestion. The reset gpio technique is used on the TI IDK boards and while it is causing issues here this should work. I will continue working on this and will consult additional resources for additional resolution suggestions. Did you come across a patch indicating the support removal by chance?

Best Regards,

Schuyler

Hi 

Could you share you full Kernel DT file? You can add .dtb file, or better de-compile it, like

dtc -I dtb -O dts ./omap-arm/arch/arm/boot/dts/am437x-gp-evm.dtb >> am437x-gp-evm.dts.txt

1) You shell use "phy-handle", like

&cpsw_emac0 {

phy-handle = <&ethphy0>;

phy-mode = "mii";

}

2) Documentation/devicetree/bindings/ is the main source of DT documentation

3) Just to confirm: by adding davinci_mdio->reset-gpios you do expect reset pulse to be generated on PHY reset line,right?

reset-gpios can be added as to MDIO node as to PHY node (if correct binding are used)

Documentation/devicetree/bindings/net/mdio.txt

Documentation/devicetree/bindings/net/phy.txt

Documentation/devicetree/bindings/net/ethernet.txt

4) gpio-hog is a good choice if gpio need to be initialized one time

Documentation/devicetree/bindings/gpio/gpio.txt

This thread seems mixing u-boot with kernel :( consider all above valid for Kernel first of all. It should work in u-boot also, except MDIO/PHY "reset-gpios".

attached is the dts file. the kernel does not support the dtc command

am437x-UTI.zip

1) i assume "shell" means "should". the EVM doesn't use it so i would assume that it would work still 

2) thank you for that

3) yes, i expect it to reset the phy

4) unfortunately i tried hog and it didn't work

Hi

1) Do you really need xx_sleep pinmuxes, if not better to remove?

2) You should switch to new PHY DT bindings, otherwise you can add DT properties for the PHY. And migration is good time for that, so pls use "phy-handle"

3)  With "phy-handle" you can move PHy reset in PHY node, like

&davinci_mdio {
    status = "okay";
/* This option for the case when >1 PHYs has shared GPIO reset line
    reset-gpios = <&gpio3 22 GPIO_ACTIVE_LOW>;
        reset-delay-us = <2>; 
*/
    phy0: ethernet-phy@1 {
        reg = <1>;
        reset-gpios = <&gpio3 22 GPIO_ACTIVE_LOW>;
        reset-assert-us = <10000>;
        reset-deassert-us = <100>; 
    };
};

4) i feel below diff should fix Kernel crash when reset-gpios added to "davinci_mdio" node. But still do not understand why  "couldn't get reset GPIO" error happens when  reset-gpios added to "davinci_mdio"

diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
index 228e687e91fb..c21fcab47cbf 100644
--- a/drivers/net/phy/mdio_bus.c
+++ b/drivers/net/phy/mdio_bus.c
@@ -390,9 +390,9 @@ int __mdiobus_register(struct mii_bus *bus, struct module *owner)
                gpiod = devm_gpiod_get_index_optional(&bus->dev, "reset",
                                                      i, GPIOD_OUT_LOW);
                if (IS_ERR(gpiod)) {
-                       dev_err(&bus->dev, "mii_bus %s couldn't get reset GPIO\n",
-                               bus->id);
-                       return PTR_ERR(gpiod);
+                       dev_err(&bus->dev, "mii_bus %s couldn't get reset GPIO[%d] %d\n",
+                               bus->id, i, PTR_ERR(gpiod));
+                       goto error;
                } else  if (gpiod) {
                        bus->reset_gpiod[i] = gpiod;

so it didn't crash but also it doesn't release the reset for the phy:

&davinci_mdio {
pinctrl-names = "default", "sleep";
pinctrl-0 = <&mdio_1_pins_default>;
pinctrl-1 = <&mdio_1_pins_sleep>;
status = "okay";

phy0: ethernet-phy@1 {
reg = <1>;
reset-gpios = <&gpio3 22 GPIO_ACTIVE_LOW>;
reset-assert-us = <10000>;
reset-deassert-us = <100>;
};
};

could you share "dmesg | grep mdio"?

and also share - "cat /sys/kernel/debug/gpio"

root@am437x-evm:~# dmesg|grep mdio
[ 1.091489] mdio_bus fixed-0: GPIO lookup for consumer reset
[ 1.091499] mdio_bus fixed-0: using lookup tables for GPIO lookup
[ 1.091506] mdio_bus fixed-0: No GPIO consumer reset found
[ 1.111374] mdio_bus 4a101000.mdio: GPIO lookup for consumer reset
[ 1.111384] mdio_bus 4a101000.mdio: using device tree for GPIO lookup
[ 1.111405] of_get_named_gpiod_flags: can't parse 'reset-gpios' property of node '/ocp@44000000/ethernet@4a100000/mdio@4a101000[0]'
[ 1.111417] of_get_named_gpiod_flags: can't parse 'reset-gpio' property of node '/ocp@44000000/ethernet@4a100000/mdio@4a101000[0]'
[ 1.111425] mdio_bus 4a101000.mdio: using lookup tables for GPIO lookup
[ 1.111431] mdio_bus 4a101000.mdio: No GPIO consumer reset found
[ 1.169610] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6, bus freq 1000000
[ 1.177315] libphy: 4a101000.mdio: probed
[ 1.181608] mdio_bus 4a101000.mdio: MDIO device at address 1 is missing.
[ 23.449032] libphy: PHY 4a101000.mdio:01 not found
[ 23.648389] net eth0: phy "4a101000.mdio:01" not found on slave 0, err -19
root@am437x-evm:~# cat /sys/kernel/debug/gpio
gpiochip0: GPIOs 0-31, parent: platform/44e07000.gpio, gpio-0-31:
gpio-31 ( |vmmcwl_fixed ) out hi

gpiochip1: GPIOs 32-63, parent: platform/4804c000.gpio, gpio-32-63:
gpio-33 ( |LossOfPowerDetect ) in hi IRQ
gpio-37 ( |matrix_kbd_row ) in hi IRQ
gpio-38 ( |matrix_kbd_row ) in hi IRQ
gpio-39 ( |matrix_kbd_row ) in hi IRQ
gpio-48 ( |matrix_kbd_row ) in hi IRQ
gpio-52 ( |matrix_kbd_row ) in hi IRQ
gpio-53 ( |matrix_kbd_row ) in hi IRQ

gpiochip2: GPIOs 64-95, parent: platform/481ac000.gpio, gpio-64-95:

gpiochip3: GPIOs 96-127, parent: platform/481ae000.gpio, gpio-96-127:
gpio-113 ( |CODEC_RESET ) out hi

gpiochip4: GPIOs 128-159, parent: platform/48320000.gpio, gpio-128-159:
gpio-129 ( |mute_led ) out lo
gpio-130 ( |captions_led ) out lo
gpio-131 ( |keypad_led ) out lo
gpio-132 ( |vol6_led ) out lo
gpio-133 ( |vol5_led ) out lo
gpio-134 ( |vol4_led ) out lo
gpio-135 ( |vol3_led ) out lo
gpio-136 ( |vol2_led ) out lo
gpio-137 ( |vol1_led ) out lo
gpio-138 ( |hfree_led ) out lo
gpio-139 ( |matrix_kbd_col ) out lo
gpio-140 ( |matrix_kbd_col ) out lo
gpio-141 ( |matrix_kbd_col ) out lo
gpio-142 ( |matrix_kbd_col ) out lo
gpio-147 ( |AVDD_EN ) out hi
gpio-149 ( |RingFlasher ) out lo

gpiochip5: GPIOs 160-191, parent: platform/48322000.gpio, gpio-160-191:
gpio-166 ( |DaaInterrupt ) in hi IRQ
gpio-167 ( |RingDetect ) in hi IRQ
gpio-180 ( |HookSwitch ) in hi IRQ

do i have to define that gpio somewhere so the system knows it's available for use?

Hi

The pinmux has to be defined properly for required GPIO - check PULL cfg.

From your log GPIO parsed and attached properly.

gpiochip3: GPIOs 96-127, parent: platform/481ae000.gpio, gpio-96-127:
gpio-113 ( |CODEC_RESET ) out hi <======== hi - PHY in reset

I can use the following for further debugging :

- remove "reset-gpios" from PHY node

- boot

-  export PHY reset gpio: "echo 113 > /sys/class/gpio/export"

    -- cat  /sys/class/gpio/gpio113/*

    -- echo out > /sys/class/gpio/gpio113/direction

    -- echo X > /sys/class/gpio/gpio113/value  <=== X - is 1 or 0

  <===^^^^^^ I assume PHY have some auto LEDs, so if cable plugged in and PHY out of reset the state of some LEDs should change (ON), when PHY is in reset - all LEDs OFF 

           This should help to check if PHY reset GPIO configured properly

I'v simulated it on TI am571x-idk platform with TI kernel  4.19.94 by using GPIO pin connected to the LED (there is no PHY reset line) and saw no issues.

In MDIO reset case: LED blinks during boot and stay ON

In PHY reset case: LED goes "ON" on ifconfig up and "OFF" on  ifconfig down

 &cpsw_emac0 {
-       phy_id = <&davinci_mdio>, <0>;
+       phy-handle = <&ethphy0>;
        phy-mode = "rgmii";
        dual_emac_res_vlan = <1>;
 };
 
 &cpsw_emac1 {
-       phy_id = <&davinci_mdio>, <1>;
+       phy-handle = <&ethphy1>;
        phy-mode = "rgmii";
        dual_emac_res_vlan = <2>;
 };
 
+&davinci_mdio {
+       status = "okay";
+//     reset-gpios = <&gpio7 25 GPIO_ACTIVE_LOW>;
+       ethphy0: ethernet-phy@0 {
+               reg = <0>;
+       };
+
+       ethphy1: ethernet-phy@1 {
+               reset-gpios = <&gpio7 25 GPIO_ACTIVE_LOW>;
+               reg = <1>;
+       };
+};
+

when i did this for gpio118 i set it to a 1 which made the phy come out of reset, so the line works. i can do this in u-boot so i knew that. i looked at my pinmux and i had that gpio line commented out (to make a change stated previously in this thread) but it didn't seem to help to uncomment it because it didn't make a difference.

Hi

I think, I might found a problem, to be sure I'd like to ask you to move "reset-gpios" back in mdio node and try with diff I've provided in

https://e2e.ti.com/support/processors/f/791/p/937659/3496515#3496515 

setting it up like this did not make a crash like it used to but did not bring the ethernet out of reset

&davinci_mdio {
pinctrl-names = "default", "sleep";
pinctrl-0 = <&mdio_1_pins_default>;
pinctrl-1 = <&mdio_1_pins_sleep>;
status = "okay";

/*phy0: ethernet-phy@1 {
reg = <1>;
reset-gpios = <&gpio3 22 GPIO_ACTIVE_LOW>;
reset-assert-us = <2>;
reset-deassert-us = <2>;
};*/

reset-gpios = <&gpio3 22 GPIO_ACTIVE_LOW>;
reset-delay-us = <2>; //1us reset time
};

You commented out phy ;( correct DT:

&davinci_mdio {
pinctrl-names = "default", "sleep";
pinctrl-0 = <&mdio_1_pins_default>;
pinctrl-1 = <&mdio_1_pins_sleep>;
status = "okay";

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

reset-gpios = <&gpio3 22 GPIO_ACTIVE_LOW>;
reset-delay-us = <2>; //1us reset time
};

You can check if "reset-gpios" is actually present by doing:

# find . /proc/device-tree/ -name *mdio*

The output should be like: /proc/device-tree/ocp/ethernet@48484000/mdio@48485000

# ls /proc/device-tree/ocp/ethernet@48484000/mdio@48485000/ 

#address-cells bus_freq ethernet-phy@0 name reg status
#size-cells compatible ethernet-phy@1 phandle reset-gpios ti,hwmodsn

^^^ "reset-gpios" is present

By the way, GPIO hogs helped to solve similar issue: https://e2e.ti.com/support/processors/f/791/p/944601/3498043#3498043 

In your case:

&gpio3 {

  p22 {
   gpio-hog;
   gpios = <22 GPIO_ACTIVE_LOW>;
   line-name = "PHY1 reset";
   output-low;
  };

};

i tried it both way, with the phy and without (since the evm dts file doesn't have it so it sure doesn't seem to be necessary or do anything) and it never worked

reset-gpios does exist:

root@am437x-evm:~# find /proc/device-tree/ -name *mdio*
/proc/device-tree/ocp@44000000/ethernet@4a100000/mdio@4a101000
/proc/device-tree/ocp@44000000/pruss-soc-bus@54426004/pruss@54400000/mdio@54432400
/proc/device-tree/ocp@44000000/l4_wkup@44c00000/scm@210000/pinmux@800/mdio_1_pins_default
/proc/device-tree/ocp@44000000/l4_wkup@44c00000/scm@210000/pinmux@800/mdio_1_pins_sleep

root@am437x-evm:~# ls /proc/device-tree/ocp@44000000/ethernet@4a100000/mdio@4a101000/
#address-cells bus_freq ethernet-phy@1 phandle pinctrl-1 reg reset-gpios ti,hwmods
#size-cells compatible name pinctrl-0 pinctrl-names reset-delay-us status

and i have tried hog tying it but when it boots and i do an ifconfig i do not have an IP address even though i can see via the LEDs that it is out of reset and data is being communicated

the ONLY thing that works right now is setting the gpio line high in u-boot and putting "ti,no-reset-on-init;" in the gpio3 properties