topic Re: kernel boot problems with iMX6D running with 16bit DDR in i.MX Processors

kernel boot problems with iMX6D running with 16bit DDR

EdSutter — Mon, 27 Jan 2014 21:05:55 GMT

I've built and run with linux-3.12 mainline and it actually runs (with quirks) on my custom hardware.

Now, to get over some of those quirks, I've stepped back to using the code from git.freescale.com

(imx_3.0.35_4.1.0). Now I see nothing at bootup after the initial decompression message...

Uncompressing Linux... done, booting the kernel.

This obviously works fine when I use the SABRESD eval board ( and note I was able to boot 3.12 on my hardware to a linux command prompt.

My custom hardware is running with an imx6D and only x16 DDR memory at the moment.

When I dump the log_buffer (I'm able to soft reset my board when it hangs), I see this output:

U-Boot > md.b 10afdcd8 512

10afdcd8: 3c 35 3e 4c 69 6e 75 78 20 76 65 72 73 69 6f 6e <5>Linux version

10afdce8: 20 33 2e 30 2e 33 35 2d 30 33 30 35 33 2d 67 38 3.0.35-03053-g8

10afdcf8: 64 32 62 31 36 39 2d 64 69 72 74 79 20 28 65 6c d2b169-dirty (el

10afdd08: 73 40 65 6c 73 6c 69 6e 75 78 31 29 20 28 67 63 s@elslinux1) (gc

10afdd18: 63 20 76 65 72 73 69 6f 6e 20 34 2e 37 2e 33 20 c version 4.7.3

10afdd28: 28 53 6f 75 72 63 65 72 79 20 43 6f 64 65 42 65 (Sourcery CodeBe

10afdd38: 6e 63 68 20 4c 69 74 65 20 32 30 31 33 2e 30 35 nch Lite 2013.05

10afdd48: 2d 32 34 29 20 29 20 23 39 20 53 4d 50 20 50 52 -24) ) #9 SMP PR

10afdd58: 45 45 4d 50 54 20 4d 6f 6e 20 4a 61 6e 20 32 37 EEMPT Mon Jan 27

10afdd68: 20 31 34 3a 32 33 3a 33 38 20 45 53 54 20 32 30 14:23:38 EST 20

10afdd78: 31 34 0a 3c 31 3e 43 50 00 00 00 00 00 00 00 00 14.<1>CP........

10afdd88: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

10afdd98: 00 00 00 00 00 00 00 00 76 69 73 69 6f 6e 20 31 ........vision 1

10afdda8: 30 20 28 41 52 4d 76 37 29 2c 20 63 72 3d 31 30 0 (ARMv7), cr=10

10afddb8: 63 35 33 63 37 64 0a 3c 00 00 00 00 00 00 00 00 c53c7d.<........

10afddc8: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

10afddd8: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

10afdde8: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

10afddf8: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

10afde08: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

10afde18: 00 00 00 00 00 00 00 00 51 75 61 64 2f 44 75 61 ........Quad/Dua

10afde28: 6c 4c 69 74 65 2f 53 6f 6c 6f 20 53 61 62 72 65 lLite/Solo Sabre

10afde38: 2d 53 44 20 42 6f 61 72 64 0a 00 00 00 00 00 00 -SD Board.......

10afde48: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

10afde58: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

10afde68: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

10afde78: 00 00 00 00 00 00 00 00 63 69 6e 67 3a 20 45 52 ........cing: ER

10afde88: 52 4f 52 3a 20 46 61 69 6c 65 64 20 74 6f 20 61 ROR: Failed to a

10afde98: 6c 6c 6f 63 61 74 65 20 00 00 00 00 00 00 00 00 llocate ........

10afdea8: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

10afdeb8: 00 00 00 00 00 00 00 00 2e 0a 3c 30 3e 0a 3c 31 ..........<0>.<1

10afdec8: 3e 5b 3c 38 30 30 34 63 39 34 63 3e 5d 20 28 75 >[<8004c94c>] (u

10afded8: 6e 77 69 6e 64 5f 62 61 63 6b 74 72 61 63 65 2b nwind_backtrace+

10afdee8: 30 78 30 2f 30 78 66 38 29 20 66 72 6f 6d 20 5b 0x0/0xf8) from [

10afdef8: 3c 38 30 35 30 66 32 62 00 00 00 00 00 00 00 00 <8050f2b........

10afdf08: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

10afdf18: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

10afdf28: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

10afdf38: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

10afdf48: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

10afdf58: 00 00 00 00 00 00 00 00 2b 30 78 33 34 2f 30 78 ........+0x34/0x

10afdf68: 33 63 29 0a 3c 31 3e 5b 3c 38 30 30 31 61 62 61 3c).<1>[<8001aba

10afdf78: 63 3e 5d 20 28 6d 65 6d 62 6c 6f 63 6b 5f 61 6c c>] (memblock_al

10afdf88: 6c 6f 63 5f 62 61 73 65 2b 30 78 33 34 2f 30 78 loc_base+0x34/0x

10afdf98: 33 63 29 20 66 72 6f 6d 00 00 00 00 00 00 00 00 3c) from........

10afdfa8: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

10afdfb8: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

10afdfc8: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

10afdfd8: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

10afdfe8: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

10afdff8: 00 00 00 00 00 00 00 00 66 72 6f 6d 20 5b 3c 38 ........from [<8

10afe008: 30 30 30 61 64 30 34 3e 5d 20 28 61 72 6d 5f 6d 000ad04>] (arm_m

10afe018: 65 6d 62 6c 6f 63 6b 5f 00 00 00 00 00 00 00 00 emblock_........

10afe028: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

10afe038: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

10afe048: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

10afe058: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

10afe068: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

10afe078: 00 00 00 00 00 00 00 00 63 2f 30 78 36 65 63 29 ........c/0x6ec)

10afe088: 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

10afe098: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

10afe0a8: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

10afe0b8: 00 00 00 00 00 00 00 00 34 3e 5d 20 28 73 74 61 ........4>] (sta

10afe0c8: 72 74 5f 6b 65 72 6e 65 6c 2b 30 78 39 30 2f 30 rt_kernel+0x90/0

10afe0d8: 78 32 39 34 29 0a 00 00 00 00 00 00 00 00 00 00 x294)...........

10afe0e8: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

10afe0f8: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

10afe108: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

10afe118: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

10afe128: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

10afe138: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

10afe148: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

10afe158: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

10afe168: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

10afe178: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

10afe188: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

10afe198: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

10afe1a8: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

10afe1b8: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

10afe1c8: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

10afe1d8: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

10afe1e8: 00 00

Any thoughts on what might be going on here?

I'm guessing it has something to do with the fact that I have x16 DDR right now;

but I can't point to anything specific in the kernel.

More information (EDIT)...

I rebuilt the kernel with i/d cache disabled and the log buffer is more sane...

Linux version 3.0.35-03053-g8d2b169-dirty (els@elslinux1) (gcc version 4.7.3 (Sourcery CodeBench Lite 2013.05-24) )#

14 SMP PREEMPT Mon Jan 27 16:17:21 EST 2014.

CPU: ARM v7 Processor [41 2fc09a] revision 10 (ARMv7), cr= 10c52c79.

CPU: VIPT nonaliasin g data cache, VI PT aliasing inst ruction cache.

Machine: Freescale i.MX 6Quad/D ualLite/Solo Sab re-SD Board.

debug: ignoring loglevel setting. .

Kernel panic - not syncing: ERROR: Failed to allocate 0x8000000 bytes below 0x40000000...

[<8004c94c>] (unwind_backtrac e+0x0/0xf8) from [<8050f2b8>] (p anic+0x70/0x190) .

[<8050f2b8>] (panic+0x70/0x1 90) from [<8001abd4>] (memblock_alloc_base+0x34/ 0x3c).

[<8001abd4>] (memblock_alloc_base+0x34/0x3c) from [<8000f78c>] (mx6q_sabresd_reserve+0x54/0x68).

[<8000f78c>] (mx6q_sabresd_reserve+0x54/0x68) from [<8000ad04>] (arm_memblock_init+0x90/0xa0).

[<8000ad04>] (arm_memblock_init+0x90/0xa0) from [<80009e28>] (setup_arch+0x4ac/0x6ec).

[<80009e28>] (setup_arch+0x4ac/0x6ec) from[<800086c4>] (start_kernel+0x90/0x294).

[<800086c4>] (start_kernel+0x90/0x294 from [<10008040>] (0x10008040)

Message was edited by: Ed Sutter

Re: kernel boot problems with iMX6D running with 16bit DDR

EdSutter — Mon, 27 Jan 2014 21:47:16 GMT

Replying to my own post here...

There's a function called mx6q_sabresd_reserve() that appears to be attempting to allocate more memory than

is on my board (.25Gig right now), so I think I'm getting close...

Re: kernel boot problems with iMX6D running with 16bit DDR

EdSutter — Mon, 27 Jan 2014 21:56:54 GMT

More...

I found that disabling CONFIG_MXC_GPU_VIV got me over the initial hump.

Now I get kernel output at startup and it locks up at i.MXC CPU frequency driver

Re: kernel boot problems with iMX6D running with 16bit DDR

MarekVasut — Mon, 27 Jan 2014 22:58:21 GMT

Are you passing the correct memory size and placement to the kernel ? I think the DRAM location is different on MX6Solo and MX6Quad ... that might cause the discrepancy with the memory allocator. Try pasting 'bdinfo' output from U-Boot in here.

Re: Re: kernel boot problems with iMX6D running with 16bit DDR

EdSutter — Tue, 28 Jan 2014 13:24:42 GMT

Marek,

Thanks for responding...

On my SABRESD board, the bdinfo is this:

U-Boot > bdinfo

arch_number = 0x00000F8C

boot_params = 0x10000100

DRAM bank = 0x00000000

-> start = 0x10000000

-> size = 0x40000000

eth0name = FEC

ethaddr = 00:04:9f:02:69:e3

current eth = FEC

ip_addr = <NULL>

baudrate = 115200 bps

TLB addr = 0x4FFF0000

relocaddr = 0x4FF76000

reloc off = 0x38776000

irq_sp = 0x4F573F38

sp start = 0x4F573F28

FB base = 0x00000000

On my custom hardware, with a slightly slimmed down uboot, bdinfo is this:

U-Boot > bdinfo

arch_number = 0x00000F8C

boot_params = 0x10000100

DRAM bank = 0x00000000

-> start = 0x10000000

-> size = 0x10000000

eth0name = FEC

ethaddr = 00:60:1d:02:09:05

current eth = FEC

ip_addr = <NULL>

baudrate = 115200 bps

TLB addr = 0x1FFF0000

relocaddr = 0x1FF85000

reloc off = 0x08785000

irq_sp = 0x1F582F40

sp start = 0x1F582F30

This reflects the smaller memory size correctly as far as I can tell.

The only other difference is that I disabled the frame-buffer code in my custom u-boot,

but I didn't do the equivalent in the kernel... Will look into that...

Re: Re: kernel boot problems with iMX6D running with 16bit DDR

MarekVasut — Tue, 28 Jan 2014 19:50:57 GMT

OK, I suspect that must be something funny with the Freescale BSP. Sorry, but I don't think I can be of more help .

Re: kernel boot problems with iMX6D running with 16bit DDR

EdSutter — Sat, 01 Feb 2014 16:53:56 GMT

I'm still getting beat up by this kernel boot...

The board I'm booting is a very minimal module, the only thing on board (that is applicable to this bootup) is console UART, Ethernet and .25G DRAM. It boots from SPI-NOR flash, and eventually will also run with eMMC. Note also that I am running with an iMX6D, not an iMX6Q. The periphery I mentioned is wired the same as the SABRESD (except that at the moment my DRAM is only 16bits wide). Note that I do not have a PMIC of any kind on this module, no USB periphery, and no multimedia interfaces. I need the kernel to be able to boot this (admittedly very minimal) platform.

For uboot, I started with u-boot-2013.10 from denx and modified it for this hw. For kernel, I started with git clone http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git. Note that I have used this combination on a SABRESD platform and it boots just fine; so I am assuming the issues are related to pruning down the kernel to match my custom board's periphery.

I believe uboot is in good shape. It boots fine and network access is intact. I've modified uboot so that it passes a unique machine-id so that the kernel will use my custom startup code under arch/arm/mach-mx6. I started by simply duplicating the board-mx6q_sabresd.c to board-mx6d_custom.c, and modified the MACHINE_START macro at the base of the file to use this new machine id. I also modified Kconfig in that directory with a new MACH_MX6D_CUSTOM that

initially looks just like MACH_MX6Q_SABRESD. This, I believe (someone please correct me if I'm wrong), allows me to run the same kernel on my hardware and the SABRESD; because uboot on my board will pass the kernel a different machine-id than uboot on SABRESD.

I start with make imx6_defconfig; and (as described above) I disable CONFIG_MXC_GPU_VIV. That allows the kernel log to start printing at the console.

Then it locks up at i.MXC CPU frequency driver...

Linux version 3.0.35-03053-g8d2b169-dirty (els@elslinux1) (gcc version 4.7.3 (Sourcery CodeBench Lite 2013.05-

24) ) #1 SMP PREEMPT Sat Feb 1 11:33:03 EST 2014

CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c53c7d

CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache

Machine: Custom i.MX6D Board

Memory policy: ECC disabled, Data cache writealloc

CPU identified as i.MX6Q, silicon rev 1.2

PERCPU: Embedded 7 pages/cpu @80d0a000 s5440 r8192 d15040 u32768

Built 1 zonelists in Zone order, mobility grouping off. Total pages: 32256

Kernel command line: console=ttymxc0,115200 root=/dev/nfs ip=dhcp nfsroot=135.222.138.108:/home/els/imx6/pass4

/rootfs/buildroot-2013.08/my_rootfs,v3,tcp

PID hash table entries: 512 (order: -1, 2048 bytes)

Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)

Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)

Memory: 128MB = 128MB total

Memory: 117556k/117556k available, 144588k reserved, 0K highmem

Virtual kernel memory layout:

vector : 0xffff0000 - 0xffff1000 ( 4 kB)

fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)

