i.MX6 Manufacturing Tool Issue

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

i.MX6 Manufacturing Tool Issue

Jump to solution
1,295 Views
PaulDeMetrotion
Senior Contributor I

I am working on a custom device that uses the i.MX6Q processor. I am trying to use the Manufacturing Tool version 4.1.0 to program an SPI-NOR device on an SPI bus. I use LTIB to generate u-boot and uImage binaries without any problems. I also generate the initramfs.cpio.gz.uboot file.

If I use the initramfs.cpio.gz.uboot file included with the manufacturing tool release, I can program our device without any problem. If I try to use the initramfs file built by LTIB, I cannot use the manufacturing tool.

Following is a portion of the console output where the boot fails. Any idea why the root device being searched for is not included? Is there a build setting that I need to change?

mxc_dvfs_core_probe

DVFS driver module loaded

snvs_rtc snvs_rtc.0: setting system clock to 1970-01-01 03:06:22 UTC (11182)

VFS: Cannot open root device "(null)" or unknown-block(0,0)

Please append a correct "root=" boot option; here are the available partitions:

1f00             512 mtdblock0  (driver?)

1f01               8 mtdblock1  (driver?)

1f02            3520 mtdblock2  (driver?)

Unable to handle kernel NULL pointer dereference at virtual address 00000027

pgd = e71a8000

[00000027] *pgd=7712a831, *pte=00000000, *ppte=00000000

Internal error: Oops: 17 [#1] PREEMPT SMP

Modules linked in:

CPU: 3    Not tainted  (3.0.35-2666-gbdde708 #44)

PC is at fget+0x40/0xbc

LR is at fget+0x20/0xbc

pc : [<800e44bc>]    lr : [<800e449c>]    psr: a0000013

sp : e7181f30  ip : 10c53c7d  fp : 00000000

r10: 00000000  r9 : e7180000  r8 : 8003b184

r7 : 000000c5  r6 : 00000011  r5 : e9c4ee00  r4 : ffffffff

r3 : e74f1008  r2 : 00000100  r1 : e7181f50  r0 : 00000001

Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user

Control: 10c53c7d  Table: 771a804a  DAC: 00000015

Process env (pid: 4342, stack limit = 0xe71802f0)

Stack: (0xe7181f30 to 0xe7182000)

1f20:                                     00000001 7ee8abf0 e7181f50 800e7620

1f40: 00000001 7ee8abf0 ffffffff 800e7814 e9d61d80 60000013 00000001 2aae9000

1f60: 2aae9000 e7180000 00000005 00000000 e7180000 00000000 7ee8aaac 800d1fdc

1f80: 08100875 0002ab82 e9c4ee40 e9bb8000 2aae9560 00000018 2aac4724 0000040f

1fa0: 2ad645d0 8003b000 2ad645d0 ffffffff 00000001 7ee8abf0 7ee8abf0 00000001

1fc0: 2ad645d0 ffffffff 00000011 000000c5 0000011e 00000000 2aae9000 00000000

1fe0: 2ac9ccf0 7ee8abe4 2ac9a1c8 2acf6034 20000010 00000001 79ffc811 79ffcc11

[<800e44bc>] (fget+0x40/0xbc) from [<800e7620>] (vfs_fstat+0xc/0x3c)

[<800e7620>] (vfs_fstat+0xc/0x3c) from [<800e7814>] (sys_fstat64+0x14/0x30)

[<800e7814>] (sys_fstat64+0x14/0x30) from [<8003b000>] (ret_fast_syscall+0x0/0x30)

Code: e5933004 e7934104 e3540000 0a000017 (e5943028)

Labels (1)
0 Kudos
1 Solution
612 Views
PaulDeMetrotion
Senior Contributor I

I get my first response right after I fixed the problem. The solution was simple but not specified in the Manufacturing Tool Firmware Development Guide. The document should specify that the uuc and mtd-utils packages should be included in the kernel build. This may be obvious but I missed it. Once I selected these packages, the archive file initramfs.cpio.gz.uboot was usable during the manufacturing process.

View solution in original post

0 Kudos
3 Replies
612 Views
PaulDeMetrotion
Senior Contributor I

I have attached a file that shows the difference between the two console outputs. The top one shows a successful boot with the original initramfs file and the bottom one shows the boot failure with the custom built initramfs file.
otg.png

0 Kudos
612 Views
KursadOney
NXP Employee
NXP Employee

You should post the full boot log. There is not enough information here. There are many things that might have gone wrong like:

* Your u-boot doesn't boot to initramfs

* Incorrect address for initramfs

* Problem with the initramfs configuration or files

As a first thing, I would check if /init is pointing to the right place like /bin/busybox. Avoid using relative paths like ../bin/busybox.

0 Kudos
613 Views
PaulDeMetrotion
Senior Contributor I

I get my first response right after I fixed the problem. The solution was simple but not specified in the Manufacturing Tool Firmware Development Guide. The document should specify that the uuc and mtd-utils packages should be included in the kernel build. This may be obvious but I missed it. Once I selected these packages, the archive file initramfs.cpio.gz.uboot was usable during the manufacturing process.

0 Kudos