U-Boot (2020.10) fails to boot with either `dtoverlay=disable-bt` or `dtoverlay=miniuart-bt` (Pi 3B)

[lcnittl]

Describe the bug With either dtoverlay=disable-bt or dtoverlay=miniuart-bt set in usercfg.txt (or config.txt) the bootloader does not initiate. After powering on the Pi, it is stuck at the splash screen.

To reproduce

echo "dtoverlay=disable-bt"  >> /boot/firmware/usercfg.txt
reboot

also

echo "dtoverlay=miniuart-bt"  >> /boot/firmware/usercfg.txt
reboot

Expected behaviour Boot with bluetooth off.

Actual behaviour U-Boot does not even seem to start. No output, just stuck at the splash screen.

System

• Which model of Raspberry Pi? Pi3B
• Which OS and version (cat /etc/rpi-issue)? ubuntu 20.04
• Which firmware version (vcgencmd version)? 6379679d1ec6a8c746d7e77e015f5b56b939976f (clean) (release) (start)
• Which kernel version (uname -a)? Linux <hostname> 5.4.0-1022-raspi #25-Ubuntu SMP PREEMPT Thu Oct 15 14:22:53 UTC 2020 armv7l armv7l armv7l GNU/Linux

Additional context Same symptoms as in #1483, yet, (seemingly) different cause. An enable_uart=0 does, in my case, not cause this behavior.

Probably related: https://bugs.launchpad.net/snappy/+bug/1740655

To be honest: I am not sure where the problems lies: Is it at U-Boot or is it here in the firmware. (I would be surprised if it was ubuntu, as at this early stage of boot).

[pelwell]

You failed to state the firmware version, surely the most important information in the firmware repo.

[lcnittl]

Sorry, my bad. Wanted to add it in the end as I could not find it immediately and then forgot.

Now comes a stupid question: Ubuntu 20.04 LTS server for Raspberry Pi does not provide vcgencmd - Where can I install it from? If I deduced it correctly, it is part of libraspberrypi-bin which is supplied in an optional PPA. To this point, there are no packages for ubuntu 20 as it seems - I will try to find a way to enable install and report back.

In the meantime, I assume this does not help, right:

# apt list linux-firmware-raspi2
linux-firmware-raspi2/focal-updates,now 1.20200601+arm64-0ubuntu2~20.04.1 armhf

[lcnittl]

Managed to use the PPA from 18.04.

# vcgencmd version
Jun  1 2020 13:25:21
Copyright (c) 2012 Broadcom
version 6379679d1ec6a8c746d7e77e015f5b56b939976f (clean) (release) (start)

Added it to the OP.

[juergh]

Please report Ubuntu issues here: https://bugs.launchpad.net/ubuntu

[emilm]

I have my own dts for CM3+ . I experience a similar issue, where I apply the overlay miniuart-bt it locks up doring boot, not even starting kernel. My custom DTS doesn't need the overlay since I explicitly set uart0 pins to 14,15 etc.

It seems like there's something not liking that serial0 = &uart0 in aliases. That's how I narrowed down the problem. If I set serial0 = &uart1 and serial1 = &uart0, it boots fine. The overlays set serial0 = &uart0, serial1 = &uart1, which leads to the same problem.

[pelwell]

If U-boot is loading a different Device Tree to the one the firmware used then the firmware may activate the wrong UART and/or enable the wrong alternate functions on GPIOs 14&15. This can upset the UART driver to the extent that it stalls completely.

@emilm If you are not a U-boot user then this is the wrong place for your report.

[emilm]

@pelwell Thanks! I use u-boot.

file name "bcm2710-rpi-cm3.dts" which replaces the original. As you can see I incorporated the mini-bt overlay into the main dts file. Based on: https://github.com/raspberrypi/linux/blob/rpi-5.4.y/arch/arm/boot/dts/bcm2710-rpi-cm3.dts Incorporated https://github.com/raspberrypi/linux/blob/rpi-5.4.y/arch/arm/boot/dts/overlays/miniuart-bt-overlay.dts

raspberry pi kernel commit #eceb0d58aeca9f65fa5e8b9f7e263697a6534f27 Firmware commit #1eb8921ae7158249894f89e8bb6c4bfb04ec7377 libubootenv https://github.com/sbabic/libubootenv/commit/824551ac77bab1d0f7ae34d7a7c77b155240e754 uboot: https://source.denx.de/u-boot/u-boot/-/commit/303f8fed261020c1cb7da32dad63b610bf6873dd I have looked over this like 1000 times, and I just can't see what I am doing wrong. Pardon me if it's my fault :)

