I am emulating a board from TI which run ARM-Cortex A15. The board using UART8250 and the default uart number is 3 at address 0x48020000. I use U-boot to boot the Linux kernel and run qemu with:
qemu-system-arm -machine vexpress-a15 -smp 1 -m 1G -kernel u-boot.elf \
-drive file="nandflash.bin",if=mtd,index=0,format=raw \ -chardev file,id=char1,path="${HOME}/serial1.txt",signal=on\ -chardev file,id=char2,path="${HOME}/serial2.txt",signal=on\
-s -S -serial chardev:char1 -serial chardev:char2 -serial stdio
Linux image, skipping rbs!
OK! Booting Image main.bin with bootargs console=ttyO2,9600 rdinit=/sbin/init quiet loglevel=7 log_buf_len=1M...
## Booting kernel from Legacy Image at 84000200 ...
Image Name: linux
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 4086200 Bytes = 3.9 MiB
Load Address: 82000000
Entry Point: 82000000
## Loading init Ramdisk from Legacy Image at 843fae14 ...
Image Name: rootfs
Image Type: ARM Linux RAMDisk Image (uncompressed)
Data Size: 23410472 Bytes = 22.3 MiB
Load Address: 00000000
Entry Point: 00000000
## Flattened Device Tree blob at 843e5df8
Booting using the fdt blob at 0x843e5df8
Loading Kernel Image ... OK
Loading Ramdisk to 9c8db000, end 9df2e728 ... OK
Loading Device Tree to 9c8c3000, end 9c8dae19 ... OK
Starting kernel ...
SF: Detected n25q256 with page size 256 Bytes, erase size 4 KiB, total 32 MiB, mapped at 5c000000
Uncompressing Linux... done, booting the kernel.
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 4.14.115-rt59 (lamnguyen@DENEC1LT0933) (gcc version 11.3.0) #1 PREEMPT RT Mon Jul 17 10:48:38 UTC 2023
[ 0.000000] CPU: ARMv7 Processor [414fc0f0] revision 0 (ARMv7), cr=30c53c7d
[ 0.000000] CPU: div instructions available: patching division code
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[ 0.000000] OF: fdt: Machine model: Hirschmann Greyhound Switch
[ 0.000000] Memory policy: Data cache writeback
[ 0.000000] cma: Reserved 24 MiB at 0x000000009e400000
[ 0.000000] OMAP4: Map 0x000000009fd00000 to fe600000 for dram barrier
[ 0.000000] CPU: All CPU(s) started in SVC mode.
I can get all the message from U-Boot and the kernel messages from Linux but messages from application are not printed to the console. When the kernel run my init scripts, it only print the messages which tee to /dev/kmsg. For example:
#This one below will not print to my console (ttyS2)
echo -n " Mounting /dev/pts : "
#This one will but in the format of kernel message with the timestamp
echo -n " Mounting /dev/pts : " | tee /dev/kmsg
Those scripts are actually running, but the problem is that I will see nothing with the normal command "echo". I think my serial terminal is working well. Unless, I won't see not things include the kernel messages. I put dmesg | grep "tty" | tee /dev/kmsg when running init script and get:
[ 16.141290] [ 0.000000] Kernel command line: console=ttyO2,9600 rdinit=/sbin/init quiet loglevel=7 log_buf_len=1M
[ 16.141290] [ 0.017880] WARNING: Your 'console=ttyO2' has been replaced by 'ttyS2'
[ 16.141290] [ 3.235689] 48020000.serial: ttyS2 at MMIO 0x48020000 (irq = 45, base_baud = 3000000) is a 8250
[ 16.141290] [ 7.652801] console [ttyS2] enabled
My goal is to get the output from "echo without tee /dev/kmsg" printed to my console. I can not debug with GDB since when those init scripts executed, the only thing I saw is CPU go to WFI and NOP. I am new learner so any advices from you would be considerably valued to me.
I can think of two lines of attack for debugging this:
Firstly, 'console=ttyO2' on the kernel command line tells the kernel to use that serial port, but it doesn't necessarily tell /sbin/init to use that serial port (eg for spawning a login prompt). So there might be some config within the guest filesystem that controls that. Check whether your guest userspace processes are even trying to send data to the kernel to go to the serial port.
Secondly, it's possible that the in-kernel printing is using the UART in a non-interrupt-driven way, whereas printing via the tty layer uses the UART with interrupts. Since you say this is a custom board model, you should check whether you've handled the interrupts correctly (i.e. whether they are wired up to the interrupt controller as the guest's UART driver expects).