qemu serial output stops when init boots (goes into loopback mode)

[Loïc Minier]

Hey

Since about the time of the ttyS2 -> ttyO2 change, qemu-system-arm -M beaglexm doesn't have a getty on the serial port anymore.

This was discovered by pm215 in bug #697824, and we addressed the ttyS2 -> ttyO2 rename in linaro-image-tools, but it seems another issue prevents the getty from starting under qemu.

Apparently, the getty should be started by the upstart job etc/init/auto-serial-console.conf which defaults to reading the tty name from /proc/cmdline if a tty.conf doesn't already exist, and spawns a root-login wrapper (configured in etc/default/autogetty).

So this might be a bug in linaro-overlay.

Cheers,

[Peter Maydell (pmaydell)]

I'm not convinced this is just a matter of the getty not being started. On 1011 the kernel prints the "Freeing init memory:nnnK" message to both serial and screen. On 20110203 it is printed only to the screen, not serial. (The last we see on serial is:
[ 4.636901] fbcvt: 1280x720@60: CVT Name - .921M9-R
[ 4.723236] Console: switching to colour frame buffer device 160x45
[ 4.758422] regulator_init_complete: incomplete constraints, leaving VDAC on
[ 4.759277] regulator_init_complete: incomplete constraints, leaving VUSB3V1 on
[ 4.760253] regulator_init_complete: incomplete constraints, leaving VUSB1V8 on
[ 4.761291] regulator_init_complete: incomplete constraints, leaving VUSB1V5 on
[ 4.788269] twl_rtc twl_rtc: setting system clock to 2011-02-07 14:19:06 UTC (1297088346)

[Loïc Minier (lool)]

I think this is a qemu issue; first, I tried forcing a getty to start on ttyO2 and at some point saw:
ttyO2: 717 input overrun(s)
on tty1 (repeated many times with different values); then I tried breaking into the initrd: I was expecting to be able to interact with linux on ttyO2 by passing the relevant console= cmdline and stopping the boot at the initrd; with an alpha2 beagle image that I'm starting with:
qemu-system-arm -M beaglexm -sd omap.img
and which will boot to a console on tty1, I'm interrupting the boot in u-boot and changing bootargs to stop in the initrd; I boot with:
setenv bootargs 'console=ttyO2,115200n8 break=top'
mmc rescan 0
fatload mmc 0:1 0x80000000 uImage; fatload mmc 0:1 0x81600000 uInitrd; bootm 0x80000000 0x81600000

and then qemu indeed stop bootig at roughly the time where the initrd kicks in, and I can't input anything on the serial console anymore (it was working only within u-boot, not within linux)

Cheers,

[Peter Maydell (pmaydell)]

This is a qemu bug: the omap UART model is not good enough for the new highspeed serial driver.

In particular, what is happening is that hw/omap_uart.c has

/* The OMAP UART functionality is similar to the TI16C752 rather than
 * the 16550A. When the flag below is enabled, the code will however
 * offer 'only' the basic 16550A emulation. */
/* TODO: real functionality for the TI16C752 enhanced features. Note
 * QEMU's SerialState emulation internally always uses a 16-byte FIFO
 * whereas we would need a 64-byte FIFO for OMAP. */
#define OMAP_UART_16550A

so we just act like a 16550A. The enhanced features include a way to access more UART registers by writing a magic value to one register which swaps out the standard ones for a new set. So the kernel is trying to set the UART_XON1 extended register, but qemu doesn't model the register swapping so it behaves as if the kernel had set the UART_MCR. As it happens the value written has the MCR_LOOP bit set and the model goes into loopback mode, so we never see anything more.

Just commenting out that #define and rebuilding gives back a root prompt on serial. However I don't know if this breaks anybody else (eg omap-but-not-omap3 models?)

[Peter Maydell (pmaydell)]

Merge request sent to the meego folks:
http://meego.gitorious.org/qemu-maemo/qemu/merge_requests/7

and an equivalent set of commits added to the qemu-linaro tree.