I’m building a custom initrd and would like to connect and troubleshoot with an interactive shell via the uart usb port connected to my laptop vs keyboard and monitor plugged into the Jetson. Is this possible? (I can login normally when the root fs mounts and starts, but can’t interact with shell inside initrd)
Inside the initrd, I tested adding:
mknod -m 644 console c 5 1
mknod -m 622 ttyS0 c 4 0
but no success, do you know if this is possible?
Would really help with debugging.
Many Thanks
Do you mean how to use the micro usb port (uart port) to enable the serial console?
If you are using a linux host, then you could use below command.
sudo picocom -b 115200 /dev/ttyUSB3.
This is how I usually do.
I’m on a mac, and can access via minicom or screen, I see the output but can’t interact with the shell in my custom initrd, BUT can login after the system has fully booted. Just wondering what needs to be done to interact within the initrd, e.g. if I prompt for user input, on monitor (and keyboard) I can see and respond, but via uart port, I don’t see the prompt nor be able to input any commands.
Hi,
I am not sure if correctly understand your description. Actually, the serial console is not able to get the input in first boot.
You need to configure the user account on HDMI monitor before serial console to work fine.
user account already configured and first initialisation already done, but this is regarding the initrd (L4T/bootloader/l4t_initrd.img), the script that runs before root is mounted, I’ve modified the init shell script, am trying to interact with it, like for debugging I can tell it which root partition to mount by entering a number.
Did you pass the serial console information to the kernel in the initrd? Can you adjust the initrd to output the content of “cat /proc/cmdline” in some way? If it has “console=ttyS0,115200n8” within it, then that is the minimal requirement should “ttyS0” be your serial console (and this is what the previous bootloader stage would have used).
this is the /proc/cmdline:
root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyTCU0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 rootfstype=ext4 video=tegrafb no_console_suspend=1 earlycon=tegra_comb_uart,mmio32,0x0c168000 gpt tegra_fbmem=0x800000@0xa069b000 lut_mem=0x2008@0xa0696000 usbcore.old_scheme_first=1 tegraid=19.1.2.0.0 maxcpus=8 boot.slot_suffix= boot.ratchetvalues= 0.4.2 vpr_resize sdhci_tegra.en_boot_part_access=1
Indeed ttyS0 is missing, I’ll try to figure out how to hack this in.
Many Thanks
This is actually ok since the name of the device on Xavier is ttyTCU0. The “console=ttyTCU0,115200n8” entry does the job. The other Jetsons have directly connected UARTs and I tend to forget the Xavier uses the alternate UART name (ttyS0 is actually the wrong name on Xavier, but the goal is just to be sure the kernel had been told to use serial console).
This reminded me that there is one other issue to think about in the initrd which you won’t need to worry about on the other Jetsons: The USB has to be working before the USB serial UART will work. Does your initrd contain USB and the USB serial UART drivers (the UART is FTDI, so the kernel config item is “CONFIG_USB_SERIAL_FTDI_SIO”)?
inside my init it contains:
/lib/firmware/tegra18x_xusb_firmware
/lib/firmware/tegra19x_xusb_firmware
Regarding the kernel, it’s the default nvidia one, no modifications, when I unpack the source for it and look in it’s .config I can see:
CONFIG_USB_SERIAL_FTDI_SIO=m
does that look right?
I found /lib/modules/4.9.140-tegra/kernel/drivers/usb/serial/ftdi_sio.ko
Gonna test dropping the whole 4.9.140-tegra directory into the init… <init>/lib/modules/
no luck :(
Output from console: RCM Output · GitHub
(I added a timeout in the initrd so if no user input it carries on with mounting root and booting, so that’s why you see the login prompt at the end, but I want to interact with the shell within initrd prior to that)
from the logs, even though I flash from ./flash.sh it still uses u-boot, so I appended console=ttyTCU0 to the APPEND line in /boot/extlinux/extlinux.conf and now I can interact with the shell in initrd :)
This is good for debugging (without wiring up hdmi to monitor and extra keyboard) but to clarify, for production, I assume once I flash and enable secure boot, cboot will be used?
I do not know about all of the details of secure boot which you are interested in, someone else will need to provide a full answer, but some basic info follows…
CBoot is used anyway (this is an early boot stage), but the question is more one of whether content being loaded has signing enforced based on a private key. Certainly all of the bootloader stages (including CBoot) will require signing for the content to be allowed when the secure boot is enabled, but the rootfs itself will not use signing. It is up to the earlier stages to load only the correct content.
The initrd might be considered a rootfs, one that happens to be a cpio tar archive instead of an ext4 filesystem. The methods used by earlier boot stages to determine which content to load as initrd might enforce something. Presumably, if your boot content is guaranteed authentic, and if your boot content only loads the correct initrd, then everything up to that point is guaranteed up to the strength of the signing. That initrd is yours though, and you might choose to add something like filesystem encryption prior to the pivot_root. The pivot_root itself ends the life of the existing initrd and transfers life to the ext4 filesystem. At this point it comes down to your creativity as to what occurs during that pivot_root to ensure valid content.
One variation which some people consider is having a read-only rootfs which becomes the backing to OverlayFS.
NOTE: CBoot runs regardless of whether U-Boot is used or not.
thanks for your help, your many contributions in other threads certainly helped too, read-only root is a great idea, I’ll definitely look into that :)