Can't enable UART1 on CM3

[DonMorr]

Description
If I try to enable uart1 in the config.txt on my Compute Module 3, the device is not enabled and the kernel log reports an error. uart0 works as expected on pins GPIO_14 and GPIO_15.
I've reproduced this issue on the heads of sumo, thud and master branches.
This is not an issue on the official Raspian Image, when using this, both uarts can be enabled simultaneously on different sets of GPIO pins..

Steps to reproduce the issue:

1. Modify the local.conf of a fresh checkout of the required layers, to include the following line: CMDLINE_append += " console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 "
   Also set the MACHINE to "raspberrypi-cm3".
2. Run the bitbake build: bitbake core-image-minimal
3. Copy the generated rpi-sdimg file to the target.
4. Mount the file targets' file systems, and add the following to /boot/config.txt:

core_freq=250                                                                   
dtoverlay=pi3-disable-bt
dtparam=uart1=on                                                                
dtoverlay=uart1,txd1_pin=40,rxd1_pin=41
enable_uart=1  

This should enable uart1 to operate on pins 40 and 41.
5. Boot the target.

Describe the results you received:
When the target boots, the following is currently observed:

• The device file for uart1, /dev/ttyS0, is not created.
• The following errors are reported by dmesg:

[    0.721626] uart-pl011 3f201000.serial: cts_event_workaround enabled
[    0.721766] 3f201000.serial: ttyAMA0 at MMIO 0x3f201000 (irq = 81, base_baud = 0) is a PL011 rev2
[    1.703800] bcm2835-aux-uart 3f215040.serial: unable to register 8250 port - -28
[    1.711224] bcm2835-aux-uart: probe of 3f215040.serial failed with error -28
[    1.783593] uart-pl011 3f201000.serial: no DMA platform data

Describe the results you expected:

• The device file for uart1, /dev/ttyS0, to be created.
• No errors reported in dmesg output.

Additional information you deem important (e.g. issue happens only occasionally):

• This issue occurs across the heads of sumo, thud and master branches.
• Does not occur on the latest official Raspian image.
• uboot is not enabled.

#
# This file is your local configuration file and is where all local user settings
# are placed. The comments in this file give some guide to the options a new user
# to the system might want to change but pretty much any configuration option can
# be set in this file. More adventurous users can look at local.conf.extended
# which contains other examples of configuration which can be placed in this file
# but new users likely won't need any of them initially.
#
# Lines starting with the '#' character are commented out and in some cases the
# default values are provided as comments to show people example syntax. Enabling
# the option is a question of removing the # character and making any change to the
# variable as required.

#
# Machine Selection
#
# You need to select a specific machine to target the build with. There are a selection
# of emulated machines available which can boot and run in the QEMU emulator:
#
#MACHINE ?= "qemuarm"
#MACHINE ?= "qemuarm64"
#MACHINE ?= "qemumips"
#MACHINE ?= "qemumips64"
#MACHINE ?= "qemuppc"
#MACHINE ?= "qemux86"
#MACHINE ?= "qemux86-64"
#
# There are also the following hardware board target machines included for 
# demonstration purposes:
#
#MACHINE ?= "beaglebone-yocto"
#MACHINE ?= "genericx86"
#MACHINE ?= "genericx86-64"
#MACHINE ?= "mpc8315e-rdb"
#MACHINE ?= "edgerouter"
#
# This sets the default machine to be qemux86 if no other machine is selected:
MACHINE ??= "raspberrypi-cm3"

#
# Where to place downloads
#
# During a first build the system will download many different source code tarballs
# from various upstream projects. This can take a while, particularly if your network
# connection is slow. These are all stored in DL_DIR. When wiping and rebuilding you
# can preserve this directory to speed up this part of subsequent builds. This directory
# is safe to share between multiple builds on the same machine too.
#
# The default is a downloads directory under TOPDIR which is the build directory.
#
DL_DIR ?= "/media/donal/data/yocto/downloads/"

#
# Where to place shared-state files
#
# BitBake has the capability to accelerate builds based on previously built output.
# This is done using "shared state" files which can be thought of as cache objects
# and this option determines where those files are placed.
#
# You can wipe out TMPDIR leaving this directory intact and the build would regenerate
# from these files if no changes were made to the configuration. If changes were made
# to the configuration, only shared state files where the state was still valid would
# be used (done using checksums).
#
# The default is a sstate-cache directory under TOPDIR.
#
#SSTATE_DIR ?= "${TOPDIR}/sstate-cache"
SSTATE_DIR ?= "/media/donal/data/yocto/sstate-cache/"

