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 libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
PirateRename.tar.bz
Description: Binary data
|
