libftdi Archives

Subject: Re: ftdi_eeprom_build function produces faulty EEPROM image

From: Piotr Pawluczuk <piotrek@xxxxxxxxxxxx>
To: "Gerd v. Egidy" <gerd.von.egidy@xxxxxxxxxxxxx>
Cc: libftdi@xxxxxxxxxxxxxxxxxxxxxxx
Date: Thu, 28 Jan 2010 16:15:34 +0100
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

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
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

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.



libftdi - see for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx   

Description: Binary data

Current Thread