AnsweredAssumed Answered

Kernel lock

Question asked by michael carrier on Jan 26, 2016
Latest reply on Jan 28, 2016 by michael carrier

We have a design based largely on the imx6ULevk. The code is build using yocto and the *.sdcard file is copied to the SD via dd command. The SD card is then inserted into the imx6ulevk, u-boot and the kernel boot as expected. If I take that same SD card and attempt to boot, u-boot is loaded by the IMX6ul ROM, u-boot runs and is able to see the mmc into which the SD card is inserted. U-boot is then able to extract the zImage and device tree blobs. The kernel then hangs. I have placed several printk statements into the kernel but our custom board seems to have trouble after the zImage is decompressed. Here is the output from our custom board:

 

reading zImage

6339800 bytes read in 329 ms (18.4 MiB/s)

Booting from mmc ...

reading imx6ul-14x14-evk.dtb

30156 bytes read in 20 ms (1.4 MiB/s)

Kernel image @ 0x80800000 [ 0x000000 - 0x60bcd8 ]

## Flattened Device Tree blob at 83000000

   Booting using the fdt blob at 0x83000000

   Using Device Tree in place at 83000000, end 8300a5cb

 

Starting kernel ...

 

Uncompressing Linux... done, booting the kernel.

 

Here is the output from the EVK:

 

reading zImage

6339800 bytes read in 328 ms (18.4 MiB/s)

Booting from mmc ...

reading imx6ul-14x14-evk.dtb

30156 bytes read in 20 ms (1.4 MiB/s)

Kernel image @ 0x80800000 [ 0x000000 - 0x60bcd8 ]

## Flattened Device Tree blob at 83000000

   Booting using the fdt blob at 0x83000000

   Using Device Tree in place at 83000000, end 8300a5cb

Starting kernel ...

Uncompressing Linux... done, booting the kernel.

start_kernel: Function Entered   <--------------------------my printk

start_kernel: Calling smp_setup_processor_id()<--------------------------my printk

smp_setup_processor_id: Function Entered<--------------------------my printk

Booting Linux on physical CPU 0x0

Linux version 3.14.38-6UL_ga+ge4944a5 (mac@ubuntu) (gcc version 4.9.2 (GCC) ) #18 SMP PREEMPT Tue Jan 26 15:58:27 CST 2016

 

 

At this point I would like to place a dump_stack() or similar call to see where arch/arm/boot/compressed/misc.c: decompress_kernel() returns to thereby allowing me to see where the kernel locks. Any thoughts?

Outcomes