I see that this project can have a wiki like other projects here. Perhaps this would be a good place to explain how to activate the serial console, and tell people in the readme to visit documentation in the wiki specific to the embedded images. I could write a wiki entry transplanting the serial instructions I gave into it if I had access to create a wiki page for this project.

I've noted this in 478574f4

What would happen if this was to be enabled by default?

The comment you added makes it seem like this is a problem for the rpi2 as well as the rpi3. However, things are fine just as they are right now for the rpi2, so this issue at this moment is specific to the rpi3 only. As what would happen if we enabled this by default, from https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=141195 : "1. The automatic UART initialisation should work on all RPis, whether or not the loaded kernel/U-Boot is DT-capable. The choice of UART to initialise is controlled by the "serial" aliases in the DTB, as set by the pi3-miniuart-bt and pi3-disable-bt overlays, but the default is the mini-UART on Pi3 and PL011 on other models. Note that if a custom dt-blob is in use that remaps pins 14 & 15 to something other than TXD0/RXD0 (even on a Pi3 - don't hard-code TXD1/RXD1) then the pin function is left unchanged to allow, for example, the VGA666 interface to be used.

2. A new config.txt setting has been introduced - "enable_uart" - the purpose of which is to control the initialisation of the UART(*). The default value varies according to the primary UART on the platform - if the PL011 is the primary UART (that used for the console and boot messages) then enable_uart defaults to 1, and if the mini-UART is the primary then it defaults to 0. The reason for the additional setting is that making use of the mini-UART requires the core frequency to be fixed, so setting enable_uart will limit the core to the minimum (unless force_turbo is set, since that will fix the core frequency to the maximum, provided the Pi is adequately powered and cooled). The previous default behaviour, which rendered much of the output illegible, was not useful, but we didn't want to restrict all users (even those who don't care about the UART) to the minimum core frequency. We also wanted to be able to remove the restriction when the PL011 is chosen on a Pi3, hence the need for a dedicated setting indicating the reason for the frequency limit."

So, setting enable_uart=1 in config.txt on the rpi2 would make the default explicit. On the rpi3, it would lock the core to the minimum frequency (unless force_turbo was also set), and it would enable the mini uart. Now, for cmdline.txt, and /etc/inittab. Right now, the console in both files is set up for ttyAMA0. This is fine for the rpi2, but on the rpi3 ttyAMA0 is the bluetooth modem, unless the pi3-disable-bt overlay is loaded. The way raspbian gets around this is to change "console=ttyAMA0,115200" to "console=serial0,115200" in cmdline.txt, and start a getty instance listening on /dev/serial0 instead of /dev/ttyAMA0. The /dev/serial0 and /dev/serial1 symlinks are created by raspbian's /etc/udev/rules.d/99com.rules. I described this at: #14 (closed)

There is however a problem. If enable_uart=1 isn't set in config.txt on the rpi3, /dev/serial0 doesn't get created, and agetty exits as a result. So, setting agetty to listen on /dev/serial0 would mean that init would keep respawning it if enable_uart=1 isn't set in config.txt. It seems that systemd can gracefully deal with a getty instance on a missing serial port. I don't know how that's actually done though. On the other hand, setting enable_uart=1 in config.txt by default would impact performance on the rpi3 as I said above, but would always create /dev/serial0 on both the rpi2 and rpi3 no matter what. I see no easy fix here, unless we can detect in inittab that a serial port doesn't exist, and programaticly not set agetty to listen on that port. So, I think simply documenting the issue and leaving things as they are is probably the best way to go at this point. As I discussed in issue 14, the line at the bottom of /etc/inittab will also impact the bluetooth modem on the rpi3 once we get the firmware issues sorted out with that. I hope that sheds a bit more light on the issue, and explains adequately enough what would happen if this was made the default, as well as the implications of doing so.

Was this ever resolved?

It depends on how we define resolved. If the comment in 478574f4 is a good enough resolution, then this issue can be closed. As far as the devuan_jessie_1.0.0_arm64_raspi3.img.xz image that I downloaded yesterday, nothing has changed.

I've documented this in the following bugs: https://bugs.devuan.org/db/87/87.html https://bugs.devuan.org/db/88/88.html https://bugs.devuan.org/db/89/89.html

Thank you. I will attend to the bugs.do tracking.

closed