Closed Grinimod closed 6 years ago
did you use arm32 or arm64?
arm32
I just test it at i.MX7D platform. It work well.
I compared g_descriptors, which is exactly the same as my data.
Does your kernel support FUNCTIONFS_DESCRIPTORS_MAGIC_V2 ?
0x03 0x00 0x00 0x00 0xE4 0x00 0x00 0x00 0x0F 0x00 0x00 0x00 0x03 0x00 0x00 0x00 0x03 0x00 0x00 0x00 0x05 0x00 0x00 0x00 0x02 0x00 0x00 0x00 0x09 0x04 0x00 0x00 0x02 0xFF 0x00 0x00 0x01 0x07 0x05 0x81 0x02 0x00 0x00 0x00 0x07 0x05 0x02 0x02 0x00 0x00 0x00 0x09 0x04 0x00 0x00 0x02 0xFF 0x00 0x00 0x01 0x07 0x05 0x81 0x02 0x00 0x02 0x00 0x07 0x05 0x02 0x02 0x00 0x02 0x01 0x09 0x04 0x00 0x00 0x02 0xFF 0x00 0x00 0x01 0x07 0x05 0x81 0x02 0x00 0x04 0x00 0x06 0x30 0x00 0x00 0x00 0x00 0x07 0x05 0x02 0x02 0x00 0x04 0x01 0x06 0x30 0x00 0x00 0x00 0x00 0x01 0x23 0x00 0x00 0x00 0x01 0x00 0x04 0x00 0x01 0x00 0x00 0x01 0x57 0x49 0x4E 0x55 0x53 0x42 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x54 0x00 0x00 0x00 0x01 0x00 0x05 0x00 0x01 0x00 0x49 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x14 0x00 0x44 0x65 0x76 0x69 0x63 0x65 0x49 0x6E 0x74 0x65 0x72 0x66 0x61 0x63 0x65 0x47 0x55 0x49 0x44 0x00 0x27 0x00 0x00 0x00 0x7B 0x34 0x38 0x36 0x36 0x33 0x31 0x39 0x41 0x2D 0x46 0x34 0x44 0x36 0x2D 0x34 0x33 0x37 0x34 0x2D 0x39 0x33 0x42 0x39 0x2D 0x44 0x43 0x32 0x44 0x45 0x42 0x33 0x36 0x31 0x42 0x41 0x39 0x7D 0x00
0x03 0x00 0x00 0x00 0xe4 0x00 0x00 0x00 0x0f 0x00 0x00 0x00 0x03 0x00 0x00 0x00 0x03 0x00 0x00 0x00 0x05 0x00 0x00 0x00 0x02 0x00 0x00 0x00 0x09 0x04 0x00 0x00 0x02 0xff 0x00 0x00 0x01 0x07 0x05 0x81 0x02 0x00 0x00 0x00 0x07 0x05 0x02 0x02 0x00 0x00 0x00 0x09 0x04 0x00 0x00 0x02 0xff 0x00 0x00 0x01 0x07 0x05 0x81 0x02 0x00 0x02 0x00 0x07 0x05 0x02 0x02 0x00 0x02 0x01 0x09 0x04 0x00 0x00 0x02 0xff 0x00 0x00 0x01 0x07 0x05 0x81 0x02 0x00 0x04 0x00 0x06 0x30 0x00 0x00 0x00 0x00 0x07 0x05 0x02 0x02 0x00 0x04 0x01 0x06 0x30 0x00 0x00 0x00 0x00 0x01 0x23 0x00 0x00 0x00 0x01 0x00 0x04 0x00 0x01 0x00 0x00 0x01 0x57 0x49 0x4e 0x55 0x53 0x42 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x54 0x00 0x00 0x00 0x01 0x00 0x05 0x00 0x01 0x00 0x49 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x14 0x00 0x44 0x65 0x76 0x69 0x63 0x65 0x49 0x6e 0x74 0x65 0x72 0x66 0x61 0x63 0x65 0x47 0x55 0x49 0x44 0x00 0x27 0x00 0x00 0x00 0x7b 0x34 0x38 0x36 0x36 0x33 0x31 0x39 0x41 0x2d 0x46 0x34 0x44 0x36 0x2d 0x34 0x33 0x37 0x34 0x2d 0x39 0x33 0x42 0x39 0x2d 0x44 0x43 0x32 0x44 0x45 0x42 0x33 0x36 0x31 0x42 0x41 0x39 0x7d 0x00
My board is i.MX6Q and the dev env is Ubuntu 16.04, SOC kernel 4.1.15 supports FUNCTIONFS_DESCRIPTORS_MAGIC_V2. The EINVAL is thrown by https://elixir.bootlin.com/linux/v4.1.15/source/drivers/usb/gadget/function/f_fs.c#L2066.
I completely removed the Windows part and ran a string similar to this
echo -ne '\x03\x00\x00\x00\x69\x00\x00\x00\x07\x00\x00\x00\x03\x00\x00\x00\x03\x00\x00\x00\x05\x00\x00\x00\x09\x04\x00\x00\x02\xFF\x00\x00\x01\x07\x05\x81\x02\x00\x00\x00\x07\x05\x02\x02\x00\x00\x00\x09\x04\x00\x00\x02\xFF\x00\x00\x01\x07\x05\x81\x02\x00\x02\x00\x07\x05\x02\x02\x00\x02\x01\x09\x04\x00\x00\x02\xFF\x00\x00\x01\x07\x05\x81\x02\x00\x04\x00\x06\x30\x00\x00\x00\x00\x07\x05\x02\x02\x00\x04\x01\x06\x30\x00\x00\x00\x01'>/dev/usb-utp/ep0
EDITED The answer is (I patched/added all the kernel prints for debugging)
Read length and length check passed: 105
Type FUNCTIONFS_DESCRIPTORS_MAGIC_V2 has valid flags| len=93
Expect 3 full speed descriptors
Expect 3 high speed descriptors
Expect 5 super speed descriptors
Expect 0 MS OS descriptors
len=81
Done descriptors 0 |len=58
Done descriptors 1 |len=35
Done descriptors 2 |len=0
__ffs_data_got_descs is returning with 0
len is the variable noting the unparsed bytes left.
I did not yet test if the client will work with that substitution though
look like kernel side problem. Not sure why MS OS descriptors cause failure.
g_descriptors.os_desc.Reserved1 = cpu_to_le32(0)
, so the code provided can only work on Linux 4.11+ unpatched.This ways actually is very popular at android system. Android's ADB using functionfs. and use script to setup configfs.
Could you please provide me with your kernel version on which you tested it positively? Is it mainline or a NXP linux-imx branch? Unfortunately I am clearly using a setup which cannot work out-of-the-box. Then i should be able investigate whether it is feasible to update or to stick with MfgTools 2.
nxp linux-imx. 4.9.y.
Just some minutes ago I got my image with your imx_4.9.11_1.0.0_ga kernel up and running and I can confirm that there is no patch needed and I got to the point:
Linux version 4.9.11 (Grinimod@imx) (gcc version 5.3.0 (GCC) ) #12 SMP PREEMPT Thu Aug 2 14:14:57 CEST 2018
uuu fastboot client 1.0.0 [Aug 2 2018 15:28:19]
Start init usb
write string
Start handle command
But once again there is no IMX device shown on my host system via lsusb
. I have to exclude any possible source of error on my (host) pc, but I really doubt that this is the cause. Maybe the state of the gadget function is somehow not preserved. My first testing approach would be to write into /dev/usb-utp/ep2 directly, but I don't know if that can work even if the usb gadget function is set up correctly.
Can you try plug windows PC? Did you see message like "usb config high speed" at uart console?
If not, PC have not enumerate such devices.
OK, I'm getting close dmesg
on host
[ 3698.777878] usb 1-4: usbfs: process 31439 (uuu) did not claim interface 0 before use
[ 3699.763339] usb 1-4: USB disconnect, device number 17
Can you try plug and unplug cable again?
Plug and unplug of the otg USB-cable while the ufb keeps running in background on the iMX does not show any reaction on dmesg
. (I used another port to make really sure)
I think your board USB OTG port have problem. At same time, mass storage device also enabled by linuxrc. Did you have mass storage appear?
No, I have to check if any of the deactivated patches while updating caused any harm to the usb.
Reverted to the old setup mfgtoolcli/uuc and that will stop after the boot, so I really suspect the usb setup to be broken with that rushed kernel upgrade. I will have to wait for the full environment upgrade. Probably a hint to to require a kernel 4.9.11+ could have been useful.
Hello again, after I started the ufb client, the USB entry point declined the built-in configuration. It is an errno 22 so I expect the Value to be declined. Probably an endianess (LSB) or padding issue (32bit). Debugged by printing out the data in the g_descriptors yields:
I could not find an error yet (comparing to https://elixir.bootlin.com/linux/v4.1.15/source/include/uapi/linux/usb/functionfs.h) but E4 (228) bytes are a long way to go...