Hi @WayneWWW ,
I had given the target board name .But I missed while posting the command.
This was the command
sudo ./flash.sh -k LNX target board name mmcblk0p1.Full flash is working for me.
What error did you get there?
Hi @WayneWWW ,
Please see the error.
Error: Return value 13
Command tegradevflash_v2 --write DTB /home/vkchlt0280/Desktop/src/TX2_NX_SDK/Jetson_Linux_R32.6.1_aarch64/Linux_for_Tegra/bootloader/kernel_tegra186-p3636-0001-p3509-0000-a01.dtb
Failed to flash/read t186ref.
please always attach full log file.
Hi @WayneWWW ,
Sorry for the late reply.I will share the log.I have one more query regarding the boot time optimisation
I could reduce the boot time to ~9 sec
Currently the time taken by kernel and userspace is as follows,
systemd-analyze
Startup finished in 1.348s (kernel) + 3.015s (userspace) = 4.364s
multi-user.target reached after 2.680s in userspace
As per boot logs bootloader is taking around 4 sec to load.
bootloader+kernel+usersapce =~8.5sec
In Bootloader side I removed the delay for user prompt to stop autoboot.Initially bootloader was taking around 6sec to load and now it is 4sec
Can we do some more optimisation on bootloader side?
How much is the minimum boot time that a user can expect ? Kindly confirm.
Note that the full serial console boot log contains timestamps. This is how you find out where the time is spent.
Hi @linuxdev ,
I calculated the bootloader time from boot log . Time taken by kernel and userspace is calculated using systemd-analyze .I am not able to understand what all things can be disabled in bootloader section to optimize the time.Is it really possible to reduce bootloader time?Could you please guide me.Can we reduce the total boot time to < 5 sec ?
Hi @WayneWWW
Could you please tell me the lowest boot time that we can achieve in nvidia jetson tx2 nx? Can we reduce the total boot time to < 5 sec ?
Hi,
There is no such test on our side. So there is no such value I can tell.
Okay @WayneWWW .Can we do more optimization in cboot or tegraboot side[Bootloader side]? As per boot logs cboot is taking around 3sec.
You should post the full serial console boot log so others can see where the time is spent.
Note that it only takes 0.762 seconds to complete the MB2 stage (“master boot 2”…think of it as bringing up power rails and clocks through that point, and nothing can be avoided there).
I see a device tree issue:
[0001.425] I> tegrabl_gpio_driver_register: register 'max77620-gpio' driver
[0001.435] E> failed to read label property for node 150404: 13
[0001.442] E> failed to read reg property for node 150500: 13
[0001.449] E> failed to read reg property for node 150552: 13
[0001.455] E> failed to read label property for node 150636: 13
[0001.462] E> failed to read reg property for node 150704: 13
[0001.469] E> failed to read reg property for node 150776: 13
However, that only takes 44 millliseconds. Probably something could be removed from the device tree to remove part of that time (or perhaps fixed, but then it takes time to initialize it when valid). The point here is that this is how you find candidates for time reduction.
Loading the kernel and partition for it takes about 1 second, but that time is unavoidable. The part which occurs after MB2 takes about 3.2 seconds, but I don’t think there is much you can do. Then U-Boot offers its prompt. I don’t know how much time that takes, but if you set up the environment variable to not search for alternate boot devices (or to only search for one such device, e.g., if you think you might boot from SATA USB drive, then you could leave that search in and remove others), then you might be able to save a second; or not searching for any and not delaying for a second to allow dropping in to the U-Boot console (it might actually be CBoot on newer releases), another second might be saved.
Once Linux starts you begin seeing some more significant delays. There is the imx296 setup time, but if you don’t have an imx296 sensor, perhaps you could remove the driver (and/or device tree for it?). That might save you a quarter of a second at the first part of it, and another quarter of a second later on.
Ethernet setup takes some time because it depends on a DHCP server replying. Do you need networking? Pretty much everyone needs loopback, but disabling DHCP query of wired or Wi-Fi would save a couple of seconds.
Do consider that this is not a microcontroller appliance. This is a full computer. It has a caching filesystem, with a journal, so you can’t just yank the power; you also can’t expect it to be as fast as memory in some ROM which is hard wired. An ordinary microcontroller also does not have anywhere nearly as complex initial setup.
Note: If you don’t use the GUI, that’s the biggest boot time for something to remove.
Hi @linuxdev ,
Thank you for the response.I removed the user prompt delay (2 sec) and disabled the ethernet .I don’t need GUI.Hence gui is also disabled.But I didn’t change the the environment variable to not search for alternate boot devices .I will try this.
Hi @WayneWWW ,
I have seen in the below Nvidia document that ,we can optimise the boot time to approximately 3 seconds.But as per boot logs even the bootloader section itself is taking around 4 seconds.
https://docs.nvidia.com/jetson/archives/r34.1/DeveloperGuide/text/SD/Kernel/BootTimeOptimzation.html
Could you please comment on this?
I have a query in the systemd services.Please see the systemd-analyze blame results
~$ systemd-analyze blame
1.811s dev-mmcblk0p1.device
1.085s dev-zram0.device
1.069s dev-zram1.device
1.045s dev-zram2.device
1.022s dev-zram3.device
1.004s dev-zram4.device
994ms dev-zram5.device
953ms networkd-dispatcher.service
728ms nv-l4t-usb-device-mode.service
621ms alsa-restore.service
571ms NetworkManager.service
536ms nv.service
434ms systemd-rfkill.service
420ms containerd.service
337ms systemd-udev-trigger.service
314ms systemd-resolved.service
303ms nvphs.service
200ms ssh.service
196ms resolvconf-pull-resolved.service
187ms systemd-journald.service
176ms systemd-udevd.service
174ms networking.service
155ms systemd-logind.service
150ms nvfb-early.service
147ms user@1000.service
126ms ofono.service
116ms systemd-modules-load.service
111ms wpa_supplicant.service
101ms nvpmodel.service
93ms nv-l4t-usb-device-mode-runtime.service
89ms nfs-config.service
80ms systemd-journal-flush.service
78ms console-setup.service
77ms systemd-sysctl.service
74ms sys-kernel-config.mount
66ms systemd-tmpfiles-setup-dev.service
66ms kerneloops.service
64ms systemd-random-seed.service
59ms ubuntu-fan.service
55ms polkit.service
53ms resolvconf.service
44ms systemd-update-utmp.service
42ms rpcbind.service
30ms systemd-tmpfiles-setup.service
30ms dev-hugepages.mount
28ms pppd-dns.service
27ms sys-kernel-debug.mount
24ms systemd-user-sessions.service
23ms grub-common.service
20ms systemd-remount-fs.service
19ms bluetooth.service
17ms systemd-update-utmp-runlevel.service
16ms nvfb.service
14ms dev-mqueue.mount
13ms run-rpc_pipefs.mount
12ms kmod-static-nodes.service
9ms rtkit-daemon.service
I am not having a clear idea why dev-mmcblk0p1.device is taking aroud 2s.Can we reduce this time? Kindly help me
@WayneWWW what is the purpose of nvphs.service in Nvidia .sometimes it is also taking around 2sec. Can we remove this service?
Hi @WayneWWW ,
nvphs.service is taking around 2 sec only if containerd packages has been removed from nvidia.I am not sure whether this service is important one or not.If I remove the nvph.service nvpmodel service will take around 2 sec .How can we reduce the time taken by these services.can we really remove the nvphs.service? Kindly help me
This is probably something you could do without:
The above is what provides the virtual network device over ethernet (when flash installs optional packages this is how USB gets the IP address of 192.168.55.1; plus it is the example README file over the micro-B USB cable).
I will suggest that eMMC startup time is typical and not out of reason. The device itself has to have queries performed before partitions can be queried, and then the filesystem type has to be determined when examining partitions.
Hi @linuxdev,
Thank you for the response.Do you know the answer for the following query
"nvphs.service is taking around 2 sec only if containerd packages has been removed from nvidia.I am not sure whether this service is important one or not.If I remove the nvph.service nvpmodel service will take around 2 sec .How can we reduce the time taken by these services.can we really remove the nvphs.service? "
Hi,
We don’t guarantee it would be fine to remove this.