# FTDI kernel modules for FreeBSD? Compiling a linux kernel module



## caesius (Feb 5, 2011)

I am trying to set this under FreeBSD.

When it is plugged in to a USB port:

```
Feb  5 13:30:07 blackbox kernel: ugen1.2: <Olimex Ltd.> at usbus1
```
(it should show up as ttyUSB0 under linux)

There seem to be a few options to get this thing going, one guide I've found says to compile a new kernel module. How do I do what this makefile is wanting me to do under FreeBSD?


```
obj-m += ftdi_sio.o

all:
	make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
 
clean:
	make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
```

Any other bright ideas? Cheers.


----------



## wblock@ (Feb 5, 2011)

The Linux instructions don't apply, it's a different world.

See uftdi(4).  You should be able to kldload uftdi and ucom, then get a /dev/cuaU0 device.


----------



## caesius (Feb 5, 2011)

Thanks for reply wblock.

I already have both of those modules loaded. There exists an entry similar to what you said, but it is there from boot up, regardless of whether I've plugged in the programmer.


```
> ls /dev/ | grep cua
cuau0
cuau0.init
cuau0.lock
```

Maybe just easier to use Linux?

Cheers


----------



## wblock@ (Feb 5, 2011)

The capital U is significant.
/dev/cuau0 is the serial port.
/dev/cuaU0 is a USB serial adapter.



> Maybe just easier to use Linux?



Well, maybe.  I've got a Sparkfun FTDI Basic USB-to-serial board here:

```
% ls /dev/cua?0
/dev/cuau0

ugen3.3: <FTDI> at usbus3
uftdi0: <FT232R USB UART> on usbus3

% ls /dev/cua?0
/dev/cuaU0	/dev/cuau0
```

It's possible they've used a different FTDI chip, or maybe just changed the USB vendor and product IDs so it's not detected.  Use
`% usbconfig -d 1.2 dump_device_desc`
to show them.


----------



## caesius (Feb 5, 2011)

```
blackbox# usbconfig -d 4.2 dump_device_desc
ugen4.2: <Olimex AVR-ISP500 Olimex Ltd.> at usbus4, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON

  bLength = 0x0012 
  bDescriptorType = 0x0001 
  bcdUSB = 0x0200 
  bDeviceClass = 0x0002 
  bDeviceSubClass = 0x0000 
  bDeviceProtocol = 0x0000 
  bMaxPacketSize0 = 0x0010 
  idVendor = 0x15ba 
  idProduct = 0x000c 
  bcdDevice = 0x0105 
  iManufacturer = 0x0001  <Olimex Ltd.>
  iProduct = 0x0002  <Olimex AVR-ISP500>
  iSerialNumber = 0x0003  <OL2C1AF00293509>
  bNumConfigurations = 0x0001
```

You seem like a knowledgeable person wblock! I appreciate your help.


----------



## wblock@ (Feb 5, 2011)

caesius said:
			
		

> You seem like a knowledgeable person wblock! I appreciate your help.



You're welcome!  I looked but couldn't find a schematic for what's inside that thing.  If it acts like an ordinary FTDI chip, uftdi(4) can be patched for it.  (Note: there are a lot of comments about needing the latest firmware...)

The standard warnings:

This may not work at all, no way to test from here, no guarantees.
It probably will not damage your hardware.  Probably.
May cause insanity or fascination with shiny objects.
May cause hair loss in pets or, well, anything really.
Make sure you have recentish 8.x source in /usr/src.

Download the patch: View attachment patch-uftdi.txt

Apply the patch:
`# cd /usr/src`
`# patch < patch-uftdi.txt`

If you're using a custom kernel without the uftdi module, you can just rebuild and reload the module.  If you're using the GENERIC kernel, uftdi is built in and the whole kernel has to be rebuilt using the standard formula:
`# rm -rf /usr/obj/usr; cd /usr/src; make -j4 kernel`

Reboot, put on safety goggles, fire-retardant underwear, and preferably, stilts.
Attach the device and look for /dev/cuaU0.
Think good thoughts and see if avrdude can program a disposable microcontroller without that horrible burning plastic smell.

If this all works, let me know and I'll submit a PR.


----------



## caesius (Feb 5, 2011)

Bugger. Didn't seem to work, as in nothing new is happening, still just reports:


```
Feb  5 13:30:07 blackbox kernel: ugen1.2: <Olimex Ltd.> at usbus1
```

Hey thanks for the effort though wblock, even if this doesn't work I've learned a bit about patching kernels 

Is there any further output/digging I could be doing to solve this? I don't know my way around the FreeBSD dev source very well..

Cheers.

P.S. I have also used a WIN32 machine to load on the latest firmware.


----------



## wblock@ (Feb 5, 2011)

A link to that Linux kernel article might provide clues.  Some of the other Olimex devices use USB ACM drivers, appearing as a modem.  The fancier version of the AVR-ISP500 has USB mass storage so you just copy the file to be programmed to it.  And there's also the possibility that there isn't an FTDI chip in there, or it's a different kind that uftdi doesn't support.


----------



## caesius (Feb 5, 2011)

Very good point! What I posted was the Makefile from the Linux drivers that I downloaded from the Olimex product page - I forgot to look through the code!

It comes with these files, which I won't post here because of their size:

```
Makefile
ftdi_sio.c
ftdi_sio.h
ftdi_sio_ids.h
```

I could look through these and figure out what is missing ideally right? I guess I'll start here:


```
> grep OLIMEX ftdi_*.[c,h]
ftdi_sio.c:     { USB_DEVICE(OLIMEX_VID, OLIMEX_ARM_USB_OCD_PID),
ftdi_sio.c:     { USB_DEVICE(OLIMEX_VID, OLIMEX_AVR_ISP500_ISO_PID) },
ftdi_sio_ids.h:#define OLIMEX_VID                       0x15BA
ftdi_sio_ids.h:#define OLIMEX_ARM_USB_OCD_PID           0x0003
ftdi_sio_ids.h:#define OLIMEX_AVR_ISP500_ISO_PID        0x000B
```

Hmmm, A lot of those look like just what you put in that patch wlock (0x15ba etc)

Cheers


----------



## wblock@ (Feb 5, 2011)

caesius said:
			
		

> Very good point! What I posted was the Makefile from the Linux drivers that I downloaded from the Olimex product page - I forgot to look through the code!
> 
> 
> ```
> ...



Yes, but that 0x000b is interesting.  The usbconfig output showed 0x000c.  Could be a composite device (ick), or that might just be for the fancier version.


----------



## caesius (Feb 5, 2011)

Yeah I went and changed it to 0x000b but still no luck.

Hmmm might just be moving to Linux for this one, cheers for your help wblock.


----------



## wblock@ (Feb 5, 2011)

If you find out any more details, it would be nice to have support for it in FreeBSD.  Someone on the freebsd-usb or freebsd-embedded mailing lists may be able to help, too.


----------

