Hello. We are using L4T 32.7.5 for both nano and xavier nx boards and NFS boot is really important for the application.
Right now we are using connectech quark board and our own board that is based on devkit board.
We get into NFS boot by editing extlinux.conf
NFS boot works correctly on from the LAN NFS server for:
Nano+our board, using usb2eth chip.
Nano+connetech quark using PCIE onboard ETH.
Xavier+connetech quark board using PCIE onboard ETH.
NFS boot does not work on:
Xavier+ our board using usb2eth chip.
Procedure goes like:
- Setup NFS rootfs on linux host pc
- edit extlinux.conf with the appropriate settings
- if system is xavier sign the extlinux.conf with tegrasign thingy
- rewrite exlinux.conf in the emmc for the nano/xavier modules, if module is xavier also add signature file
- reboot
- system boots to rootfs over LAN
extlinux.conf APPEND lines that we use:
the $MY_IP and so on are generated during generation of the extiliux.conf files, quite obvious what those are.
nano+ our board
APPEND \${cbootargs} root=/dev/nfs rw netdevwait ip=:::::eth1:on ip=:::::eth1:on nfsroot=$MY_IP:$NFS_RFS_PATH console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 sdhci_tegra.en_boot_part_access=1
nano+ connectech quark board
APPEND \${cbootargs} root=/dev/nfs rw netdevwait ip=:::::eth0:on nfsroot=$MY_IP:$NFS_RFS_PATH console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 sdhci_tegra.en_boot_part_access=1
xavier+ connectech board
APPEND \${cbootargs} root=/dev/nfs rw netdevwait ip=:::::eth1:on nfsroot=$MY_IP:$NFS_RFS_PATH console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 sdhci_tegra.en_boot_part_access=1
xavier + our board that doesnt work
APPEND \${cbootargs} root=/dev/nfs rw netdevwait ip=:::::eth0:on ip=:::::eth1:on nfsroot=$MY_IP:$NFS_RFS_PATH console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 sdhci_tegra.en_boot_part_access=1
This should have DHCP on both eth0 and eth1 so the board can easily connect to the LAN NFS, but it doesnt.
I tried booting to the emmc root FS and checked dmesg to deduce the problems. What we do in our distro is we rename ethernet interfaces with sytemD after the boot into emmc, for consistency with hardware layouts. I can clearly see comparing nano dmesg to xavier dmesg when paired with the usb2eth chip that in dmesg from nano the smsc95xx is loaded at 1.6 seconds in the boot, meanwhile on xavier smsc95xx is only loaded by systemd. This begs a question, is it possible that the extlinux environment for xavier does not load smsc95xx driver?
If so how can i make it so the driver is loaded.
For the boards we use flash.sh conf files from nvidia and connectech:
nano+our board:
./flash.sh --no-root-check jetson-nano-emmc mmcblk0p1
nano+connectech quark:
./flash.sh --no-root-check base-nano mmcblk0p1
xavier+connectech:
./flash.sh --no-root-check base-xavier mmcblk0p1
xavier+our board (THIS IS THE ONE THAT DOES NOT SEE smsc95xx in bootloader or is not capable of using it):
./flash.sh $1 --no-root-check jetson-xavier-nx-devkit-emmc mmcblk0p1
The dmesg outputs for the boards after booting into emmc can be seen here, plus i added the serial ouput from xavier+our board when its booting into emmc, im no expert expert in this but it looks like smsc95xx is loaded not in bootloader but in the rootfs, thats why it cant get DHCP and boot into NFS when using the extlinux command i shown above. I hope you understand what our issue is and know how this can be fixed :)
dmesg xavier-e1350-NFSBROKEN.log (60.6 KB)
dmesg-CTI-xavier-nfsCapable.log (58.3 KB)
dmesg-nano-e1350-nfsCapable.log (58.4 KB)
xavier-e1350-serial-NFSBROKEN.log (39.1 KB)
we use this procedure to update full rootFS over eth port, if theres another way to do so, over eth to rewrite full rootFS on l4t 32.7.5 then i am glad to hear out what other way we can do so if there is no solution for the smsc95x. We need to do this over smsc95x because we have deployed systems with the boards where nvidias integrated eth is not accessible from the outside, only smsc95x.