DMA : 0xf4600000 - 0xffe00000 ( 184 MB)

vmalloc : 0x90800000 - 0xf2000000 (1560 MB)

lowmem : 0x80000000 - 0x90000000 ( 256 MB)

pkmap : 0x7fe00000 - 0x80000000 ( 2 MB)

modules : 0x7f000000 - 0x7fe00000 ( 14 MB)

.init : 0x80008000 - 0x8003e000 ( 216 kB)

.text : 0x8003e000 - 0x80a70034 (10441 kB)

.data : 0x80a72000 - 0x80ad76c0 ( 406 kB)

.bss : 0x80ad76e4 - 0x80b0546c ( 184 kB)

SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=2, Nodes=1

Preemptible hierarchical RCU implementation.

NR_IRQS:624

MXC GPIO hardware

sched_clock: 32 bits at 3000kHz, resolution 333ns, wraps every 1431655ms

arm_max_freq=800MHz

MXC_Early serial console at MMIO 0x2020000 (options '115200')

bootconsole [ttymxc0] enabled

Console: colour dummy device 80x30

Calibrating delay loop... 1581.05 BogoMIPS (lpj=7905280)

pid_max: default: 32768 minimum: 301

Mount-cache hash table entries: 512

CPU: Testing write buffer coherency: ok

