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
Solved! Go to 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.
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.
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.
To debug this issue, I would suggest you to use NFS.
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.
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.
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.
Might be simple thing and I've used NFS before, but what do you mean to use NFS in this case?
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.
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.
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?
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?