log file seems corrupted that could not be opened.
orin_log_jetson.txt (59.5 KB)
Hi!
I hope this helps. Thanks again!
What is the behavior or hardware signal at this moment? Reset pin/MDIO/MDC sitauion.
Are you sure this driver really in use in our default kernel?
Please check if the activity is happened in UEFI or kernel.
I expect activity should happen in kernel but not UEFI.
We see this activity during UEFI , but not during when kernel takes control. Then, it immediately stops and MDC and MDIO lines are stagnant
Could you use tricks to disable eqos in UEFI dtb only but keeps it enabled in kernel?
I would like to see what would happen in hardware signal here.
Go to check your flash board config.
TBCDTB_FILE is for UEFI to read.
DTB_FILE is for kernel to use.
Default setting is that these two are equal.
Need to disable EQOS in TBCDTB_FILE dtb so that UEFI won’t have EQOS.
Then setting EQOS as enabled in DTB_FILE sot that kernel would still have EQOS.
RAMCODE=4;
BPFDTB_FILE=“tegra234-bpmp-3701-0008-3737-0000.dtb”;
DTB_FILE=“tegra234-p3737-0000+p3701-0008-nv.dtb”;
TBCDTB_FILE=“${DTB_FILE}”;
BADPAGEFILE=“bootloader/badpage.bin”;
EMMC_CFG=“flash_t234_qspi_sdmmc_industrial.xml”;
FSIFWFILE=“bootloader/fsi-lk.bin”;
Just to be clear, would you like for me to create another dtb for TBCDTB and disable eqos there? Then and modify the same in Linux_for_Tegra and board config and flash onto the board?
Yes, that would make UEFI won’t touch eqos so that your hardware signal would only have kernel side activities.
Hi!
We tried the above as described. It did boot, but ethernet node, eqos, mdio keywords aren’t present at all (sudo dmesg) and there is no activity.
board_conf_flash.txt (3.8 KB)
Oh. Sorry about that. This just reminds me that some of the items that eqos needed are only handled by the UEFI. For example, MAC address is handled by UEFI and then pass to kernel.
Thus, we could not disable EQOS in UEFI here.
Let’s change this to another way. For example, let nvethernet.ko got rmmod and modprobe again and see what is the signal result.
nvethernet_ko_logs.txt (2.3 KB)
Hello!
PFA our logs for the same. Thank you
I am not sure why you only shared me the log as what I requested is the hardware signal…
Hope you really understand what we are doing now. Want to check MDC/MDIO/RST signal situation with above method.
Even RST signal didn’t have anything toggled?
please also follow this post to dump register value.
Hi!
When we reboot we get the following on our logic analyser. The reset toggles continously when rmmod is issued and immediately stops when insmod is issued (sudo insmod nvethernet.ko)
Channel 5 is reset, Channel 6 is MDIO and Channel 7 is MDC.
We see MDIO activity after booting, occasionaly. During some reboots we see MDC activity (minimal, hardly a toggle) but this is inconsistent on every reboot.
We have attached the snippets as well as regdump.
Thank you so much!
orin@orin:~$ sudo busybox devmem 0x02434070
[sudo] password for orin:
0x00000150
orin@orin:~$ sudo busybox devmem 0x02434078
0x00000000
orin@orin:~$ sudo busybox devmem 0x02445018
0x00002400
orin@orin:~$ sudo busybox devmem 0x02445010
0x00002400
orin@orin:~$ sudo busybox devmem 0x02445008
0x00002400
orin@orin:~$ sudo busybox devmem 0x02445000
0x00002400
orin@orin:~$ sudo busybox devmem 0x02445068
0x00002400
orin@orin:~$ sudo busybox devmem 0x02445040
0x00002458
orin@orin:~$ sudo busybox devmem 0x02445030
0x00002458
orin@orin:~$ sudo busybox devmem 0x02445028
0x00002458
orin@orin:~$ sudo busybox devmem 0x02445020
0x00002458
orin@orin:~$ sudo busybox devmem 0x02445070
0x00002458
orin@orin:~$ sudo busybox devmem 0x02445060
0x00002458
orin@orin:~$ sudo busybox devmem 0x02445038
0x00002440
orin@orin:~$ sudo busybox devmem 0x02445048
0x00002400
orin@orin:~$ sudo busybox devmem 0x02445050
0x00002000
orin@orin:~$ sudo busybox devmem 0x022140a0
0x00000003
orin@orin:~$ sudo busybox devmem 0x02214080
0x00000001
This value is not correct for your interrupt pin.