hw perfevents: enabled with ARMv7 Cortex-A9 PMU driver, 7 counters available

CPU1: Booted secondary processor

Brought up 2 CPUs

SMP: Total of 2 processors activated (3162.11 BogoMIPS).

print_constraints: dummy:

NET: Registered protocol family 16

*************************************iram init

print_constraints: vddpu: 725 <--> 1300 mV at 1150 mV fast normal

print_constraints: vddcore: 725 <--> 1300 mV at 1150 mV fast normal

print_constraints: vddsoc: 725 <--> 1300 mV at 1200 mV fast normal

print_constraints: vdd2p5: 2000 <--> 2775 mV at 2400 mV fast normal

print_constraints: vdd1p1: 800 <--> 1400 mV at 1100 mV fast normal

print_constraints: vdd3p0: 2625 <--> 3400 mV at 3000 mV fast normal

********************************mx6_vsm400_board_init completed!

hw-breakpoint: found 6 breakpoint and 1 watchpoint registers.

hw-breakpoint: 1 breakpoint(s) reserved for watchpoint single-step.

hw-breakpoint: maximum watchpoint size is 4 bytes.

L310 cache controller enabled

l2x0: 16 ways, CACHE_ID 0x410000c7, AUX_CTRL 0x32070000, Cache size: 1048576 B

