Serial port corruption with 2.6.38

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

Serial port corruption with 2.6.38

1,755 Views
PhilEndecott
Contributor II
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?
Labels (1)
0 Kudos
10 Replies

1,204 Views
Noel_V
Contributor III


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



     

0 Kudos

1,204 Views
fcs
Contributor IV
0 Kudos

1,204 Views
MiroslavIMX53QS
Contributor I
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.
0 Kudos

1,204 Views
TroyKisky
Contributor II

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,
 };

0 Kudos

1,204 Views
PhilEndecott
Contributor II
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...
0 Kudos

1,204 Views
rlorriaux
Contributor I
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.
0 Kudos

1,204 Views
PhilEndecott
Contributor II
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?
0 Kudos

1,204 Views
PhilEndecott
Contributor II
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?
0 Kudos

1,204 Views
rlorriaux
Contributor I

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).

0 Kudos

1,204 Views
MiroslavIMX53QS
Contributor I
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...".
0 Kudos