Following the Nvidia Docs, I performed a successful manual flash to JP 6.22 Super on an Nvidia Jetson Orin nano carrier with an NX SOC and 256 GB Mvme. Everything works great.
The problem is that when powering up, after the Nvidia Splash Screens are displayed for 10 seconds, then there is 60 seconds of blank screen time before anything is seen on the monitor.
We have developed and immediately launch a custom C++ app that opens great to our custom menu in 2-3 seconds after boot. No complaints.
Well 60 seconds of no visual activity during startup is enough to make any lay customer think that the system didn’t start. And naturally they push the power button and pull the plug several times to no avail and walk away thinking the system doesn’t work.
I recall there was a long matrix like string of data scrolling in JP 6.1ish.
I recall editing sudo nano /boot/extlinux/extlinux.conf to silence the scroll. The customer didnt like the scroll, but the blank screen is worse, so we went back to the scroll.
I did read about altering the kernel to show custom splash screens, but why would they persist any longer than the current Nvidia splash screens (10 sec).
I see the problem with displaying a splash screen when the OS is not fully loaded.
What if anything can be done to show a custom splash screen (with progress bar) during the 60 seconds of JP6.22 video silence?
Worst case, how do I get the scrolling data from the Matrix Movie back?
— 🤖 This is an automated AI response. I’m here to help, but please verify important details! —
To address the issue of a dark display during boot on the Jetson Orin Nano with JP 6.22, the provided context does not offer a direct solution for displaying a custom splash screen with a progress bar during the 60 seconds of video silence. However, it mentions editing /boot/extlinux/extlinux.conf to silence the scroll, which implies that this file can be modified to change boot behavior.
Regarding the scrolling data (often referred to as the boot log), it can be re-enabled by modifying the /boot/extlinux/extlinux.conf file. To do so, you would need to comment out or remove any lines that suppress the boot log output. Typically, this involves removing or commenting out lines that contain quiet or loglevel=0 parameters in the kernel boot arguments.
Here’s a step-by-step approach based on the provided context:
Edit /boot/extlinux/extlinux.conf:
sudo nano /boot/extlinux/extlinux.conf
Modify the boot arguments:
Look for the line that starts with append and contains boot arguments. If you see quiet or loglevel=0, these are likely responsible for suppressing the boot log output. You can remove or comment out these parameters to re-enable the boot log display.
Save and reboot:
After saving the changes, reboot your Jetson Orin Nano to see if the boot log is displayed again during boot.
As for displaying a custom splash screen with a progress bar, the provided context does not offer a straightforward solution for JP 6.22. Custom splash screens typically require modifying the kernel or using specific tools and frameworks that might not be directly supported or documented in the provided context for the Jetson Orin Nano with JP 6.22.
Therefore, the most direct action based on the provided context is to re-enable the boot log display, which might provide some visual feedback during the boot process, even if it’s not a custom splash screen with a progress bar. For more advanced customization, such as a custom splash screen, further research into Jetson Orin Nano’s specific capabilities and limitations with JP 6.22, or exploring NVIDIA’s official documentation and forums, might be necessary.
— We support team will also look into your issue to have further suggestions soon. please stay tuned. —
mminit_loglevel=8, which is supposed to be the most verbose.
Then I added
video=efifb:on,
I even eliminated
console=ttyTCU0,115200
as I read that the order of the parameters might make a difference.
And so I ended up with
APPEND ${cbootargs} root=PARTUUID=c374eb33-9606-4719-ae9b-5194f9da70f2 rw rootwait rootfstype=ext4 mminit_loglevel=8 firmware_class.path=/etc/firmware fbcon=map:0 video=efifb:on console=tty0 efi=runtime pci=pcie_bus_perf nvme.use_threaded_interrupts=1
None of this brought the boot log to the main monitor.
To eliminate any issues with the monitor, I have tried it with a straight Display Port to Display Port 4K monitor.
Well, we fell back to a single DP 4K monitor that works well after booting and did an xrandr to find the name of the attached monitor and tried using that at the end of extlinux.conf as in
video=DP-0:3840x2160@30
Buit that didnt work…
Then I tried appending
ignore_loglevel initcall_debug earlycon
That didnt work either..
So I went to the 6.22 SDK docs looking for a readme file that might talk about it…
There was nothing about suppression of the boot log in readme 6.22, 6.21, 6.1 or 6.0
David here again. Did you know that if you clone a JP6.21 Mvme (with your application and preferences) from an 8 GB NX and pop it into a JP 6.22 16 GB Nvme slot that the boot log still doesn’t show up on the Main Monitor, even though the Jetpack shows it has been rolled back to 6.2.1 when running sudo apt show nvidia-jetpack -a
But if you re-flash that same JP 6.22 16 GB SOC with JP 6.21 that you DO IN FACT GET THE BOOT LOG DISPLAYED on the Main Monitor !!!
Further, if you take yourJP6.21 Nvme from an 8 GB NX and pop it into a JP 6.22 16 GB Nvme slot after the SOC has been freshly re flashed to 6.2.1 that the boot log shows up on the main monitor!! And your cloned application works great…
That must mean that the Boot Log to Main Monitor Display is not controlled by extlinux.conf file as the lovely and always gracious carolyuu had kindly suggested. Seems that in JP 6.22 the display boot log to the main monitor is actually buried in the SOC somewhere.
David.AI is just me talking to myself in this empty room. LOL a tongue in cheek poke at carolyuu. I suppose I should expect an AI company to put a bot in here.
Thanks for the info on JP 7.2
Since this a developer forum, I think maybe production issues, like splash screens are not front and center.
So lets look for a hardware solution where a monitor displays a custom splash screen until a GPIO bit stops it. Thinking an Arduino static splash screen that happens at power up. Then the Jetson asserts a bit and the Arduino changes the DP stream to the Jetson.