#
# Where to place the build output
#
# This option specifies where the bulk of the building work should be done and
# where BitBake should place its temporary files and output. Keep in mind that
# this includes the extraction and compilation of many applications and the toolchain
# which can use Gigabytes of hard disk space.
#
# The default is a tmp directory under TOPDIR.
#
#TMPDIR = "${TOPDIR}/tmp"

#
# Default policy config
#
# The distribution setting controls which policy settings are used as defaults.
# The default value is fine for general Yocto project use, at least initially.
# Ultimately when creating custom policy, people will likely end up subclassing 
# these defaults.
#
DISTRO ?= "poky"
# As an example of a subclass there is a "bleeding" edge policy configuration
# where many versions are set to the absolute latest code from the upstream 
# source control systems. This is just mentioned here as an example, its not
# useful to most new users.
# DISTRO ?= "poky-bleeding"

#
# Package Management configuration
#
# This variable lists which packaging formats to enable. Multiple package backends
# can be enabled at once and the first item listed in the variable will be used
# to generate the root filesystems.
# Options are:
#  - 'package_deb' for debian style deb files
#  - 'package_ipk' for ipk files are used by opkg (a debian style embedded package manager)
#  - 'package_rpm' for rpm style packages
# E.g.: PACKAGE_CLASSES ?= "package_rpm package_deb package_ipk"
# We default to rpm:
PACKAGE_CLASSES ?= "package_rpm"

#
# SDK target architecture
#
# This variable specifies the architecture to build SDK items for and means
# you can build the SDK packages for architectures other than the machine you are
# running the build on (i.e. building i686 packages on an x86_64 host).
# Supported values are i686 and x86_64
#SDKMACHINE ?= "i686"

#
# Extra image configuration defaults
#
# The EXTRA_IMAGE_FEATURES variable allows extra packages to be added to the generated
# images. Some of these options are added to certain image types automatically. The
# variable can contain the following options:
#  "dbg-pkgs"       - add -dbg packages for all installed packages
#                     (adds symbol information for debugging/profiling)
#  "src-pkgs"       - add -src packages for all installed packages
#                     (adds source code for debugging)
#  "dev-pkgs"       - add -dev packages for all installed packages
#                     (useful if you want to develop against libs in the image)
#  "ptest-pkgs"     - add -ptest packages for all ptest-enabled packages
#                     (useful if you want to run the package test suites)
#  "tools-sdk"      - add development tools (gcc, make, pkgconfig etc.)
#  "tools-debug"    - add debugging tools (gdb, strace)
#  "eclipse-debug"  - add Eclipse remote debugging support
#  "tools-profile"  - add profiling tools (oprofile, lttng, valgrind)
#  "tools-testapps" - add useful testing tools (ts_print, aplay, arecord etc.)
#  "debug-tweaks"   - make an image suitable for development
#                     e.g. ssh root access has a blank password
# There are other application targets that can be used here too, see
# meta/classes/image.bbclass and meta/classes/core-image.bbclass for more details.
# We default to enabling the debugging tweaks.
EXTRA_IMAGE_FEATURES ?= "debug-tweaks"

#
# Additional image features
#
# The following is a list of additional classes to use when building images which
# enable extra features. Some available options which can be included in this variable
# are:
#   - 'buildstats' collect build statistics
#   - 'image-mklibs' to reduce shared library files size for an image
#   - 'image-prelink' in order to prelink the filesystem image
# NOTE: if listing mklibs & prelink both, then make sure mklibs is before prelink
# NOTE: mklibs also needs to be explicitly enabled for a given image, see local.conf.extended
USER_CLASSES ?= "buildstats image-mklibs image-prelink"

#
# Runtime testing of images
#
# The build system can test booting virtual machine images under qemu (an emulator)
# after any root filesystems are created and run tests against those images. It can also
# run tests against any SDK that are built. To enable this uncomment these lines.
# See classes/test{image,sdk}.bbclass for further details.
#IMAGE_CLASSES += "testimage testsdk"
#TESTIMAGE_AUTO_qemuall = "1"