bio: create slab <bio-0> at 0

mxs-dma mxs-dma-apbh: initialized

print_constraints: SPKVDD: 4200 mV

print_constraints: vmmc: 3300 mV

SCSI subsystem initialized

spi_imx imx6q-ecspi.0: probed

usbcore: registered new interface driver usbfs

usbcore: registered new interface driver hub

usbcore: registered new device driver usb

Freescale USB OTG Driver loaded, $Revision: 1.55 $

mc_pfuze 1-0008: recv failed!:-5,84

mc_pfuze: probe of 1-0008 failed with error -1

imx-ipuv3 imx-ipuv3.0: IPU DMFC NORMAL mode: 1(0~1), 5B(4,5), 5F(6,7)

imx-ipuv3 imx-ipuv3.1: IPU DMFC NORMAL mode: 1(0~1), 5B(4,5), 5F(6,7)

mxc_mipi_csi2 mxc_mipi_csi2: i.MX MIPI CSI2 driver probed

mxc_mipi_csi2 mxc_mipi_csi2: i.MX MIPI CSI2 dphy version is 0x3130302a

MIPI CSI2 driver module loaded

Advanced Linux Sound Architecture Driver Version 1.0.24.

Bluetooth: Core ver 2.16

NET: Registered protocol family 31

Bluetooth: HCI device and connection manager initialized

