Booting TX2 via NFS

Autonomous Machines Jetson & Embedded Systems Jetson TX2
#1

Hello
I want to boot TX2 by NFS. When i use this command :
sudo ./flash.sh -n 192.168.1.5:192.168.1.3:192.168.1.1:255.255.255.0 -N 192.168.1.3:/home/tx2/nfsroot jetson-tx2 eth0

When the flash is done, After resetting the board, i expected to see a message about completing the configuration via /dev/ttyACM0. like when i flash the board for eMMC : sudo ./flash.sh jetson-tx2 mmcblk0p1. But this step does not exist and Board boots from NFS. Because the config process is not done, I did not specify a usrname and pass and so I cannot log in. I’ve tested nvidia/nvidia and ubuntu/ubuntu.
To solve this problem, I did an irrational way: Flashing the board and booting from eMMC, Copy the /etc directory from within the eMMC instead of the 
/L4T/rootfs/etc directory!!! And then I logged in with the username and password I entered in the config phase after flashing the board for emmc!!!

And that’s where the trouble began!
When I enter the following command to view the camera image on the EVM via HDMI :
DISPLAY=:0.0 gst-launch-1.0 videotestsrc ! ‘video/x-raw(memory:NVMM), width=1920, height=1080, format=(string)NV12, framerate=(fraction)30/1’ ! nvoverlaysink -e
I see the error below :
libcuda.so.1: cannot open shared object file: No such file or directory
Then i run “sudo ldconfig”. and this problem was fixed. But i see the following error now :
No protocol specified
No protocol specified
No protocol specified
No protocol specified
No protocol specified
nvbuf_utils: Could not get EGL display connection
Setting pipeline to PAUSED 

Pipeline is live and does not need PREROLL 

Setting pipeline to PLAYING 

(Argus) Error FileOperationFailed: Connecting to nvargus-daemon failed: No such file or directory (in src/rpc/socket/client/SocketClientDispatch.cpp, function openSocketConnection(), line 201)
(Argus) Error FileOperationFailed: Cannot create camera provider (in src/rpc/socket/client/SocketClientDispatch.cpp, function createCameraProvider(), line 102)
Error generated. /dvs/git/dirty/git-master_linux/multimedia/nvgstreamer/gst-nvarguscamera/gstnvarguscamerasrc.cpp, execute:526 Failed to create CameraProvider
New clock: GstSystemClock
Got EOS from element “pipeline0”.
Execution ended aexport DISPLAY=:0

I use this gst pipe when the board booted from eMMC and it works well.

Please Help Me!

Fixing the issue of configuring the board when flashing for NFS
Fixing problem with links and libraries and modules

#2

Hi,

Something to clarify here.

  1. We notice there are some bugs in bootloader so that boot from NFS for TX2 should not work.

  2. It requires a monitor to configure your user account/password. Do you have a monitor?

#3

Also, may I know how you got this flash command? I don’t see it in our document.

#4

Hi WayneWWW,

Also, may I know how you got this flash command? I don’t see it in our document.

In 
/Linux_for_Tegra/flash.sh

-n -------- Static nfs network assignments :::

-N --------- i.e. :/my/exported/nfs/rootfs

#5

Hi WayneWWW, Thanks for your reply.

  1. It requires a monitor to configure your user account/password. Do you have a monitor?
    I have a monitor. I also connected a monitor to the board. But it is not possible to configure it either!
#6

I have a monitor. I also connected a monitor to the board. But it is not possible to configure it either!

May I know why? Why you cannot configure it?

#7

1- “I flash the board for eMMC” :
In the first boot I see a message about completing the configuration via /dev/ttyACM0. So I can set the password and username

2- “I flash the board for eth0” "
In the first boot the device does not send a message to complete the configuration. After the flashing is completed, the board resets and then enters directly into the login screen. If i connect board to a HDMI monitor, i can see login page, but i have not any usr and pass!!!

I have both TX2 and Nano modules and the result is the same on both.
I also did these tests with two host system.

Please Help me!!!

#8

You might want to run this script on the rootfs at the NFS server side:
https://devtalk.nvidia.com/default/topic/1054926/jetson-nano/jetson-nano-all-usb-ports-suddenly-stopped-working/post/5356153/#5356153

