Re: ftdi_eeprom_build function produces faulty EEPROM image

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ftdi_eeprom_build function produces faulty EEPROM image

Gerd v. Egidy
Administrator
Hi Piotr,

so you are the guy who developed the Bus Pirate renaming tool, right? Did you
publish the source somewhere? I did a short look but couldn't find it.

> I was going to write it
> in the mailing list, but as email addresses are published and I have
> enough spam coming to my mailbox already, I've decided to contact you
> directly.

You mean in our web-archive, correct? I just fixed that, it now hides all mail
addresses. We very much prefer to discuss such stuff on the mailinglist so
that other can take part in the discussions. I sent a CC of this mail to the
list, I hope you don't mind.

> The problem is EEPROM image generated by ftdi_eeprom_build breaks the
> chip.

Not good.

> It then produces kernel panic on Mac and BSOD under Windows.

Hmm, maybe you should also report this to Apple and Microsoft. Being able to
kill the whole system just by inserting a badly configured usb device doesn't
seem to be sane behaviour to me. Maybe you can even use this to execute code
from the EEPROM...

> 1. Under the address 0x00, original FTDI EEPROM has two bytes 0x00 and
> 0x40, ftdilib always forces 0x00 0x00. I am guessing the 0x40 ( 64 dec )
> indicates how many 16 bit words are in the EEPROM.

When we started with libftdi back in 2003, we signed an NDA with FTDIchip and
got some sparse documentation for the chips available at that time. These docs
say that the first 2 bytes are 0x00 0x00.

We asked FTDIchip several times about updated documentation but never got
anything back.

We haven't done any further reverse-engineering with the EEPROM data yet. Some
guy sent us code for decoding the chip-id stuff, but we didn't have the time
yet to investigate into that further.
 
> 2. USB strings in the original EEPROM start at 0x18, libftdi puts them
> at offset 0x14. There are a four bytes 0x23,0x10,0x08,0x00 under address
> 0x14 in the original EEPROM. I do not know what they mean.

Me neither.

> 3. FT232RL chip type value is 0x06 which is (0x04 | 0x02), libftdi
> forces 0x02. It does not break the device, but I guess it should be
> handled somehow?

We just used the EEPROM stuff with older chips. This should probably be
updated.
 
> 4. What's the reason for not having fixed size char arrays for USB
> strings in the ftdi_eeprom structure? The malloc with no free causes
> memory leaks and a few bytes more won't hurt anyone. Just a thought.

If I'm not totally mistaken these values all have a maximum allowed size. So
you are right, using a fixed size char array would be more easy and safe to
handle. Care to cook up a patch to change this?

Kind regards,

Gerd


--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]  

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ftdi_eeprom_build function produces faulty EEPROM image

Piotr Pawluczuk
Hello Gerd,

Sorry for doubled message, I forgot to put mailing list address in the
CC, and my mail client skipped it.

On 10-01-28 15:45, Gerd v. Egidy wrote:
> Hi Piotr,
>
> so you are the guy who developed the Bus Pirate renaming tool, right?
> Did you
> publish the source somewhere? I did a short look but couldn't find it.
>
I was holding with source code release until I got some feedback. I
wanted to release it bug-free if possible. I have attached it with this
message.

>> I was going to write it
>> in the mailing list, but as email addresses are published and I have
>> enough spam coming to my mailbox already, I've decided to contact you
>> directly.
>
> You mean in our web-archive, correct? I just fixed that, it now hides
> all mail
> addresses. We very much prefer to discuss such stuff on the
> mailinglist so
> that other can take part in the discussions. I sent a CC of this mail
> to the
> list, I hope you don't mind.
Thanks, I will now continue posting messages to the mailing list.
>> The problem is EEPROM image generated by ftdi_eeprom_build breaks the
>> chip.
> Not good.
Since I can easily recover with a Linux box I will test which bytes
generated by libftdi are the cause of the problem. I will work on it
over the weekend.
>> It then produces kernel panic on Mac and BSOD under Windows.
>
> Hmm, maybe you should also report this to Apple and Microsoft. Being
> able to
> kill the whole system just by inserting a badly configured usb device
> doesn't
> seem to be sane behaviour to me. Maybe you can even use this to
> execute code
> from the EEPROM...
It's the kernel extension from FTDI causing the kernel panic on a Mac,
and I think I was able to resolve the BSOD problems with the latest FTDI
drivers, but it might still be there as I think I now only have the D2XX
drivers. I could connect to the device with them ( it took a minute
compared to a second with a healthy chip ) but could not restore with
any of FTDI utilities. Only RAW eeprom write helped.

>> 1. Under the address 0x00, original FTDI EEPROM has two bytes 0x00 and
>> 0x40, ftdilib always forces 0x00 0x00. I am guessing the 0x40 ( 64 dec )
>> indicates how many 16 bit words are in the EEPROM.
>
> When we started with libftdi back in 2003, we signed an NDA with
> FTDIchip and
> got some sparse documentation for the chips available at that time.
> These docs
> say that the first 2 bytes are 0x00 0x00.
>
> We asked FTDIchip several times about updated documentation but never got
> anything back.
>
> We haven't done any further reverse-engineering with the EEPROM data
> yet. Some
> guy sent us code for decoding the chip-id stuff, but we didn't have
> the time
> yet to investigate into that further.
I have a few different FTDI chips around, I will make EEPROM dumps and
compare what's inside. Maybe I will be able to find some useful
information.
>> 2. USB strings in the original EEPROM start at 0x18, libftdi puts them
>> at offset 0x14. There are a four bytes 0x23,0x10,0x08,0x00 under address
>> 0x14 in the original EEPROM. I do not know what they mean.
> Me neither.
I will check all the FT232RL chips I have with untouched EEPROM for this
offset. Maybe there's some kind of a pattern.