Bluetooth: HCI socket layer initialized

Bluetooth: L2CAP socket layer initialized

Bluetooth: SCO socket layer initialized

cfg80211: Calling CRDA to update world regulatory domain

max17135 2-0048: PMIC MAX17135 for eInk display

i2c-core: driver [max17135] using legacy suspend method

i2c-core: driver [max17135] using legacy resume method

Switching to clocksource mxc_timer1

NET: Registered protocol family 2

IP route cache hash table entries: 1024 (order: 0, 4096 bytes)

TCP established hash table entries: 4096 (order: 3, 32768 bytes)

TCP bind hash table entries: 4096 (order: 3, 49152 bytes)

TCP: Hash tables configured (established 4096 bind 4096)

TCP reno registered

UDP hash table entries: 128 (order: 0, 4096 bytes)

UDP-Lite hash table entries: 128 (order: 0, 4096 bytes)

NET: Registered protocol family 1

RPC: Registered named UNIX socket transport module.

RPC: Registered udp transport module.

RPC: Registered tcp transport module.

RPC: Registered tcp NFSv4.1 backchannel transport module.

PMU: registered new PMU device of type 0

Static Power Management for Freescale i.MX6

wait mode is enabled for i.MX6

cpaddr = 90880000 suspend_iram_base=90918000

PM driver module loaded

IMX usb wakeup probe

the wakeup pdata is 0x84225b40

add wake up source irq 75

IMX usb wakeup probe

the wakeup pdata is 0x8419d7c0

cpu regulator mode:ldo_enable

i.MXC CPU frequency driver

Note also in the above log: CPU identified as i.MX6Q, silicon rev 1.2.

My CPU is an iMX6D. I'm assuming this is ok, since it later only initializes 2 cores.

So, at this point I use menuconfig to turn of CPUfreq driver for i.MX CPUs (because I don't have a PMIC). This hangs, but with the log ending at "the wakeup pdata is 0x8419d7c0",

two lines above. I started pruning things from arch/arm/mach-mx6/Kconfig and the board_init function in board-mx6d_custom.c. But no matter how much I prune bootup still hangs...

Linux version 3.0.35-03053-g8d2b169-dirty (els@elslinux1) (gcc version 4.7.3 (Sourcery CodeBench Lite 2013.05-24) ) #24 PREEMPT Fri Jan 31 15:55:01 EST 2014

CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c53c7d

CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache

Machine: Alcatel-Lucent i.MX6D VSM400

Memory policy: ECC disabled, Data cache writeback

CPU identified as i.MX6Q, silicon rev 1.2

Built 1 zonelists in Zone order, mobility grouping off. Total pages: 32256

Kernel command line: console=ttymxc0,115200 root=/dev/nfs ip=dhcp nfsroot=135.222.138.108:/home/els/imx6/pass4/rootfs/buildroot-2013.08/my_rootfs,v3,tcp

PID hash table entries: 512 (order: -1, 2048 bytes)

Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)

Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)

Memory: 128MB = 128MB total

Memory: 124072k/124072k available, 138072k reserved, 0K highmem

Virtual kernel memory layout:

vector : 0xffff0000 - 0xffff1000 ( 4 kB)

fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)

DMA : 0xf4600000 - 0xffe00000 ( 184 MB)

vmalloc : 0x90800000 - 0xf2000000 (1560 MB)

lowmem : 0x80000000 - 0x90000000 ( 256 MB)

pkmap : 0x7fe00000 - 0x80000000 ( 2 MB)

modules : 0x7f000000 - 0x7fe00000 ( 14 MB)

.init : 0x80008000 - 0x80029000 ( 132 kB)