#
# Interactive shell configuration
#
# Under certain circumstances the system may need input from you and to do this it
# can launch an interactive shell. It needs to do this since the build is
# multithreaded and needs to be able to handle the case where more than one parallel
# process may require the user's attention. The default is iterate over the available
# terminal types to find one that works.
#
# Examples of the occasions this may happen are when resolving patches which cannot
# be applied, to use the devshell or the kernel menuconfig
#
# Supported values are auto, gnome, xfce, rxvt, screen, konsole (KDE 3.x only), none
# Note: currently, Konsole support only works for KDE 3.x due to the way
# newer Konsole versions behave
#OE_TERMINAL = "auto"
# By default disable interactive patch resolution (tasks will just fail instead):
PATCHRESOLVE = "noop"

#
# Disk Space Monitoring during the build
#
# Monitor the disk space during the build. If there is less that 1GB of space or less
# than 100K inodes in any key build location (TMPDIR, DL_DIR, SSTATE_DIR), gracefully
# shutdown the build. If there is less that 100MB or 1K inodes, perform a hard abort
# of the build. The reason for this is that running completely out of space can corrupt
# files and damages the build in ways which may not be easily recoverable.
# It's necesary to monitor /tmp, if there is no space left the build will fail
# with very exotic errors.
BB_DISKMON_DIRS ??= "\
    STOPTASKS,${TMPDIR},1G,100K \
    STOPTASKS,${DL_DIR},1G,100K \
    STOPTASKS,${SSTATE_DIR},1G,100K \
    STOPTASKS,/tmp,100M,100K \
    ABORT,${TMPDIR},100M,1K \
    ABORT,${DL_DIR},100M,1K \
    ABORT,${SSTATE_DIR},100M,1K \
    ABORT,/tmp,10M,1K"

#
# Shared-state files from other locations
#
# As mentioned above, shared state files are prebuilt cache data objects which can
# used to accelerate build time. This variable can be used to configure the system
# to search other mirror locations for these objects before it builds the data itself.
#
# This can be a filesystem directory, or a remote url such as http or ftp. These
# would contain the sstate-cache results from previous builds (possibly from other
# machines). This variable works like fetcher MIRRORS/PREMIRRORS and points to the
# cache locations to check for the shared objects.
# NOTE: if the mirror uses the same structure as SSTATE_DIR, you need to add PATH
# at the end as shown in the examples below. This will be substituted with the
# correct path within the directory structure.
#SSTATE_MIRRORS ?= "\
#file://.* http://someserver.tld/share/sstate/PATH;downloadfilename=PATH \n \
#file://.* file:///some/local/dir/sstate/PATH"

#
# Yocto Project SState Mirror
#
# The Yocto Project has prebuilt artefacts available for its releases, you can enable
# use of these by uncommenting the following line. This will mean the build uses
# the network to check for artefacts at the start of builds, which does slow it down
# equally, it will also speed up the builds by not having to build things if they are
# present in the cache. It assumes you can download something faster than you can build it
# which will depend on your network.
#
#SSTATE_MIRRORS ?= "file://.* http://sstate.yoctoproject.org/2.5/PATH;downloadfilename=PATH"

#
# Qemu configuration
#
# By default qemu will build with a builtin VNC server where graphical output can be
# seen. The two lines below enable the SDL backend too. By default libsdl2-native will
# be built, if you want to use your host's libSDL instead of the minimal libsdl built
# by libsdl2-native then uncomment the ASSUME_PROVIDED line below.
PACKAGECONFIG_append_pn-qemu-system-native = " sdl"
PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl"
#ASSUME_PROVIDED += "libsdl2-native"

# CONF_VERSION is increased each time build/conf/ changes incompatibly and is used to
# track the version of this file when it was generated. This can safely be ignored if
# this doesn't mean anything to you.
CONF_VERSION = "1"


#
# Parallel Build - make the most of your CPUs
#
PARALLEL_MAKE = " \
-j 10 \
-l ${@int(os.sysconf(os.sysconf_names['SC_NPROCESSORS_ONLN'])) * 150/100} \
"

CMDLINE_append += " console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 "

[kraj]

Add ENABLE_UART = "1" to local.conf

[DonMorr]

Hi @kraj, thank you for the suggestion. I tested this on head of master, but no luck, I'm still getting the same errors.
Any other suggestions? Is there anyone free to test this with their Compute Module 3?
Cheers,
Donal

[agherzan]

I've never tested uart1 on cm3. Can you try without dtoverlay=pi3-disable-bt?

[DonMorr]

