Unable to use mfgtools to program a QWKS-SCMIMX6DQ

[marcooman]

We are having problems in programming a board and I'd like to share a test that i consider meaningful/interesting.

The critical point is write the root file system and while studying what is going on I tried to build a large file in ramdisk.So I added two lines like the following

    <CMD state="Updater" type="push" body="$ df -h ."/>
    <CMD state="Updater" type="push" body="$ dd if=/dev/zero of=/home/test.dat bs=1M count=8"/>

They should build a 8MB file. And it seems to work: this is rthe log from the console

UTP: received command '$ df -h .'
UTP: executing "df -h ."
Filesystem      Size  Used Avail Use% Mounted on
rootfs          339M   20M  319M   6% /
UTP: sending Success to kernel for command $ df -h ..
utp_poll: pass returned.
UTP: received command '$ dd if=/dev/zero of=/home/test.dat bs=1M count=8'
UTP: executing "dd if=/dev/zero of=/home/test.dat bs=1M count=8"
8+0 records in
8+0 records out
8388608 bytes (8.4 MB) copied, 0.066104 s, 127 MB/s
UTP: sending Success to kernel for command $ dd if=/dev/zero of=/home/test.dat bs=1M count=32.
utp_poll: pass returned.
UTP: received command '$ df -h .'
UTP: executing "df -h ."
Filesystem      Size  Used Avail Use% Mounted on
rootfs          339M   28M  311M   9% /
UTP: sending Success to kernel for command $ df -h ..
utp_poll: pass returned.

The file system usage has grown by a 3% and all is OK.

but if I try to build a larger file (64MB) this is what I get:

UTP: received command '$ df -h .'
UTP: executing "df -h ."
Filesystem      Size  Used Avail Use% Mounted on
rootfs          339M   20M  319M   6% /
UTP: sending Success to kernel for command $ df -h ..
utp_poll: pass returned.
UTP: received command '$ dd if=/dev/zero of=/home/test.dat bs=1M count=64'
UTP: executing "dd if=/dev/zero of=/home/test.dat bs=1M count=64"
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = 865b8000
[00000000] *pgd=166b9831, *pte=00000000, *ppte=00000000
Internal error: Oops: 17 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 3 PID: 91 Comm: dd Not tainted 4.1.15-1.0.0-mfgtool+g3924425 #1
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
task: 8632e3c0 ti: 86672000 task.ti: 86672000
PC is at __wake_up_common+0x14/0x80
LR is at __wake_up+0x38/0x4c
pc : [<80064cc4>]    lr : [<80064d68>]    psr: a00d0093
sp : 86673db0  ip : 00000000  fp : 00000000

Any idea bout what goes wrong?

[igorpadykov]

Hi Marco

what mfg tool (full name, link), media (sd, spi-nor), script  used in the case, please try

Programmers (Flash, etc.)
SCM-i.MX 6 Series Manufacturing Toolkit for Linux 4.1.15_2.0.0

Quick Start Board for SCM-i.MX 6DQ|NXP 

Use appropriate vbs script for programming, for example mfgtool2-yocto-mx6dqscm-1gb-qwks-rev3-sd.vbs

for sd card. Mfg Tools presentation:

AMF-AUT-T2324 - Manufacturing Tool 

Partition size can be adjusted using ../Linux/OS Firmware/mksdcard.sh.tar

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[marcooman]

Sorry Igor for omitting to list the basic coordinates of the problem.

So I am using mfgtools_L4.1.15_2.0.0-ga_MX6SCM.tar.gz downloaded from

Quick Start Board for SCM-i.MX 6DQ|NXP 

The script I run it

mfgtool2-yocto-mx6dqscm-1gb-qwks-rev3-sd.vbs, (SCM-SDCard), I am using the top SD slot (the small one).

I made several tests and gained some confidence with the script provided; I have tested also the bottom slot (the large, by changing the vbs) and the result is the same: it works fully only if the final filesystem is small (3MB zipped, the minimal image produced by yocto).

I described the problems in terms of executing a command like "dd if=/dev/zero of=/home/test.dat bs=..." because it looks like the simplest possible example that should work but it doesn't. It makes me think that there is something wrong on the boot system running in RAM, and not e.g. in USB transfer.

As a side note I can mention my comment on the following post:

Problem with linux-mfgtool and initramfs | NXP Community which I think is a problem very similar to my one (it could be just a matter of different symptoms of the same bug/misconfiguration or whatever).

Thanks for the reference to AMF-AUT-T2324 - Manufacturing Tool 

[igorpadykov]

Hi Marco

could you try to increase partition size using ../Linux/OS Firmware/mksdcard.sh.tar

Best regards
igor

[marcooman]

The mkscard.sh makescurrently two partitions, the first uses about 500MB and the second the rest of the card. I tried 8GB/32GB/65GB SDs with the same result. Actually I often limited the formatting (not the partition) to 1 or 2GB otherwise a single test takes ages. Anyway note that:

1. I am trying to transfer a tar.gs with is about 44MB and expanded uses less that 200MB. If I do it manually on a linux box it works

