Serial port corruption with 2.6.38

[PhilEndecott]

I am trying to build a 2.6.38 kernel. I have something that is basically functional, but the serial output is corrupt. It gives the impression that perhaps the clock speed is wrong, or something. It worked fine with my previous 2.6.35 kernel, and still works with uboot and the "Uncompressing.." message, but after that it produces garbage. I see that in my 2.6.35 tree, there is drivers/serial/imx.c and also drivers/serial/mxc_uart.c. I believe that the latter was used. Now in 2.6.38, there is only drivers/tty/serial/imx.c, which is used instead. Does anyone have any ideas what is going on here? Has anyone else seem symptoms like this?

[Noel_V]

Hi all

I'm using the latest patches (mxcuart_pm)  from freescale and I  seen to end up into the same situation.

I've  been putting a lot of kprintf's to get here .. as soon as the uart code reaches... mxcuart_pm..

the data on the console  is corrupted .....

Any hints ? the trick with the pll3 iso pll2 doens't seem to work for me.

Regards Noel



     

[fcs]

This is helpful

http://chezphil.org/tvcomputer/kernel.html

[MiroslavIMX53QS]

I found that problem was in my compiler. I used the latest codesourcery's compiler (2011.03-41), everything compiled fine but it didn't work. Then I tried earlier version (2009q1-203) and everything works perfect. Even a new kernel can be compiled and booted well.

[TroyKisky]

Hi Phil,

You can try this hack. We changed our u-boot to use pll3 like the previous kernel,

but this kernel assumes pll2. The linux code really should read the parent from registers.

diff --git a/arch/arm/mach-mx5/clock.c b/arch/arm/mach-mx5/clock.c
index d68d706..1139136 100644
--- a/arch/arm/mach-mx5/clock.c
+++ b/arch/arm/mach-mx5/clock.c
@@ -2126,7 +2126,7 @@ static int _clk_uart_set_parent(struct clk *clk, struct clk *parent)

 static struct clk uart_main_clk = {
        __INIT_CLK_DEBUG(uart_main_clk)
-       .parent = &pll2_sw_clk,
+       .parent = &pll3_sw_clk,
        .get_rate = _clk_uart_get_rate,
        .set_parent = _clk_uart_set_parent,
 };

[PhilEndecott]

It seems that 2.6.35_11.05.01 suffers half of this problem: the "early console" is OK, but it is corrupted once the "late" UART driver takes over. Looking at the diff between 2.6.35_11.04.01 and 2.6.35_11.05.01, I can see changes to arch/arm/mach-mx5/bus_freq.c, arch/arm/mach-mx5/clock.c and similar which are presumably related. They don't seem limited to the UART. I think it is probably best if I revert to 2.6.35_11.04.01. IT WOULD BE GREAT IF THIS WERE DOCUMENTED SOMEWHERE. Or if someone who actually understands it were reading this forum...

[rlorriaux]

I have not tested other peripherals. The serial not working made me switch my U-boot . I would use different SD Cards with different bootloaders.

[PhilEndecott]

I suppose I should also worry about whether any other clocks etc. have changed between the two versions of uboot i.e. are some other peripherals going to stop working too?

[PhilEndecott]

OK, so I guess u-boot does some sort of hardware initialisation and it sets up the uart clock source differently. Is this documented somewhere? This is rather annoying, since it makes it impossible to switch between different kernels at boot time. While I'm trying to build a new kernel, I'll want to change back and forth frequently. Perhaps I can change something in my 2.6.38 kernel to make it work with my old u-boot. Any suggestions?

[rlorriaux]

You need to make sure that you have a version of U-Boot that matches the kernel. In your case, you will want to use a newer version of U-Boot (look at the new 2011.09 Linux BSP).

[MiroslavIMX53QS]

I have a same problem. With 2.6.35 kernel there are some reasonable messages before it starts to produce garbage, but with 2.6.38 it starts to produce garbage after that message "Uncompressing...".