Hi all,
I've been working on a project recently that uses a Raspberry Pi Compute Module
1, and it uses U-Boot as a bootloader. The main UART port is required for the
project, so the mini-UART is required to be used for the console. Unfortunately
I've not been able to get U-Boot to boot when enabling the mini-UART port, and
I'm only greeted by a rainbow splash screen when I enable it and select it for
use as the console.
Some background on the work I've done to get to this point:
- I'm using U-Boot 2019.10 as a base.
- I made a copy of /arch/arm/dts/bcm2835-rpi-cm1-io1.dts and appended the
following line to the end to enable the secondary UART port:
&uart1 {
pinctrl-names = "default";
pinctrl-0 = <&uart1_gpio14>;
status = "okay";
};
This new dts file is added to the Makefile and selected in KConfig.
- I modified /drivers/serial/serial_bcm283x_mu.c to remove the checks for pin
MUXing. Since this only checks GPIO14, it wasn't going to work when the pin is
actually on GPIO 40 and the check was useless for my purposes anyway.
- I set CONSOLE_CONS_INDEX to 2 (selecting serial1) in KConfig. This selects
the mini-UART which is set as serial1 in the aliases in
/arch/arc/dts/bcm283x.dtsi.
The result of this is that the rainbow splash screen comes up and nothing is
sent from either serial port. However if I set CONFIG_CONS_INDEX to 1, I get
output on the main UART port as normal.
Setting CONFIG_OF_BOARD instead of CONFIG_OF_EMBED makes no difference. There
was a time where I was able to get some early boot messages, and setting
CONFIG_CONS_INDEX to 2 did cause U-Boot to select the mini-UART, but the
messages stopped just before relocation. Again, changing the console index back
to 1 would select the main UART and the messages would continue all the way to
boot. I haven't been able to get these early messages to work recently however.
I have a slight suspicion that it may be something to do with pin MUXing, since
changing the uart0 pins in the device-tree to GPIO 32 causes the console to TX
over both GPIO 32 and GPIO 14, but nothing can be received on either port. This
doesn't seem like the correct behaviour.
At this point I'm really stuck. I'm able to modify the DTS to set the pin
MUXings (I hope anyway), and I can select the correct serial port, however I
can't debug this any further since the crash prevents any debug info from
coming out of the board on 2019.10, even if I enable early UART debugging.
Has anyone successfully managed to get this UART port working on the Compute
Modules? Or have any tips on how to debug it?
I'm very appreciative of any help I can get.
Kindest regards,
Ed