>> 3. FT232RL chip type value is 0x06 which is (0x04 | 0x02), libftdi
>> forces 0x02. It does not break the device, but I guess it should be
>> handled somehow?
>
> We just used the EEPROM stuff with older chips. This should probably be
> updated.
>
>> 4. What's the reason for not having fixed size char arrays for USB
>> strings in the ftdi_eeprom structure? The malloc with no free causes
>> memory leaks and a few bytes more won't hurt anyone. Just a thought.
>
> If I'm not totally mistaken these values all have a maximum allowed
> size. So
> you are right, using a fixed size char array would be more easy and
> safe to
> handle. Care to cook up a patch to change this?
The included source already has this modified, but I simply used size of
64 bytes this gives 128 bytes when converted to 16bit words and it's
above the limits already.

I will keep posting when I have some more information about it.

Thanks,

Piotr


--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]  

PirateRename.tar.bz (193K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ftdi_eeprom_build function produces faulty EEPROM image

Gerd v. Egidy
Administrator
Hi Piotr,

> > so you are the guy who developed the Bus Pirate renaming tool, right?
> > Did you
> > publish the source somewhere? I did a short look but couldn't find it.
>
> I was holding with source code release until I got some feedback. I
> wanted to release it bug-free if possible. I have attached it with this
> message.

Thanks. Seems like you are already using the libusb-1.0 version done by Jie.
Wow. Is there some special reason behind or did you just want to try it out?

Don't know about package management on Mac because I have never used any. But
wouldn't it be more easy to create a package for libftdi instead of copying
the source into every project?

> Since I can easily recover with a Linux box I will test which bytes
> generated by libftdi are the cause of the problem. I will work on it
> over the weekend.

cool. Looking forward to your findings.
 
> >> It then produces kernel panic on Mac and BSOD under Windows.
> >
> It's the kernel extension from FTDI causing the kernel panic on a Mac,
> and I think I was able to resolve the BSOD problems with the latest FTDI
> drivers, but it might still be there as I think I now only have the D2XX
> drivers.

According to FTDIchip their drivers have passed those Windows driver quality
test by Microsoft. Don't know what they check there, but probably not
enough...

> I have a few different FTDI chips around, I will make EEPROM dumps and
> compare what's inside. Maybe I will be able to find some useful
> information.

Very good.Maybe we can add this info on our webpage or put it into the
Doxygen.
 
Kind regards,

Gerd

--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]  

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: ftdi_eeprom_build function produces faulty EEPROM image

Michael Plante
Gerd v. Egidy wrote:
>> According to FTDIchip their drivers have passed those Windows driver
quality
>> test by Microsoft. Don't know what they check there, but probably not
>> enough...

I can't speak for their drivers, but I can for the DLL:  that's either not
checked, or else it's black-box tested.  d2xx was what convinced me the
quality test was a scam.  The DLL has all sorts of race conditions and other
bugs (at least when I looked about 9 months ago).  If the same person wrote
the driver, then... :)

Michael


--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]  

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ftdi_eeprom_build function produces faulty EEPROM image

Piotr Pawluczuk
In reply to this post by Gerd v. Egidy
On 10-01-28 17:28, Gerd v. Egidy wrote:

>>> so you are the guy who developed the Bus Pirate renaming tool, right?
>>> Did you
>>> publish the source somewhere? I did a short look but couldn't find it.
>>
>> I was holding with source code release until I got some feedback. I
>> wanted to release it bug-free if possible. I have attached it with this
>> message.
>
> Thanks. Seems like you are already using the libusb-1.0 version done by Jie.
> Wow. Is there some special reason behind or did you just want to try it out?
I have had libusb 1.0.x installed already, and since they encourage
developers to port to the 1.0.x release I decided to try libftdi-1.0. No
problems with this branch.
>
> Don't know about package management on Mac because I have never used any. But
> wouldn't it be more easy to create a package for libftdi instead of copying
> the source into every project?
There are two reasons I have embedded it in the project. First is that I
had to modify it and I didn't want to distribute modified library. And
the other is Mac users generally don't like messing with their file
system, some are completely unaware of things like libraries and it's
always nice to have an application that works out of the box.


--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]  

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ftdi_eeprom_build function produces faulty EEPROM image

David Brownell
In reply to this post by Gerd v. Egidy
On Thursday 28 January 2010, Gerd v. Egidy wrote:
> According to FTDIchip their drivers have passed those Windows driver quality
> test by Microsoft. Don't know what they check there, but probably not
> enough...

BSODs from USB are not necessarily caused by third party drivers.

Back when I spent time making Linux-USB peripherals work with MS-Windows,
I certainly saw more than enough of them caused by the MS-Windows USB
stack misbehaving.   Someone sent me a list of a couple dozen strange
failures with pure MSFT code (in their USB/RNDIS/NET stack) ... most of
them were things I had seen, and many of them caused BSODs.  So that
experience wasn't mine alone.

The ones which caused real head scratching were on the order of seeing
network packets seem to vanish into thin air ... then reappear minutes
later, *ON THE WRONG CONNECTION OR NETWORK INTERFACE* to wreak havoc.
Sometimes culminating in BSOD.

This was with USB packets which conformed 100% to their documentation
(stick USB sniffer on the link, double check data against MSFT specs)
and processed by 100% MSFT code.

Just pointing out that WHQL may be irrelevant to the problems here.

- Dave

--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to [hidden email]  

Loading...