Modify

Opened 8 years ago

Closed 7 years ago

#7365 closed defect (fixed)

Quad USB to serial converter w/ FT4232H does not work properly

Reported by: felixka <felixka@…> Owned by: developers
Priority: normal Milestone: Backfire 10.03.1
Component: other Version: Backfire 10.03
Keywords: usb-sio_ftdi Cc:

Description

Testing with NSLU2 -ixp4xx system: The device type is recognized correctly at start up, but later application cannot establish a serial connection via RXD/TXD. Bit banging RTS and CTS works fine.
When using different FTDI device FT232BM and FT2232C, everthing works fine.
In start up log, is MaxPacketSize = 2 correct??
See attached file

Attachments (3)

FT4232_log.txt (5.8 KB) - added by felixka <felixka@…> 8 years ago.
800-usb-serial-ftdi.patch (386 bytes) - added by wileczkam@… 7 years ago.
Patch created for 2.6.32.16 (should work for 2.6.31+)
FT4232_new_log.txt (1.5 KB) - added by felixka <felixka@…> 7 years ago.

Download all attachments as: .zip

Change History (20)

Changed 8 years ago by felixka <felixka@…>

comment:1 Changed 8 years ago by wileczkam@…

I have the same problem - did you find a solution?

comment:2 Changed 7 years ago by srpape@…

I edited drivers/usb/serial/ftdi_sio.c and changed

if (ep_desc->wMaxPacketSize == 0) {
     ep_desc->wMaxPacketSize = cpu_to_le16(0x40);
     dev_info(&udev->dev, "Overriding wMaxPacketSize on endpoint %d\n", i);
}

to

if (ep_desc->wMaxPacketSize <= 2) {
     ep_desc->wMaxPacketSize = cpu_to_le16(0x40);
     dev_info(&udev->dev, "Overriding wMaxPacketSize on endpoint %d\n", i);
}

A hack for sure, but it seems to be working for me at the moment.

comment:3 Changed 7 years ago by felixka@…

what do you think, is this issue caused by the ftdi driver source or by openwrt?

comment:4 Changed 7 years ago by srpape@…

My best *guess* is that it's an endianness problem. I believe that normally the MaxPacketSize is 0x0200 (512), but it's showing up as 0x002 (2), so maybe the bytes are swapped.

Haven't had the time to look into where this might be occurring, it was easier to just override it in the ftdi driver to get around the problem.

comment:5 Changed 7 years ago by anonymous

Actually seems like the other hack is wrong.
Notice this section of code:

	/* NOTE: some customers have programmed FT232R/FT245R devices
	 * with an endpoint size of 0 - not good.  In this case, we
	 * want to override the endpoint descriptor setting and use a
	 * value of 64 for wMaxPacketSize */
	for (i = 0; i < num_endpoints; i++) {
		dev_info(&udev->dev, "Endpoint %d MaxPacketSize %d\n", i+1,
			interface->cur_altsetting->endpoint[i].desc.wMaxPacketSize);
		ep_desc = &interface->cur_altsetting->endpoint[i].desc;
		if (ep_desc->wMaxPacketSize == 0) {
			ep_desc->wMaxPacketSize = cpu_to_le16(0x40);
			dev_info(&udev->dev, "Overriding wMaxPacketSize on endpoint %d\n", i);
		}
	}

	/* set max packet size based on descriptor */
	priv->max_packet_size = ep_desc->wMaxPacketSize;

	dev_info(&udev->dev, "Setting MaxPacketSize %d\n", priv->max_packet_size);

It sets priv->max_packet_size with a little endian value, and then proceeds to print it out as though it's a big endian value (on my hardware). It then uses it all over the place assuming it's big endian.

Perhaps:

	/* set max packet size based on descriptor */
	priv->max_packet_size = le16_to_cpu(ep_desc->wMaxPacketSize);

is what was intended.

comment:6 Changed 7 years ago by srpape@…

Above comment was me, forgot to fill in the email address.

