Debugging MFGTool

[Maddis]

Hi,

I'm trying to get MFGTool working on our custom iMX6q based HW.

Our hw is based on SabreSD with 2GB RAM, eMMC in SD4 instead SD in SD3 and some other minor changes. But because of those changes I need to build the mfgtool u-boot/kernel myself and can't use the existing ones. I'm using Yocto/meta-fsl-arm to build the mfgtool -image for iMX6. I got it working and I'm able to upload mfg u-boot/kernel/initramfs to unit and it starts and talks to mfgtool.

Here is why I got so far and not sure what goes wrong and that's why it would be nice to be able to debug it somehow. I'm assuming that it does not upload the file it tries to extract, but I'm not sure why is that. I have SabreSD iMX6 develboard, but for some reason I cannot get mfgtool working with it even the freshly downloaded mfgtool. It get's stuck at: cpu_id is 0

Any idea what might be wrong and/or how to debug MFGTool?

sdhci: Secure Digital Host Controller Interface driver

sdhci: Copyright(c) Pierre Ossman

sdhci-pltfm: SDHCI platform and OF driver helper

mmc0: no vqmmc regulator found

mmc0: no vmmc regulator found

mmc0: SDHCI controller on 219c000.usdhc [219c000.usdhc] using ADMA

mmc0: BKOPS_EN bit is not set

mmc0: new high speed DDR MMC card at address 0001

mmcblk0: mmc0:0001 MMC08G 7.26 GiB

mmcblk0boot0: mmc0:0001 MMC08G partition 1 16.0 MiB

mmcblk0boot1: mmc0:0001 MMC08G partition 2 16.0 MiB

mmcblk0rpmb: mmc0:0001 MMC08G partition 3 128 KiB

mmcblk0: p1 p2 p3

mmcblk0boot1: unknown partition table

mmcblk0boot0: unknown partition table

Galcore version 4.6.9.9754

mxc_vdoa 21e4000.vdoa: i.MX Video Data Order Adapter(VDOA) driver probed

mxc_asrc 2034000.asrc: mxc_asrc registered

mxc_vpu 2040000.vpu: VPU initialized

usbcore: registered new interface driver usbhid

usbhid: USB HID core driver

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

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

TCP: cubic registered

NET: Registered protocol family 10

sit: IPv6 over IPv4 tunneling driver

NET: Registered protocol family 17

8021q: 802.1Q VLAN Support v1.8

Key type dns_resolver registered

VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4

g_mass_storage gadget: Mass Storage Function, version: 2009/09/11

g_mass_storage gadget: Number of LUNs=1

lun0: LUN: removable file: (no medium)

g_mass_storage gadget: Mass Storage Gadget, version: 2009/09/11

g_mass_storage gadget: g_mass_storage ready

drivers/rtc/hctosys.c: unable to open rtc device (rtc0)

usb 1-1: new high-speed USB device number 2 using ci_hdrc

ALSA device list:

  No soundcards found.

Freeing unused kernel memory: 300K (80be8000 - 80c33000)

Starting UTP

uuc 0.5 [built Sep 17 2015 09:01:22]

UTP: Waiting for device to appear

UTP: file/device node /dev/utp already exists

cpu_id is 0

hub 1-1:1.0: USB hub found

hub 1-1:1.0: 3 ports detected

g_mass_storage gadget: high-speed config #1: Linux File-Backed Storage

UTP: received command 'send'

UTP: sending Success to kernel for command send.

UTP: received command '$ tar xf $FILE '

UTP: executing "tar xf $FILE "

tar: no gzip/bzip2/xz magic

UTP: sending Non-success to kernel for command $ tar xf $FILE .

utp_poll: exit with status 256

[jimmychan]

what is your filesystem file in your mfgtool folder? is it something like rootfs.tar.gz? so you may check the tar command in your ucl2.xml is proper or not.

[Maddis]

It seems that it fails to upload mksdcard.sh.tar - file to device and then unpack it with tar. mksdcard.sh.tar is there on normal place and I think it's found no errors are given and it's never executed. I put changed the text in ucl2.xml when mksdcard.sh is being executed and it never gets that far, but gets stuck in step before it.

[jimmychan]

To debug this issue, I would suggest you to use NFS.

[Maddis]

I don't think the problem is in mfgtool filesystem since the mfgtool system uploaded to device clearly starts up okay and talks to MFGTool in PC.

And if you are talking about the image being loaded with the mfgtool then yes, that's correct form since I used it to program the development board's eMMC.

[jimmychan]

I saw the 'tar' command seems not work in your log  :

UTP: received command '$ tar xf $FILE '

UTP: executing "tar xf $FILE "

tar: no gzip/bzip2/xz magic

UTP: sending Non-success to kernel for command $ tar xf $FILE .

so, you may double check the 'tar' command in the ucl script. Or you may send your ucl2.xml here so I can take a look of it.

[Maddis]

Ah, didn't see your reply before sending mine. The ucl2.xml is inlucded here.

[jimmychan]

after check the ucl script, I don't see any problem. I think it is better to bootup your board with NFS. Then use the same linux commands in the script to program your emmc for debugging.

[Maddis]

Might be simple thing and I've used NFS before, but what do you mean to use NFS in this case?

[jimmychan]

The ucl script basically is a bundle of linux command used to program the emmc on your board. So you can boot your board with NFS. Then you can run the same linux commands to program the emmc. Therefore, you can check the script is right or wrong.

[Maddis · Accepted solution]

Ha. The solution was there whole time and I just couldn't see it! It's working now.

For some reason this new system wants the mksdcard.sh.tar to be also packed with gzip/bzip2/xz. So I used gzip and replaced the original file with it and now it works!

Sometimes the problems are too obvious to notice.

[Maddis]

Do you know if there are any instructions how to setup NFS so it can be used the way you suggest?  Or could you elaborate bit more?

[jimmychan]

Yocto NFS & TFTP boot

[Maddis]

While starting to test the NFS I noticed that I didn't have U-boot startup delay so I couldn't stop u-boot from booting and changing to NFS.

Anyway, I stopped the mfgtool too and it left the system at state where the mfgtool has booted  and created the Linux File-backed storage and it appeared as E: in my computer. Not sure if my problem is this. When I tried to access the E: I get error "The request could not be berformed because of I/O device error." Not entirely sure which way the mksdcard.sh.tar is uploaded to device.

I'll continue with NFS for now.

edit. On another test when trying to access drive E: Windows said "Please insert a disk into drive E:". So it seems that the File-backed storage is not working at least at that state. Not sure if I should be able to access it normally. I'd assume so?