AM4372: CPSW Dual EMAC reboot issue

Please complete this checklist and post the results here: processors.wiki.ti.com/.../5x_CPSW

This is using TI Processor Linux SDK 05.03.00.07.  The rest of the checklist is N/A because the PHY in fact works so long as we do not plug it in until after Linux as fully booted.

I skipped the normal boot process by passing "init=/bin/sh" to the kernel, and made some progress.  Initializing the linux Ethernet driver has no effect--the reboot can still occur.  If I initialized the USB driver, however, the reboot issue stops. 

Back porting this to uboot, if I initialize the USB controller there (by running "usb start") the reboot issue stops as well.  The problem is that in order to boot linux you must stop the USB controller and the board then reboots before it can re-initialize the controller.

The board does not have USB0 connected to anything

Hi,

Could you please attach a log of the boot process where the reboot happens when trying to boot into the Kernel?  I am looking for kernel panics or warns. 

When the reboot is happening are both Ethernet cables plugged in and connected to link partners?

Confirming though that the first port Ethernet boots as expected to a user prompt?

Best Regards,

Schuyler

Hi Schuyler,

Thanks for the help

• The reboot happens irregardless of whether Ethernet Port 1 is connected to anything. 
• We don't get any kernel panics or warns. 
• The first port works well and is able to load SPL and U-boot both over ethernet

This fix seems to prevent the reboot from triggering in u-boot:

board/ti/am43xx/board.c:

int board_late_init(void)
{
	struct udevice *dev;
#ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
	set_board_info_env(NULL);

	/*
	 * Default FIT boot on HS devices. Non FIT images are not allowed
	 * on HS devices.
	 */
	if (get_device_type() == HS_DEVICE)
		env_set("boot_fit", "1");
#endif

#if CONFIG_IS_ENABLED(DM_USB) && CONFIG_IS_ENABLED(OF_CONTROL)
	if (device_okay("/ocp/omap_dwc3@48380000"))
		enable_usb_clocks(0);
	if (device_okay("/ocp/omap_dwc3@483c0000"))
		enable_usb_clocks(1);
#endif

	/* Just probe the potentially supported cdce913 device */
	uclass_get_device(UCLASS_CLK, 0, &dev);

        /////////////////////////////////////////////////////////////////////////////////////////////////////////
        // This enables the PHY and prevents the reboot from happening
	writel(0x3c006006, USB2_PHY2_POWER);
        ////////////////////////////////////////////////////////////////////////////////////////////////////////

	return 0;
}
#endif

The issue is that Linux will hang if the PHY is not disabled prior to staring the kernel.  We simply get

Starting kernel ...

Normally

common/bootm.c:bootm_disable_interrupts() calls usb_stop().  If it does this then the board reboots quickly after that call:

=> run bootcmd
Booting from nand ...

NAND read: device 0 offset 0x240000, size 0x800000
 8388608 bytes read: OK
## Loading kernel from FIT Image at 87000000 ...
   Using 'butterfly-sbc-revb.dtb' configuration
   Trying 'kernel@1' kernel subimage
     Description:  Linux kernel
     Type:         Kernel Image
     Compression:  uncompressed
     Data Start:   0x870000d8
     Data Size:    3892248 Bytes = 3.7 MiB
     Architecture: ARM
     OS:           Linux
     Load Address: 0x82000000
     Entry Point:  0x82000000
   Verifying Hash Integrity ... OK
## Loading fdt from FIT Image at 87000000 ...
   Using 'butterfly-sbc-revb.dtb' configuration
   Trying 'butterfly-sbc-revb.dtb' fdt subimage
     Description:  Flattened Device Tree blob
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0x873b65b0
     Data Size:    49136 Bytes = 48 KiB
     Architecture: ARM
   Verifying Hash Integrity ... OK
   Booting using the fdt blob at 0x873b65b0
usb_stop
   Loa

The obvious question is why Ethernet Port2 is causing a crash with the 2nd USB Port.  Disabling all USB support in U-boot has no effect

Thanks!
Mike

A few more datapoints:

• We disconnected ETH2_RESETn from SYS_RESETn by removing the buffer U15 (SK EVM).   This stopped the reset loop
• The PHY still causes the board to restart 1x on power-on
• The PHY comes up with both lights on in this case and is not usable

Any ideas?  What would cause the PHY to reset the entire board?  What signal(s) would put the PHY into this wierd state?  

Hi,

Thanks for the data points. I do mostly software support. I will have to check with a fellow team member who may be able to point in a direction to look at. Could you please attach a snippet of the PHY and MAC portion of the schematic? You mentioned earlier that this is like the EVM-SK, is it exactly like the EVM-SK in this area?

Like I said I do mostly SW but I will preemptively ask what I think my HW colleague will ask for which is if you also please attach a scope capture of the voltage rails for the PHY and the AM437x? I think they will want to see if the voltage is dipping.

Best Regards,

Schuyler

Hi Michael,

As Schuyler asked, please provide the schematic snippet for the Ethernet interfaces. Please also include the MDIO interface.

Here is the schematic for the second ethernet port.  Its is a copy/paste from the SK EVM, except for the interrupt line back to the processor has been removed

(Let me know if there is a better way to share this)

Hi Schuyler, 

Sorry for the delay.  I have attached the schematic for Ethernet Port 2, but you can see it is literally a copy/paste from the SK EVM. 

The voltage rails drop when the processor resets.  Thus without a reference its hard to determine if this is a side effect of the processor reset, or if it is the source of it.

After so more digging we have found a workaround that involved disabling STRICT mode on the PMIC.  I am continuing the discussion here: https://e2e.ti.com/support/power-management/f/196/t/907493

Hi,

Thank you for the update, that is very informative. This is a different team from the one I work on. Is this answer from the PMIC team sufficient? I would need to discuss this with another HW team member concerning the PMIC mode. To answer the PMIC testing question is that the EVMs that TI provides are test the platforms. If the PMIC evolves after the EVM development is completed I am not sure this gets back to the EVM platform.  

Best Regards,

Schuyler 

Hi Schuyler,

The answer from the PMIC team was very helpful.  Would it be possible for your team to test the SK EVM with a D0 PMIC and see if you have the same issue?  

Thanks!

Mike

Hi Mike, it might be a while before we'd be able to test it here on our end.  

I think what may be happening is that the PHY bootstrap pins upon power up are getting latched incorrectly, putting the PHY in a inadvertent state which eventually causes the issues you are seeing when plugging in the ethernet cable.  Can you try the following?

-can you toggle ETH2_RESETn while in u-boot?  Not sure how much of the SK board you copied, but we are just looking to reset the Ethernet PHY, not trigger a warm reset, so you might have to mod the board slightly to accomplish this.  The alternative is to try to generate a soft reset to the PHY via MDIO.  If it is the boot strapping issue, this should properly latch the strapping pins on the PHY, put it in a known state, and hopefully eliminate the issue you are seeing. 

Regards,

James