512-861-3400Log inCreate Account

ubuntu 16.04 network problem

Forums › Reference, Evaluation, and Development Boards › OSD3358-SM-RED › ubuntu 16.04 network problem

Viewing 7 reply threads
  • Author
    Posts
    • April 11, 2018 at 3:40 pm #5096
      Mike Pettitmpettit
      Participant

        i built a sd card using procedures from here http://eewiki.net/display/linuxonarm/BeagleBone+Black

        the image boots but my ethernet doesn’t work, that is can not ping or get a dhcp address.

        # dmesg | grep eth

        [    2.034904] cpsw 4a100000.ethernet: Detected MACID = 38:d2:69:57:de:f8

        [    2.041751] cpsw 4a100000.ethernet: initialized cpsw ale version 1.4

        [    2.048170] cpsw 4a100000.ethernet: ALE Table size 1024

        [    2.053470] cpsw 4a100000.ethernet: cpts: overflow check period 1250 (jiffies)

        [   11.034721] net eth0: initializing cpsw version 1.12 (0)

        [   11.067083] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready

        [   13.092175] cpsw 4a100000.ethernet eth0: Link is Up – 100Mbps/Full – flow control rx/tx

        [   13.092283] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

        [  249.826115] NETDEV WATCHDOG: eth0 (cpsw): transmit queue 0 timed out

        i have tried with kernel versions 4.15.16-bone4 and 4.14.32-ti-rt-r42

        i have also tried the am335x-boneblack.dtb and osd3358-bsm-refdesign.dtb device tree files.

        the eMMC debian as shipped with board does boot and ethernet is working.

        looking for ideas on how to get my wired ethernet working.

        Mike

         

      • April 12, 2018 at 9:45 am #5098
        Neeraj Dantu
        Moderator

          Can you please post the complete boot logs? The Ethernet PHY on OSD3358-SM-RED is different from the Beaglebone black. So, the default device tree am335x-boneblack.dtb will not bring up the Ethernet interface. The first step is to make sure the device tree file osd3358-bsm-refdesign.dtb is installed correctly. Here is a procedure to install the device tree just in case:

          1. Download the OSD3358-SM-RED device tree from https://github.com/octavosystems/OSD335x-Device-Tree It is in OSD3358-SM-RED folder.

          2. Copy the device tree file osd3358-bsm-refdesign.dtb into /boot/dtbs/[kernel version]/ folder

          3. Edit the variable ‘dtb’ in /boot/uEnv.txt to say ‘dtb=osd3358-bsm-refdesign.dtb’

           

        • April 12, 2018 at 1:27 pm #5099
          Mike Pettitmpettit
          Participant

            Thank you for the reply.  The steps you described are what i have done.  I included a capture of the boot up.  This is my /boot/uEnv.txt file contents:

            #uname_r=4.1.12-bone16

            uname_r=4.14.32-ti-rt-r42

            #dtb=

            dtb=am335x-boneblack.dtb

            #dtb=am335x-bonegreen.dtb

            #dtb=am335x-bonegreen-2can.dtb

            #dtb=am335x-bonegreen-2can-uart.dtb

            #dtb=osd3358-bsm-refdesign.dtb

            #UUID=”e2a653e7-8499-43b6-a7bf-a8221fe4f5e0

            UUID=”a00e5cc6-ef2d-45d3-b817-186e74496e3d”

             

          • April 12, 2018 at 1:30 pm #5100
            Mike Pettitmpettit
            Participant

              sorry seems i had to rename the capture file

              Attachments:
              1. minicom.txt
            • April 12, 2018 at 2:00 pm #5102
              Mike Pettitmpettit
              Participant

                lets try that again, i hae a couple of disks and i see the file was missing on the last.  putting file in place did not fix problem though.

                this is the contents of the fresh build disk and log of boot up.

                ubuntu@arm:~$ cat /boot/uEnv.txt

                uname_r=4.15.16-bone4

                 

                dtb=osd3358-bsm-refdesign.dtb

                Mike

                Attachments:
                1. minicom-1.txt
              • April 12, 2018 at 3:38 pm #5104
                Mike Pettitmpettit
                Participant

                  ok, let me try this again.  apparently minicom did not overwrite the capture file the last time.

                  This capture shows the boot finding the file correctly and the contents of the /boot/uEnv.txt file.

                  I did notice that i mentioned to add uboot_enable_overlays=1  might that be what i am missing?

                  Attachments:
                  1. minicom-2.txt
                  • April 16, 2018 at 10:59 am #5111
                    Neeraj Dantu
                    Moderator

                      Mike,

                      From the updated bootlog minicom-2.txt, it looks like the ethernet PHY is being probed successfully (lines 226-233). Ubuntu is also trying to bring the ethernet interface (eth0) up at line 461. I am not sure whether it is succeeding.

                      Can you run ‘systemctl status networking.service’ to see if the networking daemon is running?

                      I will go through the build process for Ubuntu and try to debug on this side, meanwhile, please let me know if you make progress.

                  • April 17, 2018 at 7:24 am #5116
                    Mike Pettitmpettit
                    Participant

                      Thanks for looking into this,

                      ubuntu@arm:~$ systemctl status networking

                      ??? networking.service – Raise network interfaces

                      Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor prese

                      Drop-In: /run/systemd/generator/networking.service.d

                      ??????50-insserv.conf-$network.conf

                      Active: failed (Result: timeout) since Sat 2017-12-09 19:40:42 UTC; 4 days ag

                      Docs: man:interfaces(5)

                      Process: 195 ExecStart=/sbin/ifup -a –read-environment (code=killed, signal=T

                      Process: 184 ExecStartPre=/bin/sh -c [ “$CONFIGURE_INTERFACES” != “no” ] && [

                      Main PID: 195 (code=killed, signal=TERM)

                       

                      Dec 09 19:40:03 arm dhclient[289]: DHCPDISCOVER on eth0 to 255.255.255.255 port

                      Dec 09 19:40:03 arm ifup[195]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 i

                      Dec 09 19:40:22 arm dhclient[289]: DHCPDISCOVER on eth0 to 255.255.255.255 port

                      Dec 09 19:40:22 arm ifup[195]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 i

                      Dec 09 19:40:39 arm dhclient[289]: DHCPDISCOVER on eth0 to 255.255.255.255 port

                      Dec 09 19:40:39 arm ifup[195]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 i

                      Dec 09 19:40:42 arm systemd[1]: networking.service: Start operation timed out. T

                      Dec 09 19:40:42 arm systemd[1]: Failed to start Raise network interfaces.

                      Dec 09 19:40:42 arm systemd[1]: networking.service: Unit entered failed state.

                      Dec 09 19:40:42 arm systemd[1]: networking.service: Failed with result ‘timeout’

                      lines 1-20/20 (END)

                       

                      • April 19, 2018 at 10:30 am #5140
                        Neeraj Dantu
                        Moderator

                          Mike,

                          Here is an update for this issue:

                          The board boots and loads the PHY driver. As indicated by the LED activity on the connector and ifconfig, it looks like there is data transfer on Tx and Rx interfaces. However, there is no DHCP/ARP request going out on the network connected to the board. I don’t think there is an issue with the protocol stack as I am able to use a USB WiFi dongle to connect to the internet and install packages.

                          When it is connected to an ethernet switch on the network, the board is able to capture packets on the network using tcpdump, so, the rx interface seems to be working fine.

                          We are currently trying to see if there a configuration issue with the PHY.

                      • April 23, 2018 at 3:59 pm #5210
                        Mike Pettitmpettit
                        Participant

                          today i noticed that the Ubuntu image doesn’t load the same drive as the Debian image for the phy …

                          ubuntu@arm:~$ dmesg | grep phy

                          [    0.000000] Booting Linux on physical CPU 0x0

                          [    1.887704] libphy: Fixed MDIO Bus: probed

                          [    1.977736] davinci_mdio 4a101000.mdio: detected phy mask ffffffef

                          [    1.986222] libphy: 4a101000.mdio: probed

                          [    1.990310] davinci_mdio 4a101000.mdio: phy[4]: device 4a101000.mdio:04, driver unknown

                          [    2.042184] am335x-phy-driver 47401300.usb-phy: 47401300.usb-phy supply vcc not found, using dummy regulator

                          [    2.057993] am335x-phy-driver 47401b00.usb-phy: 47401b00.usb-phy supply vcc not found, using dummy regulator

                          [    7.824009] Generic PHY 4a101000.mdio:04: attached PHY driver [Generic PHY] (mii_bus:phy_addr=4a101000.mdio:04, irq=POLL)

                          ………

                          debian@beaglebone:~$ dmesg | grep phy

                          [    0.000000] Booting Linux on physical CPU 0x0

                          [    2.425604] libphy: Fixed MDIO Bus: probed

                          [    2.481775] davinci_mdio 4a101000.mdio: detected phy mask ffffffef

                          [    2.496055] libphy: 4a101000.mdio: probed

                          [    2.496086] davinci_mdio 4a101000.mdio: phy[4]: device 4a101000.mdio:04, driver Atheros 8035 ethernet

                          [    2.506836] 47401300.usb-phy supply vcc not found, using dummy regulator

                          [    2.513461] 47401b00.usb-phy supply vcc not found, using dummy regulator

                          [   21.798813] Atheros 8035 ethernet 4a101000.mdio:04: attached PHY driver [Atheros 8035 ethernet] (mii_bus:phy_addr=4a101000.mdio:04, irq=-1)

                           

                          • April 23, 2018 at 5:09 pm #5211
                            Neeraj Dantu
                            Moderator

                              Mike,

                              That was good info. We went and looked at the kconfig files of Debian and Ubuntu images and it looks like the kernel in the Debian image was setup to load the 8035 driver as a kernel module vs the kernel in the Ubuntu image was not (These files can be found in /boot folder):

                              Ubuntu (config-4.14.34-ti-r43)
                              #
                              # MII PHY device drivers
                              #
                              # CONFIG_AMD_PHY is not set
                              # CONFIG_AQUANTIA_PHY is not set
                              # CONFIG_AT803X_PHY is not set
                              # CONFIG_BCM7XXX_PHY is not set
                              # CONFIG_BCM87XX_PHY is not set
                              # CONFIG_BROADCOM_PHY is not set
                              # CONFIG_CICADA_PHY is not set
                              # CONFIG_CORTINA_PHY is not set
                              # CONFIG_DAVICOM_PHY is not set
                              CONFIG_DP83848_PHY=y
                              CONFIG_DP83867_PHY=m
                              CONFIG_FIXED_PHY=y
                              # CONFIG_ICPLUS_PHY is not set
                              # CONFIG_INTEL_XWAY_PHY is not set
                              # CONFIG_LSI_ET1011C_PHY is not set
                              # CONFIG_LXT_PHY is not set
                              # CONFIG_MARVELL_PHY is not set
                              # CONFIG_MARVELL_10G_PHY is not set

                              Debian (config-4.9.82-ti-r102)
                              #
                              # MII PHY device drivers
                              #
                              CONFIG_AMD_PHY=m
                              CONFIG_AQUANTIA_PHY=m
                              CONFIG_AT803X_PHY=m
                              CONFIG_BCM7XXX_PHY=m
                              CONFIG_BCM87XX_PHY=m
                              CONFIG_BCM_NET_PHYLIB=m
                              CONFIG_BROADCOM_PHY=m
                              CONFIG_CICADA_PHY=m
                              CONFIG_DAVICOM_PHY=m
                              CONFIG_DP83848_PHY=y
                              CONFIG_DP83867_PHY=m
                              CONFIG_FIXED_PHY=y
                              CONFIG_ICPLUS_PHY=m
                              # CONFIG_INTEL_XWAY_PHY is not set
                              CONFIG_LSI_ET1011C_PHY=m
                              CONFIG_LXT_PHY=m
                              CONFIG_MARVELL_PHY=m
                              CONFIG_MICREL_PHY=y
                              CONFIG_MICROCHIP_PHY=m
                              CONFIG_MICROSEMI_PHY=y
                              CONFIG_NATIONAL_PHY=m
                              CONFIG_QSEMI_PHY=m
                              CONFIG_REALTEK_PHY=m
                              CONFIG_SMSC_PHY=y
                              CONFIG_STE10XP=m
                              CONFIG_TERANETICS_PHY=m
                              CONFIG_VITESSE_PHY=y

                              This is pretty conclusive evidence. We have not tried it, but once you modify your kconfig file to load the driver for Atheros 8035 PHY during the building process, the image should function normally. This has also been notified to Beagleboard Ubuntu maintainers.

                              Thanks,

                              Neeraj

                            • April 24, 2018 at 2:13 pm #5212
                              Neeraj Dantu
                              Moderator

                                Mike,

                                The kernel has been patched: https://github.com/RobertCNelson/ti-linux-kernel-dev/commit/6643bcf15b1379c5bbcde801106b5b65f04df058#diff-ba79210cd3316674807a5388d265a3f2 

                                Note that the patch is for 4.14.36-ti-r45 kernel

                                • This reply was modified 6 years, 8 months ago by Neeraj Dantu.
                          • Author
                            Posts
                          Viewing 7 reply threads
                          • You must be logged in to reply to this topic.

                          Octavo Systems LLC all rights reserved
                          OCTAVO is registered in the U.S. Patent and Trademark Office. OSD, C-SiP, and the Octavo Logo are trademarks of Octavo Systems LLC.