Mity CPU Platforms » MitySOM-335x (ARM Cortex-A8 Based Products)

Thank you for the detailed summary. But I am a little confused at why you did all this work. We provide a working u-boot and kernel which we've modified from the TI's SDK to work with our SOMs. My recommendation would be use them as a starting point instead of starting from TI's stuff. You should also be using git to check out u-boot and the kernel instead of copying from a tarball.

Note if you are using the TI SDK 05.03.00 compiler then you want our 3.2 kernel and 2013.10 u-boot branches. If you want to use device tree then you'll need to move to our newer Yocto based toolchain and the 2018.01 uboot and linux "linux4.14" branch.

For older TI SDK 05.03 compiler see: https://support.criticallink.com/redmine/projects/armc8-platforms/wiki/Das_U-Boot_Port and https://support.criticallink.com/redmine/projects/armc8-platforms/wiki/Linux_Kernel

For newer Yocto built compiler see: https://support.criticallink.com/redmine/projects/armc8-platforms/wiki/Wiki#2018-MDK-Release-Notes

If you have questions about these please feel free to ask.

Hi,

As per your suggestion, we have used mityarm u-boot and kernel and followed below steps:

Setup the MDK++
source /opt/criticallink/mitysom-335x_2018-04-16/environment-setup-cortexa8hf-neon-criticallink-linux-gnueabi

U-BOOT:++
We have updated u-boot mux.c and som.c as per the attachment and built u-boot as below:
Attached files: mux.c and som.c

make ARCH=arm CROSS_COMPILE=arm-criticallink-linux-gnueabi- distclean
make CROSS_COMPILE=arm-criticallink-linux-gnueabi- O=srini_mityarm mitysom335x_devkit_256MB_defconfig
make CROSS_COMPILE=arm-criticallink-linux-gnueabi- O=srini_mityarm

KERNEL+
Case 1:+

We used default “am335x-mitysom-devkit.dts” file except for below line from Linux and tested and we have ping failure, please find the log attached.
phy_id = <&davinci_mdio>, <3>;
Attached files:
am335x-mitysom-devkit_default.dts & Critical_link_log_22Nov_with_default_dts.txt

Case 2:++
We have same micrel phy working on AM3352 board with TI SDK 05.03.00. We have updated dts file as per working AM3352 hardware and tested and we have ping failure, please find the log attached.
Attached files: am335x-mitysom-devkit.dts & Critical_link_log_22Nov_with_working _AM3352_reference.txt
Kernel was built as below:
make ARCH=arm CROSS_COMPILE=arm-criticallink-linux-gnueabi- distclean
make ARCH=arm CROSS_COMPILE=arm-criticallink-linux-gnueabi- mrproper
make CROSS_COMPILE=arm-criticallink-linux-gnueabi- mitysom-335x-devkit_defconfig
make CROSS_COMPILE=arm-criticallink-linux-gnueabi- -j4 zImage

In both case 1 and case 2, we have problem with ping. If you can give some input based on logs attached, will be of great help.

Regards
Srinivasa

Some unrelated while I look into this:

O=srini_mityarm

Note, I've found that when doing O= builds, its more reliable if I give it a absolute path. Some projects will create multiple srini_mityarm folders otherwise. So I usually do O=$PWD/srini_mityarm. I don't recall if u-boot has this problem though.

make ARCH=arm CROSS_COMPILE=arm-criticallink-linux-gnueabi- distclean
make ARCH=arm CROSS_COMPILE=arm-criticallink-linux-gnueabi- mrproper

distclean calls mrproper fyi

# distclean
#
PHONY += distclean

distclean: mrproper

Ok, we shall use O=$PWD/srini_mityarm.

We have deleted srini_mityarm before our build. Hope the logs I have shared does not have any sideeffect becasue of this.

Regards
Srinivasa

I've attached an example boot log using the 2018 April MDK kernel, u-boot, and filesystem on our devkit.

We have same micrel phy working on AM3352 board with TI SDK 05.03.00.

I am a little unclear what you mean by "AM3352 board". Is this our devkit or TI's EVK?
What micrel phy are you using?

Could you provide the schematic for your custom baseboard? Feel free to email it to

• "working_AM3352_reference.txt"

