• State TI Thinks Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 3 answers
  • Subscribers 98 subscribers
  • Views 1335 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Issue of network on GLSDK

yangwoo Lee
Intellectual 910 points

Hello.

Im working with GLSDK on Jacinto 6

Recently I applied SPL boot as to below. Accurately, It is qspi boot working without u-boot stage(only work SPL and kernel)

http://processors.wiki.ti.com/index.php/DRA7xx_GLSDK_Software_Developers_Guide#Using_the_Late_attach_functionality

After apply it, I couldn't access SSH server of host side(jacinto6). I guessing it because of no u-boot stage.

The reason I think this is, I saw same situation when I remove all network feature in config file in u-boot.

Please help me. How can I alive network again? below is log

INIT: version 2.88 booting
Starting Bootlog daemon: bootlogd: cannot allocate pseudo tty: No such file or directory
bootlogd.
INIT: Entering runlevel: 5
Starting tiipclad daemon
Opened log file: lad.txt

Spawned daemon: /usr/bin/lad_dra7xx

Sending discover...
Sending discover...
Sending discover...
No lease, forking to background
done.
Starting Dropbear SSH server: dropbear.

root@dra7xx-evm:~# ifconfig
eth0 Link encap:Ethernet HWaddr C6:8C:87:D2:FD:9A
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:7019 errors:0 dropped:0 overruns:0 frame:0
TX packets:59 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:543887 (531.1 KiB) TX bytes:20178 (19.7 KiB)
Interrupt:78

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:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

root@dra7xx-evm:~#

  • 0
    TI__Mastermind 29520 points

    Hello Yangwoo,

    Let's start with the definition of Late attach functionality:

    To satisfy the startup time requirements of specific use cases, one would need a remote core booted up early at the boot loader before the Linux kernel is booted. The kernel then attaches with the already booted remote core for further communication. We refer to this feature as the "Early Boot - Late Attach" functionality.

    Could you check the functionality of late_attach:

    target # dmesg | grep late_attach