2. The sample command of my original question (dd if=/dev/zero of=/home/test.dat bs=1M count=32) runs on the ramfs. A simple dh -h . tells me that I have plenty of space (details below), but creating a 32MB file fails....

UTP: received command '$ df -h .'
UTP: executing "df -h ."
Filesystem      Size  Used Avail Use% Mounted on
rootfs          339M   20M  320M   6% /
UTP: sending Success to kernel for command $ df -h ..

[igorpadykov]

mfg tools performs the same programmings steps as described

in sect.4.3 Preparing an SD/MMC card to boot Linux Guide included in documentation

https://www.nxp.com/webapp/Download?colCode=L4.1.15_2.0.0-LINUX-DOCS 

So one can narrow down issue (and test board) performing the same sd programming steps

on PC. If it will success, afterwards some operations for example like formatting can be

performed on PC and other with mfg tools (comment formatting line in ucl2.xml).

Then one can try to run linux on board with help spi-nor uboot and tftp, check that the

same commands (in ucl2.xml) works fine. If not, adjust them and if necessary, rebuild mfg

tools firmware (files in mfg tool /firmware folder) using sect.6.2 Manufacturing Tool, MFGTool

Yocto Guide from documentation package.

Best regards
igor

[marcooman]

Programming steps are correct. They work on yocto core-image-minimal (2.8MB for .tar.gs, 12MB for the .ext4).

The problems arise with larger images. For instance the command

   <CMD state="Updater" type="push" body="pipe tar -jxv -C /mnt/mmcblk%mmc%p2" file="files/core-image-base-imx6dqscm-1gb-qwks-rev3.rootfs.tar.bz2" ifdev="MX6Q">Sending and writing rootfs</CMD>

fails with some kind of kernel panic. (image is larger but not huge: about 28MB for the tar.bz2 file, the board has 1GB)The failure is approximately always at the same point, with a message like the following one:

./usr/lib/python2.7/weakref.pyc
./usr/lib/python2.7/platform.pyc
./usr/lib/python2.7/cmd.py
./usr/lib/python2.7/dummy_thread.py
tar: invalid tar magic
Kernel panic - not syncing: Attempted to kill init! exitcode=0x00008d00

CPU0: stopping
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.1.15+ #1
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[<80015ed8>] (unwind_backtrace) from [<80012768>] (show_stack+0x10/0x14)
[<80012768>] (show_stack) from [<80691f00>] (dump_stack+0x80/0xc8)
[<80691f00>] (dump_stack) from [<80014d08>] (handle_IPI+0x15c/0x190)
[<80014d08>] (handle_IPI) from [<80009478>] (gic_handle_irq+0x58/0x60)
[<80009478>] (gic_handle_irq) from [<80013240>] (__irq_svc+0x40/0x74)

Sometimes the last message is "short read" instead of "invalid tar magic". The same happens with the original files downloaded from NXP web side.

[igorpadykov]

one can try to perform the same programming steps on board

running linux (run it for example with tftp). If it works rebuild mfg tool firmware.

Recipes used to build a manufacturing tool image are linux-imx-mfgtool and u-boot-mfgtool.

A manufacturing tool kernel is built using the imx_v7_mfg_defconfig while the default

kernel is built by using the imx_v7_defconfig.

[marcooman]

I'm getting the impression that we are focusing on different aspects. Programming steps are OK. What is not OK is the bootstrap linux (the collection made up of uboot, kernel, initramfs, and device tree) used to to the bootstrap.

It starts, but stops with kernel panic systematically as soon as the final filesystem is not tiny. So I am thinking that there is something wrong there, like a memory overlap. I gave a look e.g. at /proc/iomem but I can't see anything wrong. Any help in doing this investigation about details of this kind would be appreciated. Otherwise I am forced to conclude that I have seen all cookbook answers, I won't get anything more and so I need to look for a solution somewhere else.

[igorpadykov]

unfortunately I have not that board for testing,

could you try Linux 3.14.52 MfgTool_scm, it has files/rootfs.tar.bz2  ~250MB

https://www.nxp.com/webapp/Download?colCode=SCM-IMX6DQ-L3.14.52-PATCH&appType=license 

in L4.1.15_2.0.0-ga_mfg-tools ucl2.xml seeks for files/rootfs_imx%soc%.tar.bz2 so you should

put such file in folder and rename it appropriately.

Best regards
igor

[marcooman]

A last question before closing this thread. on

git.freescale.com/git I can see there are several branches for fsl-arm-yocto-bsp.

Which one shall I use? (I am currently on imx-4.1-krogoth)

[igorpadykov]

please try scm-imx_4.1.15_2.0.0_ga

linux-imx.git - i.MX Linux Kernel 

or

linux-imx - i.MX Linux kernel 

Best regards
igor

[marcooman]

As a final note I will add the best solution found so far, which is transfer with mfgtool just u-boot, start it and at u-boot prompt enable the USB mass storage gadget with command

ums 0 mmc 1

ThenI have been able to flash the SD from the PC

[marcooman]

This little note just to put emphasis on the fact that the system works. So the whole chain is OK. The problem is that the current solution is fragile, since works only for very tiny rootfs (say toys/examples), not real ones.