Switching console UARTs on i.MX6S w/Android is crashing badly...

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Switching console UARTs on i.MX6S w/Android is crashing badly...

Jump to solution
4,473 Views
louiskoziarz
Contributor II

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

Labels (4)
0 Kudos
1 Solution
1,349 Views
lily_zhang
NXP Employee
NXP Employee

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.

View solution in original post

0 Kudos
3 Replies
1,350 Views
lily_zhang
NXP Employee
NXP Employee

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.

0 Kudos
1,349 Views
fushi_peng
NXP Employee
NXP Employee

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 .

0 Kudos
1,349 Views
louiskoziarz
Contributor II

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.

0 Kudos