On a normal PC you have a BIOS (or its UEFI equivalent). That BIOS provides a uniform interface to boot loaders, and that interface includes driver support for certain minimal features of the motherboard. For example, USB and USB keyboards are set up by the BIOS, as well as drivers for any SATA port. When you halt boot on that PC you are entering into the BIOS editing environment. Embedded systems do not have a BIOS…everything done in the BIOS is instead done in the boot loader (this is in addition to the things a PC boot loader would do). Especially important would be a video driver…boot loaders on a PC do not need to have a video driver because the motherboard does this for them before the boot loader is ever reached. Putting an entire video driver in a small embedded system’s boot loader is rather difficult.
So serial console is used instead. It’s just a serial UART with a string of bytes. No video driver required, no framebuffer required, no network stack required, no keyboard software required (including USB variants), no special protocols. But serial UARTs are not smart, they need to be told what speed to run at, along with any conventions like if flow control is used and if parity is used (but this is integral in the UART itself, only a tiny amount of support is required in software). The basic and minimal connection is a ground plus a TX and RX line. Assuming software flow control, this is all you’d use. Add hardware flow control via clear-to-send (CTS) and request-to-send (RTS) and speeds or cable lengths can increase…that’s two more wires, and those are optional. Video can fail (or not be implemented in the case of an embedded boot loader stage), ethernet can fail, and almost anything you can think of which can fail won’t get in the way of a serial UART doing nothing more than streaming bytes it sees. All of the video and other drivers are actually on the remote host that runs the serial console program. Since u-boot does not have a video driver you must use serial console via serial UART to access the features which a BIOS would do on a PC.
Incidentally, although an embedded system seems light weight and simpler than a PC, the boot loader does more than grub and could be considered more complicated even if it is less flexible.
So if you want to see the boot loader you have to see that stream of bytes. If you want to talk to the boot loader you have to also send a stream of bytes. A serial console program such as minicom or PuTTY or gtkTerm (my favorite) does the display and formatting of that stream of bytes from the remote host PC. To work with any PXE environment on a Jetson will pretty much make serial console mandatory.
If you want to modify or compile a boot loader on a PC you won’t have any real issues because all of the stuff which is custom to the motherboard hardware is in the BIOS. If you go to use an alternative boot loader source not written for a Jetson you will lose all customization…which includes serial console hardware, memory controller, eMMC access, USB hardware, ethernet hardware, so on. If you want to compile and modify the boot loader on the Jetson expect to start with the source code provided in the L4T distribution. If not, then you have lots of work ahead (or whoever makes it work has lots of work ahead). You could consider customizing someone else’s boot loader as writing a complete BIOS in software and integrating it into the normal boot loader functionality.
Some of the boot loader functionality may actually be slightly simpler because “t-boot” (nvtboot, or tegra-boot), part of the boot environment, is actually built into the Jetson. There may be some small and critical early steps to booting a Jetson which would not be required in u-boot because of this.
Overall though I do believe the existing u-boot has some support for network booting. That network boot environment can be edited from the serial console prompt, and so it is flexible and not necessarily too difficult to work with if you use the supplied u-boot with serial console.