#include "bcm2710.dtsi"
#include "bcm2709-rpi.dtsi"
#include "bcm283x-rpi-csi0-2lane.dtsi"
#include "bcm283x-rpi-csi1-4lane.dtsi"
#include "bcm283x-rpi-i2c0mux_0_28.dtsi"

/ {
    compatible = "raspberrypi,3-compute-module", "brcm,bcm2837";
    model = "Raspberry Pi Compute Module 3";

    chosen {
        bootargs = "coherent_pool=1M 8250.nr_uarts=1";
    };

    aliases {
        serial0 = &uart0; // this causes the lock up / hang
        serial1 = &uart1;   
    };
};

&gpio {
    spi0_pins: spi0_pins {
        brcm,pins = <9 10 11>;
        brcm,function = <4>; /* alt0 */
    };

    spi0_cs_pins: spi0_cs_pins {
        brcm,pins = <8 7>;
        brcm,function = <1>; /* output */
    };

    i2c0_pins: i2c0 {
        brcm,pins = <0 1>;
        brcm,function = <4>;
    };

    i2c1_pins: i2c1 {
        brcm,pins = <2 3>;
        brcm,function = <4>;
    };

    i2s_pins: i2s {
        brcm,pins = <18 19 20 21>;
        brcm,function = <4>; /* alt0 */
    };

    bt_pins: bt_pins {
        brcm,pins = <43>;
        brcm,function = <4>; /* alt0:GPCLK2 */
        brcm,pull = <0>;
    };

    uart0_pins: uart0_pins {
        brcm,pins = <14 15>;
        brcm,function = <4>; /* alt0=UART0 */
        brcm,pull = <0 2>;
    };

    uart1_pins: uart1_pins {
        brcm,pins = <32 33>;
        brcm,function = <2>; /* alt5=UART1 */
        brcm,pull = <0 2>;
    };

    audio_pins: audio_pins {
        brcm,pins = <40 41>;
        brcm,function = <4>;
    };

    fake_bt_cts: fake_bt_cts {
            brcm,pins = <31>;
            brcm,function = <1>; /* output */
    };
};

&soc {
    virtgpio: virtgpio {
        compatible = "brcm,bcm2835-virtgpio";
        gpio-controller;
        #gpio-cells = <2>;
        firmware = <&firmware>;
        status = "okay";
    };

};

&firmware {
    expgpio: expgpio {
        compatible = "raspberrypi,firmware-gpio";
        gpio-controller;
        #gpio-cells = <2>;
        status = "okay";
    };
};

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

&uart1 {
    pinctrl-names = "default";
    pinctrl-0 = <&uart1_pins &bt_pins &fake_bt_cts>;
    status = "okay";

    minibt: bluetooth {
        compatible = "brcm,bcm43438-bt";
        max-speed = <460800>;
        shutdown-gpios = <&expgpio 0 GPIO_ACTIVE_HIGH>;
        status = "disabled";
    };
};

&spi0 {
    pinctrl-names = "default";
    pinctrl-0 = <&spi0_pins &spi0_cs_pins>;
    cs-gpios = <&gpio 8 1>, <&gpio 7 1>;

    spidev0: spidev@0{
        compatible = "spidev";
        reg = <0>;  /* CE0 */
        #address-cells = <1>;
        #size-cells = <0>;
        spi-max-frequency = <125000000>;
    };

    spidev1: spidev@1{
        compatible = "spidev";
        reg = <1>;  /* CE1 */
        #address-cells = <1>;
        #size-cells = <0>;
        spi-max-frequency = <125000000>;
    };
};

&i2c0if {
    clock-frequency = <100000>;
};

&i2c1 {
    pinctrl-names = "default";
    pinctrl-0 = <&i2c1_pins>;
    clock-frequency = <100000>;
    status = "okay";    
};

&i2c2 {
    clock-frequency = <100000>;
};

&i2s {
    pinctrl-names = "default";
    pinctrl-0 = <&i2s_pins>;
};

&leds {
    act_led: act {
        label = "led0";
        linux,default-trigger = "mmc0";
        gpios = <&virtgpio 0 0>;
    };
};

