Hello all,
I'm working with the standard Freescale Linux and Android distribution (R13.4) on an i.MX6Solo board. This board was based off the SABRESD design so I'm using the sabresd_6dq-eng Android lunch combo.
I'd like the system (and Android) to use UART2 instead of UART1 for the runtime console. I'm not changing the board bringup files in arch/arm/mach-mx6 yet, but have just changed the kernel command line to suit (e.g. "console=ttymxc1,115200 .... androidboot.console=ttymxc1"). I've set the UART port pins appropriately in the pad mux array of the board-mx6q_sabresd.h/c files.
Right now, the kernel switches over to UART2 at the appropriate time in the process (after early console) and emits kernel boot info, but then the Android shell never comes up on ttymxc1/UART2 through this same serial port. So I know the hardware is working, but then when Android init takes over I lose the port.
Even more strangely, when I get into the system with "adb shell" via USB, set appropriate permissions on /dev/ttymxc*, then try to send a simple string out the OLD console port (e.g. echo "hi" > /dev/ttymxc0), the kernel hangs or panics (can't tell, since the consoles are down). Echoing to ttymxc1 is fine.
I've seen other threads asking if the mxc serial drivers are busted. Has anyone else seen something similar or can they try this on their Android systems?
Thanks,
Louis
Solved! Go to Solution.
Based on our experience, to change boot option on command line and make uart initialization right in driver should be OK.
From your description, if your log is destroyed after Android is running, please check your init.rc used /dev/ttymxc1 for other purpose. If like so, you should change init.rc accordingly.
Meanwhile, if you don't configuare hardware pins for /dev/ttymxc0, it won't work well. So i don't think /dev/ttymxc0 trial is meaningful.
Based on our experience, to change boot option on command line and make uart initialization right in driver should be OK.
From your description, if your log is destroyed after Android is running, please check your init.rc used /dev/ttymxc1 for other purpose. If like so, you should change init.rc accordingly.
Meanwhile, if you don't configuare hardware pins for /dev/ttymxc0, it won't work well. So i don't think /dev/ttymxc0 trial is meaningful.
Hi Louis,
Can you reference the board-mx6q_arm2.c and board-mx6q_sabresd.c , these boards use different UART for console.
Can you check your imx6q_xxxx_init_uart and early_console_setup .
Fushi,
My problem does not sit with the early console and UART setup in the kernel. The UARTs have initialized properly in the board setup (I'm using board-mx6q_sabresd.c) and switch ports at the proper time:
imx-uart.0: ttymxc0 at MMIO 0x2020000 (irq = 58) is a IMX
imx-uart.1: ttymxc1 at MMIO 0x21e8000 (irq = 59) is a IMX
console [ttymxc1] enabled, bootconsole disabled
And then the kernel finishes booting with output to ttymxc1 as expected. The panic happens when writing to ttymxc0 after this point.