DM8148 PHY reset problem

Hi Devang,

Devang Tailor said:

We are using ezSDK, psp04.04.00.01

Please try with the latest versions of u-boot and linux kernel, available at the below links:

Devang Tailor said:

We are using DM8148 in our custom board

Try to reproduce this issue on the DM814x TI EVM.

Devang Tailor said:

booting up the board via tftp

Try to reproduce this issue via booting from other source (SD card, NAND/NOR/SPI flash, UART)

BR
Pavel

Hi Pavel,

Thank you for the response. I will do the require changes in Uboot and kernel and will let you know.

Currently I dont have the EVM, so I can not try to reproduce it. A month before, I have used EVM with DVRRDK 4.x (not with ezsdk) and i didn't face such issue.

The LED blinking periodoically at 1 sec (whenever this issue occurs). Is that code indicate the root cause for the issue ?

Regards,
Devang

Devang,

Can you also try with the in built WDTimer (not with external DS1374), below is example application for using this WDT:
processors.wiki.ti.com/.../TI81XX_PSP_WDT_Driver_User_Guide
ti-ezsdk_dm814x-evm_5_05_02_00/example-applications/linux-driver-examples-psp04.04.00.01/watchdog

See also if the below e2e thread will help:
e2e.ti.com/.../257979

BR
Pavel

Hi Pavel,

The issue is not seeems to be related to watchdog beacuse putting the board in continueous reboot loop (continueous reboot) can also reproduce this issue.

I have gone through the link suggested by you and done changes related to CPSW in Uboot as well in kernel, but still same issue is occurring.

While debugging, we found that whenever this issue produced at that time the registers of LAN8720A shows that Link is down and autonegotiation is not completed.

Regards,
Devang

Devang,

Please review also the below wiki page:
processors.wiki.ti.com/.../TI81xx_PSP_Porting_Guide

You can also run HW diagnostic test to see that you do not have HW issues.

www.mistralsolutions.com/.../support-downloads

rgmii_emac_0

This CCS test application validates the EMAC0 for its ability to perform write access; read access and data TX/RX ability. The test application writes a known pattern into the TX Buffer and then reads back and verifies the same via a external loopback. The known pattern written into the memory is the incremental hexadecimal numbers. After transferring the entire memory area, this application reads them back and validates the data read. If the data read does not match the expected pattern, this test is declared failed. It is declared pass otherwise.

BR
Pavel

Devang Tailor said:

Currently I dont have the EVM, so I can not try to reproduce it. A month before, I have used EVM with DVRRDK 4.x (not with ezsdk) and i didn't face such issue.

Can you send me the exact steps? I will try it on my EVM.

BR
Pavel

Hi Pavel,

Just reboot the EVM when kernel gets up. We have made a script inside /etc/rc5.d/S99rmnologin which will be execute automatically each time the kernel gets up. The script contain a line "reboot -f"

So EVM will be rebooted continuously.

Hi Devang,

I tested on DM814x TI EVM, I can not observe this issue. I am using:

Boot u-boot from NAND, using the latest u-boot code base:

;a=shortlog;h=refs/heads/ti81xx-master

Then load uImage from tftp and load rootfs from NFS:

bootcmd=setenv autoload no; dhcp; setenv serverip 172.20.1.195; tftp 0x81000000 uImage; bootm 0x81000000

bootargs=console=ttyO0,115200n8 root=/dev/nfs nfsroot=172.20.1.195:/home/users/pbotev/targetfs,nolock rw mem=364M@0x80000000 mem=320M@0x9FC00000 vmalloc=500M notifyk.vpssm3_sva=0xBF900000 ip=dhcp noinitrd

I am using "reboot -f", and I can always tftp the uImage successful:

root@dm814x-evm:~# reboot -f

musb-hdrc musb-hdrc.1: remove, state 1

usb usb2: USB disconnect, address 1

musb-hdrc musb-hdrc.1: USB bus 2 deregistered

