UART issue when setting RPI_USE_U_BOOT = "1"

[brocaar]

Description

I have a Raspberry Pi 3 with a GPS module connected to the UART interface. I'm using the thud branch of meta-raspberrypi to build images and all is working fine. When I cat /dev/ttyAMA0 I see NMEA messages coming in.

I created the following rpi-config_%.bbappend file to update the config.txt file:

do_deploy_append() {
    echo "dtparam=spi=on" >>${DEPLOYDIR}/bcm2835-bootfiles/config.txt
    echo "enable_uart=1" >>${DEPLOYDIR}/bcm2835-bootfiles/config.txt
}

do_deploy_append_raspberrypi3() {
    echo "core_freq=250" >>${DEPLOYDIR}/bcm2835-bootfiles/config.txt
    echo "dtoverlay=pi3-disable-bt" >>${DEPLOYDIR}/bcm2835-bootfiles/config.txt
}

When I add RPI_USE_U_BOOT = "1" to my configuration, the image is generated fine and the Raspberry Pi is booting using u-boot. However cat /dev/ttyAMA0 no longer returns any output.

Steps to reproduce the issue:

1. Add RPI_USE_U_BOOT = "1" to the configration

Describe the results you received:

After adding RPI_USE_U_BOOT = "1" and rebuilding the image, cat /dev/ttyAMA0 no longer returns any NMEA messages.

Describe the results you expected:

I was expecting to see NMEA messages when executing cat /dev/ttyAMA0 like I was able to without RPI_USE_U_BOOT = "1" in my configuration.

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

After adding RPI_USE_U_BOOT = "1", the config.txt still contains

dtparam=spi=on
enable_uart=1
core_freq=250
dtoverlay=pi3-disable-bt

Additional details (revisions used, host distro, etc.):

Using thud branch and raspberrypi3 as machine in my configuration.

Using the command mentioned here: https://unix.stackexchange.com/questions/289563/how-to-list-the-kernel-device-tree, I've created a dump of the device-tree when using RPI_USE_U_BOOT = "1" and without RPI_USE_U_BOOT = "1":

dt-no-uboot.txt dt-uboot.txt

I'm not an expert at this, but there doesn't seem to be any difference which is related to for example the pi3-disable-bt overlay not applied:

[nandra]

Good reference for using/configuring uarts on rpi can be found here: https://www.raspberrypi.org/documentation/configuration/uart.md

By adding pi3-disable-bt

 pi3-disable-bt disables the Bluetooth device and restores UART0/ttyAMA0 to GPIOs 14 and 15. It is also necessary to disable the system service that initialises the modem so it doesn't use the UART: 

you add AMA0 to gpio14 and 15 and I assume your GPS module is connected to other pins? I would try without pi3-disable-bt option.

[brocaar]

@nandra but if that would be the case, would it matter if I have RPI_USE_U_BOOT = "1" or not in my configuration?

As I tried to explain, without RPI_USE_U_BOOT = "1" the GPS works as expected, but after adding RPI_USE_U_BOOT = "1" it no longer works.

[nandra]

@brocaar I don't think so. You can first try to drop RPI_USE_UBOOT -> this will only to jump to u-boot instead of kernel directly (then u-boot load uImage and continue with booting). So you want to say that it works without RPI_USE_UBOOT and with additions in config.txt? Thx.

[brocaar]

@nandra yes that is correct. When buiding an image without RPI_USE_UBOOT = "1", the GPS works fine. When I generate an image with boots using u-boot (thus RPI_USE_UBOOT = "1"), it does not work.

Please also see my initial post with the diff of /proc/device-tree which doesn't seem to be much different. I'm not an expert in this, but to me it seems that the issue is caused by adding u-boot to the boot sequence.