.text : 0x80029000 - 0x804587e4 (4286 kB)

.data : 0x8045a000 - 0x80494940 ( 235 kB)

.bss : 0x80494964 - 0x804b1f18 ( 118 kB)

SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1

Preemptible hierarchical RCU implementation.

NR_IRQS:624

MXC GPIO hardware

sched_clock: 32 bits at 3000kHz, resolution 333ns, wraps every 1431655ms

arm_max_freq=800MHz

MXC_Early serial console at MMIO 0x2020000 (options '115200')

bootconsole [ttymxc0] enabled

Console: colour dummy device 80x30

Calibrating delay loop... 1581.05 BogoMIPS (lpj=7905280)

pid_max: default: 32768 minimum: 301

Mount-cache hash table entries: 512

CPU: Testing write buffer coherency: ok

hw perfevents: enabled with ARMv7 Cortex-A9 PMU driver, 7 counters available

NET: Registered protocol family 16

hw-breakpoint: found 6 breakpoint and 1 watchpoint registers.

hw-breakpoint: 1 breakpoint(s) reserved for watchpoint single-step.

hw-breakpoint: maximum watchpoint size is 4 bytes.

L310 cache controller enabled

l2x0: 16 ways, CACHE_ID 0x410000c7, AUX_CTRL 0x32070000, Cache size: 1048576 B

bio: create slab <bio-0> at 0

mxs-dma mxs-dma-apbh: initialized

SCSI subsystem initialized

spi_imx imx6q-ecspi.0: probed

Switching to clocksource mxc_timer1

NET: Registered protocol family 2

IP route cache hash table entries: 1024 (order: 0, 4096 bytes)

TCP established hash table entries: 4096 (order: 3, 32768 bytes)

TCP bind hash table entries: 4096 (order: 2, 16384 bytes)

TCP: Hash tables configured (established 4096 bind 4096)

TCP reno registered

UDP hash table entries: 256 (order: 0, 4096 bytes)

UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)

NET: Registered protocol family 1

RPC: Registered named UNIX socket transport module.

RPC: Registered udp transport module.

RPC: Registered tcp transport module.

RPC: Registered tcp NFSv4.1 backchannel transport module.

PMU: registered new PMU device of type 0

Static Power Management for Freescale i.MX6

wait mode is enabled for i.MX6

cpaddr = 90880000 suspend_iram_base=90828000

PM driver module loaded

Any clue on what may be causing the hangup?

I'm by no means an expert at this, so I may be totally wrong in my approach. Anyone have any thoughts on what is best here?

One final point to mention...

I had built a kernel based on kernel.org's linux-3.13 (using device tree), and was able to boot to a linux login prompt on this board. I stepped back to the git.freescale version (not using device tree) because there were other subtle issues (command line doesn't process wildcards, why?) that made me suspicious that I needed to be more in sync with git.freescale.

Re: kernel boot problems with iMX6D running with 16bit DDR

EdSutter — Sat, 01 Feb 2014 18:55:25 GMT

Made a bit more progress, just with regard to debugging this.

With initcall_debug set, I see that the initailization is hung up in kswapd_init...

....

RPC: Registered tcp transport module.

RPC: Registered tcp NFSv4.1 backchannel transport module.

initcall init_sunrpc+0x0/0x70 returned 0 after 16461 usecs

calling default_rootfs+0x0/0x6c @ 1

initcall default_rootfs+0x0/0x6c returned 0 after 25 usecs

calling timer_init_syscore_ops+0x0/0x18 @ 1

initcall timer_init_syscore_ops+0x0/0x18 returned 0 after 1 usecs

calling etm_init+0x0/0x88 @ 1

initcall etm_init+0x0/0x88 returned 0 after 464 usecs

calling register_pmu_driver+0x0/0xc @ 1

PMU: registered new PMU device of type 0

initcall register_pmu_driver+0x0/0xc returned 0 after 3694 usecs

calling pm_init+0x0/0x218 @ 1

Static Power Management for Freescale i.MX6

wait mode is enabled for i.MX6

cpaddr = 90880000 suspend_iram_base=90828000

PM driver module loaded <<<<<<<<<<<<<<<<<<<< This is where I thought it was locking up

initcall pm_init+0x0/0x218 returned 0 after 12836 usecs

calling proc_execdomains_init+0x0/0x4c @ 1

initcall proc_execdomains_init+0x0/0x4c returned 0 after 9 usecs

