Please provide the following info (check/uncheck the boxes after clicking “+ Create Topic”): Software Version
[+] DRIVE OS Linux 5.2.0
DRIVE OS Linux 5.2.0 and DriveWorks 3.5
NVIDIA DRIVE™ Software 10.0 (Linux)
NVIDIA DRIVE™ Software 9.0 (Linux)
other DRIVE OS version
other
Host Machine Version
[+] native Ubuntu 18.04
other
Hi,
I just flashed my Target from DriveWorks 10.0 to DriveOS v5.2.0. After the flashing I am trying to finalize the DriveAGX System Setup but my internet is not working and not able to setup the target.
Can you please help me debug this issue? Thanks in advance.
Hi @pola5392, I tried to fix the time using the RTC dongle. I see that system time is correct now. But It still is not connected to the network yet. Any ideas?
@rborad Could you provide screenshots of your terminal after running timedatectl ? It is possible that the time zone is wrong. If I remember correctly, on the Drive OS 5.2 there was only one time zone available.
I wrote this down on my documentation whenever I fixed this problem on my machine. It might be helpful for you but take it with a grain of salt because I am not sure how much of this really contributed to fixing my issue and these aren’t official nvidia instructions.
In order to be able to download anything from the internet you will need to sync the true time to the Xavier chip that you are using. The time zone is set to UTC by default; you don’t need to change the time zone. Also, don’t be confused if you run timedatectl list-timezones and don’t get any time-zones in return because the version of Ubuntu that you are working with does not include them.
Make sure that you set up the RTC module correctly by following the Hardware Quick Start Guide manual. The RTC module is used to keep track of time so if you cut power to the RTC module then you will need to reset the time again. Unless you use a NTP server but this would not be best practice. You have to keep in mind that the AGX is built to travel in vehicles and would not always have access to the internet to keep track of time.
In order to insure that the time dependent on the RTC, run timedatectl set-local-rtc 1
Now you can use timedatectl to set the time on the system. Note that the timezone is set to UTC so add 5 hours to the local time zone (Keep in mind this is different for your time zone) and use the command: sudo timedatectl set-time HH:MM:SS. Note that the hours are in 24hr format.
Now you will need to set the correct time on the RTC.
Use the bash shell to launch the canrtc.sh script and get the time as follows: sudo bash /usr/local/sbin/canrtc.sh set
Reboot your system and wait a couple of minutes for the computer to adjust to the real time.
Once you’ve done that, do a quick apt update to ensure that the time is in sync. You should get not erros and the flags should be “[GET]”
Also, how are you checking that you are connected to the internet? Are you using apt-get or ping? If so, could you share the output from the terminal?
Thank you for your reply @pola5392. You are right there is only one timezone. I am in PST timezone but i converted my current time to UTC. Is it a problem if my time is off by a few seconds?
Also, i am using both ping and apt-get update to check if device is connected to the network. I followed your instructions and confirmed that time in both my RTC as well as Target is in sync with UTC time. Still no luck
@VickNV, is there anything else I should be looking at? my eth0 port doesn’t have an IPv4 address (screenshot here). Is that a problem?
@SivaRamaKrishnaNV , thank you for the reply. Please find the picture attached here. As mentioned before. It was connected to the network when it was running DriveWorks 10.0 (same connections). Doesn’t work when i updated to DriveOS V5.2. I ran into this issue when I was trying to 1.4 Finalize Development Environment Setup. I tried to enable the display. My Display gets input from the Target but doesn’t display anything(blank screen). I am connected to the target using Minicom.
Did you want me to look at something specific from the link you shared above? It talks mostly about system requirements and HW setup. As mentioned before, I am using the setup that was connected to the Network when I was running DriveWorks10.0.
I tried flashing my target with DriveWorks 10.0 and see if it connects to the network like before. And it doesn’t. This is strange. It used to work before and now it doesn’t after flashing again. Target acquires ipv4 address but no connection when trying to ping 8.8.8.8. Also, Updated target time to UTC time.
Connections are same as before. Same Ethernet cable works great on my other computers.
Here is my network config info if it helps:
nvidia@tegra-ubuntu:~$ ip neighbour show
10.42.0.29 dev eth0.200 INCOMPLETE
192.168.0.1 dev enp4s0 FAILED
nvidia@tegra-ubuntu:~$ ip route list
default via 192.168.0.1 dev enp4s0 proto static metric 2048 linkdown
10.1.0.0/16 dev eth0 proto kernel scope link src 10.1.0.81
10.42.0.0/24 dev eth0.200 proto kernel scope link src 10.42.0.28
192.168.0.0/24 dev enp4s0 proto kernel scope link src 192.168.0.10 linkdown
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.200
192.168.12.0/24 dev hv0 proto kernel scope link src 192.168.12.4
192.168.200.48 dev eth0 scope link
224.0.0.0/4 dev eth0 proto static
nvidia@tegra-ubuntu:~$ route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default _gateway 0.0.0.0 UG 2048 0 0 enp4s0
10.1.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
10.42.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0.200
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 enp4s0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.12.0 0.0.0.0 255.255.255.0 U 0 0 0 hv0
192.168.200.48 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
224.0.0.0 0.0.0.0 240.0.0.0 U 0 0 0 eth0
nvidia@tegra-ubuntu:~$
This is different from the original topic. Could you create a new topic for the issue of installing DRIVE Software 10 back from DRIVE OS 5.2.0? Thanks.
Dear @rborad,
Please check Vick’s suggestion in Downgrade DRIVE OS 5.2.0 to DRIVE Software 10 if you want to migrate DRIVE OS 5.2.0 → DRIVE SW 10.0. Please file a new topic if it does not fix with relevant flashing logs.
