iMX6UL, MfgTool and kernel 4.6

[jiriluznicky]

Hello,

we're trying to move to Linux kernel 4.6. It was easy job. Despite one thing. We also need this kernel to work with mfg tool. But we're not able to make it work.

We have enabled/set (relevant to usb gadget):

-  Device Drivers/USB/EHCI HCD/Support for Freescale i.MX on-chip EHCI

- DD/USB/USB Mass Storage Support

- DD/USB/ChipIdea Highspeed Dual Role Controller/ChipIdea device controller

- DD/USB/USB Gadget Support/Mass Storage Gadget

-DD/SCSI/SCSI disk support

In Windows, with this configuration, we got the "USB Mass Storage Device" and "Linux File-Stor Gadget USB Device" to appear.

But the Linux uuc util is stuck in "Waiting for device to appear", although in MfgTool all actions are run through really fast with status OK, but nothing is done on device.

We can also spot in dmesg (for a lot of commands, not only for READ CAPACITY):

[    0.000000] SCSI CDB: 25 00 00 00 00 00 00 00 00 00

[    0.000000] g_mass_storage gadget: SCSI command: READ CAPACITY;  Dc=10, Di=8;

  Hc=10, Hi=8

So, I would like to ask, if at least somebody knows what to enable in kernel (even in older one), or better know what makes this to happen in newer kernels.

Thanks in advance

Jiri Luznicky

[jirinovotnyle · Accepted solution]

Have you also ported FSL "improvment" to MSC gadget driver?

Please see drivers/usb/gadget/function/fsl_updater in official kernel tree. It also modifies f_mass_storage

#ifdef CONFIG_FSL_UTP

        void                    *utp;

#endif

At end it will add new config option in kernel config

https://postimg.org/image/dhkhgkyrr/

[jiriluznicky]

Hello,

No, I forgot, and that was the mistake. Now I quickly tried to apply some patch for 3.X Kernel and with little refactoring it works. Almost works, commands are OK, but file upload not.

Thanks

Jiri

[jirinovotnyle]

Hello,

no problem. Probably 4.1 kernel files will work aout of the box.

linux-2.6-imx.git - Freescale i.MX Linux Tree

Have a nice day

[jiriluznicky]

FYI: After applying patches (no modifications needed) MLK-11483-1 .. MLK-11483-4 from rel_imx_4.1.15_1.2.0_ga  file upload still not working. Maybe I missed another important patche, or maybe something changed between 4.1 and 4.6. I will give it some time later.

[jimmychan]

Is there any log message from debug uart?

have you try to build the MfgTool firmware in the official BSP L3.14.38?

[jiriluznicky]

Hello,

yes there is a log from uart: http://pastebin.com/hK1HhscQ . Even more, there is a log from dmsg: http://pastebin.com/FNFYFZbV.

As the g_mass_storage gadget is compiled with debug enabled, it's possible to see how normal SCSI commands works fine (some commands fails properly, due to missing file= parameter), but the REQUEST SENSE command which is send by mfgtool itself always ends with  length problem.

The gadget itself works fine. When I add the file parameter to the gadget, I'm even able to mount it, and use the device as USB flash. But it has no effect on mfg tool part. As far as I know, there was some huge rework in mass storage gadget around kernel 3.8. Maybe the mfgtool doesn't reflects it. (Anyway tried 2.3.?, self compiled 2.3.1 and 2.6.2 with no difference)

The official BSP L3.14.38 works fine, but we need to move towards 4.6 due to some ubifs issues.

Thanks in advance

Jiri Luznicky

[jimmychan]

Are you programming the images to NAND flash?

[jiriluznicky]

Yes, we use NAND flash.

[jimmychan]

As L3.14.38 works fine, you can use the L3.14.38 MfgTool firmware to program the kernel 4.6 images to your NAND flash.

[jiriluznicky]

Yes, that would be obvious solution.

But the reason to move to 4.6 kernel (and also more recent u-boot) was, that if you run this sequence of command repeatedly under L3.14.38:

	<CMD state="Updater" type="push" body="$ flash_erase /dev/mtd3 0 0">Erasing rootfs device</CMD>
	<CMD state="Updater" type="push" body="$ ubiformat /dev/mtd3">Formatting UBI device</CMD>
	<CMD state="Updater" type="push" body="$ ubiattach /dev/ubi_ctrl -m 3">Attaching UBI device</CMD>
	<CMD state="Updater" type="push" body="$ ubimkvol /dev/ubi0 -N rootfs -m">Creating UBI volume</CMD>
	<CMD state="Updater" type="push" body="$ ubiupdatevol /dev/ubi0_0 -t">Truncating UBI volume</CMD>
	<CMD state="Updater" type="push" body="$ mkdir -p /mnt/mtd3"/>
	<CMD state="Updater" type="push" body="$ mount -t ubifs ubi0:rootfs /mnt/mtd3">Mounting UBI volume</CMD>
	<CMD state="Updater" type="push" body="pipe tar -jxv -C /mnt/mtd3" file="files/rootfs-%machine%.tar.bz2" ifdev="MX6UL">Sending and writting rootfs</CMD>
	<CMD state="Updater" type="push" body="frf">Finishing rootfs write</CMD>
	<CMD state="Updater" type="push" body="$ umount /mnt/mtd3">Unmounting rootfs partition</CMD>

then in first run is ok. After reset ubifs is attached and mounted under u-boot, kernel loaded and everything works fine.

But if you decide to reflash the device, then consequent run of script above leads to broken ubifs during attach in u-boot.

During reflashing everything seems OK. It's possible to mount reflashed FS under Linux. But after reset, u-boot is not able to attach the ubifs partition. Yes, there is fast workaround to use nand erase.chip in u-boot, and then reset into mfg mode. But as our device are expected to be used in hardly accessible locations, we can not afford to risk problems with persistent storage.

So before finding out whether is the root of this problem in u-boot ubi support, flash_erase, ubiformat or somewhere else, we have decided to move to current versions (of u-boot, kernel, userspace utils). Have working 4.6 kernel in mfgtool is part of it.

[jiriluznicky]

Uh. Just noticed, that I pasted bad script line:

• <CMD state="Updater" type="push" body="$ ubiupdatevol /dev/ubi0_0 -t">Truncating UBI volume</CMD>

shouldn't be there.