calling ioresources_init+0x0/0x58 @ 1

initcall ioresources_init+0x0/0x58 returned 0 after 8 usecs

calling uid_cache_init+0x0/0xd4 @ 1

initcall uid_cache_init+0x0/0xd4 returned 0 after 11 usecs

calling init_posix_timers+0x0/0x1dc @ 1

initcall init_posix_timers+0x0/0x1dc returned 0 after 31 usecs

calling init_posix_cpu_timers+0x0/0xe4 @ 1

initcall init_posix_cpu_timers+0x0/0xe4 returned 0 after 1 usecs

calling nsproxy_cache_init+0x0/0x40 @ 1

initcall nsproxy_cache_init+0x0/0x40 returned 0 after 5 usecs

calling timekeeping_init_ops+0x0/0x18 @ 1

initcall timekeeping_init_ops+0x0/0x18 returned 0 after 1 usecs

calling init_clocksource_sysfs+0x0/0x50 @ 1

initcall init_clocksource_sysfs+0x0/0x50 returned 0 after 170 usecs

calling init_timer_list_procfs+0x0/0x3c @ 1

initcall init_timer_list_procfs+0x0/0x3c returned 0 after 6 usecs

calling alarmtimer_init+0x0/0x134 @ 1

initcall alarmtimer_init+0x0/0x134 returned 0 after 239 usecs

calling futex_init+0x0/0x60 @ 1

initcall futex_init+0x0/0x60 returned 0 after 7 usecs

calling proc_modules_init+0x0/0x38 @ 1

initcall proc_modules_init+0x0/0x38 returned 0 after 7 usecs

calling kallsyms_init+0x0/0x38 @ 1

initcall kallsyms_init+0x0/0x38 returned 0 after 4 usecs

calling ikconfig_init+0x0/0x54 @ 1

initcall ikconfig_init+0x0/0x54 returned 0 after 3 usecs

calling utsname_sysctl_init+0x0/0x18 @ 1

initcall utsname_sysctl_init+0x0/0x18 returned 0 after 25 usecs

calling perf_event_sysfs_init+0x0/0xac @ 1

initcall perf_event_sysfs_init+0x0/0xac returned 0 after 434 usecs

calling init_per_zone_wmark_min+0x0/0x90 @ 1

initcall init_per_zone_wmark_min+0x0/0x90 returned 0 after 1488 usecs

calling kswapd_init+0x0/0x18 @ 1

Re: kernel boot problems with iMX6D running with 16bit DDR

EdSutter — Wed, 05 Feb 2014 20:43:15 GMT

yet another self-reply here...

Still working on this issue. I'm adding trace/debug all over the kernel, and I'm now realizing

that .25G is apparently not enough DRAM to boot this kernel. I took my SABRESD board and

reconfigured its uboot to think it only has .25G and it hangs as well.

Is there a way to tweak things so the system doesn't need so much DRAM?

Re: kernel boot problems with iMX6D running with 16bit DDR

EdSutter — Wed, 05 Feb 2014 22:10:01 GMT

Final self-reply on this thread...

There is a menuconfig parameter which specifies the amount of memory that is to be used by CMA (contiguous memory allocator).

This is apparently used by DMA. It was set to 256M. I lowered this to 32M and it boots just fine.

On to the next problem...

Re: kernel boot problems with iMX6D running with 16bit DDR

jkobs2014 — Fri, 21 Mar 2014 19:20:23 GMT

I would like to know if you tweaked the CMA for the 3.12 kernel, or the 3.0.35 kernel that you stepped back to. The 3.0.35 kernel doesn't seem to support CMA, not in the same way the later kenerls do. So I'm trying to figure out the equivalent for the 3.0.35 kernel (or consider moving to a later kernel).

Re: kernel boot problems with iMX6D running with 16bit DDR

EdSutter — Fri, 21 Mar 2014 19:37:30 GMT

My error there...

At some point in my above "travels" I updated to imx_3.10.17_1.0.0_beta, and it was with that build (from git.freescale) that I was able to narrow my problem down to the CMA allocation. I've had good results with this kernel.

EDIT---

This, IMHO, is a big issue... I started out on this project using what came with LTIB. Some folks on the forum said go with mainline, so I pulled it down (3.12 at the time). That had issues, and I then tried to get YOCTO running on my host box (with no success); and finally settled (by chance) on the above tree. It would be nice to know which one is the "best" one to use.