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