@agherzan , just tried that again without dtoverlay=pi3-disable-bt, but the same result for uart1:

[    1.706084] bcm2835-aux-uart 3f215040.serial: unable to register 8250 port - -28                                                                    
[    1.713529] bcm2835-aux-uart: probe of 3f215040.serial failed with error -28   

I have also tried uart1 on pins 32 and 33, but the same issue.

Any further suggestions?

My additions to config.txt now looks like the following:

# Enable UART                                            
enable_uart=1
core_freq=250                                  
dtparam=uart1=on
dtoverlay=uart1,txd1_pin=40,rxd1_pin=41

[DonMorr]

My current suspicion is that this is a kernel configuration issue. Tracing the issue through 8250_core.c, it looks to be caused by the CONFIG_SERIAL_8250_RUNTIME_UARTS kernel configuration to being set to 0.
If I manually override this in the kernel config, I can get /dev/ttyS0 to be created with no errors when the device is being registered.
However, I can't appear get data to be transmitted successfully through /dev/ttyS0. Will continue to do some more testing.

[agherzan]

That is interesting @DonMorr . Keep us updated.

[DonMorr]

@agherzan What's the best way to test a kernel configuration? I'd like to try to narrow the issue down to either the kernel configuration or something in userland. But can't seem to get the yocto build to use the kernel config from the Raspian image (which uart1 works correctly on).
I've tried adding a do_configure_append to my linux-raspberrypi_%.bbappend, which gets called, but the config (~/yocto-master-rpi/build/tmp/work/raspberrypi_cm3-poky-linux-gnueabi/linux-raspberrypi/1_4.19.27+gitAUTOINC+c0e09b3420-r0/linux-raspberrypi_cm3-standard-build/.config) gets overridden later in the build.

do_configure_append() {
    bbwarn "Using custom kernel configuration"

    if [ "${S}" != "${B}" ] && [ -f "${S}/.config" ] && [ ! -f "${B}/.config" ]; then
        mv "${S}/.config" "${B}/.config"
    fi

    cp "${WORKDIR}/custom_config" "${B}/.config"
}

[agherzan]

If it's just temporary I would probably use a devshell or copy something over just before compile.

[agherzan]

@DonMorr can you try without enable_uart=1?

[DonMorr]

@agherzan Thanks for your suggestion. Just tried without that, but getting the same result. My config.txt now only has the following related to uart1:

core_freq=250
dtparam=uart1=on
dtoverlay=uart1,txd1_pin=40,rxd1_pin=41

Getting the same error:

root@raspberrypi-cm3:~# dmesg | grep uart
[    0.721599] uart-pl011 3f201000.serial: cts_event_workaround enabled
[    1.704379] bcm2835-aux-uart 3f215040.serial: unable to register 8250 port - -28
[    1.711814] bcm2835-aux-uart: probe of 3f215040.serial failed with error -28
[    1.784219] uart-pl011 3f201000.serial: no DMA platform data

[agherzan]

@DonMorr What I actually meant but didn't come out right was to use enable_uart=0. Sorry for the confusion.

[s-maynard]

I use both UARTs in my yocto build for the CM3. I had to use the following overlay:

/*

• Device tree overlay for D600 UARTs
• Compile:

•     dtc -@ -I dts -O dtb -o d600-uarts-overlay.dtb d600-uarts-overlay.dts
  

*/

/dts-v1/;
/plugin/;

/{
compatible = "brcm,bcm2708";

fragment@0 {
    target = <&uart0>;
    __overlay__ {
        pinctrl-names = "default";
        pinctrl-0 = <&uart0_pins>;
        status = "okay";
    };
};

fragment@1 {
    target = <&uart1>;
    __overlay__ {
        pinctrl-names = "default";
        pinctrl-0 = <&uart1_pins>;
        status = "okay";
    };
};

fragment@2 {
    target = <&gpio>;
    __overlay__ {
        uart0_pins: uart0_pins {
            brcm,pins = <36 37 38 39>; /* UART0: TXD0 RXD0 RTS0 CTS0 */
            brcm,function = <6>; /* alt2 */
            brcm,pull = <0 2 0 2>;
        };
    };
};

fragment@3 {
    target = <&gpio>;
    __overlay__ {
        uart1_pins: uart1_pins {
            brcm,pins = <14 15>; /* UART1: TX1 RX1 */
            brcm,function = <2>; /* alt5 */
            brcm,pull = <0 2>;
        };
    };
};

fragment@4 {
    target-path = "/chosen";
    __overlay__ {
        bootargs = "8250.nr_uarts=1";
    };
};

__overrides__ {
    txd0_pin = <&uart0_pins>,"brcm,pins:0";
    rxd0_pin = <&uart0_pins>,"brcm,pins:4";
    rts0_pin = <&uart0_pins>,"brcm,pins:0";
    cts0_pin = <&uart0_pins>,"brcm,pins:4";
    txd1_pin = <&uart1_pins>,"brcm,pins:0";
    rxd1_pin = <&uart1_pins>,"brcm,pins:4";
};

};

