File size: 6,697 Bytes
6c7b14a
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
Ticket Name: Issue of network on GLSDK

Query Text:
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:~#

Responses:
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

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.

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

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

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.

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

Sorry It was not solution. I confused with mmc partion 1 and 2. It still not working without u-boot initialization

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.

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

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.

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");