I am aware that dropping the RPI_USE_UBOOT config will boot the kernel directly, however I do need u-boot as I wish to integrate Mender (https://mender.io/) (actually I noticed the GPS issue after integrating Mender as I needed the RPI_USE_UBOOT config for this integration).

[brocaar]

See also: https://github.com/brocaar/lora-gateway-os/tree/uart_debug for my recipes, and https://www.dropbox.com/sh/5cbrm0lfcfnzge5/AABNiUKy5b5WhukIhiTjO1Lta?dl=0 for an image with and one without u-boot in case that would help debugging this issue.

The difference in these images is keeping / removing this configuration line: https://github.com/brocaar/lora-gateway-os/blob/uart_debug/layers/targets/meta-raspberrypi/conf/layer.conf#L14.

[nandra]

@brocaar ok I see. Just guessing could be possible that systemd will start getty on ttyAMA0 and it could be reason why you don't get data out of it? IIRC mender using systemd by default. But this is only hint not direct help ;). Also s it's related to mender integration you can ask maybe on hub.mender.io forum (did you try enable u-boot without mender and verify results?) Thx

[brocaar]

@nandra This is not the issue. To reproduce the issue, I completely removed the Mender integration to make sure it was not caused by Mender. Also I'm not using systemd in my images.

[nandra]

@brocaar ok fine so have no more ideas, sorry ;).

[mirzak]

Jumping in here with some ideas :).

I know of people that has had similar issue, and unfortunately I do not know of any exact solution.

But I largely suspect that the code in U-boot is interfering and this might be better suited for the U-boot mailing list, or at least bring it up there as well.

One thing that I would look in to is the U-boot built in device tree, it does some pinmuxing on uarts which might override what you set in config.txt. This, https://github.com/u-boot/u-boot/blob/master/arch/arm/dts/bcm2837-rpi-3-b.dts#L22-L34

And I would try to go trough the U-boot source trying to disable all attempts to configure serial ports.

[brocaar]

@mirzak thanks! That indeed seems to be the issue. After the patch below, I finally was able to access my GPS module (cat /dev/ttyAMA0) :-) I also had to make sure that the GPS module would not write to u-boot as it would interrupt the boot process. See also: https://stackoverflow.com/a/40367443.

diff --git a/arch/arm/dts/bcm2837-rpi-3-b.dts b/arch/arm/dts/bcm2837-rpi-3-b.dts
index 20725ca487..96cc179b88 100644
--- a/arch/arm/dts/bcm2837-rpi-3-b.dts
+++ b/arch/arm/dts/bcm2837-rpi-3-b.dts
@@ -19,20 +19,6 @@
    };
 };

-/* uart0 communicates with the BT module */
-&uart0 {
-   pinctrl-names = "default";
-   pinctrl-0 = <&uart0_gpio32 &gpclk2_gpio43>;
-   status = "okay";
-};
-
-/* uart1 is mapped to the pin header */
-&uart1 {
-   pinctrl-names = "default";
-   pinctrl-0 = <&uart1_gpio14>;
-   status = "okay";
-};
-
 /* SDHCI is used to control the SDIO for wireless */
 &sdhci {
    pinctrl-names = "default";
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index 153a1fdcb7..322ceb35e1 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -491,3 +491,10 @@ int ft_board_setup(void *blob, bd_t *bd)

    return 0;
 }
+
+int board_early_init_f(void)
+{
+   gd->flags |= (GD_FLG_SILENT | GD_FLG_DISABLE_CONSOLE);
+   return 0;
+}
+
diff --git a/configs/rpi_3_32b_defconfig b/configs/rpi_3_32b_defconfig
index bbf902bb91..a92a0f8973 100644
--- a/configs/rpi_3_32b_defconfig
+++ b/configs/rpi_3_32b_defconfig
@@ -41,3 +41,4 @@ CONFIG_SYS_WHITE_ON_BLACK=y
 CONFIG_CONSOLE_SCROLL_LINES=10
 CONFIG_PHYS_TO_BUS=y
 CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_BOOTDELAY=0
diff --git a/include/configs/rpi.h b/include/configs/rpi.h
index 9ce41767a9..12cb89a891 100644
--- a/include/configs/rpi.h
+++ b/include/configs/rpi.h
@@ -160,5 +160,9 @@
    ENV_MEM_LAYOUT_SETTINGS \
    BOOTENV

+#define CONFIG_DISABLE_CONSOLE
+#define CONFIG_SILENT_CONSOLE
+#define CONFIG_SYS_DEVICE_NULLDEV
+#define CONFIG_BOARD_EARLY_INIT_F 1

 #endif

[agherzan]

@brocaar if you report this in uboot please link us here as well. We should fix this there.

