Shop OBEX P1 Docs P2 Docs Learn Events
FT231XS com-port drivers for Linux kernel 2.6? — Parallax Forums

FT231XS com-port drivers for Linux kernel 2.6?

LawsonLawson Posts: 870
edited 2015-03-04 15:46 in Propeller 1
We have an old LIDAR system at work that's running Linux kernel 2.6 and we're having a hard time finding virtual com port drivers that support the new FT231XS chips on the quick-start boards. Anybody know of a way to get the FT231XS chips working without upgrading the kernel? (Upgrading the kernel is likely to brake a lot of your custom code, so we'd prefer to avoid the upgrade)

Marty

Comments

  • TorTor Posts: 2,010
    edited 2015-02-25 19:21
    Can you compile your own kernel? Which exact version is it? (Presumably it's not 2.6.0..)
    It doesn't seem too difficult to backport just the changes for FT231XS to the 2.6.x kernels.

    -Tor
  • evanhevanh Posts: 15,921
    edited 2015-02-25 21:46
    I'm no Linux wiz but I very much doubt any kernel compiling would be needed to load an updated/new ordinary character device driver unless there is something lacking in the kernel USB support system or similar.
  • evanhevanh Posts: 15,921
    edited 2015-02-25 21:51
    What you might have to do is do the backport of relevant device driver.
  • TorTor Posts: 2,010
    edited 2015-02-25 22:04
    Well, yes, that's basically what I said. And that _is_ kernel compiling. Even if you just compile that driver.
    In any case, the lastest kernel driver has some subtle differences in the driver model which may prevent a simple source drop-in replacement. But the changes necessary for supporting the FT231XS are not so large and could be applied to the 2.6.x driver.

    -Tor
  • evanhevanh Posts: 15,921
    edited 2015-02-25 22:20
    Ah, I had always thought it meant a recompile of the kernel itself, rather than just one runtime loadable module. Thinking about it, I've never considered drivers to be a kernel feature but I suppose that's where the monolithic view differs ...
  • Heater.Heater. Posts: 21,230
    edited 2015-02-26 01:21
    Linux device drivers can be compiled and linked into the kernel as one huge binary blob. You need to have drivers compiled into the kernel so that the thing can start up. How would it get to your disk without disk driver and file system code built in?

    Or drivers can be compiled as loadable modules.

    Either way that driver code is relies on the internal API's (If that is the right term) of the Linux kernel. At run time they run in "kernel space".

    All in all we can think of it as "kernel compile". It's the same in the Windows world.

    Anyway, what is this Linux running on? I can't help thinking it would be better to get your code running on a newer Linux install rather than messing around with historic stuff.

    I have had an ongoing problem with one of our drivers, keeping it working with new versions of Linux as they arise. I'd hate to be doing that work backwards!

    Of course it would be better if the Quick start stopped using FTDI devices. Those things are not USB standard serial devices and their manufacturer has been known to distribute malware in it's driver.
  • evanhevanh Posts: 15,921
    edited 2015-02-26 12:55
    Yep, Heater, I knew all that. Well, not the Windoze part. That still didn't make me think of it as a kernel compile unless one really was compiling the kernel.

    To me, a module is a program that's just accessing another API, or rather, DPI, hehe. Like DX is another API alongside Win32.
  • Heater.Heater. Posts: 21,230
    edited 2015-02-26 14:50
    evanh,

    Well, OK, yes. Compiling a kernel module is not compiling a whole kernel.

    However that kernel module you have compiled will require root privileges for you to load it into a running kernel.

    When it is loaded it is part of the kernel.

    At that point, the code you have written in the module can totally mess with anything on your machine.

    So any little bug in there and it can be poof! Light's out for you OS.

    Or if you have obtained your driver from elsewhere, it can be any kind kind of malware that the provider puts in there. Like the recent USB device killing malware provided in USb/serial drivers by FTDI.

    Same as in Windows as far as I can tell.
  • LawsonLawson Posts: 870
    edited 2015-03-04 15:46
    Thank you for all the advice. We have managed to fix this driver issue, but there was WAY more to it than we expected.

    First, the Lidar we wanted to use the FT231XS chip with has 7 custom PCI boards with custom kernel drivers that do photon-counting. Porting that to a new Linux kernel is a LOT of work. We have the custom drivers working on Centos 5 and 6, though this system is one of our oldest so still ran Centos 5. (with Kernel 2.6.18)

    Testing narrowed the failure down to a combination of Centos 5 and the specific industrial PC motherboard used in the LIDAR. Centos 6 worked on a newer Lidar upstairs. Centos 5 worked in a VM when hosted on a Mac laptop and Centos 6 PC. The final solution was to move this old Lidar to the newer Centos 6 distribution that we had running another lidar.

    Marty
Sign In or Register to comment.