I'm obviously on different pins, but you can modify that and recreate your dtb then load like this (in your config.txt):

Enable UARTs

enable_uart=1
dtoverlay=pi3-disable-wifi
dtoverlay=pi3-disable-bt
dtoverlay=d600-uarts

[DonMorr]

@agherzan @s-maynard Cheers guys, will give both of those a go.

[DonMorr]

@agherzan Setting enable_uart=0 disables all uart functionality for me (inc UART0).

@s-maynard That worked a treat, thank you very much for sharing.

I had missed that there is an overlay for uart1 in the repo here:
arch/arm/boot/dts/overlays/uart1-overlay.dts, which could be patched to use different pins as required.
@agherzan Is it worth putting details of this in the documentation here?

Thanks to everyone for their help, very much appreciated.

[agherzan]

@DonMorr That is definitely something to push in the docs. Do you want to have a PR for it?

[DonMorr]

@agherzan yes, happy to do this over the next few days.

[agherzan]

Appreciated.

[agherzan]

@DonMorr Any updates on this?

[ghost]

My organization has what seems to be the same problem using uart1 on a CM3/CM3+. We only have observed the problem since we switched over to testing 4.19.66. The 4.14.112 code we were previously using does not exhibit the problem.

@s-maynard Thanks for posting what may be a possible workaround. What is the meaning of the d600 in the name of your overlay file? - Does it have some specific meaning to your work or your environment, or is this something related to the Raspberry Pi with which I am unfamiliar?

[ghost]

By the way, the following entries in config.txt were sufficient for 4.14.112 kernels running on CM3/CM3+ for allowing use of both uart0 and uart1:

# Tell Linux to not drive serial Console on GPIO pins 14 & 15
enable_uart=1
# Disable Bluetooth (frees up UART0 and connects UART0 TXD0 and RXD0 pins to GPIO pins 14 & 15, respectively)
dtoverlay=pi3-disable-bt
# CONFIGURE UART1 FOR LEGACY MIDI USE, connecting UART1 TXD1 and RXD1 pins to GPIO pins 32 & 33, respectively
dtoverlay=uart1,txd1_pin=32,rxd1_pin=33
# midi-uart1: fake out tty driver so that baudrate 38400 yields 31250 for UART1
dtoverlay=midi-uart1

This is evidently not sufficient in 4.19 flavors. It sure would be good to understand why.

[s-maynard]

My organization has what seems to be the same problem using uart1 on a CM3/CM3+. We only have observed the problem since we switched over to testing 4.19.66. The 4.14.112 code we were previously using does not exhibit the problem.

@s-maynard Thanks for posting what may be a possible workaround. What is the meaning of the d600 in the name of your overlay file? - Does it have some specific meaning to your work or your environment, or is this something related to the Raspberry Pi with which I am unfamiliar?

apologies - the d600 is a product name for my company; I should have generalized the comment for all to consume...

[s-maynard]

PS. I am still on 4.14.112

[ghost]

@s-maynard Thanks much for the clarification about d600 potential meaning, and also for reporting that you are using 4.14.112. It seems that my issue of losing the ability to use uart1 in 4.19.66 as compared to 4.14.112 is a different problem than this issue 400, which is just related to having combined acceptable settings for uart1 in the overlays and config.txt, which does seem to be more of a doc issue. I may have to consider opening a separate issue. Thanks much again.

[ghost]

@DonMorr Were you able to get uart0 and uart1 to work in 4.19? (I noticed above your comments contained "linux-raspberrypi/1_4.19.27+gitAUTOINC+c0e09b3420-r0/").

Can anyone get it to work on 4.19.66? We can not, yet both work beautifully on 4.14.112.

[pbrkr]

The original issue seems to be resolved and there's a new issue open for the problem with the more recent kernel. Closing this.