musb-hdrc musb-hdrc.0: remove, state 1

usb usb1: USB disconnect, address 1

musb-hdrc musb-hdrc.0: USB bus 1 deregistered

Restarting system.

U-Boot 2010.06 (May 26 2015 - 15:38:30)

TI8148-GP rev 2.1

ARM clk: 600MHz

DDR clk: 400MHz

DRAM:  1 GiB

DCACHE:  Off

NAND:  HW ECC BCH8 Selected

256 MiB

Using default environment

The 2nd stage U-Boot will now be auto-loaded

Please do not interrupt the countdown till TI8148_EVM prompt if 2nd stage is already flashed

Hit any key to stop autoboot:  0

NAND read: device 0 offset 0x20000, size 0x40000

262144 bytes read: OK

## Starting application at 0x81000000 ...

U-Boot 2010.06 (Jun 15 2015 - 10:26:24)

TI8148-GP rev 2.1

ARM clk: 600MHz

DDR clk: 400MHz

I2C:   ready

DRAM:  1 GiB

DCACHE:  On

NAND:  HW ECC BCH8 Selected

256 MiB

MMC:   OMAP SD/MMC: 0

                         .:;rrr;;.                  

                   ,5#@@@@#####@@@@@@#2,            

                ,A@@@hi;;;r5;;;;r;rrSG@@@A,          

              r@@#i;:;s222hG;rrsrrrrrr;ri#@@r        

            :@@hr:r;SG3ssrr2r;rrsrsrsrsrr;rh@@:      

           B@H;;rr;3Hs;rrr;sr;;rrsrsrsrsrsr;;H@B    

          @@s:rrs;5#;;rrrr;r#@H:;;rrsrsrsrsrr:s@@    

         @@;;srs&X#9;r;r;;,2@@@rrr:;;rrsrsrsrr;;@@  

        @@;;rrsrrs@MB#@@@@@###@@@@@@#rsrsrsrsrr;;@@  

       G@r;rrsrsr;#X;SX25Ss#@@#M@#9H9rrsrsrsrsrs;r@G

       @9:srsrsrs;2@;:;;:.X@@@@@H::;rrsrsrsrsrsrr:3@

      X@;rrsrsrsrr;XAi;;:&@@#@Bs:rrsrsrsrsrsrsrsrr;@X

      @#;rsrsrsrsrr;r2ir@@@###::rrsrsrsrsrsrsrsrsr:@@

      @A:rrsrsrsrr;:2@29@@M@@@;:;rrrrsrsrsrsrsrsrs;H@

      @&;rsrsrsrr;A@@@@@@###@@@s::;:;;rrsrsrsrsrsr;G@

      @#:rrsrsrsr;G@5Hr25@@@#@@@#9XG9s:rrrrsrsrsrs:#@

      M@;rsrsrsrs;r@&#;::S@@@@@@@M@@@@Grr:;rsrsrsr;@#

      :@s;rsrsrsrr:M#Msrr;;&#@@@@@@@@@@H@@5;rsrsr;s@,

       @@:rrsrsrsr;S@rrrsr;:;r3MH@@#@M5,S@@irrsrr:@@

        @A:rrsrsrsrrrrrsrsrrr;::;@##@r:;rH@h;srr:H@  

        ;@9:rrsrsrsrrrsrsrsrsr;,S@Hi@i:;s;MX;rr:h@;  

         r@B:rrrrsrsrsrsrsrr;;sA@#i,i@h;r;S5;r:H@r  

          ,@@r;rrrsrsrsrsrr;2BM3r:;r:G@:rrr;;r@@,    

            B@Mr;rrrrsrsrsr@@S;;;rrr:5M;rr;rM@H      

             .@@@i;;rrrrsrs2i;rrrrr;r@M:;i@@@.      

               .A@@#5r;;;r;;;rrr;r:r#AsM@@H.        

                  ;&@@@@MhXS5i5SX9B@@@@G;            

                      :ihM#@@@@@##hs,                