&hdmi {
    hpd-gpios = <&expgpio 4 GPIO_ACTIVE_LOW>;
};

&audio {
    pinctrl-names = "default";
    pinctrl-0 = <&audio_pins>;
};

/ {
    __overrides__ {
        act_led_gpio = <&act_led>,"gpios:4";
        act_led_activelow = <&act_led>,"gpios:8";
        act_led_trigger = <&act_led>,"linux,default-trigger";   

        krnbt = <&minibt>,"status";
    };
};

[pelwell]

Can you post your boot.scr?

[emilm]

Sure! boot.zip

[pelwell]

I don't know those mender_setup and mender_try_to_recover steps do, but it looks as though U-boot is configured to use the DTB passed in by the firmware, which is what I recommend.

Your cm3 DTS has more modifications than you list, including enabling audio on GPIOs 40&45 and moving the HDMI hotplug to GPIO 4 on the expander (which is unconnected). However, despite this I can boot a CM3 running the current Raspbian Lite overwritten with the most recent 5.4 kernel and the bcm2710-rpi-cm3.dtb compiled from your source. Can you try the same test?

[emilm]

Thanks! Does it matter whether it's CM3 or CM3+? I use CM3+

Yes it's a mender patched uboot I suppose, since that "meta-mender" layer in yocto probably modifies u-boot, which I forgot. I should try a "vanilla" u-boot: https://github.com/mendersoftware/meta-mender/tree/dunfell/meta-mender-raspberrypi/recipes-bsp Looks like config changes

And meta-raspberrypi: https://github.com/agherzan/meta-raspberrypi/blob/dunfell/recipes-bsp/u-boot/files/0001-dm-core-Move-ofdata_to_platdata-call-earlier.patch

I also enabled earlycon during testing:

Read File: config.txt, 36569
Read File: start_cd.elf, 793340 (bytes)
Read File: fixup_cd.dat, 3191 (bytes)

U-Boot 2020.01 (Jul 21 2021 - 16:27:30 +0000)

DRAM:  998 MiB
RPI Compute Module 3+ (0xa02100)

If the kernel has anything to say, shouldn't it show "starting kernel...." ? It halts here and shows nothing more. To me it seems not to reach the stage where it even begins starting it.

Thanks again for helping.

[pelwell]

Does it matter whether it's CM3 or CM3+? I use CM3+

No.

I also enabled earlycon during testing:

An incorrect earlycon can easily kill your boot. You have to get the write address for the chosen UART on your Pi, and it must match the non-earlycon usage (and any firmware/U-boot access as well).

What is your earlycon setting?

[pelwell]

And cmdline.txt and config.txt, while we're at it.

[emilm]

It was temporarily enabled to debug in cmdline.txt. It was taken out once I figured I didn't get more info. the DTS I posted was a stripped-down version as well, which I also tested to rule out other things. I used earlycon=pl011,mmio32,0x3f201000 in cmdline.txt but only temporary. It hangs without it too. config.zip

[emilm]

I downloaded Raspberry Pi OS Lite, and used it's kernel7.img in the boot partition, it came a lot further there so it has to be that somehow.

[emilm]

This is my uboot config uboot_config.txt Kernel config kernel_config.txt

Maybe I should turn on debug logging in u-boot?

[emilm]

I found the problem. This patch was not applied since I have a different machine name in yocto: https://github.com/agherzan/meta-raspberrypi/blob/dunfell/recipes-bsp/u-boot/files/0001-dm-core-Move-ofdata_to_platdata-call-earlier.patch I applied the patch correctly, and now it boots. I guess this is applied in later versions of u-boot. Very strange issue. This could explain related issues and why changing uboot image files / versions would work for CM3 and possibly other versions of PI.

[pelwell]

You did well to find the solution - I don't think it's at all obvious that the lack of that commit would cause your problem.

OK to close?

[emilm]

Thanks! It was very difficult to find the problem since I had to comb through all the code and see if it was applied. This is a modification to make u-boot work with CM3. The fix is done in the meta-raspberrypi yocto layer, but how is it in the source itself? Apparently it works since we tried the kernel7.img from raspberry pi OS.

I can see in later revisions of u-boot source that the section has been moved up to the same location, so it executes in the same order as the patched version

So basically - that uboot from that period won't work with CM3 unless patched. OK to close :)