=> mii info
PHY 0x03: OUI = 0x0885, Model = 0x21, Rev = 0x01, 10baseT, HDX
=> mii dump 3 0
(2040:0000) 0. 6,13 = b00 speed selection = 10 Mbps
(0100:0000) 0. 8 = 0 duplex = half

Something might be wrong with your phy or magnetics. Unless you have an ancient 10Mbps hub to plug your device into, it should be at least 100Mbps Full duplex. The mii status is reported between the phy and the connected hub/switch and doesn't rely on working communication with the processor. So even if u-boot or the kernel was broken, this link should still be correct.

The relevant log from our devkit

=> mdio list
cpsw:
2 - Micrel ksz9031 <--> cpsw
=> mii info
PHY 0x02: OUI = 0x0885, Model = 0x22, Rev = 0x02, 1000baseT, FDX
=> mii dump 2 0
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)

Note that even your "working" log shows ping failures so I'm not sure I understand why you've labeled it working.

• "with_default_dts" log actually reported a 1000baseT, full duplex link but it was lost by the time you ran mii dump...
• "with_default_dts" log reported finding the phy and the other one didn't.
• Note that both boards do report a 1Gbps/full duplex link once in the kernel. So that is somewhat confusing. cpsw 4a100000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
  

  --- "Critical_link_log_22Nov_with_working _AM3352_reference.txt">---2019-11-22 12:39:39.333316192 -  0500
  +++ Critical_link_log_22Nov_with_default_dts.txt>---2019-11-22 12:40:01.540909091 -0500
  @@ -30,16 +30,15 @@
   => mii info
  -PHY 0x03: OUI = 0x0885, Model = 0x21, Rev = 0x01,  10baseT, HDX
  +PHY 0x03: OUI = 0x0885, Model = 0x21, Rev = 0x01, 1000baseT, FDX
  @@ -295,12 +289,15 @@
  +[] net eth0: initializing cpsw version 1.12 (0)
  +[] net eth0: initialized cpsw ale version 1.4
  +[] net eth0: ALE Table size 1024
  +[] net eth0: phy found : id is : 0x221611
   ***************************************************************
   ***************************************************************
   NOTICE: This file system contains the following GPLv3 packages:
  @@ -705,21 +683,50 @@
   root@spx-vanguard:~# ifconfig eth0 192.168.35.55
   root@spx-vanguard:~#.
   root@spx-vanguard:~#.
   root@spx-vanguard:~#.
   root@spx-vanguard:~#.
  +root@spx-vanguard:~# ifconfig.
  +eth0      Link encap:Ethernet  HWaddr E0:C7:9D:A6:59:3B..
  +          inet addr:192.168.35.55  Bcast:192.168.35.255  Mask:255.255.255.0
  +          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  +          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  +          TX packets:17 errors:0 dropped:0 overruns:0 carrier:0
  +          collisions:0 txqueuelen:1000.
  +          RX bytes:0 (0.0 B)  TX bytes:4404 (4.3 KiB)
  +          Interrupt:179.
  +
  +lo        Link encap:Local Loopback..
  +          inet addr:127.0.0.1  Mask:255.0.0.0
  +          UP LOOPBACK RUNNING  MTU:65536  Metric:1
  +          RX packets:165 errors:0 dropped:0 overruns:0 frame:0
  +          TX packets:165 errors:0 dropped:0 overruns:0 carrier:0
  +          collisions:0 txqueuelen:1.
  +          RX bytes:12522 (12.2 KiB)  TX bytes:12522 (12.2 KiB)
  +
   root@spx-vanguard:~# ping 192.168.35.56
   PING 192.168.35.56 (192.168.35.56): 56 data bytes
   ^C
   --- 192.168.35.56 ping statistics ---
  -3 packets transmitted, 0 packets received, 100% packet loss
  +4 packets transmitted, 0 packets received, 100% packet loss
   root@spx-vanguard:~#.
   root@spx-vanguard:~# ethtool eth0.
   Settings for eth0:
   >--Supported ports: [ TP MII ]
   >--Supported link modes:   10baseT/Half 10baseT/Full.
  @@ -751,12 +758,13 @@
   >--Current message level: 0x00000000 (0)
  .>-->--->---.......
   >--Link detected: yes
   root@spx-vanguard:~#.
  -root@spx-vanguard:~# ethtool eth0 ^H^H^H^H^H ^H_^H ^H- ^HS ^H.
  +root@spx-vanguard:~# ethtool eth0^H^H^H^H ^H_ ^H ^H^H ^H- ^HS ^H.
   NIC statistics:
        Good Rx Frames: 0
        Broadcast Rx Frames: 0
  @@ -769,8 +777,8 @@
        Undersize (Short) Rx Frames: 0
        Rx Fragments: 0
        Rx Octets: 0
  -     Good Tx Frames: 21
  -     Broadcast Tx Frames: 16
  +     Good Tx Frames: 25
  +     Broadcast Tx Frames: 20
        Multicast Tx Frames: 5
        Pause Tx Frames: 0
        Deferred Tx Frames: 0
  @@ -781,14 +789,14 @@
        Late Collisions: 0
        Tx Underrun: 0
        Carrier Sense Errors: 0
  -     Tx Octets: 5004
  -     Rx + Tx 64 Octet Frames: 5
  +     Tx Octets: 5542
  +     Rx + Tx 64 Octet Frames: 8
        Rx + Tx 65-127 Octet Frames: 3
        Rx + Tx 128-255 Octet Frames: 0
  -     Rx + Tx 256-511 Octet Frames: 13
  +     Rx + Tx 256-511 Octet Frames: 14
        Rx + Tx 512-1023 Octet Frames: 0
        Rx + Tx 1024-Up Octet Frames: 0
  -     Net Octets: 5004
  +     Net Octets: 5542
        Rx Start of Frame Overruns: 0
        Rx Middle of Frame Overruns: 0
        Rx DMA Overruns: 0
  @@ -805,22 +813,24 @@
        Rx DMA chan: good_dequeue: 0
        Rx DMA chan: requeue: 0
        Rx DMA chan: teardown_dequeue: 0
  -     Tx DMA chan: head_enqueue: 21
  +     Tx DMA chan: head_enqueue: 25
        Tx DMA chan: tail_enqueue: 0
        Tx DMA chan: pad_enqueue: 0
        Tx DMA chan: misqueued: 0
        Tx DMA chan: desc_alloc_fail: 0
        Tx DMA chan: pad_alloc_fail: 0
        Tx DMA chan: runt_receive_buf: 0
  -     Tx DMA chan: runt_transmit_buf: 5
  -     Tx DMA chan: empty_dequeue: 21
  +     Tx DMA chan: runt_transmit_buf: 8
  +     Tx DMA chan: empty_dequeue: 25
        Tx DMA chan: busy_dequeue: 0
  -     Tx DMA chan: good_dequeue: 21
  +     Tx DMA chan: good_dequeue: 25
        Tx DMA chan: requeue: 0
        Tx DMA chan: teardown_dequeue: 0
   root@spx-vanguard:~#.
  

