> Date: Thu, 21 Dec 2023 17:26:36 +0100 > From: Patrick Wildt <patr...@blueri.se> > > On Thu, Dec 21, 2023 at 01:29:32PM +0000, Miod Vallat wrote: > > > Hello Miod, > > > > > > Thank you for your reply. > > > > > > It would appear that, at least in my case, /dev/tty00 is not mapped to > > > any driver. > > > > Oops, my had, I hadn't looked carefully enough. It turns out that there > > are no device nodes created for pluart at the moment. > > > > The following diff takes care of it; you will need to build a new kernel > > with the conf.c change and also need to use the updated MAKEDEV to > > create the /dev/ttyP0 node. > > Ah, I guess we only steal the com(4) ones when we find it through > pluartcnattach: > > /* Look for major of com(4) to replace. */ > for (maj = 0; maj < nchrdev; maj++) > if (cdevsw[maj].d_open == comopen) > break; > if (maj == nchrdev) > return ENXIO; > > cn_tab = &pluartcons; > cn_tab->cn_dev = makedev(maj, 0); > cdevsw[maj] = pluartdev; /* KLUDGE */
Ah yes, but that is a good thing. Because the Pi's have both pluart(4) and com(4) serial ports. So we don't really want pluart(4) to steal the com(4) major if it isn't the serial console. This major stealing has been bothering me since a long a time. Should we try to kill it? We'd need to come up with a sensible device naming scheme though that leaves us room for expansion if we have more drivers. The default /etc/ttys on armv7 and arm64 start a getty on /dev/console, so the disruption should be managable.
