Find the answer to your Linux question:
Results 1 to 6 of 6
Hi, I have a very odd problem with FT4242H devices, which I hope someone recognizes. The FT4242H uses an external EEPROM for things like vendor/product strings and serial number. Without ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Oct 2011
    Posts
    3

    FT4232H semi-randomly fails to read EEPROM on cold reboot


    Hi,

    I have a very odd problem with FT4242H devices, which I hope someone
    recognizes.

    The FT4242H uses an external EEPROM for things like vendor/product
    strings and serial number. Without the external EEPROM the
    vendor/product strings reverts to defaults and there is no support for a
    serial number (which is the thing I'm really interested in). Typically I
    keep 4 separate devices conneced (so a total of 16 ports). On a cold
    reboot only about half of the FT4242H devices will read the EEPROM
    contents. The rest of them will just report defaults when examined with
    udevadm info. When one of the devices, which failed to report a serial
    number, is unplugged and plugged back in it will always succeed in
    reading the EEPROM contents, and will report the stored serial number.
    I've seen this issue turn up in both kernel 2.6.32.26 and 2.6.40.4.

    The problem does not seem to be tied to particular devices. For example,
    if I swap a working and a non-working board the problem usually does not
    move with the board. If anything, specific USB ports seems to work
    better than others, but that's not the full explanation either. So far
    I've not been able to spot any significant difference between a
    successful and failed read in dmesg or messages.

    Is there anyone here who is familiar with this type of problem?

    As a workaround I've tried to use udevadm trigger to simulate unplug +
    re-plug without any success. The default product string is 'Quad RS232-HS'
    so I've tried

    udevadm trigger --verbose --attr-match=interface=Quad*

    which seems to match only the devices that have failed to read the EEPROM.
    Unfortunately no combination of remove, add or change has successfully simulated
    a unplug + re-plug. Is this entirely the wrong approach, or what am I doing wrong?

  2. #2
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Posts
    11,393
    This sounds like a race condition in that the OS is booting before the EEPROM has come to a runable/initialized state. Unless this is a recently occurring problem, I'm not sure what you can do to fix it, other than modifying the BIOS to insert a wait state into the power-on sequence so that the EEPROM can initialize properly before control is given to the boot process.
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

  3. #3
    Just Joined!
    Join Date
    Oct 2011
    Posts
    3
    A certain combination of boards and ports mysteriously started working two days ago. Equally mysteriously the same combination of boards and ports stopped working this morning. I still don't have any idea what's going on.

    In any case I no longer need the serial numbers. As a workaround we're using the device nodes instead of the serial numbers to separate the boards.

  4. #4
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Posts
    11,393
    A certain combination of boards and ports mysteriously started working two days ago. Equally mysteriously the same combination of boards and ports stopped working this morning. I still don't have any idea what's going on.
    This sort of behavior reinforces my opinion that there is some sort of boot-time race condition happening. Does your board have a j-tag diagnostic header that you can use to probe the system as it boots in real-time?
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

  5. #5
    Just Joined!
    Join Date
    Oct 2011
    Posts
    3
    Quote Originally Posted by Rubberman View Post
    This sort of behavior reinforces my opinion that there is some sort of boot-time race condition happening. Does your board have a j-tag diagnostic header that you can use to probe the system as it boots in real-time?
    No j-tag header

  6. #6
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Posts
    11,393
    Quote Originally Posted by joakim_at_tangiamo View Post
    No j-tag header
    Too bad. That makes diagnosing this sort of problem much more difficult. Anyway, here is a link to the wikipedia article on the subject if you are interested in learning more about it: Joint Test Action Group - Wikipedia, the free encyclopedia
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •