Janos Szigetvari

@c0rnelius Also, I would like to thank you for your time, effort and help!

@c0rnelius I would like to report back with the news of full success: I have updated cmdline.txt to start with: console=tty1 console=ttyAMA0,115200 earlycon=pl011,0x107d001000,115200n8 And also added the following to config.txt: usb_max_current_enable=1 enable_uart=1 dtparam=uart0 dtparam=uart0_console dtparam=pciex1 dtparam=pciex1_gen=3 dtoverlay=disable-wifi-pi5 dtoverlay=disable-bt-pi5 All this with the HAT+ (in the picture above) still connected. The early boot console also works, and I also get a login prompt, which is all I wanted. After this I tried replacing ttyAMA0 to serial0 in cmdline.txt, to see if there is any difference, but they both seemed to work in the end.

@c0rnelius I will try that too, along with some other ideas that I came across. I won't have time to work on this during the weekend, but I will get back to you early next week. Appreciate your patience!

Well, that's strange, and thus I am a bit confused. I retried a few times: flashed Armbian_25.8.1_Rpi4b_noble_current_6.12.41_xfce_desktop.img.xz onto a micro-SD card in a UGREEN SD-card reader. I tried both rpi-imager and plain old dd. I am using a WCH340-based USB-serial adapter (came from the Pine64 webshop) wired up apparently correctly (see the attached photo). (I believe that my initial problem may have been caused by the rpi-imager custiomization settings, that I thought were supported with the Armbian image too.) Since then I stopped using those customization settings. The system now boots OK, the GUI comes up, but I'm still not seeing anything in the minicom screen. My config.txt settings are still: usb_max_current_enable=1 enable_uart=1 dtoverlay=uart0 dtparam=pciex1 dtparam=pciex1_gen=3 max_current_enable=1 dtoverlay=disable-wifi dtoverlay=disable-bt I now have both ttyAMA0 and ttyAMA10 devices: root@rpi5b:~# ls -l /dev/ttyAMA* crw-rw---- 1 root dialout 204, 64 nov 7 12:16 /dev/ttyAMA0 crw--w---- 1 root tty 204, 74 nov 7 12:57 /dev/ttyAMA10 root@rpi5b:~# systemctl status serial-getty@ttyAMA10.service ● serial-getty@ttyAMA10.service - Serial Getty on ttyAMA10 Loaded: loaded (/usr/lib/systemd/system/serial-getty@.service; enabled-runtime; preset: enabled) Drop-In: /usr/lib/systemd/system/serial-getty@.service.d └─10-term.conf Active: active (running) since Fri 2025-11-07 12:57:12 CET; 1h 49min ago Docs: man:agetty(8) man:systemd-getty-generator(8) https://0pointer.de/blog/projects/serial-console.html Main PID: 2714 (agetty) Tasks: 1 (limit: 9411) Memory: 200.0K (peak: 1.7M) CPU: 12ms CGroup: /system.slice/system-serial\x2dgetty.slice/serial-getty@ttyAMA10.service └─2714 /sbin/agetty -o "-p -- \\u" --keep-baud 115200,57600,38400,9600 - linux nov 07 12:57:12 rpi5b systemd[1]: serial-getty@ttyAMA10.service: Scheduled restart job, restart counter is at 1. nov 07 12:57:12 rpi5b systemd[1]: Started serial-getty@ttyAMA10.service - Serial Getty on ttyAMA10. root@rpi5b:/usr/lib/systemd/system# systemctl enable --now serial-getty@ttyAMA0 Created symlink /etc/systemd/system/getty.target.wants/serial-getty@ttyAMA0.service → /usr/lib/systemd/system/serial-getty@.service. root@rpi5b:/usr/lib/systemd/system# systemctl restart serial-getty@ttyAMA0 root@rpi5b:/usr/lib/systemd/system# fuser -c /dev/ttyAMA0 /dev/ttyAMA0: 42rc 3040m 4999 root@rpi5b:/usr/lib/systemd/system# ps auxfw | fgrep 4999 root 5013 0.0 0.0 9040 2108 pts/4 S+ 14:50 0:00 \_ grep -F --color=auto 4999 root 4999 0.0 0.0 8192 1956 ttyAMA0 Ss+ 14:49 0:00 /sbin/agetty -o -p -- \u --keep-baud 115200,57600,38400,9600 - linux root@rpi5b:/usr/lib/systemd/system# systemctl restart serial-getty@ttyAMA10 root@rpi5b:/usr/lib/systemd/system# And in the end, nothing seems to be happening when I start the new getty on AMA0 or restart the old one on AMA10. I am puzzled.

I am using the Noble image. I have added the following entries to config.txt: usb_max_current_enable=1 enable_uart=1 dtoverlay=uart0 dtparam=pciex1 dtparam=pciex1_gen=3 max_current_enable=1 dtoverlay=disable-wifi dtoverlay=disable-bt I now have both ttyAMA* devices. As the next step, I tried to remove the ttyAMA10 getty and add a ttyAMA0 one: systemctl disable serial-getty@ttyAMA10 systemctl enable --now serial-getty@ttyAMA0 But it doesn't seem to work. I'm still not seeing any activity in minicom. (It worked right after installation, and I haven't touched the wiring since.)

Yes, I kind of reached the same conclusion, unfortunately. BTW, does it have any mode, where it would do a dry run, and tell you what it would modify? As for ttyAMA0, I don't seem to have it, even though have the UART enabled in config.txt: The priority increase seems to work, in the sense that serial now likely has the upper hand, but the system is not booting, so something is likely not working. I will try reverting the console priority.

Furthermore, I found the following: I used the noble xfce image from 2025-08-08 The serial console (login console, not boot console!) worked initially After the install, I did an apt-upgrade, and also used raspi-config to enable the serial console After that, the systemd console service seems to have moved from ttyAMA0 to ttyAMA10, and I am gettin no output in minicom So I have mixed feelings.

Okay, I tested, but it works kind of weird: they work in tandem, but the boot messages were only output to the video console, not on the serial one. Once after the initial automatic login, the output started to go to both consoles, but the initial and systemd boot messages were only output to the video console, which would have made sharing the details of the initial problem difficult.

@c0rnelius Thanks for stepping in to help. I've added enable_uart=1 to config.txt In cmdline.txt, I currently have: console=serial0,115200 console=tty1 ... Do the two settings work in tandem, or do they override each other?

@laibsch Hmmm, the current latest image seems to work OK. On the other hand, I tried to get the serial console working, but I did not manage to do so. I used an FTDI-based cable ( https://ftdichip.com/wp-content/uploads/2020/07/DS_TTL-232R_RPi.pdf ) with the recommended connection diagram, but nothing ever showed up on minicom's output. (It always showed it as Offline, and not even a single byte came through) I tried 9600 and 115200 baud for minicom, and also set `dtoverlay=uart0` in config.txt at some point. But neither helped in any way.

@laibsch Thanks for the suggestion, but I wasn't able to actually get a login prompt, or start up a shell as a result of this problem. (No UI or virtual console was visible or accessible.)

Any comments on this would be welcome.

The Trixie-based XFCE image seems to work fine too, so only the Noble-based images seem to be broken.

I can report back that the above mentioned HAT works well well with the Kioxia SSD I have. So this problem very likely has something to do with armbian, and is not hardware related.

All the while the Raspberry PI OS (version September 2025) has booted out of the box on the board itself. I will check it with with the HAT added too.