Hi, And thanks for your help.
> Great to hear! > > > > However, I am encountering another problem now: in Dom0 and in > > dom0less-booted DomUs, I cannot use /dev/hvc0. > > For dom0less-booted DomUs it is normal because they don't get a PV console, > they get an emulated PL011 UART instead. Make sure to have a "vpl011" tag in > device tree to enable it (ImageBuilder generates it by default.) The device > name is usually ttyAMA0. Ok, understood. I had my vpl011 tag in the dom0less DomUs nodes in the DT, so that's not the problem. I am able to see DomUs boot prompt when booting dom0less. The problem is after DomU boots, that I am not able to switch to its console from Dom0, in order to be able to log in. > > Even though I'm specifying "console=hvc0" in dom0-bootargs, when dom0 > > finishes booting, it looks like I cannot use the getty spawned on /dev/hvc0. > > > > This is the end of the boot log: > > [ 2.947845] random: rngd: uninitialized urandom read (4 bytes read) > > [ 2.958415] random: rngd: uninitialized urandom read (4 bytes read) > > [ 2.965452] random: rngd: uninitialized urandom read (2500 bytes read) > > . > > [ 2.972410] random: crng init done > > Starting OpenBSD Secure Shell server: sshd done. > > Starting /usr/sbin/xenstored... > > Setting domain 0 name, domid and JSON config... > > Done setting up Dom0 > > Starting xenconsoled... > > Starting QEMU as disk backend for dom0 Starting domain watchdog > > daemon: xenwatchdogd startup > > > > [done] > > > > Auto Linux BSP 1.0 s32g274aevb /dev/hvc0 > > > > s32g274aevb login: > > Auto Linux BSP 1.0 s32g274aevb /dev/ttyLF0 > > > > s32g274aevb login: > > > > ----- END ----- > > > > It seems that the getty spawned on /dev/ttyLF0 overwrites the one > > spawned on /dev/hvc0. Which I do not understand, since Dom0 should not > > have access (?) directly to ttyLF0 (the serial console device on our > > boards). If I remove the line which spawns the getty on ttyLF0 from > > /etc/inittab, the system hangs when waiting for the username, and it does > > not let me type in any characters. For the record, hvc0 is added to > > /etc/securetty. > > > > In a system where I boot DomU via xl from Dom0, I can switch to its > > console with xl console, and hvc0 works there. > > > > The problem that comes with this is that I can not use the CTRL-AAA > > command to switch between Dom0 console and DomU console in a dom0less > > case, and I cannot therefore test that the passthrough works. But at least > > Dom0 does not have an entry for it under /dev, anymore, and DomU boot > > prompt tells that the driver has been registered. > > It looks like there is some kind of interference between the dom0 ttyLF0 > driver and the Xen serial driver. > > Is your Xen UART driver marking the device as "used by Xen"? See for instance > the pl011 driver, at the end of > xen/drivers/char/pl011.c:pl011_dt_uart_init: > > dt_device_set_used_by(dev, DOMID_XEN); > > Devices that are marked as "used by Xen" are not exposed to dom0, so you > shouldn't see the ttyLF0 device come up in Linux at all. I've checked my Xen UART Driver and that call is there. So ttyLF0 should be marked for Xen to use. I don't have any ideas why this happens. I've attached the driver [0], if you want to take a look. [0] https://pastebin.com/PuXi50H0 Thanks, Andrei Cherechesu, NXP Semiconductors