Net:   Detected MACID:90:d7:eb:d5:13:96

cpsw

Hit any key to stop autoboot:  0

link up on port 0, speed 100, full duplex

BOOTP broadcast 1

DHCP client bound to address 172.20.0.126

link up on port 0, speed 100, full duplex

Using cpsw device

TFTP from server 172.20.1.195; our IP address is 172.20.0.126

Filename 'uImage'.

Load address: 0x81000000

Loading: #################################################################

#################################################################

#################################################################

#################################################################

#################################################################

#################################################################

#################################################################

#################################################################

####################

done

Bytes transferred = 2760108 (2a1dac hex)

 

May be this issue is related to your custom PHY. Can you check if this PHY has been reset and fully functional before trying to fetch the uImage through tftp?

BR
Pavel

Hi Pavel,

We tried to debug this issue by putting debug prints in some functions of the U-boot.  We found some misbehavior inside the  function  cpsw_slave_update_link() of file drivers/net/cpsw.c .

For cold reboot case,

CONDITION  if (reg & PHY_BMSR_LS) { /* link up */  is  always true

For warm reboot case,

CONDITION  if (reg & PHY_BMSR_LS) { /* link up */  is false sometimes and link never recovers (which stops the board from booting)

Can you please let us know in which cases the link may remain down for PHY and recovers only when we do cold reboot?

Please let me know if there are any queries or you need more information.

Thanks,

Devang

Devang,

Seems like your EMAC PHY Basic Status Register (addr 0x1) bit 2 (Link Status) is 0 (link is down). This looks to me issue related to this external PHY. Have you tried to contact this external PHY supplier why it can not establish a link?

BR
Pavel

Are you using RSTOUTn pin K6 to connect to the PHY RSTn pin? What is the value of BTMODE[11] pin? Can you measure with a scope this connection (DM814x RSTOUTn pin to PHY RSTn pin), if there is any difference between working case and failing case.

BR
Pavel

Hi Pavel,

No, we are not using K6 to connect to the PHY RSTn pin (K6 is open)
Value of BTMODE[11] is 1 i.e. 3.3 V
As we have no connection between DM814x RSTOUTn pin to PHY RSTn pin we won't be able to measure the same.

Thanks,
Devang

Devang,

Devang Tailor said:

No, we are not using K6 to connect to the PHY RSTn pin (K6 is open)

Devang Tailor said:

As we have no connection between DM814x RSTOUTn pin to PHY RSTn pin we won't be able to measure the same.

Are you using the PHY RSTn pin or leaving it NC (Not Connected)? If using PHY RSTn pin, to which DM814x device pin you are connecting the PHY RSTn pin? And is there any other device pin connected to the PHY RSTn pin?

BR
Pavel

PHY reset pin is connected to GP2[21] of DM8148.

Devang Tailor said:

PHY reset pin is connected to GP2[21] of DM8148.

How do you expect this GP2[21] pin to take the RSTOUTn functionality when you are making reset? Please take the DM814x TI EVM schematics as a reference - there you will find how the PHY is reset properly.

BR
Pavel

Hi Pavel,

Some more information about the link status behavior when issue is re-produced,

Initially the link on port 0 is up with PHY's status register's value 0x782D. After that when U-boot try to load the kernel from TFTP, it continuously print TTT and then after few try, PHY 's status register's value is changes to 0x7809 (link down).

Regards,
Devang

Hi Pavel,

We are going through the registers of EMAC switch of DM8148. We found that some registers value are different  from the expected one when the issue is reproduce. We didn't get why the some registers' s value (like slave emac addresses [value change to zero] and  ALE [enable to disable] ) are being changed after few reboot cycle. For initial few reboot cycle the registers value are as per expectation. Below is the table indicating register addresses and their value for working case and non working case (issue produce). Rest all registers value are same for both working and non-working case.

Table for registers addresses and value : Values are taken from U-boot prompt

Register Address	Description	Value for working Case	Value for non-working case
0x4a10000c	CPSW_STAT_PORT_EN	0x1	0x0
0x4a10002c	P0_BLK_CNT	0xc1	0x41
0x4a100054	P1_BLK_CNT	0x42	0x41
0x4a100060	P1_TX_PRI_MAP	0x33221100	0x33221001
0x4a100070	SL1_SA_LO	0x7ec3	0x0
0x4a100074	SL1_SA_HI	0xf74c99b4	0x0
0x4a1000a0	P2_TX_PRI_MAP	0x33221100	0x33221001
0x4a1000b0	SL2_SA_LO	0x7ec3	0x0
0x4a1000b4	SL2_SA_HI	0xf74c99b4	0x0
0x4a100124	DMASTATUS	0x4000	0x80000000
0x4a100180	TX_INTSTAT_RAW	0x0	0x1
0x4a1001b0	DMA_INTSTAT_RAW	0x2	0x0
0x4a100240	TX0_CP	0x0	0x806f99bc
0x4a100608	ALE_CONTROL	0x80000000	0x0
0x4a100620	ALE_TBLCTL	0x5	0x0
0x4a100638	ALE_TBLW1	0x20050000	0x0
0x4a10063c	ALE_TBLW0	0x50005	0x0
0x4a100640	ALE_PORTCTL0	0x3	0x0
0x4a100644	ALE_PORTCTL1	0x3	0x0
0x4a100648	ALE_PORTCTL2	0x3	0x0
0x4a100714	SL1_BOFFTEST	0xd20000	0x3c10000
0x4a100754	SL2_BOFFTEST	0x2950000	0xbb0000

 

Let me know if you have any query.

Regards,

Devang

Hi Pavel,

Any update or any suggestion on above issue ?

Regards,

Devang

Devang,

I would suggest you verify you are covering the external ethernet PHY reset requirements. The external PHY reset requirements should be described in its datasheet. Check reset timing, level, front etc requirements are covered by your custom design.

BR
Pavel

Hi Pavel,

We have already measured the timings to reset the PHY and they are meeting the expected one (more than enough), that's why we moved towards 3PSW - EMAC registers to debug it further and we found that even if we are writing the registers like SL1_SA_LO, SL1_SA_HI etc. they are getting changed to 0 .

What are the possible reasons for it ?

Regards ,
Devang

Devang,

Are you using the EMAC reset isolation feature described in DM814x datasheet section 7.3.13 EMAC Switch Reset Isolation and DM814x TRM section 2.7.13.2 EMAC Switch Reset Isolation ?

If yes, refer to DM814x silicon errata, Advisory 3.0.85.

BR
Pavel

Hi Pavel,

We are not using the EMAC reset isolation. However we have also tried it to check whether it affect the behavior or not. But in both case we are getting the same result and issue exist in both case.

Regards,
Devang

Devang,

Devang Tailor said:

For initial few reboot cycle the registers value are as per expectation. Below is the table indicating register addresses and their value for working case and non working case (issue produce). Rest all registers value are same for both working and non-working case.

Your registers values for the non-working case have the reset values (see 9.4 Registers - reset values). So it seems that the initialization for the CPSW module has been skipped in the non-working case. Can you check that you have exactly the same initialization code running for both working and non-working case?

BR
Pavel

Hi Pavel,

We have checked that also by using print in initialization code and confirmed that same initialization code is being executed for both cases. We have also check (using print ) what value is being written at which address. For both working and non working case we are getting same print for value and address pair.
 

But for non working case some how the values are being changed to zero. Still could find the root cause.

Regards,

Devang

Devang,

This looks to be HW malfunction to me, as I can not reproduce this "warm reset" issue on the TI EVM. I would suggest you to double check the HW design and also run the EMAC HW diagnostic test.

BR
Pavel