Hi All:
I want to do something and debug in the initrd stage. Is there a way for me to keep the serial port in the initrd stage without executing the following command and keep the serial port interactive interface in the initrd state for debugging?
exec chroot . /sbin/init 2;
I followed the following link to debug some customized functions of initrd, but I want to debug directly in the initrd stage without executing the exec chroot of the init file in initrd. /sbin/init 2
I cannot fully answer your question. I will give some ideas that should help get started, but I won’t be able to give you a complete answer. For all that you test make sure the “quiet” is removed from any entry in “/boot/extlinux/extlinux.conf” (and I don’t know what external devices are present; this might apply to both the eMMC and the external device if any).
When you are still in the boot stages you can probably save a serial console boot log which tells you which device is used for serial console, e.g., it might be “ttyS0”. Normally you would continue to use this exact device so that it doesn’t have to reinitialize the driver when the Linux kernel loads (and the kernel loads as the initrd starts). It is possible you might then see the device for serial port (after the initrd) change to a “/dev/ttyTHS#”, but mostly this would not be the case and it should continue as the same “/dev/ttyS#”. The serial UARTs on the Jetson are one of the few devices you’ll find that can run simultaneously with two drivers. The “/dev/ttyS#” uses the legacy 16550A driver, while the “/dev/ttyTHS#” runs on the exact same UART, but enables DMA (it is the “Tegra High Speed” driver). Mostly you don’t want to switch drivers for serial console, you want to use the same driver from boot through Linux. This might or might not show up, and probably you don’t need to worry about it, but if there is a change, then this will make life difficult debugging in the initrd.
You can try an echo to the serial device within the initrd to see if you have the right one. I’ll pretend it is “/dev/ttyS0”. As the initrd script runs it will begin a minimal bash script. Perhaps you could try something like this just to see if the port is active either to log files or to serial boot output (you’d log serial console during boot, and check dmesg after): echo 'TEST TO TTYS0' > /dev/ttyS0
Early boot stages might need a debug version of the boot software to see the serial console logs in any detail prior to the initrd, but since you are working on the initrd (which has Linux running) this shouldn’t be an issue. If you can find that “echo” in dmesg logs or serial console logs, then you have a starting point. Possibly if a kernel module itself is using a kprintf, then something more might need to be set up.
