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:
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
so you are the guy who developed the Bus Pirate renaming tool, right?
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
You mean in our web-archive, correct? I just fixed that, it now hides
addresses. We very much prefer to discuss such stuff on the
that other can take part in the discussions. I sent a CC of this mail
list, I hope you don't mind.
Thanks, I will now continue posting messages to the mailing list.
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.
The problem is EEPROM image generated by ftdi_eeprom_build breaks the
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.
It then produces kernel panic on Mac and BSOD under Windows.
Hmm, maybe you should also report this to Apple and Microsoft. Being
kill the whole system just by inserting a badly configured usb device
seem to be sane behaviour to me. Maybe you can even use this to
from the EEPROM...
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
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
got some sparse documentation for the chips available at that time.
say that the first 2 bytes are 0x00 0x00.
We asked FTDIchip several times about updated documentation but never got
We haven't done any further reverse-engineering with the EEPROM data
guy sent us code for decoding the chip-id stuff, but we didn't have
yet to investigate into that further.
I will check all the FT232RL chips I have with untouched EEPROM for this
offset. Maybe there's some kind of a pattern.
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.
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.
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
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
you are right, using a fixed size char array would be more easy and
handle. Care to cook up a patch to change this?
I will keep posting when I have some more information about it.
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
Description: Binary data