[   13.387830]  remoteproc1: late_attach is 1

    My suggestion is to take a detail look on a similar thread - https://e2e.ti.com/support/omap/f/885/t/391870

    You can try using new u-boot image - 3755.u-boot.zip

    Best regards,

    Yanko

  • 0 in reply to Yanko Todorov-XID
    Intellectual 910 points

    Thank you for answer Yanko

    But I don't know your suggestion is good approach or not.

    because my question was about network is not available in QSPI spl boot.

    except network problem, everything is working including remoteprc test(IPU1,2 DSP1,2)

    Why you suggest late attach ?

    Anyway I applied late attach for you in short time.

    but I saw another problem in late attach... there was no attached message

    root@dra7xx-evm:~# dmesg | grep late_attach
    [    6.139856]  remoteproc3: late_attach is 0
    [    6.382567]  remoteproc2: late_attach is 0
    [    6.733915]  remoteproc0: late_attach is 0
    [    6.766229]  remoteproc1: late_attach is 0

    below is log about error with late attach.

     

  • 0 in reply to yangwoo Lee
    Intellectual 910 points
    Sorry I had small misunderstood about your suggestion.
    Anyway below my late attach result of qspi spl boot
    root@dra7xx-evm:~# dmesg | grep late_attach
    [ 2.831971] remoteproc3: late_attach is 0
    [ 2.962444] remoteproc2: late_attach is 0
    [ 3.614248] remoteproc0: late_attach is 0
    [ 3.636176] remoteproc1: late_attach is 1
  • 0 in reply to Yanko Todorov-XID
    Intellectual 910 points
    Hello Yanko.Really this system has some dependency with u-boot and kernel.
    Related to this issue, network initialization has same relation.
    If I set network feature in u-boot, like below, network is working also in kernel.
    But when I remove below configuration in u-boot(include/configs/dra7xx_evm.h), network is also not working in kernel.
    Really it has dependency in this system. for example, I guessing, kernel has insufficient initialization for network because without uboot network initialize, kernel network also not work.
    Please fix this issue, and give some patch of kernel. /* CPSW Ethernet */
    #define CONFIG_CMD_NET /* 'bootp' and 'tftp' */#define CONFIG_CMD_DHCP
    #define CONFIG_BOOTP_DNS /* Configurable parts of CMD_DHCP */
    #define CONFIG_BOOTP_DNS2#define CONFIG_BOOTP_SEND_HOSTNAME
    #define CONFIG_BOOTP_GATEWAY#define CONFIG_BOOTP_SUBNETMASK
    #define CONFIG_NET_RETRY_COUNT 10#define CONFIG_CMD_PING
    #define CONFIG_CMD_MII#define CONFIG_DRIVER_TI_CPSW /* Driver for IP block */
    #define CONFIG_MII /* Required in net/eth.c */
    #define CONFIG_PHY_GIGE /* per-board part of CPSW */#define CONFIG_PHYLIB
  • 0 in reply to yangwoo Lee
    Intellectual 910 points
    It solved by ethaddr of bootenv.
    The problem caused by no ethaddr bootenv. For example if I bootup with network feature of u-boot, ethaddr bootenv is automatically applied. Without u-boot network initialize, kernel can't find ethaddr bootenv. So I added fixed "ethaddr=??:??:??:??:??:??\0" to ti_omap5_common.h. Now network is working without u-boot network config.
  • 0 in reply to yangwoo Lee
    TI__Mastermind 29520 points

    Hello Yangwoo,

    I am glad to hear that.
    For your information, you can take a look on following threads:
    processors.wiki.ti.com/.../AM335x_U-Boot_User's_Guide#U-Boot_Network_configuration
    lists.denx.de/.../149291.html
    processors.wiki.ti.com/.../Linux_Core_U-Boot_User's_Guide

    https://e2e.ti.com/support/embedded/linux/f/354/t/141507


    Best regards,
    Yanko

  • 0 in reply to Yanko Todorov-XID
    Intellectual 910 points
    Sorry It was not solution. I confused with mmc partion 1 and 2.
    It still not working without u-boot initialization
  • 0 in reply to yangwoo Lee
    Intellectual 910 points
    Finally I add "#defineCONFIG_DRIVER_TI_CPSW" in u-boot with "ethaddr=??:?:??:??" of bootenv. after then it working now.
    Anyway still I need kernel patch to activate kernel network without u-boot dependency. because uboot spl will not excute any network feature.
  • 0 in reply to yangwoo Lee
    TI__Mastermind 29520 points
    Yangwoo,

    CONFIG_DRIVER_TI_CPSW is defined in u-boot/board/ti/dra7xx/evm.c:
    #ifdef CONFIG_DRIVER_TI_CPSW
    #include <cpsw.h>
    #endif

    #ifdef CONFIG_DRIVER_TI_CPSW

    /* Delay value to add to calibrated value */
    #define RGMII0_TXCTL_DLY_VAL ((0x3 << 5) + 0x8)
    #define RGMII0_TXD0_DLY_VAL ((0x3 << 5) + 0x8)
    #define RGMII0_TXD1_DLY_VAL ((0x3 << 5) + 0x2)
    #define RGMII0_TXD2_DLY_VAL ((0x4 << 5) + 0x0)
    #define RGMII0_TXD3_DLY_VAL ((0x4 << 5) + 0x0)
    #define VIN2A_D13_DLY_VAL ((0x3 << 5) + 0x8)
    #define VIN2A_D17_DLY_VAL ((0x3 << 5) + 0x8)
    #define VIN2A_D16_DLY_VAL ((0x3 << 5) + 0x2)
    #define VIN2A_D15_DLY_VAL ((0x4 << 5) + 0x0)
    #define VIN2A_D14_DLY_VAL ((0x4 << 5) + 0x0)

    Take a look on this patch set: comments.gmane.org/.../165201

    Best regards,
    Yanko
  • 0 in reply to Yanko Todorov-XID
    Intellectual 910 points
    Below updated modification.
    Please check condition. It looks related with dpll clock setting. Can you check kernel dpll clock setting for gmac?
    I expect that kernel dpll for gmac is not perfect.
  • 0 in reply to yangwoo Lee
    Intellectual 910 points
    I remove " CONFIG_DRIVER_TI_CPSW"
    and only remain below code in arch/arm/cpu/armv7/omap-common/clocks-common.c
    params = get_gmac_dpll_params(*dplls_data);
    do_setup_dpll((*prcm)->cm_clkmode_dpll_gmac, params, DPLL_LOCK, "gmac");