Could you provide the schematic for your custom baseboard? Feel free to email it to

Email info@criticallink.com

Hi,

We have same micrel phy working on AM3352 board with TI SDK 05.03.00.

I am a little unclear what you mean by "AM3352 board". Is this our devkit or TI's EVK? What micrel phy are you using?

Plese find "AM3352_am3359_Board_Setup.docx" attached, which explains the setup.

Could you provide the schematic for your custom baseboard? Feel free to email it to

Custom board is our customer proprietary board and we have requested their permission before sharing with you. We are awaiting for their response.

Thanks for the log "2018AprilMDK_working_devkit.txt".
We understand that you have used "mitysom335x_devkit_256MB_defconfig" in u-boot. Is our understanding correct?
Are you able to ping from u-boot?

DTS & Kernel
In Kernel, we understand you have used am335x-mitysom-devkit.dts & mitysom-335x-devkit_defconfig for kernel building without any modifications. Is our understanding correct?

The only difference we notice here is the Micrel PHY. You are using Micrel KSZ9031 and our schematics has Micrel KSZ9021. Towards this do we need to modify anything in u-boot or Kernel?
Please let us know on which development kit you have tested this?

Regards
Srinivasa

Srinivasa Wunnimani wrote:

Hi,

We have same micrel phy working on AM3352 board with TI SDK 05.03.00.