Note that during boot it is possible an initial ram disk (initrd) is being used for catching the first boot, and that if your NFS served files do not have both the rootfs changes needed and the initrd changes as well, then there might be differences in booting related to the differences in initrd. I am thinking that perhaps (I don’t know for certain) there is initrd content still stored on the Jetson outside of the rootfs. I have not checked changes to initrd from older releases to current releases, but much content ended up being moved out of the rootfs and into other partitions when earlier boot stages needed that content.

1 Like
#9

Hi linuxdev

Thank you verrrrrryyyyyyyyyy much!!!

#10

Now my TX2 boot through NFS. But it takes a long time.
In this step :
[ 21.576851] using random self ethernet address
[ 21.576856] using random host ethernet address
[ 29.418220] using random self ethernet address
[ 29.422760] using random host ethernet address

How can i set static ip in u-boot? Because I don’t want to install DHCP on the Host

I flash my board by this commnd:
sudo ./flash.sh -n 192.168.1.5:192.168.1.3:192.168.1.1:255.255.255.0 -N 192.168.1.3:/home/tx2/nfsroot jetson-tx2 eth0

When the board boots, eth0 has ip=192.168.1.5.

#11

If you use the serial console, and drop into the U-Boot shell, then you can examine or set various environment variables. Those variables are used as macro expansion. When booting you should see this, and then hit a key to halt boot:

U-Boot 2016.07-g0eb73f4 (Mar 13 2019 - 00:20:34 -0700)

TEGRA186
Model: NVIDIA P2771-0000-500
DRAM:  7.8 GiB
MC:   Tegra SD/MMC: 0, Tegra SD/MMC: 1
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   eth0: ethernet@2490000
Hit any key to stop autoboot:  0 
Tegra186 (P2771-0000-500) #

The command “help” shows a number of commands. If you set a variable, but do not save, then the edit is only for that one boot. Running the command “boot” continues boot. If you like the edit, then you can “saveenv” and the change will persist.

An example help command:

Tegra186 (P2771-0000-500) # help dhcp
dhcp - boot image via network using DHCP/TFTP protocol

Usage:
dhcp [loadAddress] [[hostIPaddr:]bootfilename]

This is a command, not a macro. However, if you examine the system’s environment via “printenv”, you’ll notice some interesting macros. I am not certain which ones you will be interested in, but here are some interesting macros/variables (note that “echo” naming a macro prefixed with dollar sign “$” also prints an environment variable):

boot_targets=mmc1 mmc0 usb0 <b>pxe dhcp</b>

distro_bootcmd=for target in ${boot_targets}; do run <b>bootcmd_${target}</b>; done

bootcmd_pxe=run boot_net_usb_start; run boot_net_pci_enum; <b>dhcp</b>; if pxe get; then pxe boot; fi

bootcmd_dhcp=run boot_net_usb_start; run boot_net_pci_enum; if dhcp ${scriptaddr} ${boot_script_dhcp}; then source ${scriptaddr}; fi;setenv efi_fdtfile ${fdtfile}; setenv efi_old_vci ${bootp_vci};setenv efi_old_arch ${bootp_arch};setenv bootp_vci PXEClient:Arch:00011:UNDI:003000;setenv bootp_arch 0xb;if dhcp ${kernel_addr_r}; then tftpboot ${fdt_addr_r} dtb/${efi_fdtfile};if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r}; else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi;fi;setenv bootp_vci ${efi_old_vci};setenv bootp_arch ${efi_old_arch};setenv efi_fdtfile;setenv efi_old_arch;setenv efi_old_vci;

Note that many of these macros simply test for possible optional choices, and that you could edit out choices which you know you do not use, e.g., if no USB network dongle, you could remove that. Certainly you could skip the PCI enumeration if you don’t use a PCI NIC. Instead of running the dhcp command, you could add an argument to the dhcp command (see earlier “help dhcp”) to specifically name the IP address. Or you could switch to a tftpboot command (see “help tftpboot”). I have not actually tested this so I couldn’t tell you the specific changes needed, but this is the interface from which to do so.

See also “help setenv”. You could for example:

setenv -f server_address 192.168.1.5
setenv -f server_netmask 255.255.255.0


which would mean any occurrence of “{server_address}" or "{server_netmask}” would substitute your values (you’d need to “saveenv” for this to save across boots, but if you only add new items and don’t modify anything else, then there is no reason to not “saveenv” for that step). You’ll have to experiment with that, but if you use serial console, then you’ll be able to see what actually goes on at the moment you run the “boot” command.

#12

Thanks linuxdev
I will try it