Can't Get my Jetson Nano to Display on Dell Monitor

I am new to the NVIDEA community. Just started using a Jetson Nano with a 5V 2.5A USB power supply (from adafruit) and trying to display through a DP cable to a DELL monitor. Monitor has power and my 16GB (U1) SD card has the image on it and it is inserted in the board. I haven’t had any luck at getting anything to show up on the monitors (I have tried two of them).

Any ideas on what I should try next in order to track down the solution to my issue?

Thanks!

Have the same problem. Brand new SD card, written as described,
power source is able to drive 2.5A.
Network is connected, HDMI full HD monitor, keyboard and mouse.
Green Led is on, but nothing happens.
With RPI I never had this kind of problem
Received it today, SN 0421219027011
Please let me now how to debug this.
Kasimir

it works now. SD card was corrupt

Thanks for letting me know. Were you able to re-flash the same SD card, or did you need to get a different one?

Let me know.

Thanks!

my SD card was flashed on Linux PC with dd ( as described )
Jetson was unable to boot from.
Then I made the following on Windows 7 PC:
1.) remove all existing partitions
2.) create 1 primary partition
3.) format with FAT32
4.) flash the image with Etcher

Then it worked fine ( 32GB SD card )
Good luck
Kasimir

Unless something has reformatted the VFAT into ext4 the install won’t work correctly. Non-Linux file systems do not understand Linux permissions (they have no concept of groups, SUID, SGID, sticky bits, device special files, so on). One example is that “sudo ls” would fail…if this works, then the flash process probably reformatted to ext4.

for my understanding Etcher works based on an image. File system, user & access rights are set in that image. Etcher overwrites all existing data, partitions and creates everything new based on that image data. That’s independent of the OS. As result you can see Linux file system, user and access rights on SD.
Are you agree with that? dd on Linux operates a little bit different, so my first try to create the SD failed.
Kasimir

If you were to copy an image directly, then you are correct. The reason I mention this:

3.) format with FAT32

In some cases JetPack or SDKM creates an image by first unpacking files into a file system. The image which is written uses the same file system where the files were unpacked at. If the image was created where any point in the chain FAT32 was used, then your image inherited FAT32 and won’t work. Did you verify the image created was really ext4 at every step?

If you can loopback mount the “Linux_for_Tegra/bootloader/system.img.raw”, and then look at the permissions of “usr/bin/sudo”, then you should see “-rwsr-xr-x 1 root root”. If “s” is missing, then you have FAT32 somewhere in the chain of building the image.

To add to this:

lsblk -f

Should list any block devices along with their mount points and types. vfat will indicate fat while ext4 is probably what you want under the MOUNTPOINT column under /

There ist absolutely no problem if you follow instructions to prepare and write the image on Windows OS. With dd on Linux I had bad luck. Everything is fine and works well. Independent of that, my BeagleBone is booting faster a lot. With one 1 core. Think there is room for optimisation.
Please close this thread, problem is solved.
Kasimir

Hi Kasimir,

Could you share the part number/brand name of that SDcard which is not compatible?

the SD card works fine, problem was dd.
At the first try I used dd on Linux as described.
Have got the expected messages, no error reported.
Then I made the following on Windows and it worked:
1.) remove all existing partitions
2.) create 1 primary partition
3.) format with FAT32
4.) flash the image with Etcher

Think it’s possible to skip 3., because Etcher creates a new partition table.

Kasimir

If Etcher is written properly, it should be possible to skip 1-3.

We’re you trying to flash the .zip with dd, by chance? Because that will succeed but not boot. Can you post the failed dd command you used?

clear, flash a .zip file is not a good idea :-) No, I did it as described with dd.
On my SD card was already a filesystem, think I used the card for BeagleBone.
Finally, I recommend to use Etcher, because it simply works.
Trying to get my myo sensors to work now …

Kasimir

Instructions to format with FAT32 may be incorrect if this refers to the rootfs partition (FAT32 is used with UEFI “efi” partitions). Jetsons don’t actually use or need an efi partition (there is no BIOS/UEFI, the magic is all moved into boot software stages prior to the kernel loading).

“dd” itself is about as close to flawless as software can get. What wouldn’t surprise me is if instructions were off when switching between different install methods. The earlier comment of checking with “lsblk -f” is still the correct thing to do. One would have to find out after the SD card setup is complete if the rootfs is “ext4” or something else. Anything “VFAT” or “FAT32” would fail to run correctly as a final result.

hello, I have a problem displaying the Jetson Nano display output to the monitor, I initially tried to use a monitor with the same VGA display input conversion to HDMI, at first the boot went smoothly without any problems until the NVIDIA logo appeared and I was able to log in to user registration, but when registration is complete and try to enter the desktop page my computer suddenly turns off, where the green light on the computer also dies, and on the monitor screen can not display anything there is only the writing no signal, I try to turn on my computer but unsuccessfully, I tried to reinstall my sd card again and tried the manual installation step but it still didn’t work. Do friends have a solution to my problem? I beg for your help, because this concerns my university graduation. Thank you

Powering off is usually due to a power requirement (the power must be quite stable). Going into a GUI mode requires more power. I suspect power regulation. Many adapters have minor changes in voltage during boot which most systems would not care about, but even tiny fluctuations during boot will be a problem. There are a number of steps to have better power delivery, e.g., shorter cables with thicker gauge, high capacitance added right at the connector (5000 to 10000 uF), power supplies with better regulators, so on.

Also, VGA is not supported (even with an HDMI adapter since the wire for auto configuration is missing on VGA and the driver has no way to know what is attached). There is a fallback mode if the driver cannot see what is there, but this is a hit and miss random issue as to whether that will work. Once power is stable you may find that in GUI mode the monitor no longer works.

I suspect power as well, but I may be biased as I had this issue yesterday. Either that or the monitor since if you do indeed mean VGA, that is not supported. Sorry this is happening as such a bad time :( Best wishes you get it solved. If the board is dead, Nvidia is nice about replacements.