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 libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
|