[brocaar]

I have posted it on the mailinglist with a link to this issue. It is awaiting moderator approval.

[Romaxx]

I have a similar issue, I am working on a custom PI HAT using true UART (used by BT but disabled with pi3-disable-bt), this HAT supply COM terminal, u-boot seems to send some data over this UART during boot procedure (probably the default ttyS0 serial console), my board respond and the boot fail. I'm investigating on how to resolve that. Another issue, I've tried to add uEnv.txt to restrict boot_targets=mmc0 but u-boot dont read it, it read only boot.scr (is the uEnv.txt supported by the u-boot mainline ?) @mirzak thank you.

[Romaxx]

I have some responses, for u-boot, default config is 'stdout=serial,vidconsole' (https://github.com/u-boot/u-boot/blob/master/include/configs/rpi.h line 88), so data is written on serial during boot, @brocaar GSM UART receive this data and the buffer could be filled with uncomprehending datas, causing unresponsive UART when the PI take the UART after u-boot, remove serial from stdout, stderr and stdin to resolve issue. for uEnv.txt, new board configuration use "config_distro_bootcmd.h", uEnv is obsolete.

[bderuijsscher]

After patching the U-boot recipe to disable console output during U-boot phase (thanks @Romaxx) I noticed that the ENABLE_UART="1" directive still introduced the serial0 console in the Linux kernel. This resulted in /dev/ttyS0 from being present but unavailable for our application since it was used as a console device.

Probably not the most elegant way of fixing this - but I thought worth mentioning - was to patch the meta-raspberrypi layer directly after cloning the repository by removing the console output from the cmdline.txt boot config:

sed -i 's/console=serial0,115200/console=tty1/g' ${BASE}/src/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi.inc

(This can safely be done since I am using a fork of an initialisation script to (re)construct a reproducible build environment https://gist.github.com/drewmoseley/816701ec0ca30d495786f03afea518dc )

[agherzan]

ENABLE_UART enables the cmdline as well. We could improve this with some additional logic but also you can redefine CMDLINE (https://github.com/agherzan/meta-raspberrypi/blob/master/recipes-kernel/linux/linux-raspberrypi.inc#L25) in a bbappend or in local.conf for example.

CMDLINE = "dwc_otg.lpm_enable=0 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait"

[bderuijsscher]

hello @agherzan yes manually adding this CMDLINE to local.conf is a way more elegant solution. Thanks for pointing that out.

Is there any easy way to skip this boot delay in U-Boot entirely? I have read that it should be possible to instruct U-Boot to have bootdelay=0.

I have managed to accomplish this manually by interactively enter the commands in the uboot prompt:

setenv bootdelay 0
saveenv

Any suggestions how to add this automatically in a Yocto build process, Preferably in local.conf?.

Thanks in advance

[agherzan]

You can patch uboot for that. See an example here: https://github.com/balena-os/balena-raspberrypi/pull/270

[minusplusminus]

HI everyone,

I'm currently using mender-convert to patch my raspbian img Linux 4.9.184-linuxkit x86_64 for my rpi 3. I'm using Waveshare SIM7600E-H_4G_HAT that I connect using an USB port so I can create an direct 4G internet connection using qmicli I disable the ttyAMA0.service.

To send AT commands, I use/dev/ttyAMA0 and set enable_uart=1 and dtoverlay=pi3-disable-bt in /boot/config.txt

Currently it's boken after running mender-convert. It's unclear for me wat I have to do to fix this issue using mender-convert. As far as I can see I have to:

1. patch mender-convert file convert-stage-4.sh and replace meta_mender_repo="https://raw.githubusercontent.com/mendersoftware/meta-mender" with forked and patched version.
2. Modify meta-mender layer named meta-raspberrypi with forked and patch proposed by brocaar.

Is there a more direct way for this?

Thanks

[nandra]

IIRC you need to patch u-boot not mender. I think best would be ask on hub.mender.io instead here as you can get feedback from people familiar with problematic :)

[pbrkr]

@agherzan The original issue here seems to have been passed up to the u-boot list, I recommend we close this issue. If others (@Romaxx, @bderuijsscher, @minusplusminus) still have problems they should be opened as new issues.