Enabling UART0 on BB-AI64

I am trying to get uart0 (pin 9_11 and 9_13) working on the bb-ai64. I want those pins using uart because of my cape.
I follow the same steps from my previous post https://forum.beagleboard.org/t/need-help-enabling-uart-on-ai64/34844.
Except I add BONE_UART0.dts and include it in extlinux.conf and also see that it got loaded on reboot.

&{/chosen} {
	overlays {
		BONE-UART0.kernel = __TIMESTAMP__;

&bone_uart_0 {
	status = "okay";

I also edit k3-j721e-beagleboneai64-bone-buses.dtsi with:

bone_uart_0: &main_uart0 {
	pinctrl-names = "default";
	pinctrl-0 = <
		&P9_11_uart_pin /* uart0_rxd */
		&P9_13_uart_pin /* uart0_txd */
	symlink = "bone/uart/0";
	status = "okay";

I realized that P9_11 p9_13 had a beat using my logic analyzer which I think is caused by BONE_LED_P9_11.dts in arm64/overlays/? But I did not include the dtbo file in extlinux.conf and the beat was still there after deleting the file. Or is it caused by the line in extlinux.conf “append console=ttyS2,115200n8” in ttyS2 since uart0 is using the same link?

1 Like


I found this online. BeagleBone cape interface spec — BeagleBoard Documentation

and…one of the three pin headers is for seeing boot logs while the other one is for a very specific boot log having to do w/ security (I think). Introduction — TISCI User Guide


P.S. I am not sure if UART0 is completely available b/c of the boot log usage dedication. I am sure others that are behind the building of the board will introduce more in time. I am sort of guessing here but familiarity w/ the am335x and UART0 being the debug header makes me think it is similar on this board but I could be severely mistaken.



1 Like

Thanks for the documentation. That’s interesting. Now i’m wondering if it’s possible to disable the console debug or to move it to a different uart.

1 Like

If you really need to use UART0 then depending on what you have hooked up to it and what it does when it gets input, you will need to -

  1. modify and recompile u-boot so that it does not use UART0
  2. Remove the console= from the kernel command line, passed by u-boot
  3. modify linux so it does not start up a tty on the serial port. Probably a Systemd config somewhere (used to be in inittab when using SYSV init)

If whatever you have connected can live with a little spam on the UART, you could skip step 1.

1 Like

That can be turned off in the kernel.

I was referring to u-boot debug text, which can only be stopped y recompiling u-boot.

Yes, correct. The kernel config also has settings to customize the messages sent out. It just depends on how far one needs to go.

Thanks for all the help.
So I removed the “console=…” from the kernel command line and also stopped the systemd services. Specifically the serial-getty@ttyS2.service and serial-getty@ttyGS0.service on boot.

I am not sure what to modify in the u-boot. I tried removing the default pins uart0 controls. But I am still getting the console debug output on the pins.

Ok I was looking at the schematic for the bbai64 and I was wrong, you don’t need to modify u-boot at all.

The debug serial console output from uart0 on the debug pins is actually muxed to different pins from uart0 on P9.11 & P9.13

In which case just disabling the console in linux and of course loading the correct pinmux overlay should be enough to make uart0 available.