I am a little unclear what you mean by "AM3352 board". Is this our devkit or TI's EVK? What micrel phy are you using?

Plese find "AM3352_am3359_Board_Setup.docx" attached, which explains the setup.

Okay that helps. I looked through your pins. And it looks like you have the right pins for RGMII2.

Could you provide the schematic for your custom baseboard? Feel free to email it to

Custom board is our customer proprietary board and we have requested their permission before sharing with you. We are awaiting for their response.

Thanks for the log "2018AprilMDK_working_devkit.txt".
We understand that you have used "mitysom335x_devkit_256MB_defconfig" in u-boot. Is our understanding correct?
Are you able to ping from u-boot?

I used mitysom335x_devkit_512MB_defconfig, since my module had a 512MB nand. But otherwise should be identical.
Yes pinging from u-boot works.

U-Boot 2017.01 (Apr 16 2018 - 11:29:39 -0400)

CPU  : AM335X-GP rev 2.1
I2C:   ready
DRAM:  512 MiB
NAND:  512 MiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
In:    ns16550_serial
Out:   ns16550_serial
Err:   ns16550_serial
Net:   cpsw
Hit any key to stop autoboot:  0 
=> 
=> dhcp
cpsw Waiting for PHY auto negotiation to complete...... done
link up on port 1, speed 1000, full duplex
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
DHCP client bound to address 10.0.103.201 (1268 ms)
=> ping 10.0.0.23
link up on port 1, speed 1000, full duplex
Using cpsw device
host 10.0.0.23 is alive

DTS & Kernel
In Kernel, we understand you have used am335x-mitysom-devkit.dts & mitysom-335x-devkit_defconfig for kernel building without any modifications. Is our understanding correct?

Correct.

The only difference we notice here is the Micrel PHY. You are using Micrel KSZ9031 and our schematics has Micrel KSZ9021. Towards this do we need to modify anything in u-boot or Kernel?

I'm not aware of what the differences between these two chips are. They seem pretty similar.
https://www.microchip.com/wwwproducts/en/KSZ9021
https://www.microchip.com/wwwproducts/en/KSZ9031

However note in order to get the micrel phy working on our devkit, I had to play with the skew delay registers quite a bit.

Looking at the changes in som.c¶

Comments are preceded by ///
u-boot-som.diff

Looking at the differences between your dts and ours.¶

