I did not watch all of this. Some comments:
- The Mac should work fine for using Etcher and creating the SD card.
- Unless it runs Linux, then the Mac probably is not going to succeed when running JetPack/SDK Manager. A VM will possibly work, but they are problematic.
- Looking at your last screenshot, everything succeeded up to the point of “first boot user account setup”. It simply is not triggering letting you log in. You would have reached this point much sooner than 24 hours (maybe 20 minutes?), and this is where it fails: It needs to show a login user setup screen. The GUI should have triggered for this.
- SD card is only part of the install. In this case I don’t think the other part matters, but it might. More on that later.
Alternatively, the serial console should allow first boot setup. Or even just rebooting might trigger going to account setup. Serial console is interactive, and uses your host PC for display (and a Mac works for that, but I don’t know the details of what serial device or program to use), and so it works even when GUI and much of the system fails. Anyone doing any development at all on any Jetson is going to want a serial console UART cable, and they are inexpensive, so that is your next step if simply rebooting it doesn’t result in the prompt going to first boot setup. The UART cable to get is for 3.3V (TTL level), and setting is 115200 8N1. More on that here:
https://www.jetsonhacks.com/2019/04/19/jetson-nano-serial-console/
The history on first account setup is that California set up laws preventing shipping many devices with a default user name and password. First boot setup is so that the user sets that up. If it fails, there is a second method which is very reliable. However, that involves the install step I mentioned above which is really the other half of installing.
Most embedded devices, including Jetsons, don’t have an actual BIOS (which would use power and cost more and make it larger). Instead, that content is performed with software, and is part of flash. The SD card is just the operating system partition. Bootloader and the equivalent of BIOS is actually in QSPI memory which is on the module itself. To update QSPI memory one would flash using JetPack/SDK Manager and an Ubuntu 18.04 host PC (amd64/x86_64).
If you were to run JetPack/SDKM (which is a GUI front end to install/flash software), then this would update the QSPI memory. On a non-SD card model there is eMMC, and this would also be how you would flash eMMC on a non-SD card model. There is a utility on the flash software capable of setting up the login name and password. The flash software home location would be at:
~/nvidia/nvidia_sdk/JetPack_...version.../Linux_for_Tegra/
Within that is “tools/l4t_create_default_user.sh”. This updates login setup directly to the o/s content before a flash. First boot would already be complete prior to ever booting for the first time. It operates on the content at “Linux_for_Tegra/rootfs/”. If you mount your SD card there, then it will make that update directly to the SD card and you can probably skip flashing the QSPI on the Jetson. You’d plug the SD card in to the host, mount it there, run “sudo ./l4t_create_default_user.sh”, unmount the SD to avoid corruption, and then remove it. Plug it in to the Nano, and boot. It should “just work”.
If not, then you do need to flash the QSPI using JetPack/SDKM. If it gets to that point, then you probably do need a native Ubuntu 18.04 install (probably the Mac works if it is native; many people dual boot).
Just ask if you need more information, but do mention if you have Linux running on the Mac. JetPack/SDKM has limitations on what host flavors of Linux it will run on, but command line typically works on a wider range of hosts, and the script you are interested in just uses command line (actually, flash is less dependent upon flavor of Linux, it is the GUI which is most dependent).
FYI, you SD card will have some particular L4T release (which is Ubuntu plus NVIDIA drivers). This is tied to a particular JetPack/SDKM release, so picking one picks the other. On your Mac https://developer.nvidia.com/linux-tegrayou can find the L4T release with the first line of the SD card file “/etc/nv_tegra_release”. You can then go here to get to the correct software to use with that release:
- (https://developer.nvidia.com/linux-tegra
- You would use the “driver package” and “sample rootfs”. This is the actual flash software without the GUI. You’d unpack the driver package without
sudo, as a normal user. Within that is the “Linux_for_Tegra/rootfs/” directory, and you’d go there and unpack the sample rootfs with sudo (you want root user permissions). Then you’d go back to “Linux_for_Tegra/”, and run “sudo ./apply_binaries.sh”. This is the full normal command line setup, and it is set to allow flash from then on via command line.
- Then you’d mount your SD card partition to “
rootfs/”, and from “Linux_for_Tegra/”, run “sudo ./tools/l4t_create_default_user.sh” (you might need to cd to “tools/” and run it there, not sure). Then umount the SD card, and boot again on the Jetson. It’ll probably “just work”.
Once there, things are easiest if you have an Ubuntu 18.04 host PC. Then you can just download and install JetPack/SDK Manager, which in turn downloads and unpacks everything for you. If not, then it isn’t much more difficult to manually unpack just the flash content (without the GUI). I’ve used the flash content on Fedora and several versions of Ubuntu which the GUI would not like (these days I just use Ubuntu). But you do need an actual Linux install, MacOS won’t work. Do you have Linux on the Mac?
I’ll add that almost all of the confusion is because things installed correctly, but without the serial console, you did not see the alternative first account setup. You really should have a serial UART cable (3.3V TTL level) if you want to work with the Jetson, it will make life much easier. Also, in most cases, it is advisable to flash the QSPI anyway right at the start (QSPI content handles several L4T release versions, but if mismatched, things don’t boot correctly; looks like yours did boot correctly, you just lack the GUI).
Incidentally, HDMI monitors can be queried via a wire in the cable such that the monitor tells the GPU what the monitor’s specs are. Sometimes HDMI televisions are a bit quirky in that response. The text output would succeed as it did, but if the monitor had quirks and prevented the GUI, then this might be the reason (and a different monitor might work). With the “l4t_create_default_user.sh” script having been run, you will get past first account setup, but if there are quirks with that monitor (television), then you might still have problems. Serial console logs would answer if that is going on (and would allow first account setup without the monitor, so serial console would have two chances to solve this).
