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

Reply via email to