The smaller port is actually an “On the Go” USB port (“OTG”). USB is a one-way connection, and one end is always a device, the other is always a host. If a type-A connector is used, that end is always a host; if a type-B connector is used, that end is always a device. The connector you see on a mouse or keyboard is a type-A, with the type-B being embedded within the device; Jetsons just use a discrete cable. The OTG port is unusual in the ability to accept either of a type-A or type-B micro USB connector; however, there is an ID pin, and the Jetson knows which type is plugged in.
All Jetsons with a micro OTG connector allow a type-B device mode. In recovery mode, only a type-B connector makes sense because a recovery mode Jetson can only be a device, not a host. I think a Nano does not have any host mode software to run as a host even if you were to use a type-A connector (charger cables, and the flash cable are all type-B; you’d have to carefully search to find a micro-A for sale). On other models, which do allow either type-A or type-B, such as the TX2, different drivers are installed and activated depending on which connector type is found. If it is a keyboard, then the connector would identify host mode, and the keyboard device would work. Most Jetsons, if put in device mode while Linux is running (which is quite different versus recovery mode), have example applications for people wanting to use the port for their purposes. Those examples include the wired virtual ethernet device, and a mass storage device that shows up as a README type file on the host with the type-A connector host end.
Headless mode is only indirectly related to flash. In all cases of flash, the recovery mode Jetson eventually completes flash, and then it reboots and is no longer in recovery mode (it is fully operating at that point, and Linux is what you see). Since I don’t think a Nano supports host mode on the micro-OTG connector (someone correct me if wrong), you’d need your Wi-Fi device to go to one of the full-sized USB connectors (which are always host mode).
There is software, upon booting Linux, whereby it wants a first boot account setup. Normally one would be intending to boot to the GUI with a directly attached monitor and keyboard. This would be how you would set up the account name and password. Headless mode is very similar, in that it still boots Linux, but it expects the setup over the serial console instead. Sometimes, if you flash using headless instructions, it actually fails to get to the first boot setup on the serial console. In some cases cycling the power once will get you to that point, but if once does not do it, then it is unlikely more reboots will help.
Can I verify that first boot setup on headless is the main problem? Or are you able to log in, and you are needing help on the WaveShare USB device? Or maybe it is m.2, I’m not sure.
Incidentally, if it is about account setup, then there is a sort of “easy cheat”. The reason NVIDIA does not ship with a default name/pass is because of California law (it’s probably a good law, people with defaults and not knowing to change the pass get hacked a lot). However, you (but not NVIDIA) are allowed to install that password on the host PC’s flash software before flashing. There is a “
Linux_for_Tegra/tools/l4t_create_default_user.sh” script which sets this up as though you’ve already completed this before you ever flash. Normally this is used with eMMC models, but if you mount an SD card there, and if the flash software is a release compatible with the SD card, then running that script on the SD card should do the same thing.