QSB -hangs often on -> CPU is i.MX53 Revision 2.1

Showing results for 
Search instead for 
Did you mean: 

QSB -hangs often on -> CPU is i.MX53 Revision 2.1

Contributor III

Hi all,

I wonder is there a kernel that should be stable for the (imx53) QSB?

Th reason why I ask this is quite simple, I've been digging nog for multiple days into multiple kernel versions in oder to come up with something stable.. which seems not to be trivial.

I've been trying to run different kernel versions .. like Freescale-kernels 2.6.35.x , 2.6.38.x ..  , linaro kernels, Official kernel(s).. etc... and every time I change kernel version I have to face (debug) into another problem.

In 99% of the cases the QSB , hangs on the same 'textual' output line... (in other words this is the last line I see.)

CPU is i.MX53 Revision 2.1   

=> THIS is the LAST thing I See and the QSB hangs for-ever.


a) when booting from power-up .... you have a 50% posibility that it boots fine (in the other 50% the system hangs)

b) when 'soft-rebooting (with reboot command) it almost hangs in 99% of the boots.

Anyone that has a clue where to look at ?

Kind regards,


<< snippet - boot-log >>

P: ARMv7 Processor [412fc085] revision 5 (ARMv7), cr=10c53c7f
CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Machine: Freescale MX53 LOCO Board
Memory policy: ECC disabled, Data cache writeback
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 250880
Kernel command line: console=ttymxc0,115200 video=mxcdi1fb:GBR24,XGA di1_primary
 tve root=/dev/nfs ip=dhcp nfsroot=
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 480MB 512MB = 992MB total
Memory: 998332k/998332k available, 17476k reserved, 0K highmem
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    DMA     : 0xf9e00000 - 0xffe00000   (  96 MB)
    vmalloc : 0xe0800000 - 0xf4000000   ( 312 MB)
    lowmem  : 0x80000000 - 0xe0000000   (1536 MB)
    pkmap   : 0x7fe00000 - 0x80000000   (   2 MB)
    modules : 0x7f000000 - 0x7fe00000   (  14 MB)
      .init : 0x80008000 - 0x80026000   ( 120 kB)
      .text : 0x80026000 - 0x807ee000   (7968 kB)
      .data : 0x8080e000 - 0x80856940   ( 291 kB)
LB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
Hierarchical RCU implementation.
        RCU-based detection of stalled CPUs is disabled.
        Verbose stalled-CPUs detection is disabled.
MXC GPIO hardware
MXC IRQ initialized
MXC_Early serial console at MMIO 0x53fbc000 (options '115200')
bootconsole [ttymxc0] enabled
Console: colour dummy device 80x30
Calibrating delay loop... 799.53 BogoMIPS (lpj=3997696)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
devtmpfs: initialized
regulator: core version 0.5
NET: Registered protocol family 16
i.MX IRAM pool: 128 KB@0xe0840000
CPU is i.MX53 Revision 2.1

Tags (1)
0 Kudos
4 Replies

Contributor III

Hi Roy,

I can confirm, that I get my QSB-board booting 2.6.35_11.09, I've been booting 20 times now and, it was booting all the time with the kernel that was hanging before.)

a) With this change you described it was working (20 times booted, booting all the time)

b) With the LATEST official u-boot (2011.12) it is also working  (20 times booted, booting all the time)

c) Even the "reboot" command does now work , in other words is booting fine on "reboot" as well.

Hope it keeps on booting...

Regards, and thanks for the info.


0 Kudos

Contributor II

I had a similar problem with our design (also MC34708 based), which was related to memory timing. The thread is http://imxcommunity.org/group/imx53hardwaredesign/forum/topics/startup-problem-from-h-w-reset although I think that the patch is included in the source files for the MC34708 version. It might be worth checking that you have included it.



0 Kudos

Contributor III

Hi, David,

Thanks for the response,

>>My hanging experience is currently limited to 2.6.38,

>>i was using a 3.1 or 3.2 kernel before without any problems - but I had to change to get video drivers.

Video: Well this is also the reason why I have switched back to 2.6.35_11.09  (and / or 2.6.38).. And like you say in 3.1 I did not have look-ups.

I my case I'm sure that If I get it running (power-up succeeds) , then I will have a look-up when I type 'reboot' at the command prompt.

The problem I have is is that I'm using a QSB (with DA9053 pmic).

We designing a own board with the iMX53x and the MC34708 pmic ( this board will be ready in a couple of weeks, so at this time I'm still testing with the QSB).

This is the reason why I change to a more recent kernel that contains MC34708 pmic related code.

Yesterday I did as a test switch back to 2.6.35 (freescale web- 2.6.35._11.01) that does not have MC34708 pmic code and it seems better, it does not lock up that often. (boots fine in 80% of the cases)

In order to have MC34708 pmic code I use  2.6.35_11.09 and this is fails all the time on my QSB. ( have to reboot more then 10 times to get to the login prompt, and a soft-reboot locks-up all the time.)

Regards Noel

0 Kudos

Contributor I

I do not have an answer and have not attempted to try to debug this, but I have had similar behavior - though I have not analyzed it to the extent you have.

My hanging experience is currently limited to 2.6.38, i was using a 3.1 or 3.2 kernel before without any problems - but I had to change to get video drivers. 

I am pretty sure I am not hanging at the same place each time,

I often get very close to a console login.  I have not noticed any condition that produces a 99% chance of lockup.

I am generally succeeding in booting about 1 in 3 times.

I feel like the problem only started recently, and has slowly been getting worse.

I have another board arriving shortly to see if I get the same behavior, as I was worried that I might have done something to my board.

0 Kudos