Talk:Geniatech T230: Difference between revisions

From LinuxTVWiki
Jump to navigation Jump to search
Line 10: Line 10:
== Anyone else also has USB String descriptor problems? ==
== Anyone else also has USB String descriptor problems? ==


On my device I found a strange USB issue: All string descriptors are reported defective. That is, The language string descriptor starts with a spurious 0x00 (really the length field), and includes all following string descriptors (wrong length in control transfer probably due to a parsing error in the firmware). The strings themselves look ok, there is just this leading 0x00 byte that is too much and which leads to strange errors also on the host side. For example, some versions of lsusb crash (assert) when using verbose mode on this device. Linux used to print a warning in older versions, now the message sounds nicer, simply saying that the language string is not provided and that it defaults to English. However, none of the strings is properly detected (due to the 0x00 length byte).
On my device I found a strange USB issue: All string descriptors are reported defective. That is, the language string descriptor starts with a spurious 0x00 (which is interpreted as the length field), and also includes all following string descriptors (wrong length of the control IN data stage probably due to internal structure parsing error in the firmware). The strings themselves look ok, there is just this leading 0x00 byte that is too much. It seems as if the firmware responds with the whole string descriptor set (structure), no matter which string it is being asked for (internal parser issue).
This leads to strange errors on the host PC. For example, some versions of lsusb crash (assert) when using verbose mode on this USB device. Linux (kernel) used to print a warning in older versions, saying that the device responded with a defective string descriptor. In later versions the message sounds nicer, simply saying that the language string is not provided and that it defaults to English (maybe someone out there had the same problem with this kind of problem and therefore fixed the message?). However, of course, none of the strings is properly detected by the host PC's USB stack.
Also, I noticed (from a USB trace of the control request), that the strings differ from the ones I found on the net. Seems that Vendor is "Gen" (instead of "Max"). Product is "USB Stick". Also, the Config #1 seems to have a string saying "Def" (for default, I guess). Is it possible that this is some generic reference design firmware? Who knows more?
Also, checking the responses in the USB trace, I noticed that the reported strings differ from the ones I found here (and on the net). Seems that my USB Vendor is "Gen" (instead of "Max"). Product is "USB Stick" (same as on the net). Also, the Config #1 seems to have a string saying "Def" (for "default configuration", I guess). The unspecific strings sound like this is some generic reference design firmware? Does anyone know more?
It seems there are different FX2 firmware versions out there.
Should we create a collection of firmware dumps of the FX2 USB frontend controller here? I would be very interested in flashing someone else's firmware and check if it resolves the problems. Who is in? Reading the EEPROM of the FX2 is very simple.
So, it seems there are different Cypress FX2 frontend firmware versions out there. Should we create a collection of firmware dumps of the FX2 USB frontend controller here? I would be very interested in flashing someone else's firmware and check if it resolves the problems. Who is in? Reading and writing the FX2's I2C-attached EEPROM is very simple (Cypress vendor-specific USB requests).

Revision as of 22:21, 13 May 2015

On the T230 page there are logs of a running linux os, what happens if You attach a T230 usb stick. But which linux distribution do You use (highest availabel kernel version at the moment is 3.18.4). But You say, 3.19 is needed ? Can You help me, "Trsqr" ?

Current stable is 3.18.5, latest testing is 3.19-rc7. Probably, that means that in 3.18.x it's not yet included and will be in 3.19 series. For now, you may try it with current linux-media, http://git.linuxtv.org/cgit.cgi/media_build.git/ --wirbel (talk) 09:06, 3 February 2015 (CET)

Details about known issues, please

Trsqr, can you please tell us more details about the known issues you mentioned, and about the operators? Which kind of problems did you observe? Thanks!

Anyone else also has USB String descriptor problems?

On my device I found a strange USB issue: All string descriptors are reported defective. That is, the language string descriptor starts with a spurious 0x00 (which is interpreted as the length field), and also includes all following string descriptors (wrong length of the control IN data stage probably due to internal structure parsing error in the firmware). The strings themselves look ok, there is just this leading 0x00 byte that is too much. It seems as if the firmware responds with the whole string descriptor set (structure), no matter which string it is being asked for (internal parser issue). This leads to strange errors on the host PC. For example, some versions of lsusb crash (assert) when using verbose mode on this USB device. Linux (kernel) used to print a warning in older versions, saying that the device responded with a defective string descriptor. In later versions the message sounds nicer, simply saying that the language string is not provided and that it defaults to English (maybe someone out there had the same problem with this kind of problem and therefore fixed the message?). However, of course, none of the strings is properly detected by the host PC's USB stack. Also, checking the responses in the USB trace, I noticed that the reported strings differ from the ones I found here (and on the net). Seems that my USB Vendor is "Gen" (instead of "Max"). Product is "USB Stick" (same as on the net). Also, the Config #1 seems to have a string saying "Def" (for "default configuration", I guess). The unspecific strings sound like this is some generic reference design firmware? Does anyone know more? So, it seems there are different Cypress FX2 frontend firmware versions out there. Should we create a collection of firmware dumps of the FX2 USB frontend controller here? I would be very interested in flashing someone else's firmware and check if it resolves the problems. Who is in? Reading and writing the FX2's I2C-attached EEPROM is very simple (Cypress vendor-specific USB requests).