comment:7 Changed 7 years ago by wileczkam@…

Just FYI, the above patch:

priv->max_packet_size = le16_to_cpu(ep_desc->wMaxPacketSize);

works on the following: FTDI 4232 ---- IXP430

Thanks!

comment:8 follow-up: Changed 7 years ago by srpape@…

Mike submitted the patch to the linux-usb group.

http://www.spinics.net/lists/linux-usb/msg35123.html

Thanks!

comment:9 in reply to: ↑ 8 Changed 7 years ago by felixka <felixka@…>

Replying to srpape@…:

Mike submitted the patch to the linux-usb group.

http://www.spinics.net/lists/linux-usb/msg35123.html

Thanks!

sorry, kindly explain what does that mean? Is there anything to do for the openwrt devs? Or just waiting that ftdi apply the patch to their driver source and then implement the uprev source?

comment:10 Changed 7 years ago by wileczkam@…

Basically, somebody forgot to swap the bytes if needed by a particular cpu. It works fine on a normal x86 PC because the bytes are in the correct order. For the ARM cpu we're working with, the bytes needs to be swapped. Meaning, instead of having a max packet size of 512, the driver was using 2! This didn't happen in previous versions because the value was hard coded to 64. Only when they officially added support for the high speed devices did they calculate the number on the fly.

I created a patch for my openwrt build. I submitted the patch to the kernel developers thinking that was the best way, but my guess is it will be a while before it shows up in openwrt. I'll try to submit the patch to openwrt as well in the next few days.

Changed 7 years ago by wileczkam@…

Patch created for 2.6.32.16 (should work for 2.6.31+)

comment:11 Changed 7 years ago by wileczkam@…

I attached the patch to the ticket and also submitted it to the kernel and openwrt. The patch file can be placed in target/linux/generic-2.6/patches-2.6.32 or whichever version you need it for.

Changed 7 years ago by felixka <felixka@…>

comment:12 Changed 7 years ago by felixka <felixka@…>

Thanks a lot...works fine now on my NSLU2 :-)

But I noticed some difference between srpape@ first hack and the final patch.
Both are working fine with my app...
First hack is setting MaxPacketSize 16384
Final patch is setting MaxPacketSize 512
What is better and what is the meaning of MaxPacketSize?

Pls see attachement

comment:13 Changed 7 years ago by srpape@…

felixka, I made both patches, but the second one replaces the first one. Don't use the hack anymore.

Set

if (ep_desc->wMaxPacketSize <= 2) {

back to == 0 and you should be good.

comment:14 follow-up: Changed 7 years ago by tlspindler <tlspindler@…>

This same issue occured on the Ubiquiti RouterStation Pro board. With this patch, the issue is resolved. My application is utilizing the FT2232H chipset, so it fixes this one as well.

Is there a URL where this patch was submitted to the kernel developers? Does anything else need to be done for this patch to be in the next RC for backfire or in the milestone version?

comment:15 in reply to: ↑ 14 Changed 7 years ago by srpape@…

Replying to tlspindler <tlspindler@…>:

This same issue occured on the Ubiquiti RouterStation Pro board. With this patch, the issue is resolved. My application is utilizing the FT2232H chipset, so it fixes this one as well.

Is there a URL where this patch was submitted to the kernel developers? Does anything else need to be done for this patch to be in the next RC for backfire or in the milestone version?

It went into stable 2.6.34.6 I guess.

See http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.34.6 and search for "fix endianess of max packet size".

The patch submission was in the mailing list. I'd post it but I keep getting flagged as spam if I do.

comment:16 Changed 7 years ago by KanjiMonster

This is "fixed" in trunk (since all kernel versions were updated to those including the fix), but not for backfire, since backfire is still at 2.6.32.16 (it was included in 2.6.32.21).

comment:17 Changed 7 years ago by hauke

  • Resolution set to fixed
  • Status changed from new to closed

This should also be fixed for backfire in r23915.

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.