• We can ignore the changes to cpsw_sleep since we aren't dealing with sleep mode yet. Though I'd recommend leaving these alone.
  

   $ diff -u ~/local/linux-314/arch/arm/boot/dts/am335x-mitysom-devkit.dts am335x-mitysom-devkit.dts 
  --- /home/jcormier/local/linux-314/arch/arm/boot/dts/am335x-mitysom-devkit.dts    2019-11-22 12:20:25.702357440 -0500
  +++ am335x-mitysom-devkit.dts    2019-11-22 08:07:50.000000000 -0500
  @@ -326,13 +326,13 @@
       cpsw_sleep: cpsw_sleep {
           pinctrl-single,pins = <
               /* Slave 1 reset value */
  -            0x040 (PIN_OUTPUT | MUX_MODE2)        /* gpmc_a0.rgmii2_tctl */
  +            0x040 (PIN_INPUT_PULLDOWN | MUX_MODE2)        /* gpmc_a0.rgmii2_tctl */
               0x044 (PIN_INPUT_PULLDOWN | MUX_MODE2)    /* gpmc_a1.rgmii2_rctl */
  -            0x048 (PIN_OUTPUT | MUX_MODE2)        /* gpmc_a2.rgmii2_td3  */
  -            0x04C (PIN_OUTPUT | MUX_MODE2)        /* gpmc_a3.rgmii2_td2  */
  -            0x050 (PIN_OUTPUT | MUX_MODE2)        /* gpmc_a4.rgmii2_td1  */
  -            0x054 (PIN_OUTPUT | MUX_MODE2)        /* gpmc_a5.rgmii2_td0  */
  -            0x058 (PIN_OUTPUT | MUX_MODE2)        /* gpmc_a6.rgmii2_tclk */
  +            0x048 (PIN_INPUT_PULLDOWN | MUX_MODE2)        /* gpmc_a2.rgmii2_td3  */
  +            0x04C (PIN_INPUT_PULLDOWN | MUX_MODE2)        /* gpmc_a3.rgmii2_td2  */
  +            0x050 (PIN_INPUT_PULLDOWN | MUX_MODE2)        /* gpmc_a4.rgmii2_td1  */
  +            0x054 (PIN_INPUT_PULLDOWN | MUX_MODE2)        /* gpmc_a5.rgmii2_td0  */
  +            0x058 (PIN_INPUT_PULLDOWN | MUX_MODE2)        /* gpmc_a6.rgmii2_tclk */
               0x05C (PIN_INPUT_PULLDOWN | MUX_MODE2)    /* gpmc_a7.rgmii2_rclk */
               0x060 (PIN_INPUT_PULLDOWN | MUX_MODE2)    /* gpmc_a8.rgmii2_rd3  */
               0x064 (PIN_INPUT_PULLDOWN | MUX_MODE2)    /* gpmc_a9.rgmii2_rd2  */
  

• Ignoring lcd changes
  

  @@ -553,6 +553,9 @@
  
   &lcdc {
       status = "okay";
  +    pinctrl-names = "default", "sleep";
  +    pinctrl-0 = <&lcd_pins_default>;
  +    pinctrl-1 = <&lcd_pins_sleep>;
   };
  
   &epwmss0 {
  

• The ti,no-rest-on-init doesn't show up anywhere in the 4.4 kernel so hopefully has no effect
• I don't think you want to change the number of slaves. By default the mac acts like a network switch so both emacs are tied together.
  

  @@ -615,27 +618,39 @@
   };
  
   &mac {
  -    pinctrl-names = "default", "sleep";
  -    pinctrl-0 = <&cpsw_default>;
  -    pinctrl-1 = <&cpsw_sleep>;
  -    status = "okay";
  +    slaves = <1>;
  +        status = "okay";
  +    ti,no-rest-on-init;
  +        pinctrl-names = "default", "sleep";
  +        pinctrl-0 = <&cpsw_default>;
  +        pinctrl-1 = <&cpsw_sleep>;
   };
  

• Note I reordered your davinci_mdio so the diff would be more readable.
• The skew-ps keys seem to exist for the micrel phy, I just am not sure if the driver would actually be loaded in this case. It might be worth adding some print statements in drivers/net/phy/micrel.c
• These skews along with rgmii/rgmii-id may need to be played with inorder to get the rgmii bus working.
  

   &davinci_mdio {
  +        /*compatible = "micrel,ksz9021";*/
      pinctrl-names = "default", "sleep";
      pinctrl-0 = <&davinci_mdio_default>;
      pinctrl-1 = <&davinci_mdio_sleep>;
      status = "okay";
  +    
  +        phy0: ethernet-phy@0 {
  +                rxc-skew-ps = <3000>;
  +                rxdv-skew-ps = <0>;
  +                txc-skew-ps = <3000>;
  +                txen-skew-ps = <0>;
  +                reg = <3>;
  +        };
   };
  

• With slaves set back to <2> we should go back to having cpsw_emac0 and 1 defined. And your custom changes should be in cpsw_emac1 since we are using rgmii2.
• status and ti,no-rest-on-init don't need to be there.
• I've never used phy-handle before but it seems okay.
• phy-mode should be tested in both rgmii and rgmii-id in conjunction with above skew values.
  • Note that "drivers/net/ethernet/ti/cpsw-phy-sel.c" handles rgmii-id/txid/rxid as the same. Though I can't say for sure that no other part of the kernel uses them so you could try each permutation.
    

     &cpsw_emac0 {
    -    phy_id = <&davinci_mdio>, <1>;
    -    phy-mode = "rgmii";
    -};
    -
    -&cpsw_emac1 {
    -    phy_id = <&davinci_mdio>, <2>;
    -    phy-mode = "rgmii";
    +        status = "okay";
    +    ti,no-rest-on-init;
    +        phy-handle = <&phy0>;
    +        phy_id = <&davinci_mdio>, <3>;
    +        /*phy-mode = "rgmii-id";*/
    +        /*phy-mode = "rgmii-txid";*/
    +        phy-mode = "rgmii";
    +    
     };
    

Looking at am335x-mitysom-devkit_default.dts. You should probably have modified the phy_id of emac1 instead of emac0. Don't comment either out too.

Please let us know on which development kit you have tested this?

https://www.criticallink.com/product/mitysom-335x-dev-kit/

Hi,

From the “22_Nov_2019.zip”, I have shared it earlier, I notice that our CPU revision is 1.0.

CPU : AM335X-GP rev 1.0
I2C: ready
DRAM: 256 MiB
NAND: 256 MiB
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1

Below wiki states “However in modules using TI's AM335x Silicon Revision 1.0 we have found that they did not design the processor to work well with both NAND/GPMC memory and the RMII2 interface.”

https://support.criticallink.com/redmine/projects/armc8-platforms/wiki/Ethernet_Phy_Selection

We have RGMII2 on AM335X-GP rev 1.0 with NAND interface on GPMC, did you come across any similar problem for RGMII2 interface?

Next Question:
In the below link, which was discussed log back for the same board and same processor (while working with old kernel) they are referring to "Table 2-7 of the AM3359 specification". Which is the document they are referring to? I could not find Table 2.7 in AM335x and AMIC110 Sitara Processors Technical Reference Manual (SPRUH73P–October 2011–Revised March 2017).

https://support.criticallink.com/redmine/boards/28/topics/1917

Regards
Srinivasa

Srinivasa Wunnimani wrote:

Hi,

From the “22_Nov_2019.zip”, I have shared it earlier, I notice that our CPU revision is 1.0.

CPU : AM335X-GP rev 1.0
I2C: ready
DRAM: 256 MiB
NAND: 256 MiB
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1

Below wiki states “However in modules using TI's AM335x Silicon Revision 1.0 we have found that they did not design the processor to work well with both NAND/GPMC memory and the RMII2 interface.”

https://support.criticallink.com/redmine/projects/armc8-platforms/wiki/Ethernet_Phy_Selection

We have RGMII2 on AM335X-GP rev 1.0 with NAND interface on GPMC, did you come across any similar problem for RGMII2 interface?

No we use the RGMII2 interface extensively on our devkit and don't have any issues. The RMII2 interface has a pinmux conflict with the NAND memory, which is why it doesn't work for Rev1 silicon.

Next Question:
In the below link, which was discussed log back for the same board and same processor (while working with old kernel) they are referring to "Table 2-7 of the AM3359 specification". Which is the document they are referring to? I could not find Table 2.7 in AM335x and AMIC110 Sitara Processors Technical Reference Manual (SPRUH73P–October 2011–Revised March 2017).

https://support.criticallink.com/redmine/boards/28/topics/1917

I believe it is referring to what is now "Table 4-2. Pin Attributes" in the datasheet. http://www.ti.com/lit/ds/symlink/am3359.pdf

For example R13's ball reset state is low.

Hi,

Thanks for your reply , we tried all the changes you have suggested in uboot som.c and in kernel dts file as well.
We are not able to ping to any host system , mean to say ping is getting failed in uboot,while dhcp command is not working as well.

---
we have observed that we can see : "Could not find PHY for cpsw: phy_mask 6" message when uboot prompt comes up.

Also we tried changing in kernel dts file with your suggested changes for RGMII2 interface , after kernel prompt comes up , we are able to ping now thanks to you, but on the same note
while doing ping test packets loss is happening (as you can see in the log file attached).Do you have any suggestions on this issue.

Attached zip folder contains following things:
1.dts file with the suggested changes.
2.updated som.c file.
3.log file of the testing

Regards,
Srinivasa

Hi,
How can we change speed of the Ethernet link from "1Gbps/full" to "100Mbps/full" as in "Link is Up - 1Gbps/Full - flow control rx/tx" .
is it in driver code or dts file after kernel is bought up.

Regards,
Srinivasa

Srinivasa Wunnimani wrote:

Hi,

Thanks for your reply , we tried all the changes you have suggested in uboot som.c and in kernel dts file as well.
We are not able to ping to any host system , mean to say ping is getting failed in uboot,while dhcp command is not working as well.

---
we have observed that we can see : "Could not find PHY for cpsw: phy_mask 6" message when uboot prompt comes up.

• Run "make menuconfig"
• Navigate to "ARM architecture"
• About half way down the list, update "Select the phy mask".
  For phy id 3, the value should be 8. "1 << 3"
• Or since you don't need to search for your phy, you can turn off CONFIG_CPSW_SEARCH_PHY and it will use the phy id you specify in the som.c

drivers/net/cpsw.c

  static int cpsw_phy_init(struct cpsw_priv *priv, struct cpsw_slave *slave)
  {
   struct phy_device *phydev;
   u32 supported = PHY_GBIT_FEATURES;

  #if defined(CONFIG_CPSW_SEARCH_PHY) && defined(CONFIG_CPSW_SEARCH_PHY_MASK)
   phydev = phy_find_by_mask(priv->bus,
            CONFIG_CPSW_SEARCH_PHY_MASK,
            slave->data->phy_if);
   if (phydev){
    phy_connect_dev(phydev, priv->dev);
   }
   else
    printf("Could not find PHY for %s: phy_mask %x\n", priv->bus->name,
            CONFIG_CPSW_SEARCH_PHY_MASK);

Also we tried changing in kernel dts file with your suggested changes for RGMII2 interface , after kernel prompt comes up , we are able to ping now thanks to you, but on the same note
while doing ping test packets loss is happening (as you can see in the log file attached).Do you have any suggestions on this issue.

Could you rerun ifconfig after getting the ping losses? To see if we are seeing any errors, dropped, overruns, or other issues.

phy-mode = "rgmii-rxid";

Attached zip folder contains following things:
1.dts file with the suggested changes.
2.updated som.c file.
3.log file of the testing

Regards,
Srinivasa

Srinivasa Wunnimani wrote:

Hi,
How can we change speed of the Ethernet link from "1Gbps/full" to "100Mbps/full" as in "Link is Up - 1Gbps/Full - flow control rx/tx" .
is it in driver code or dts file after kernel is bought up.

In u-boot we added an environment setting to disable gigabit advertising for our makerboard version.
In som.c, you can remove the ifdef and it will always set disable_giga.

  #ifdef CONFIG_MITYSOM_MAKER
  >-------env_set("disable_giga", "1");
  #endif

In the kernel dts, the phy can be given the max speed. Example taken from am335x-mitysom-maker.dts

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

 phy0: ethernet-phy@0 {
  reg = <2>;
  /* Restrict phy to 10/100 due to magnetics */
  max-speed = <100>;
 };
};

Hi,
Thank you for your reply, it worked and we are able to test it.

one more issue we are facing if u can help it will be good.

display lcd is not working in the board, although we are creating it's corresponding gpio directory.
and controlling via application, we are not able to do, can u help us with this issue with same thread.

Srinivasa Wunnimani wrote:

Hi,
Thank you for your reply, it worked and we are able to test it.

one more issue we are facing if u can help it will be good.

display lcd is not working in the board, although we are creating it's corresponding gpio directory.
and controlling via application, we are not able to do, can u help us with this issue with same thread.

Could you provide more info? Why does your lcd need a gpio exported?
It may help to have a separate post to keep the two issues but its not required.

hi,
yes thanks for the reply, we shall create a new thread regarding that issue.

& Regarding the Ethernet ping issue:

without adding max-speed property, we are getting "Link is Up - 1Gbps/Full - flow control rx/tx".
that is 1Gbps speed of link, but when we try with this configuration we are seeing packet loss of up to 80-90%.

do you have any suggestion on how to rectify this problem.

log is like this:
---------------

root@spx-vanguard:~# ping 192.168.37.170
PING 192.168.37.170 (192.168.37.170): 56 data bytes
64 bytes from 192.168.37.170: seq=10 ttl=128 time=1765.263 ms
^C
--- 192.168.37.170 ping statistics ---
15 packets transmitted, 1 packets received, 93% packet loss
round-trip min/avg/max = 1765.263/1765.263/1765.263 ms

Regards,
Srinivasa

If your magnetics are only 10/100 rated then the 1Gbps speed won't work.