Re: umcs (4-Port-USB-serial) triggering way too much ehci IRQs

[Ian Lepore]

On Tue, 2013-09-17 at 17:38 +0200, Harald Schmalzbauer wrote:
 Bezüglich Hans Petter Selasky's Nachricht vom 17.09.2013 11:24
 (localtime):
  On 09/17/13 11:06, Harald Schmalzbauer wrote:
  ...
  Shall we switch to non-list-comm?
 
  Hi,
 
  That's OK.
 
  Hmm, in my case, this 4-port-serial-USB-hub will be used as console
  concentrator. So most time it's doing nothing, just feeding tmux with
  consoles output. What latency are we talking about? Less than a some
  milliseconds should be fine.
  What I'm curious about is why my prolific USB-serial converter doesn't
  generate these high irqs.
 
  Try this patch and see what happens:
 
  ==
  --- umcs.c(revision 255492)
  +++ umcs.c(local)
  @@ -230,6 +230,7 @@
   .bufsize = 0,/* use wMaxPacketSize */
   .callback = umcs7840_intr_callback,
   .if_index = 0,
  +.interval = 20, /* ms */
   },
   };
 
 
  BTW: I see that the umcs driver shouldn't do synchronous control
  transfers from the USB interrupt transfer callback. This should be
  postponed into some worker thread, for example the USB explore thread.
  See USB audio driver for an example.
 
  --HPS
 
 I tried your patch and it works as expected: IRQs decreased to ~64/s
 when idle/disconnected.
 
 One interesting thing I never measured before:
 Console connection with 115k2 via umcs and 'while ( 21 ) echo ---...
 end' results in 8000 irqs/s :-( But that's also true for the prolific
 (uplcom). The latter just goes down to 0.0 irqs/s when idle.
 
 Doing the same with uart0 results in 1444irqs/s.
 Is it by design/unavoidable that transfering the same via USB multiplies
 by factor 5-6?
 
 Thanks,
 
 -Harry
 

I don't know about that chipset, but with the FTDI chips it does xfers
in 64 byte chunks and high speed bulk data results in an astronomical
number of interrupts (and if you go fast enough, lost data).  I have
some patches that assemble lots of the little chip-size buffers into
bigger xfers that the ohci/ehci controller can handle without
interrupting the processor; that helps the problem a bunch.

-- Ian


___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org

Re: umcs (4-Port-USB-serial) triggering way too much ehci IRQs

[Ian Lepore]

On Tue, 2013-09-17 at 19:32 +0200, Harald Schmalzbauer wrote:
 Bezüglich Ian Lepore's Nachricht vom 17.09.2013 18:16 (localtime):
  On Tue, 2013-09-17 at 17:38 +0200, Harald Schmalzbauer wrote:
  ...
  Try this patch and see what happens:
 
  ==
  --- umcs.c(revision 255492)
  +++ umcs.c(local)
  @@ -230,6 +230,7 @@
   .bufsize = 0,/* use wMaxPacketSize */
   .callback = umcs7840_intr_callback,
   .if_index = 0,
  +.interval = 20, /* ms */
   },
   };
 
 
  BTW: I see that the umcs driver shouldn't do synchronous control
  transfers from the USB interrupt transfer callback. This should be
  postponed into some worker thread, for example the USB explore thread.
  See USB audio driver for an example.
 
  --HPS
  I tried your patch and it works as expected: IRQs decreased to ~64/s
  when idle/disconnected.
 
  One interesting thing I never measured before:
  Console connection with 115k2 via umcs and 'while ( 21 ) echo ---...
  end' results in 8000 irqs/s :-( But that's also true for the prolific
  (uplcom). The latter just goes down to 0.0 irqs/s when idle.
 
  Doing the same with uart0 results in 1444irqs/s.
  Is it by design/unavoidable that transfering the same via USB multiplies
  by factor 5-6?
 
  Thanks,
 
  -Harry
 
  I don't know about that chipset, but with the FTDI chips it does xfers
  in 64 byte chunks and high speed bulk data results in an astronomical
  number of interrupts (and if you go fast enough, lost data).  I have
 
 According to ASIX product brief, MCS7840 has 512 byte buffer. Pretty
 much for an UART I think, which should make 115k2 baud connections  with
 less than 30 transfers/s work, or am I missing something?

That's the internal buffer, it still does usb transfers in smaller
chunks.  Some ftdi chips have 4k onboard buffers but do 64-byte usb
transfers.

-- Ian


___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org

Re: umcs (4-Port-USB-serial) triggering way too much ehci IRQs

[Ian Lepore]

On Tue, 2013-09-17 at 23:08 +0400, Lev Serebryakov wrote:
 Hello, Harald.
 You wrote 17 сентября 2013 г., 21:43:17:
 
 HS Is that worth a try?
 HS 
 http://www.asix.com.tw/FrootAttach/driver/MCS7840_7820_FreeBSD_driver_v1.1.zip
   Nope. I've started from this driver, and it even doesn't support BREAK
  signal (it is was first reason why I start to write new one -- I needed
  BREAK to enter kernel debugger).
 
 HS At least, it seems to be possible to enable RS485-mode :-) :-)
   I could easily add RS485 mode, BUT! FreeBSD doesn;'t have any userland API
  for it, and the same is true for higher and non-standard baud rates.

There's no API needed for higher baud rates.  I've used cfsetspeed() to
set 3mbps on ftdi chips.   I've also used it for completely arbitrary
speeds like 554000bps (happens to be the fastest I can run an ftdi chip
on a 180mhz arm without dropping chars, but going that fast requires
other changes to the driver.).

-- Ian




___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org

Supporting higher baud rates in newer FTDI chips

[Ian Lepore]

I have added support to the uftdi driver for the higher baud rates
supported by the latest H-series chips.  I hope to commit the changes
soon; the patch is attached for review.

In the process I discovered we've been setting the rate wrong on the
older chips (we put the high bit of the fractional rate in the wrong
place, but it only affects very high non-standard bit rates).  Because
the old code was wrong I ended up basically rewriting everything related
to calculating and setting the baud rate.  

The newer chips use the same product ID as the earlier ones, so I wrote
some new code to use the bcdDevice field from the device descriptor to
determine the model and version of chip.

I've tested this on all the chips I have around: 232R, 2232C, 2232D,
2232H, and 4232H.

-- Ian

Index: sys/dev/usb/serial/uftdi_reg.h
===
--- sys/dev/usb/serial/uftdi_reg.h	(revision 263112)
+++ sys/dev/usb/serial/uftdi_reg.h	(working copy)
@@ -75,31 +75,13 @@
 /*
  * BmRequestType:  0100 B
  * bRequest:   FTDI_SIO_SET_BAUDRATE
- * wValue: BaudRate value - see below
- * wIndex: Port
+ * wValue: BaudRate low bits
+ * wIndex: Port and BaudRate high bits 
  * wLength:0
  * Data:   None
  */
 /* FTDI_SIO_SET_BAUDRATE */
-enum {
-	ftdi_sio_b300 = 0,
-	ftdi_sio_b600 = 1,
-	ftdi_sio_b1200 = 2,
-	ftdi_sio_b2400 = 3,
-	ftdi_sio_b4800 = 4,
-	ftdi_sio_b9600 = 5,
-	ftdi_sio_b19200 = 6,
-	ftdi_sio_b38400 = 7,
-	ftdi_sio_b57600 = 8,
-	ftdi_sio_b115200 = 9
-};
 
-#define	FTDI_8U232AM_FREQ 300
-
-/* Bounds for normal divisors as 4-bit fixed precision ints. */
-#define	FTDI_8U232AM_MIN_DIV 0x20
-#define	FTDI_8U232AM_MAX_DIV 0x3fff8
-
 /*
  * BmRequestType:  0100 B
  * bRequest:   FTDI_SIO_SET_DATA
Index: sys/dev/usb/serial/uftdi.c
===
--- sys/dev/usb/serial/uftdi.c	(revision 263112)
+++ sys/dev/usb/serial/uftdi.c	(working copy)
@@ -92,6 +92,21 @@ enum {
 	UFTDI_N_TRANSFER,
 };
 
+enum {
+	DEVT_SIO,
+	DEVT_232A,
+	DEVT_232B,
+	DEVT_2232D,	/* Includes 2232C */
+	DEVT_232R,
+	DEVT_2232H,
+	DEVT_4232H,
+	DEVT_232H,
+	DEVT_230X,
+};
+
+#define	DEVF_BAUDBITS_HINDEX	0x01	/* Baud bits in high byte of index. */
+#define	DEVF_BAUDCLK_12M	0X02	/* Base baud clock is 12MHz. */
+
 struct uftdi_softc {
 	struct ucom_super_softc sc_super_ucom;
 	struct ucom_softc sc_ucom;
@@ -105,15 +120,16 @@ struct uftdi_softc {
 
 	uint16_t sc_last_lcr;
 
-	uint8_t sc_type;
-	uint8_t	sc_iface_index;
+	uint8_t sc_devtype;
+	uint8_t sc_devflags;
 	uint8_t	sc_hdrlen;
 	uint8_t	sc_msr;
 	uint8_t	sc_lsr;
 };
 
 struct uftdi_param_config {
-	uint16_t rate;
+	uint16_t baud_lobits;
+	uint16_t baud_hibits;
 	uint16_t lcr;
 	uint8_t	v_start;
 	uint8_t	v_stop;
@@ -135,8 +151,8 @@ static void	uftdi_cfg_open(struct ucom_softc *);
 static void	uftdi_cfg_set_dtr(struct ucom_softc *, uint8_t);
 static void	uftdi_cfg_set_rts(struct ucom_softc *, uint8_t);
 static void	uftdi_cfg_set_break(struct ucom_softc *, uint8_t);
-static int	uftdi_set_parm_soft(struct termios *,
-		struct uftdi_param_config *, uint8_t);
+static int	uftdi_set_parm_soft(struct ucom_softc *, struct termios *,
+		struct uftdi_param_config *);
 static int	uftdi_pre_param(struct ucom_softc *, struct termios *);
 static void	uftdi_cfg_param(struct ucom_softc *, struct termios *);
 static void	uftdi_cfg_get_status(struct ucom_softc *, uint8_t *,
@@ -145,7 +161,6 @@ static void	uftdi_start_read(struct ucom_softc *);
 static void	uftdi_stop_read(struct ucom_softc *);
 static void	uftdi_start_write(struct ucom_softc *);
 static void	uftdi_stop_write(struct ucom_softc *);
-static uint8_t	uftdi_8u232am_getrate(uint32_t, uint16_t *);
 static void	uftdi_poll(struct ucom_softc *ucom);
 
 static const struct usb_config uftdi_config[UFTDI_N_TRANSFER] = {
@@ -846,6 +861,80 @@ static const STRUCT_USB_HOST_ID uftdi_devs[] = {
 #undef UFTDI_DEV
 };
 
+/*
+ * Set up softc fields whose value depends on the device type.
+ *
+ * Note that the 2232C and 2232D devices are the same for our purposes.  In the
+ * silicon the difference is that the D series has CPU FIFO mode and C doesn't.
+ * I haven't found any way of determining the C/D difference from info provided
+ * by the chip other than trying to set CPU FIFO mode and having it work or not.
+ * 
+ * Due to a hardware bug, a 232B chip without an eeprom reports itself as a 
+ * 232A, but if the serial number is also zero we know it's really a 232B. 
+ */
+static void
+uftdi_devtype_setup(struct uftdi_softc *sc, struct usb_attach_arg *uaa)
+{
+	struct usb_device_descriptor *dd;
+
+	switch (uaa-info.bcdDevice) {
+	case 0x200:
+		dd = usbd_get_device_descriptor(sc-sc_udev);
+		if (dd-iSerialNumber == 0) {
+			sc-sc_devtype = DEVT_232B;
+		} else {
+			sc-sc_devtype = DEVT_232A;
+		}
+		sc-sc_ucom.sc_portno = 0;
+		break;
+	case 0x400:
+		sc-sc_devtype = DEVT_232B;
+		sc-sc_ucom.sc_portno = 0;
+		

uftdi driver - new ioctls to support FTDI bitbang and other modes

[Ian Lepore]

The attached patch, which I hope to commit sometime soon, adds support
for bitbang, MPSSE, CPU_FIFO, and other modes supported by the FTDI
serial adapter chips, using ioctl() calls.  This allows full control of
all the FTDI features that embedded folks like, using any language that
supports fd-based IO.  You can, for example, program an fpga in MPSSE
mode just by configuring the mode with a couple ioctl() calls, then
writing the bitfile image to the fd as if it were going out a serial
port.  You can also do jtag work this way.

In addition to adding the new ioctls, this change removes all the code
that reset the chip at attach and open/close time, and also the code
that turned on RTS/CTS flow control on open without any permission to do
so (that was just always a bug in the driver).  

When FTDI chips are configured as GPIO or MPSSE or other special-purpose
uses by an attached serial eeprom, the chip will power on with certain
pins driven or floating, and it's important that the driver not do
anything to the chip to perturb that unless it receives a specific
command to do so.  When used for plain old serial comms the chip
powers on into the right mode and never needs to be reset while it's
running to operate properly, so this change is transparent to most
users.

-- Ian


Index: sys/dev/usb/serial/uftdi_reg.h
===
--- sys/dev/usb/serial/uftdi_reg.h	(revision 264013)
+++ sys/dev/usb/serial/uftdi_reg.h	(working copy)
@@ -28,6 +28,10 @@
 	 * reg */
 #define	FTDI_SIO_SET_EVENT_CHAR	6	/* Set the event character */
 #define	FTDI_SIO_SET_ERROR_CHAR	7	/* Set the error character */
+#define	FTDI_SIO_SET_LATENCY	9	/* Set the latency timer */
+#define	FTDI_SIO_GET_LATENCY	10	/* Read the latency timer */
+#define	FTDI_SIO_SET_BITMODE	11	/* Set the bit bang I/O mode */
+#define	FTDI_SIO_GET_BITMODE	12	/* Read pin states in bit bang mode */
 
 /* Port Identifier Table */
 #define	FTDI_PIT_DEFAULT 	0	/* SIOA */
Index: sys/dev/usb/serial/uftdi.c
===
--- sys/dev/usb/serial/uftdi.c	(revision 264031)
+++ sys/dev/usb/serial/uftdi.c	(working copy)
@@ -38,7 +38,14 @@ __FBSDID($FreeBSD$);
  */
 
 /*
- * FTDI FT2232x, FT8U100AX and FT8U232AM serial adapter driver
+ * FTDI FT232x, FT2232x, FT4232x, FT8U100AX and FT8U232xM serial adapters.
+ *
+ * Note that we specifically do not do a reset or otherwise alter the state of
+ * the chip during attach, detach, open, and close, because it could be
+ * pre-initialized (via an attached serial eeprom) to power-on into a mode such
+ * as bitbang in which the pins are being driven to a specific state which we
+ * must not perturb.  The device gets reset at power-on, and doesn't need to be
+ * reset again after that to function, except as directed by ioctl() calls.
  */
 
 #include sys/stdint.h
@@ -64,6 +71,7 @@ __FBSDID($FreeBSD$);
 #include dev/usb/usbdi.h
 #include dev/usb/usbdi_util.h
 #include dev/usb/usb_core.h
+#include dev/usb/usb_ioctl.h
 #include usbdevs.h
 
 #define	USB_DEBUG_VAR uftdi_debug
@@ -72,6 +80,7 @@ __FBSDID($FreeBSD$);
 
 #include dev/usb/serial/usb_serial.h
 #include dev/usb/serial/uftdi_reg.h
+#include dev/usb/uftdiio.h
 
 #ifdef USB_DEBUG
 static int uftdi_debug = 0;
@@ -175,6 +184,7 @@ static usb_callback_t uftdi_read_callback;
 
 static void	uftdi_free(struct ucom_softc *);
 static void	uftdi_cfg_open(struct ucom_softc *);
+static void	uftdi_cfg_close(struct ucom_softc *);
 static void	uftdi_cfg_set_dtr(struct ucom_softc *, uint8_t);
 static void	uftdi_cfg_set_rts(struct ucom_softc *, uint8_t);
 static void	uftdi_cfg_set_break(struct ucom_softc *, uint8_t);
@@ -184,6 +194,15 @@ static int	uftdi_pre_param(struct ucom_softc *, st
 static void	uftdi_cfg_param(struct ucom_softc *, struct termios *);
 static void	uftdi_cfg_get_status(struct ucom_softc *, uint8_t *,
 		uint8_t *);
+static int	uftdi_reset(struct ucom_softc *, int);
+static int	uftdi_set_bitmode(struct ucom_softc *, uint8_t, uint8_t);
+static int	uftdi_get_bitmode(struct ucom_softc *, uint8_t *);
+static int	uftdi_set_latency(struct ucom_softc *, int);
+static int	uftdi_get_latency(struct ucom_softc *, int *);
+static int	uftdi_set_event_char(struct ucom_softc *, int);
+static int	uftdi_set_error_char(struct ucom_softc *, int);
+static int	uftdi_ioctl(struct ucom_softc *, uint32_t, caddr_t, int,
+		struct thread *);
 static void	uftdi_start_read(struct ucom_softc *);
 static void	uftdi_stop_read(struct ucom_softc *);
 static void	uftdi_start_write(struct ucom_softc *);
@@ -218,7 +237,9 @@ static const struct ucom_callback uftdi_callback =
 	.ucom_cfg_set_break = uftdi_cfg_set_break,
 	.ucom_cfg_param = uftdi_cfg_param,
 	.ucom_cfg_open = uftdi_cfg_open,
+	.ucom_cfg_close = uftdi_cfg_close,
 	.ucom_pre_param = uftdi_pre_param,
+	.ucom_ioctl = uftdi_ioctl,
 	.ucom_start_read = uftdi_start_read,
 	.ucom_stop_read = uftdi_stop_read,
 	.ucom_start_write = uftdi_start_write,

Re: usb/188683: dwc_otg FDT support for specifying usb controller mode

[Ian Lepore]

The following reply was made to PR usb/188683; it has been noted by GNATS.

From: Ian Lepore i...@freebsd.org
To: John Wehle j...@feith.com
Cc: freebsd-gnats-sub...@freebsd.org
Subject: Re: usb/188683: dwc_otg FDT support for specifying usb controller
 mode
Date: Wed, 16 Apr 2014 07:09:26 -0600

 On Wed, 2014-04-16 at 07:17 +, John Wehle wrote:
  Number: 188683
  Category:   usb
  Synopsis:   dwc_otg FDT support for specifying usb controller mode
  Confidential:   no
  Severity:   non-critical
  Priority:   low
  Responsible:freebsd-usb
  State:  open
  Quarter:
  Keywords:   
  Date-Required:
  Class:  sw-bug
  Submitter-Id:   current-users
  Arrival-Date:   Wed Apr 16 07:20:01 UTC 2014
  Closed-Date:
  Last-Modified:
  Originator: John Wehle
  Release:11 r264251
  Organization:
  Personal
  Environment:
  Not Yet
  Description:
  In my spare time I'm working on bringing FreeBSD up on amlogic based
  arm processors.  The amlogic SoC contains a dwc USB controller.
  If I enable the controller on a Visson ATV-102 box (mine appears
  to be based on the aml8726-m6 SoC) which uses a GL850G usb hub chip
  the driver fails to detect GOTGCTL_ASESVLD so it doesn't work.
  
  The attached patch allows the mode to be specifed in the FDT ...
  if the mode is set to host, then the driver doesn't looks for
  GOTGCTL_ASESVLD ... it assumes VBUS is driven.  This suffices for
  basic USB functionality on the Visson ATV-102.
  
  How-To-Repeat:
  Build FreeBSD 11 for the Visson ATV-102 (this requires code for the
  amlogic platform which I'll be supplying in the future) and attempt
  to use USB.
  Fix:
  Apply the patch to optionally specify the controller mode and added
  
mode = host;
  
  to the usb block in vsatv102-m6.dts.
  
  Patch attached with submission follows:
  
  Index: sys/dev/usb/controller/dwc_otg_fdt.c
  ===
  --- sys/dev/usb/controller/dwc_otg_fdt.c (revision 264251)
  +++ sys/dev/usb/controller/dwc_otg_fdt.c (working copy)
  @@ -91,9 +91,27 @@
   dwc_otg_attach(device_t dev)
   {
   struct dwc_otg_super_softc *sc = device_get_softc(dev);
  +pcell_t *prop;
  +phandle_t node;
  +ssize_t len;
   int err;
   int rid;
   
  +node = ofw_bus_get_node(dev);
  +len = OF_getprop_alloc(node, mode, sizeof(char), (void **)prop);
  +if (len = 0) {
  +if (strcmp((char *)prop, host) == 0)
  +sc-sc_otg.sc_mode = DWC_MODE_HOST;
  +else if (strcmp((char *)prop, device) == 0)
  +sc-sc_otg.sc_mode = DWC_MODE_DEVICE;
  +else if (strcmp((char *)prop, otg) == 0)
  +;
  +else
  +device_printf(dev,
  +  ignoring unknown value for mode attribute in FDT\n);
  +}
  +free(prop, M_OFWPROP);
  +
   /* initialise some bus fields */
   sc-sc_otg.sc_bus.parent = dev;
   sc-sc_otg.sc_bus.devices = sc-sc_otg.sc_devices;
  Index: sys/dev/usb/controller/dwc_otg.c
  ===
  --- sys/dev/usb/controller/dwc_otg.c (revision 264251)
  +++ sys/dev/usb/controller/dwc_otg.c (working copy)
  @@ -2332,7 +2332,7 @@
   
   DPRINTFN(5, GOTGCTL=0x%08x\n, temp);
   
  -dwc_otg_vbus_interrupt(sc,
  +dwc_otg_vbus_interrupt(sc, (sc-sc_mode == DWC_MODE_HOST) ? 1 :
   (temp  (GOTGCTL_ASESVLD | GOTGCTL_BSESVLD)) ? 1 : 0);
   }
   
  @@ -3182,7 +3182,7 @@
   sc-sc_host_ch_max);
   
   /* setup FIFO */
  -if (dwc_otg_init_fifo(sc, DWC_MODE_OTG))
  +if (dwc_otg_init_fifo(sc, sc-sc_mode))
   return (EINVAL);
   
   /* enable interrupts */
  @@ -3233,7 +3233,7 @@
   
   DPRINTFN(5, GOTCTL=0x%08x\n, temp);
   
  -dwc_otg_vbus_interrupt(sc,
  +dwc_otg_vbus_interrupt(sc, (sc-sc_mode == DWC_MODE_HOST) ? 1 :
   (temp  (GOTGCTL_ASESVLD | GOTGCTL_BSESVLD)) ? 1 : 0);
   
   USB_BUS_UNLOCK(sc-sc_bus);
  
  
  Release-Note:
  Audit-Trail:
  Unformatted:
 
 The DeviceTree docs indicate there's a standard property name and values
 for this:
 
  - dr_mode: tells Dual-Role USB controllers that we want to work on a
 particular mode. Valid arguments are host, peripheral and otg. In
 case this attribute isn't passed via DT, USB DRD controllers should
 default to OTG.
 
 -- Ian
 
 
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org

Re: About XHCI_TD_PAGE_SIZE.

[Ian Lepore]

On Mon, 2014-12-22 at 10:48 +0100, Hans Petter Selasky wrote:
 On 12/22/14 10:31, Kohji Okuno wrote:
  In an optimisation, we should reduce the number of LINK_TRB, too.
  I heard  from a LSI engineer that,
  Generally xhci controler has the cache of TRB array. But, LINK_TRB
  may make the cache miss.
 
 Hi,
 
 One reason for the additional link TRB's is that I think there is 
 different behaviour among the XHCI implementations how and when they 
 generate a completion event. Any changes we make in that area needs to 
 be tested with different XHCI controllers.
 
 Currently only the umass driver will use transfers greater than 64KBytes 
 in case of USB 3.0. Else the most common case is transfers below 
 64KBytes, except for custom apps.
 
 I have another idea pending, which is related to performance, but not 
 the XHCI. I was thinking that the FreeBSD libusb could be extended to 
 allocate a data buffer in the kernel which then gets mmapped to 
 userspace, to save copying/copyout of USB transfer data. The problem 
 about mmap() is that the buffers cannot be freed afterwards, and must 
 remain in the kernel.
 
 What do you think?

So you're going to be doing DMA directly in and out of buffers mapped
into userspace?  I think that will fail on ARM and MIPS at least, and
maybe others (any platform that does cache maintenance based on virtual
addresses will be unable to do the maintenance reliably if the DMA
memory is mapped to multiple virtual addresses).  The solution for that
is bounce buffers, which just gets you right back into copying the data.

-- Ian


___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org

Re: usb_pc_cpu_flush

[Ian Lepore]

On Wed, 2015-01-14 at 06:13 +0100, Hans Petter Selasky wrote:
 On 01/13/15 21:25, Ian Lepore wrote:
  On Tue, 2015-01-13 at 17:52 +0100, Hans Petter Selasky wrote:
  On 01/13/15 17:29, Ian Lepore wrote:
  On Tue, 2015-01-13 at 16:57 +0100, Hans Petter Selasky wrote:
[...]
 
  Hi,
 
  Can you give an example of a NIC driver which you consider a good
  example which use DMA both for data (not only mbufs) and the control
  path and use busdma as you consider to be correct?
 
  --HPS
 
  dev/ffec/if_ffec.c.  I'm not happy with the fact that it takes two calls
  (a PRE and a POST) to accomplish a single action, but that's the right
  way to do things in the current busdma world, PRE and POST operations
  need to be paired.
 
  I think we need new busdma support for shared concurrent access
  descriptors, because it's a type of dma that just isn't supported well
  by the existing API.  There should be a new flag for bus_dmamem_alloc()
  that indicates the memory is going to be used for such shared access
  (because some platforms may be able to provide memory that's mapped
  optimally for such situations), and there should be new sync ops that
  don't require a pair of calls to accomplish a single action.
 
  All of this is in the context of shared descriptor memory.  Regular IO
  buffers should just use the proper sequence of PRE and POST syncs (and
  most especially should *never* do POSTREAD before PREREAD like the
  current usb_pc_cpu_invalidate() does, because with bounce buffers that
  will just not work right).
 
 
 Hi,
 
 I understand and that can be done for IO-buffers like in the FFEC 
 driver. For other buffers it is a bigger task, however:
 
 I see that some memory is allocated using BUS_DMA_COHERENT in 
 if_ffec.c and in those cases no busdma sync operations are performed! Is 
 that correct? For example rxdesc_ring is allocated coherently and no 
 cache sync ops are done before and after access.
 

No, it does do sync operations on the descriptors rings, because one of
the documented rules of coherent memory is that you still have to do all
the normal sync ops.  Traditionally coherent has meant completely
disable caching on arm and you could get away with not doing the sync
ops, but that's not true anymore.  Arm memory subsystems are more
complex these days and sync ops are needed in some cases even for
uncached memory.

In the current ffec code, sync ops on descriptor memory are done on line
655/657 (these could really be back to back without the TDAR write
between them).  At this point new descriptors have been written to the
tx ring and the PREWRITE makes the changes visible to the hardware, the
write into the TDAR register informs the hardware that descriptors were
changed and it should rescan the list.  The POSTWRITE is a no-op but
included for technical correctness.

Another desc-ring related set of sync ops is on lines 683-684.  In this
case the hardware has updated some of the descriptors and the
PREREAD/POSTREAD sync ops ensure that the cpu will see the changes.  The
same is true on lines 850-851.  This is the place where having two calls
is really a performance hit, because both PRE and POSTREAD sync will do
an invalidate, and it really only needs to be done once, but the busdma
conventions are that PRE and POST ops need to come in properly-sequenced
pairs.

And finally on 899-900 is the rx code similar to the tx code on 655/657,
where the driver has updated descriptors in the ring and done a PREWRITE
to make the changes visible to the hardware.

 The buffer that Mr. Kott hit a crash on should also be allocated 
 coherently. Looking at the ARM busdma code in -current I see a possible bug:
 
  int
  _bus_dmamap_load_buffer(bus_dma_tag_t dmat, bus_dmamap_t map, void *buf,
  bus_size_t buflen, struct pmap *pmap, int flags, bus_dma_segment_t 
  *segs,
  int *segp)
  {
  bus_size_t sgsize;
  bus_addr_t curaddr;
  struct sync_list *sl;
  vm_offset_t vaddr = (vm_offset_t)buf;
  int error = 0;
 
  if (segs == NULL)
  segs = dmat-segments;
  if ((flags  BUS_DMA_LOAD_MBUF) != 0)
  map-flags |= DMAMAP_CACHE_ALIGNED;
 
  if ((dmat-flags  BUS_DMA_COULD_BOUNCE) != 0) {
  _bus_dmamap_count_pages(dmat, map, pmap, buf, buflen, 
  flags);
  if (map-pagesneeded != 0) {
  error = _bus_dmamap_reserve_pages(dmat, map, flags);
  if (error)
  return (error);
  }
  }
  CTR3(KTR_BUSDMA, lowaddr= %d boundary= %d, 
  alignment= %d, dmat-lowaddr, dmat-boundary, 
  dmat-alignment);
 
  while (buflen  0) {
  /*
   * Get the physical address for this segment.
   */
  if (__predict_true(pmap == kernel_pmap)) {
  curaddr = pmap_kextract(vaddr);
  } else

Re: usb_pc_cpu_flush

[Ian Lepore]

On Tue, 2015-01-13 at 16:27 +0100, Hans Petter Selasky wrote:
 On 01/13/15 15:49, Ian Lepore wrote:
  On Tue, 2015-01-13 at 00:14 -0700, kott wrote:
  Yes with cache disabled, this problem is not seen. Seems to be with a issue
  with l2 cache.
  Thanks kott
 
  Except that there are no known problems with l2 cache on armv7 right
  now.  There are known problems with the USB driver using the busdma
  routines incorrectly, which accidentally works okay on x86 platforms but
  likely not so well on others.
 
 
 Hi,
 
 If there is a problem it is in usb_pc_cpu_flush() or 
 usb_pc_cpu_invalidate():
 
 void
 usb_pc_cpu_flush(struct usb_page_cache *pc)
 {
  if (pc-page_offset_end == pc-page_offset_buf) {
  /* nothing has been loaded into this page cache! */
  return;
  }
  bus_dmamap_sync(pc-tag, pc-map, BUS_DMASYNC_PREWRITE);
 }
 
 USB has a very simple DMA sync language, either flush or invalidate. 
 These are used correctly from what I can see with regard to the FreeBSD 
 USB specification.
 
 If the usb_pc_cpu_flush() function does not cause the CPU cache to be 
 written to RAM before the function returns, please let me know.
 
 --HPS

You have an incomplete concept of how busdma sync operations work.  It
isn't a simple cpu cache written to ram operation, there are bounce
buffers and other complexities involved that require that the sync
operations be done at the correct time in the correct order, and the
current usb driver doesn't do that.  Instead it does things like 

bus_dmamap_sync(pc-tag, pc-map, BUS_DMASYNC_POSTREAD);
bus_dmamap_sync(pc-tag, pc-map, BUS_DMASYNC_PREREAD);

And that's just nonsense that will lead to problems like delivering
random buffer garbage to/from a device.

To the degree that USB works at all on non-x86 platforms it works by
accident.  Usually.  Except when it doesn't.

-- Ian


___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org

Re: usb_pc_cpu_flush

[Ian Lepore]

On Tue, 2015-01-13 at 16:57 +0100, Hans Petter Selasky wrote:
 On 01/13/15 16:40, Ian Lepore wrote:
  On Tue, 2015-01-13 at 16:27 +0100, Hans Petter Selasky wrote:
  On 01/13/15 15:49, Ian Lepore wrote:
  On Tue, 2015-01-13 at 00:14 -0700, kott wrote:
  Yes with cache disabled, this problem is not seen. Seems to be with a 
  issue
  with l2 cache.
  Thanks kott
 
  Except that there are no known problems with l2 cache on armv7 right
  now.  There are known problems with the USB driver using the busdma
  routines incorrectly, which accidentally works okay on x86 platforms but
  likely not so well on others.
 
 
  Hi,
 
  If there is a problem it is in usb_pc_cpu_flush() or
  usb_pc_cpu_invalidate():
 
  void
  usb_pc_cpu_flush(struct usb_page_cache *pc)
  {
if (pc-page_offset_end == pc-page_offset_buf) {
/* nothing has been loaded into this page cache! */
return;
}
bus_dmamap_sync(pc-tag, pc-map, BUS_DMASYNC_PREWRITE);
  }
 
  USB has a very simple DMA sync language, either flush or invalidate.
  These are used correctly from what I can see with regard to the FreeBSD
  USB specification.
 
  If the usb_pc_cpu_flush() function does not cause the CPU cache to be
  written to RAM before the function returns, please let me know.
 
  --HPS
 
  You have an incomplete concept of how busdma sync operations work.  It
  isn't a simple cpu cache written to ram operation, there are bounce
  buffers and other complexities involved that require that the sync
  operations be done at the correct time in the correct order, and the
  current usb driver doesn't do that.  Instead it does things like
 
  bus_dmamap_sync(pc-tag, pc-map, BUS_DMASYNC_POSTREAD);
  bus_dmamap_sync(pc-tag, pc-map, BUS_DMASYNC_PREREAD);
 
  And that's just nonsense that will lead to problems like delivering
  random buffer garbage to/from a device.
 
  To the degree that USB works at all on non-x86 platforms it works by
  accident.  Usually.  Except when it doesn't.
 
  -- Ian
 
 
 Hi,
 
 Bounce buffers are perfectly fine with USB as long as the busdma does 
 what it is told. If there is no easy way to do a simple cache flush or 
 cache invalide or bounce buffer flush or bounce buffer invalidate 
 multiple times in a row, then busdma cannot co-exist with USB. It is not 
 because I'm stubborn, but because of the way USB DMA controllers are 
 designed.
 
 With USB chipsets we sometimes need to read the RAM area for a single 
 buffer multiple times to poll for updates. From what I've been told in 
 the past BUSDMA does.
 
 --HPS
 
 --HPS
 
 --HPS
 

And so we reach the same old impasse, where you declare that USB is
special and doesn't have to behave like other drivers, even though it is
in no way unique in terms of having things like concurrent shared access
to descriptor memory, something that virtually every modern NIC has.

-- Ian


___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org

Re: usb_pc_cpu_flush

[Ian Lepore]

On Tue, 2015-01-13 at 17:52 +0100, Hans Petter Selasky wrote:
 On 01/13/15 17:29, Ian Lepore wrote:
  On Tue, 2015-01-13 at 16:57 +0100, Hans Petter Selasky wrote:
  On 01/13/15 16:40, Ian Lepore wrote:
  On Tue, 2015-01-13 at 16:27 +0100, Hans Petter Selasky wrote:
  On 01/13/15 15:49, Ian Lepore wrote:
  On Tue, 2015-01-13 at 00:14 -0700, kott wrote:
  Yes with cache disabled, this problem is not seen. Seems to be with a 
  issue
  with l2 cache.
  Thanks kott
 
  Except that there are no known problems with l2 cache on armv7 right
  now.  There are known problems with the USB driver using the busdma
  routines incorrectly, which accidentally works okay on x86 platforms but
  likely not so well on others.
 
 
  Hi,
 
  If there is a problem it is in usb_pc_cpu_flush() or
  usb_pc_cpu_invalidate():
 
  void
  usb_pc_cpu_flush(struct usb_page_cache *pc)
  {
 if (pc-page_offset_end == pc-page_offset_buf) {
 /* nothing has been loaded into this page cache! */
 return;
 }
 bus_dmamap_sync(pc-tag, pc-map, BUS_DMASYNC_PREWRITE);
  }
 
  USB has a very simple DMA sync language, either flush or invalidate.
  These are used correctly from what I can see with regard to the FreeBSD
  USB specification.
  (unless a simple restart somehow fixes the problem)
  If the usb_pc_cpu_flush() function does not cause the CPU cache to be
  written to RAM before the function returns, please let me know.
 
  --HPS
 
  You have an incomplete concept of how busdma sync operations work.  It
  isn't a simple cpu cache written to ram operation, there are bounce
  buffers and other complexities involved that require that the sync
  operations be done at the correct time in the correct order, and the
  current usb driver doesn't do that.  Instead it does things like
 
bus_dmamap_sync(pc-tag, pc-map, BUS_DMASYNC_POSTREAD);
bus_dmamap_sync(pc-tag, pc-map, BUS_DMASYNC_PREREAD);
 
  And that's just nonsense that will lead to problems like delivering
  random buffer garbage to/from a device.
 
  To the degree that USB works at all on non-x86 platforms it works by
  accident.  Usually.  Except when it doesn't.
 
  -- Ian
 
 
  Hi,
 
  Bounce buffers are perfectly fine with USB as long as the busdma does
  what it is told. If there is no easy way to do a simple cache flush or
  cache invalide or bounce buffer flush or bounce buffer invalidate
  multiple times in a row, then busdma cannot co-exist with USB. It is not
  because I'm stubborn, but because of the way USB DMA controllers are
  designed.
 
  With USB chipsets we sometimes need to read the RAM area for a single
  buffer multiple times to poll for updates. From what I've been told in
  the past BUSDMA does.
 
  --HPS
 
  --HPS
 
  --HPS
 
 
  And so we reach the same old impasse, where you declare that USB is
  special and doesn't have to behave like other drivers, even though it is
  in no way unique in terms of having things like concurrent shared access
  to descriptor memory, something that virtually every modern NIC has.
 
 
 Hi,
 
 Can you give an example of a NIC driver which you consider a good 
 example which use DMA both for data (not only mbufs) and the control 
 path and use busdma as you consider to be correct?
 
 --HPS

dev/ffec/if_ffec.c.  I'm not happy with the fact that it takes two calls
(a PRE and a POST) to accomplish a single action, but that's the right
way to do things in the current busdma world, PRE and POST operations
need to be paired.

I think we need new busdma support for shared concurrent access
descriptors, because it's a type of dma that just isn't supported well
by the existing API.  There should be a new flag for bus_dmamem_alloc()
that indicates the memory is going to be used for such shared access
(because some platforms may be able to provide memory that's mapped
optimally for such situations), and there should be new sync ops that
don't require a pair of calls to accomplish a single action.

All of this is in the context of shared descriptor memory.  Regular IO
buffers should just use the proper sequence of PRE and POST syncs (and
most especially should *never* do POSTREAD before PREREAD like the
current usb_pc_cpu_invalidate() does, because with bounce buffers that
will just not work right).

-- Ian

 

___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org

Re: How to access a FTDI usb device with a custom vendor and product id's

[Ian Lepore]

On Tue, 2015-11-10 at 17:40 +0100, Hans Petter Selasky wrote:
> On 11/10/15 17:28, Burton Sampley wrote:
> > SYSFS{idVendor}=="2100", SYSFS{idProduct}=="9e56",
> > RUN+="/sbin/modprobe -q
> > ftdi_sio vendor=0x2100 product=0x9e56"
> > 
> > How do I accomplish the same in FreeBSD?  When the cable is plugged
> > in, I
> > get the following in /var/log/messages:
> 
> Hi,
> 
> See examples here:
> 
> https://svnweb.freebsd.org/ports/head/multimedia/webcamd/files/webcam
> d.conf.in?view=markup
> 
> --HPS

But the info in those examples won't cause the uftdi driver to attach
to the device (as shown in the linux-based example), that can only
happen if the vid/pid are added to the table in the driver itself,
right?  I don't remember any mechanism in our usb world for forcing a
driver to attach to a device that isn't compiled into the driver's
usb_device_id array.

On the other hand, if the device is going to be accessed via libusb
and/or libftdi, I'm not sure the tty driver needs to attach to it at
all; don't those libraries work purely through the ugen device?

-- Ian

___
freebsd-usb@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Re: How to access a FTDI usb device with a custom vendor and product id's

[Ian Lepore]

On Wed, 2015-11-11 at 16:28 -0500, Burton Sampley wrote:
> I added a line to the table, but it seems to have failed since I used
> the
> VID# instead of the VID# name.  Where are the VID names mapped to the
> VID#'s?  Apparently, I know enough about coding to be dangerous. 
>  I'll do
> some more digging to try to fix my own error.
> 
> Here's a diff of the original source and my modified source:
> 
> [/usr/src/sys/dev/usb/serial]$ /usr/bin/diff ./uftdi.c ./uftdi.c.ORIG
> 914d913
> <   UFTDI_DEV(2100, 9e56, 0),
> [/usr/src/sys/dev/usb/serial]$
> 
> Here's the compile splattage:

The VID and PID names are in the file src/sys/dev/usb/usbdevs.

-- Ian
___
freebsd-usb@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Re: How to access a FTDI usb device with a custom vendor and product id's

[Ian Lepore]

On Wed, 2015-11-11 at 16:57 -0500, Burton Sampley wrote:
> Ian,
> 
> Thank you for your prompt reply.
> 
> Looking at the usbdevs file, I found 0x2100, but there is no entry
> for
> 0x9e56, which is my device.  So, I'm assuming that changing uftdi.c
> to the
> correct name for the VID will only solve part of my problem.  I will
> further assume that I need to find the correct/proper entry for
> usbdevs as
> well.  Is this a correct assumption?  If so, then how/where can I
> find the
> proper entry for usbdevs?
> 
> Here's the 2 closest entries:
> 
> /* RT system products */
> product RTSYSTEMS CT29B 0x9e54  FTDI compatible adapter
> product RTSYSTEMS SERIAL_VX70x9e52  FTDI compatible
> adapter
> 
> For me, what appears to be the last piece of the puzzle is to find
> the
> correct name to place in the 3rd field.  Based on the following:
> 
> $ /usr/local/bin/sudo /usr/sbin/usbconfig -d ugen2.3 dump_device_desc
> ugen2.3:  at usbus2, cfg=0 md=HOST
> spd=FULL
> (12Mbps) pwr=ON (90mA)
> 
>   bLength = 0x0012
>   bDescriptorType = 0x0001
>   bcdUSB = 0x0200
>   bDeviceClass = 0x  
>   bDeviceSubClass = 0x
>   bDeviceProtocol = 0x
>   bMaxPacketSize0 = 0x0008
>   idVendor = 0x2100
>   idProduct = 0x9e56
>   bcdDevice = 0x0600
>   iManufacturer = 0x0001  
>   iProduct = 0x0002  
>   iSerialNumber = 0x0003  
>   bNumConfigurations = 0x0001
> 
> $
> 
> does "CT-62B" look reasonable?
> 

Yep, you'll have to add a new entry to usbdevs for the the 0x9e56
device.  CT62B seems like a good name (can't put the dash in the name
for C syntax reasons).

-- Ian

> 
> Regards,
> 
> -Burton
> 
> On Wed, Nov 11, 2015 at 4:38 PM, Ian Lepore <i...@freebsd.org> wrote:
> 
> > On Wed, 2015-11-11 at 16:28 -0500, Burton Sampley wrote:
> > > I added a line to the table, but it seems to have failed since I
> > > used
> > > the
> > > VID# instead of the VID# name.  Where are the VID names mapped to
> > > the
> > > VID#'s?  Apparently, I know enough about coding to be dangerous.
> > >  I'll do
> > > some more digging to try to fix my own error.
> > > 
> > > Here's a diff of the original source and my modified source:
> > > 
> > > [/usr/src/sys/dev/usb/serial]$ /usr/bin/diff ./uftdi.c
> > > ./uftdi.c.ORIG
> > > 914d913
> > > <   UFTDI_DEV(2100, 9e56, 0),
> > > [/usr/src/sys/dev/usb/serial]$
> > > 
> > > Here's the compile splattage:
> > 
> > The VID and PID names are in the file src/sys/dev/usb/usbdevs.
> > 
> > -- Ian
> > 
> 
> 
> 
___
freebsd-usb@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Re: Digi Watchport/T temperature sensor as /dev/ttyU

[Ian Lepore]

On Fri, 2016-07-22 at 18:35 +0200, O. Hartmann wrote:
> For temperature monitoring, we have a bunch of Digi Watchport/T
> sensors: 
> 
> http://ftp1.digi.com/support/documentation/9406_H.pdf
> 
> 
[...]

I think the attached patch will make it show up as a ttyU*/cuaU* device
for you.  (You should probably use the /dev/cuaU* flavor, to avoid
problems with tty layer and modem control signals).

I keep wishing we had a mechanism, like a sysctl that could be set or
something, that would let you supply a vendor/product pair and have the
ugensa driver attach to that device, for quick testing of this sort of
thing.

-- Ian
Index: sys/dev/usb/serial/ugensa.c
===
--- sys/dev/usb/serial/ugensa.c	(revision 302505)
+++ sys/dev/usb/serial/ugensa.c	(working copy)
@@ -158,6 +158,7 @@ static const STRUCT_USB_HOST_ID ugensa_devs[] = {
 	{USB_VPI(USB_VENDOR_KYOCERA2, USB_PRODUCT_KYOCERA2_CDMA_MSM_K, 0)},
 	{USB_VPI(USB_VENDOR_HP, USB_PRODUCT_HP_49GPLUS, 0)},
 	{USB_VPI(USB_VENDOR_NOVATEL2, USB_PRODUCT_NOVATEL2_FLEXPACKGPS, 0)},
+	{USB_VPI(USB_VENDOR_INSIDEOUT, USB_PRODUCT_INSIDEOUT_WATCHPORTT, 0)},
 };
 
 DRIVER_MODULE(ugensa, uhub, ugensa_driver, ugensa_devclass, NULL, 0);
Index: sys/dev/usb/usbdevs
===
--- sys/dev/usb/usbdevs	(revision 302505)
+++ sys/dev/usb/usbdevs	(working copy)
@@ -2456,6 +2456,7 @@ product INITIO INIC_1610P	0x1e40	USB to SATA Bridg
 
 /* Inside Out Networks products */
 product INSIDEOUT EDGEPORT4	0x0001	EdgePort/4 serial ports
+product INSIDEOUT WATCHPORTT	0x0304	WatchPort/T 
 
 /* In-System products */
 product INSYSTEM F5U002		0x0002	Parallel printer
___
freebsd-usb@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Re: Digi Watchport/T temperature sensor as /dev/ttyU

[Ian Lepore]

On Sat, 2016-07-23 at 22:04 +0200, O. Hartmann wrote:
> Am Fri, 22 Jul 2016 10:52:54 -0600
> Ian Lepore <i...@freebsd.org> schrieb:
> 
> > On Fri, 2016-07-22 at 18:35 +0200, O. Hartmann wrote:
> > > For temperature monitoring, we have a bunch of Digi Watchport/T
> > > sensors: 
> > > 
> > > http://ftp1.digi.com/support/documentation/9406_H.pdf
> > > 
> > >   
> > [...]
> > 
> > I think the attached patch will make it show up as a ttyU*/cuaU*
> > device
> > for you.  (You should probably use the /dev/cuaU* flavor, to avoid
> > problems with tty layer and modem control signals).
> > 
> > I keep wishing we had a mechanism, like a sysctl that could be set
> > or
> > something, that would let you supply a vendor/product pair and have
> > the
> > ugensa driver attach to that device, for quick testing of this sort
> > of
> > thing.
> > 
> > -- Ian
> 
> No, it doesn't change anything. I applied the patch to most recent
> CURRENT and it is
> still the same. But thanks anyway.
> 
> Kind regards,
> 
> oh

Oh, my bad, I forgot to mention:  You'll have to manually "kldload
ugensa" before plugging in the device (or load it from your
loader.conf).

When the change gets committed (assuming it works), the devd usb
scripts will get regenerated, and that's what handles the auto-load of
the driver.

-- Ian

___
freebsd-usb@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Re: Digi Watchport/T temperature sensor as /dev/ttyU

[Ian Lepore]

On Sun, 2016-07-24 at 10:51 +0200, O. Hartmann wrote:
> Am Sun, 24 Jul 2016 08:38:59 +0200
> Gary Jennejohn <gljennj...@gmail.com> schrieb:
> 
> > On Sun, 24 Jul 2016 08:03:30 +0200
> > "O. Hartmann" <ohart...@zedat.fu-berlin.de> wrote:
> > 
> > > Am Sat, 23 Jul 2016 14:49:11 -0600
> > > Ian Lepore <i...@freebsd.org> schrieb:
> > >   
> > > > On Sat, 2016-07-23 at 22:04 +0200, O. Hartmann wrote:
> > > > > Am Fri, 22 Jul 2016 10:52:54 -0600
> > > > > Ian Lepore <i...@freebsd.org> schrieb:
> > > > >   
> > > > > > On Fri, 2016-07-22 at 18:35 +0200, O. Hartmann wrote:  
> > > > > > > For temperature monitoring, we have a bunch of Digi
> > > > > > > Watchport/T
> > > > > > > sensors: 
> > > > > > > 
> > > > > > > http://ftp1.digi.com/support/documentation/9406_H.pdf
> > > > > > > 
> > > > > > > 
> > > > > > [...]
> > > > > > 
> > > > > > I think the attached patch will make it show up as a
> > > > > > ttyU*/cuaU*
> > > > > > device
> > > > > > for you.  (You should probably use the /dev/cuaU* flavor,
> > > > > > to avoid
> > > > > > problems with tty layer and modem control signals).
> > > > > > 
> > > > > > I keep wishing we had a mechanism, like a sysctl that could
> > > > > > be set
> > > > > > or
> > > > > > something, that would let you supply a vendor/product pair
> > > > > > and have
> > > > > > the
> > > > > > ugensa driver attach to that device, for quick testing of
> > > > > > this sort
> > > > > > of
> > > > > > thing.
> > > > > > 
> > > > > > -- Ian  
> > > > > 
> > > > > No, it doesn't change anything. I applied the patch to most
> > > > > recent
> > > > > CURRENT and it is
> > > > > still the same. But thanks anyway.
> > > > > 
> > > > > Kind regards,
> > > > > 
> > > > > oh  
> > > > 
> > > > Oh, my bad, I forgot to mention:  You'll have to manually
> > > > "kldload
> > > > ugensa" before plugging in the device (or load it from your
> > > > loader.conf).
> > > > 
> > > > When the change gets committed (assuming it works), the devd
> > > > usb
> > > > scripts will get regenerated, and that's what handles the auto
> > > > -load of
> > > > the driver.
> > > > 
> > > > -- Ian
> > > man ugensa doesn't exist! As I wrote earlier, I tried everything
> > > to load what I could
> > > find. It seems, the patch and the hint about ugensa.ko did the
> > > magic ;-) Thank you
> > > very much! Could the patch be made permanent to FreeBSD CURRENT?
> > > 
> > > And also important: where is the man page for ugensa? Can the the
> > > module be compiled
> > > staitcally into the kernel or are there pitfalls?
> > >   
> > 
> > Even the most complete man page found in the internet, the one from
> > Dragonfly, doesn't list your Digi International device as being one
> > of those supported.
> 
> Yes. That is a pity. But Linux seems to operate this serial device. I
> have to check next
> time I get hands on a Linux box, what driver is attached to the
> sensor.
> 
> > 
> > Still, having the man page under FreeBSD would at least provide a
> > hint
> > that the driver even exists.
> 
> Agreed.
> 
> > 
> > I added device ugensa to my config file and the kernel was
> > generated
> > without an error.
> 
> Me, too.
> 
> > 
> > > root@localhost: [src] kldload ugensa
> > > 
> > > ugen2.7:  at usbus2
> > > ugensa0: 
> > > on usbus2
> > > ugensa0: Found 1 interfaces.
> > > root@thor: [src] man ugensa
> > > No manual entry for ugensa
> > > root@localhost: [src] ll /dev/cuaU0*
> > > 203 crw-rw  1 uucp  dialer  -  0xcb Jul 24 07:51 /dev/cuaU0
> > > 204 crw-rw  1 uucp  dialer  -  0xcc Jul 24 07:51
> > > /dev/cuaU0.init
> > > 205 crw-rw  1 uucp  dialer  -  0xcd Jul 24 07:51
> > > /dev/cuaU0.lo

Re: Digi Watchport/T temperature sensor as /dev/ttyU

[Ian Lepore]

On Sun, 2016-07-24 at 12:52 -0600, Warner Losh wrote:
> On Sun, Jul 24, 2016 at 12:42 PM, Kevin Oberman 
> wrote:
> > There are several different USB serial drivers. Off-hand I see
> > ubser, ubsa,
> > uchcom, ucom, ucycom, uftdi, ubgensa, umcs, umct, umoscom, uplcom,
> > usb_serial, uslcom, and uvscom. Whether any of these will support
> > the TI
> > chip, I can't say. Most have man pages, but a few, as has been
> > noted, are
> > lacking one.
> 
> I tried to automate discovery of these things. However, the only way
> you can really know for sure about the TI chip is to read it's
> datasheet
> and compare that with extant drivers. It's actually easier than it
> sounds.
> 
> I've often thought of unification of the TTY USB drivers, since they
> are
> most (but not all) based on the standard plus extra bits.
> 
> Warner

To reiterate:  we do not have a driver for TI 5052 chips.

It's not much like other usb-serial chips.  In fact it's not strictly a
usb-serial chip, it's a multifunction chip that includes a software
-controllable usb hub, 2 serial ports, gpio, an i2c bus master, an MCU
interface, a multichannel DMA controller, and apparently even has the
ability to download your own 8052-compatible microcontroller code into
the 5052 and have it take over from the built-in rom code.

It would be reasonable enough to write a driver that initially
supported only the uart part of the chip.

-- Ian

___
freebsd-usb@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Re: USB/U3G: Added support for Panasonic CF-F9 GOBI 3G modem to U3G module

[Ian Lepore]

On Wed, 2017-09-27 at 00:30 +0200, Hans Petter Selasky wrote:
> On 09/27/17 00:11, Tomasz CEDRO wrote:
> > 
> > https://github.com/freebsd/freebsd/pull/115
> > 
> > :-)
> > 
> The devd.conf rule should match more than just vendor and product:
> 
> 
> +# Load GOBI 2000/3000 U3G QDL modem firmware on attach / boot.
> +# Note: This requires additional "gobi_loader" utility to be
> installed,
> +#   as well as valid QDL driver firmware files placed in 
> /boot/firmware/gobi.
> +#   If modem does not accept valid firmware try gobi_loader -2000
> switch.
> +#   Please adjust modem VID/PID to match your device supported by
> u3g 
> module.
> +#attach 100 {
> +#match "vendor" "0x04da";
> +#match "product" "0x250e";
> +#action "/usr/local/sbin/gobi_loader /dev/cuaU0
> /boot/firmware/gobi/";
> +#};
> 
> Else patch looks good.
> 
> --HPS

Hard-coding /dev/cuaU0 cannot possibly be right.

-- Ian
___
freebsd-usb@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Re: USB/U3G: Added support for Panasonic CF-F9 GOBI 3G modem to U3G module

[Ian Lepore]

On Sun, 2017-10-01 at 20:17 +0200, Tomasz CEDRO wrote:
> On Sun, Oct 1, 2017 at 7:21 PM, Hans Petter Selasky <h...@selasky.org>
> wrote:
> > 
> > On 10/01/17 19:09, Tomasz CEDRO wrote:
> > > 
> > > 
> > > On Sun, Oct 1, 2017 at 6:40 PM, Ian Lepore <i...@freebsd.org>
> > > wrote:
> > > > 
> > > > 
> > > > On Sun, 2017-10-01 at 18:33 +0200, Tomasz CEDRO wrote:
> > > > > 
> > > > > 
> > > > > On Wed, Sep 27, 2017 at 8:32 AM, Hans Petter Selasky <hps@sel
> > > > > asky.org
> > > > > > 
> > > > > > 
> > > > > > wrote:
> > > > > > 
> > > > > > On 09/27/17 00:37, Ian Lepore wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > On Wed, 2017-09-27 at 00:30 +0200, Hans Petter Selasky
> > > > > > > wrote:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > On 09/27/17 00:11, Tomasz CEDRO wrote:
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > https://github.com/freebsd/freebsd/pull/115
> > > > > > > > > 
> > > > > > > > > :-)
> > > > > > > > > 
> > > > > > > > The devd.conf rule should match more than just vendor
> > > > > > > > and
> > > > > > > > product:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > +# Load GOBI 2000/3000 U3G QDL modem firmware on attach
> > > > > > > > / boot.
> > > > > > > > +# Note: This requires additional "gobi_loader" utility
> > > > > > > > to be
> > > > > > > > installed,
> > > > > > > > +#   as well as valid QDL driver firmware files placed
> > > > > > > > in
> > > > > > > > /boot/firmware/gobi.
> > > > > > > > +#   If modem does not accept valid firmware try
> > > > > > > > gobi_loader
> > > > > > > > -2000
> > > > > > > > switch.
> > > > > > > > +#   Please adjust modem VID/PID to match your device
> > > > > > > > supported
> > > > > > > > by
> > > > > > > > u3g
> > > > > > > > module.
> > > > > > > > +#attach 100 {
> > > > > > > > +#  match "vendor" "0x04da";
> > > > > > > > +#  match "product" "0x250e";
> > > > > > > > +#  action "/usr/local/sbin/gobi_loader /dev/cuaU0
> > > > > > > > /boot/firmware/gobi/";
> > > > > > > > +#};
> > > > > > > > 
> > > > > > > > Else patch looks good.
> > > > > > > > 
> > > > > > > > --HPS
> > > > > > > 
> > > > > > > Hard-coding /dev/cuaU0 cannot possibly be right.
> > > > > > > 
> > > > > > > -- Ian
> > > > > > > 
> > > > > > These three lines are missing:
> > > > > > 
> > > > > >  match "system"  "DEVFS";
> > > > > >  match "subsystem"   "CDEV";
> > > > > >  match "type""CREATE";
> > > > > > 
> > > > > > 
> > > > > > --HPS
> > > > > Thanks! Updated! :-)
> > > > > 
> > > > > https://github.com/freebsd/freebsd/pull/115
> > > > > 
> > > > If this is to be an example, it should be correct.  Please
> > > > replace the
> > > > "cuaU0" with "$cdev".  (See /etc/devd/uath.conf for an
> > > > example).
> > > > 
> > > > -- Ian
> > > 
> > > Thanks Ian! Is it okay now? I have moved this example to
> > > dedicated
> > > /etc/devd/u3g.conf file, and added u3g load to
> > > /etc/devd/usb.conf.. if
> > > syntax is okay I will verify on my laptop..
> > > 
> > > https://github.com/freebsd/freebsd/pull/115
> > > 
> > Looks good to me. Don't forget to MFC!
> > 
> > --HPS
> /etc/devd/u3g.conf:
> 
> notify 100 {
>  match "system" "USB";
>  match "subsystem" "DEVICE";
>  match "type" "ATTACH";
>  match "vendor" "0x04da";
>  match "product" "0x250e";
>  action "/usr/local/bin/gobi_loader /dev/$cdev /boot/firmware/gobi/";
> };
> 
> This does not work when /dev/$cdev is used.. but it works when
> /dev/cuaU0 is used. Ian, could you please advise? :-)
> 

Hmmm, then I'd have to surmise that everything in /etc/devd/uath.conf
will fail the same way.

I noticed earlier the events mentioned were

         match "system"  "DEVFS";
         match "subsystem"   "CDEV";
         match "type""CREATE";

and I would expect $cdev to have the right value on a CDEV/CREATE
event, but not necessarily on a DEVICE/ATTACH event.

-- Ian
___
freebsd-usb@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Re: USB/U3G: Added support for Panasonic CF-F9 GOBI 3G modem to U3G module

[Ian Lepore]

On Sun, 2017-10-01 at 18:33 +0200, Tomasz CEDRO wrote:
> On Wed, Sep 27, 2017 at 8:32 AM, Hans Petter Selasky <h...@selasky.org
> > wrote:
> > 
> > On 09/27/17 00:37, Ian Lepore wrote:
> > > 
> > > 
> > > On Wed, 2017-09-27 at 00:30 +0200, Hans Petter Selasky wrote:
> > > > 
> > > > 
> > > > On 09/27/17 00:11, Tomasz CEDRO wrote:
> > > > > 
> > > > > 
> > > > > 
> > > > > https://github.com/freebsd/freebsd/pull/115
> > > > > 
> > > > > :-)
> > > > > 
> > > > The devd.conf rule should match more than just vendor and
> > > > product:
> > > > 
> > > > 
> > > > +# Load GOBI 2000/3000 U3G QDL modem firmware on attach / boot.
> > > > +# Note: This requires additional "gobi_loader" utility to be
> > > > installed,
> > > > +#   as well as valid QDL driver firmware files placed in
> > > > /boot/firmware/gobi.
> > > > +#   If modem does not accept valid firmware try gobi_loader
> > > > -2000
> > > > switch.
> > > > +#   Please adjust modem VID/PID to match your device supported
> > > > by
> > > > u3g
> > > > module.
> > > > +#attach 100 {
> > > > +#  match "vendor" "0x04da";
> > > > +#  match "product" "0x250e";
> > > > +#  action "/usr/local/sbin/gobi_loader /dev/cuaU0
> > > > /boot/firmware/gobi/";
> > > > +#};
> > > > 
> > > > Else patch looks good.
> > > > 
> > > > --HPS
> > > 
> > > Hard-coding /dev/cuaU0 cannot possibly be right.
> > > 
> > > -- Ian
> > > 
> > These three lines are missing:
> > 
> > match "system"  "DEVFS";
> > match "subsystem"   "CDEV";
> > match "type""CREATE";
> > 
> > 
> > --HPS
> Thanks! Updated! :-)
> 
> https://github.com/freebsd/freebsd/pull/115
> 

If this is to be an example, it should be correct.  Please replace the
"cuaU0" with "$cdev".  (See /etc/devd/uath.conf for an example).

-- Ian

___
freebsd-usb@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Re: USB/U3G: Added support for Panasonic CF-F9 GOBI 3G modem to U3G module

[Ian Lepore]

On Sun, 2017-10-01 at 20:59 +0200, Tomasz CEDRO wrote:
> On Sun, Oct 1, 2017 at 8:23 PM, Ian Lepore <i...@freebsd.org> wrote:
> > 
> > On Sun, 2017-10-01 at 20:17 +0200, Tomasz CEDRO wrote:
> > > 
> > > [...old stuff...]
> I have verified on uath device (more on that below) and it turns out
> $cdev works fine.. but it returns /dev/usb/X.Y.Z not the /dev/cuaU0
> which does not work with this "gobi_loader" utility which requires
> /dev/cuaU0 (CDC / serial port device)... any clues how to replace
> $cdev with cuaUX? :-)
> 
> Regarding the UATH, I have TP-LINK TL-WN822N Ver2.0 based on Atheros
> 9002[1] and it seems to work with modified /dev/devd/uath.conf but
> the
> uathload returns "Operation not permitted" when executed as root and
> during boot..
> 
> [1] https://wikidevi.com/wiki/TP-LINK_TL-WN822N_v2
> 

Hmmm.  I think we need to key off the tty 'attach' event instead of the
devfs 'create' event.  The tty attach for a usb device is the one event
that has all the info we need in one message.  This is assuming the
device name in dmesg on attach is u3g0 or u3g1 or whatever.

attach 100 {
device-name "(u3g)[0-9]+";
match "vendor"  "0x04da";
match "product" "0x250e";
action "/usr/local/bin/gobi_loader /dev/cua$ttyname 
/boot/firmware/gobi/";
};

The way I arrived at this conclusion was to first look in the devd
source to figure out/remind myself that devd creates variables from all
the tag=value tuples it finds in the events coming from the kernel.
 Then I connected to devd using netcat so I could watch the events as
they happen:

  nc -U /var/run/devd.pipe

then I plugged in a usb-serial adapter (I have no u3g stuff), which
creates a whole lot of events.  The last one was the tty attach:

+uplcom0 at bus=1 hubaddr=1 port=1 devaddr=2 interface=0 ugen=ugen1.2
vendor=0x067b product=0x2303 devclass=0x00 devsubclass=0x00
devproto=0x00 sernum="" release=0x0300 mode=host intclass=0xff
intsubclass=0x00 intprotocol=0x00 ttyname=U0 ttyports=1 on uhub1

The '+' means it's an attach, the "device-name" variable is set from
the space-delimited word after the +, and then vars are created from
all the tag=value tuples between 'at' and 'on'.  So that gives us the
info to match product and vendor, and ttyname is the suffix to append
to /dev/cua to make the cdev name.

-- Ian
___
freebsd-usb@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Re: USB/U3G: Added support for Panasonic CF-F9 GOBI 3G modem to U3G module

[Ian Lepore]

On Mon, 2017-10-02 at 00:05 +0200, Tomasz CEDRO wrote:
> On Sun, Oct 1, 2017 at 10:59 PM, Ian Lepore <i...@freebsd.org> wrote:
> > 
> > On Sun, 2017-10-01 at 22:20 +0200, Tomasz CEDRO wrote:
> > > 
> > > On Sun, Oct 1, 2017 at 9:38 PM, Ian Lepore <i...@freebsd.org>
> > > wrote:
> > > > 
> > > > 
> > > > On Sun, 2017-10-01 at 20:59 +0200, Tomasz CEDRO wrote:
> > > > > 
> > > > > 
> > > > > On Sun, Oct 1, 2017 at 8:23 PM, Ian Lepore <i...@freebsd.org>
> > > > > wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On Sun, 2017-10-01 at 20:17 +0200, Tomasz CEDRO wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > [...old stuff...]
> > > > > I have verified on uath device (more on that below) and it
> > > > > turns
> > > > > out
> > > > > $cdev works fine.. but it returns /dev/usb/X.Y.Z not the
> > > > > /dev/cuaU0
> > > > > which does not work with this "gobi_loader" utility which
> > > > > requires
> > > > > /dev/cuaU0 (CDC / serial port device)... any clues how to
> > > > > replace
> > > > > $cdev with cuaUX? :-)
> > > > > 
> > > > > Regarding the UATH, I have TP-LINK TL-WN822N Ver2.0 based on
> > > > > Atheros
> > > > > 9002[1] and it seems to work with modified
> > > > > /dev/devd/uath.conf
> > > > > but
> > > > > the
> > > > > uathload returns "Operation not permitted" when executed as
> > > > > root
> > > > > and
> > > > > during boot..
> > > > > 
> > > > > [1] https://wikidevi.com/wiki/TP-LINK_TL-WN822N_v2
> > > > > 
> > > > Hmmm.  I think we need to key off the tty 'attach' event
> > > > instead of
> > > > the
> > > > devfs 'create' event.  The tty attach for a usb device is the
> > > > one
> > > > event
> > > > that has all the info we need in one message.  This is assuming
> > > > the
> > > > device name in dmesg on attach is u3g0 or u3g1 or whatever.
> > > > 
> > > > attach 100 {
> > > > device-name "(u3g)[0-9]+";
> > > > match "vendor"  "0x04da";
> > > > match "product" "0x250e";
> > > > action "/usr/local/bin/gobi_loader /dev/cua$ttyname
> > > > /boot/firmware/gobi/";
> > > > };
> > > > 
> > > > The way I arrived at this conclusion was to first look in the
> > > > devd
> > > > source to figure out/remind myself that devd creates variables
> > > > from
> > > > all
> > > > the tag=value tuples it finds in the events coming from the
> > > > kernel.
> > > >  Then I connected to devd using netcat so I could watch the
> > > > events
> > > > as
> > > > they happen:
> > > > 
> > > >   nc -U /var/run/devd.pipe
> > > > 
> > > > then I plugged in a usb-serial adapter (I have no u3g stuff),
> > > > which
> > > > creates a whole lot of events.  The last one was the tty
> > > > attach:
> > > > 
> > > > +uplcom0 at bus=1 hubaddr=1 port=1 devaddr=2 interface=0
> > > > ugen=ugen1.2
> > > > vendor=0x067b product=0x2303 devclass=0x00 devsubclass=0x00
> > > > devproto=0x00 sernum="" release=0x0300 mode=host intclass=0xff
> > > > intsubclass=0x00 intprotocol=0x00 ttyname=U0 ttyports=1 on
> > > > uhub1
> > > > 
> > > > The '+' means it's an attach, the "device-name" variable is set
> > > > from
> > > > the space-delimited word after the +, and then vars are created
> > > > from
> > > > all the tag=value tuples between 'at' and 'on'.  So that gives
> > > > us
> > > > the
> > > > info to match product and vendor, and ttyname is the suffix to
> > > > append
> > > > to /dev/cua to make the cdev name.
> > > > 
> > > > -- Ian
> > > Awsome! That works!! Thank you Ian!! Thank you for pointing out
> > >

Re: USB/U3G: Added support for Panasonic CF-F9 GOBI 3G modem to U3G module

[Ian Lepore]

On Sun, 2017-10-01 at 22:20 +0200, Tomasz CEDRO wrote:
> On Sun, Oct 1, 2017 at 9:38 PM, Ian Lepore <i...@freebsd.org> wrote:
> > 
> > On Sun, 2017-10-01 at 20:59 +0200, Tomasz CEDRO wrote:
> > > 
> > > On Sun, Oct 1, 2017 at 8:23 PM, Ian Lepore <i...@freebsd.org>
> > > wrote:
> > > > 
> > > > 
> > > > On Sun, 2017-10-01 at 20:17 +0200, Tomasz CEDRO wrote:
> > > > > 
> > > > > 
> > > > > [...old stuff...]
> > > I have verified on uath device (more on that below) and it turns
> > > out
> > > $cdev works fine.. but it returns /dev/usb/X.Y.Z not the
> > > /dev/cuaU0
> > > which does not work with this "gobi_loader" utility which
> > > requires
> > > /dev/cuaU0 (CDC / serial port device)... any clues how to replace
> > > $cdev with cuaUX? :-)
> > > 
> > > Regarding the UATH, I have TP-LINK TL-WN822N Ver2.0 based on
> > > Atheros
> > > 9002[1] and it seems to work with modified /dev/devd/uath.conf
> > > but
> > > the
> > > uathload returns "Operation not permitted" when executed as root
> > > and
> > > during boot..
> > > 
> > > [1] https://wikidevi.com/wiki/TP-LINK_TL-WN822N_v2
> > > 
> > Hmmm.  I think we need to key off the tty 'attach' event instead of
> > the
> > devfs 'create' event.  The tty attach for a usb device is the one
> > event
> > that has all the info we need in one message.  This is assuming the
> > device name in dmesg on attach is u3g0 or u3g1 or whatever.
> > 
> > attach 100 {
> > device-name "(u3g)[0-9]+";
> > match "vendor"  "0x04da";
> > match "product" "0x250e";
> > action "/usr/local/bin/gobi_loader /dev/cua$ttyname
> > /boot/firmware/gobi/";
> > };
> > 
> > The way I arrived at this conclusion was to first look in the devd
> > source to figure out/remind myself that devd creates variables from
> > all
> > the tag=value tuples it finds in the events coming from the kernel.
> >  Then I connected to devd using netcat so I could watch the events
> > as
> > they happen:
> > 
> >   nc -U /var/run/devd.pipe
> > 
> > then I plugged in a usb-serial adapter (I have no u3g stuff), which
> > creates a whole lot of events.  The last one was the tty attach:
> > 
> > +uplcom0 at bus=1 hubaddr=1 port=1 devaddr=2 interface=0
> > ugen=ugen1.2
> > vendor=0x067b product=0x2303 devclass=0x00 devsubclass=0x00
> > devproto=0x00 sernum="" release=0x0300 mode=host intclass=0xff
> > intsubclass=0x00 intprotocol=0x00 ttyname=U0 ttyports=1 on uhub1
> > 
> > The '+' means it's an attach, the "device-name" variable is set
> > from
> > the space-delimited word after the +, and then vars are created
> > from
> > all the tag=value tuples between 'at' and 'on'.  So that gives us
> > the
> > info to match product and vendor, and ttyname is the suffix to
> > append
> > to /dev/cua to make the cdev name.
> > 
> > -- Ian
> Awsome! That works!! Thank you Ian!! Thank you for pointing out how
> that was achieved! :-)
> 
> Is there any way to echo something out to the console to notify user
> that firmware is being updated? This takes some time and it would be
> nice to see something happens in the background.. I cannot see
> anything with action "logging blah"; maybe no need for that?
> 

I think you can use logger(1) in the action, like:

  action "logger -p kern.crit Loading firmware to cua$ttyname ;
    /usr/local/bin/gobi_loader etc etc"

The 'kern.crit' should be a high enough priority to ensure it comes out
on the console, but it depends on syslog.conf of course.  If
gobi_loader outputs a nice message it could be piped to logger(1)
instead of putting the message in the command.

-- Ian

___
freebsd-usb@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Re: umodem0, Cisco USB serial console, and quirks

[Ian Lepore]

On Sun, 2018-11-04 at 19:05 -0500, Mike Andrews wrote:
> On Fri, 2 Nov 2018, CeDeROM wrote:
> 
> > 
> > Try to add VID/PID of your device into a usbmodem driver. Use
> > configurations to see which one works with your device. Rebuild the
> > module/kernel, reboot, try it out untill success.
> > 
> > After your device is recognised by usbmodem and creates several cuaU*
> > devices.. still Your device may require uploading a specific firmware
> > in order for gsm modem to work. You can find those in Windows driver
> > package.
> > 
> > Use MINICOM for cuaU communications that would save you a debug time.
> > 
> > That works for me - added 3 devices like that with no problem. In fact
> > they work better on FreeBSD than Windows ;-)
> > 
> > 
> > Alternartively, replace your modem with something that is known to
> > work - for instance QUECTEL EC25 LTE module works far better than my
> > previous stock 3G module here..
> I think we're losing the plot here a bit.
> 
> While this is generally useful advice, this thread was originally about 
> the USB serial console port of Cisco ASA firewalls.  It should just be a 
> plain ol' USB-to-serial setup.  No actual modems of any kind involved, 
> especially not cellular ones.
> 
> I suspect we shouldn't even be loading umodem at all -- just ucom.  But 
> for some reason, umodem gets loaded when I plug the thing in.  With just 
> an FTDI serial-to-usb adapter in there, umodem doesn't just, just ucom.
> 
> These firewalls (and I suspect all of Cisco's newer routers and switches) 
> have both normal serial and mini-USB-to-serial ports, and you can connect 
> a simple USB-to-serial converter (PL2303, FTDI, etc) into the normal port 
> and of course that works fine on FreeBSD.  But it would be nice to skip 
> needing the dongle...

I'm curious whether the cisco side is truly a generic usb serial and
the problem is that the umodem driver is trying to do modem-specific
things which the cisco side is getting confused by.

A way to test that theory would be to add the cisco's vid/pid to the
ugensa driver (sys/dev/usb/serial/ugsena.c). If that works, I'm not
sure it's so much a solution as a clue.

I've always wanted a way to add VID/PID combos to ugsensa's internal
list on the fly, like via hints or sysctl or something, to make this
kind of quick test easier. But I never find time to add the feature.

-- Ian
___
freebsd-usb@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Re: Questions about the USB HID device drivers

[Ian Lepore]

On Mon, 2019-02-18 at 15:03 -0600, Apollo D. Sharpe, Sr. via freebsd-
usb wrote:
> On 2/18/19 3:26 AM, Hans Petter Selasky wrote:
> > Each devicename has a uniq prefix followed by a uniq unit number.
> 
> So, we just end up dumping ALL device nodes in /dev...
> 
> 
> > Character device nodes are automatically created. However it is 
> > possible for user-space applications to create symbolic links 
> > afterwards in /dev .
> 
> ...and leave it to user-space to create the hierarchy within /dev?
> Is 
> there a technical reason that kernel drivers don't automatically 
> subscribe to a hierarchy, or is this just historic inertia? It seems 
> funny to me that such decisions are left to user-space applications.
> 
> 

Not to userland applications so much as to sysadmin-controlled
configuration which is applied from userland during system startup and when new 
devices are attached. See the manpage for devfs.conf.

>From the kernel side, some subsystems do create a hierarchy (or at
least a subdir for a set of related devices), and others don't. There
is no system-wide policy about it either way.

-- Ian

___
freebsd-usb@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Is it a good idea to use a usb-serial adapter for PPS input? Yes, it is.

[Ian Lepore]

Since we added support for accepting a PPS signal on a USB-serial
adapter a couple years ago, I've seen people express reluctance to use
it several times.  Usually they cite concerns about latency and
jitter.  I decided it was time to do some rigorous testing, and post
the results.  

Complete details on the test setup appear below.  The tl;dr summary is:

A single PPS source is fanned out to 4 different types of inputs on a
Wandboard system (armv7, imx6 SoC).  Ntpd is configured to steer only
to PPS(0), and the offset and jitter numbers for the other sources
allow comparing the various PPS processing paths.  After running about
12 hours, the results are: 

 remote  refid  st t when poll reach   delay   offset  jitter
=
oPPS(0)  .gpt.   0 l8   16  3770.0000.000   0.002
 PPS(1)  .gpio.  0 l7   16  3770.000   -0.002   0.002
 PPS(2)  .usb1.  0 l6   16  3770.000   -0.201   0.034
 PPS(3)  .usb2.  0 l5   16  3770.000   -0.215   0.026
*tflex.my.lan.GPS.   1 u   32   64  3770.5680.038   0.061

PPS(0) is fed to a hardware timer block within the imx6 SoC.  The PPS
pulse triggers hardware capture of the kernel clock, eliminating
latency and jitter due to interrupt processing.  

PPS(1) is fed to a generic gpio input pin on the SoC, handled by the
standard gpiopps driver processing a pin-change interrupt.  

PPS(2) is an FTDI 232R, a USB 1.1 serial adapter, connected to a port
on a USB 2.0 hub that's connected to a USB 2.0 host port on the
Wandboard.  

PPS(3) is an FTDI 4232H, a USB 2.0 serial adapter, connected to a port
on the same USB hub as PPS(2).  

Unfortunately, the uart driver for the imx6 SoC doesn't support the CTS
or CD signals, so I couldn't measure native uart performance
directly.  I would expect the performance to be comparable to the gpio
pin input.  

As shown above, there is a 2 microsecond latency and virtually no
jitter on the GPIO input.  The USB 1.1 and USB 2.0 adapters performed
essentially identically to each other, with about 200 microseconds of
latency and negligible jitter.  There was no difference in performance
between using the CTS versus the CD pins on the adapters for input.  

To see if lots of USB bus activity increased latency or noise, I
connected a USB SATA dock containing an SSD drive to the same USB hub
as the serial adapters, and ran a continuous dd(1) from the drive to
/dev/null.  Surprisingly, there was absolutely no difference in the
results during that run.  

Most people are not worried about their kernel clock being 200
microseconds off from UTC, even if they're using the PPS signal from a
GPS receiver.  So I think most people should feel completely at ease
using a USB serial adapter as the input device for a PPS signal.  


Test setup details...


PPS measurements are made using the kernel clock.  Typically the kernel
clock is sourced from a hardware clock which isn't particularly
accurate in terms of frequency.  All clocks drift; cheap crystals on
computer boards drift a lot.  Ntpd will align both the frequency and
phase of the kernel clock using a PPS signal, but to compare the
various processing paths a PPS signal can go through, you must be able
to determine how much error came from the reference path and how much
from the path being tested.  In an ideal world, there would be no
measurement jitter, or frequency drift in the kernel clock, and thus
all PPS measurements made would be directly comparable to each other
without having to ascribe any part of the differences between sources
to the kernel clock.  

I am able to configure a Wandboard imx6 system so that the frequency
and phase alignment of kernel time is "perfect" with respect to one of
the PPS inputs.  Since all the PPS inputs are sourced by fanning out
the same source PPS signal, any difference in the offset or jitter
reported by ntpd directly represents differences in the processing
paths taken by those signals.  

The test setup consists of a commercial precision timing system which
generates a 10 MHz clock signal from a GPS-disciplined rubidium
oscillator, and it generates a PPS pulse that is derived from that 10
MHz clock using a simple "divide by 10 million" counter.  So the
leading edge of the PPS pulse is phase-coherent with the leading edge
of one of the clock pulses.  

The 10 MHz clock signal is fed to an external clock input pin on the
imx6 SoC.  Within the imx6 timer block, that clock signal drives a 32-
bit counter register, and that counter is used to implement a kernel
timecounter.  The PPS signal is also fed into that imx6 timer block,
and the leading edge of the PPS pulse causes the hardware to latch the
current value of the 32-bit timecounter into a capture register.  This
captured value is then used to generate a PPS measurement that doesn't
incorporate any interrupt processing latency or jitter.  

Because the PPS pulse and the 

Re: Is it a good idea to use a usb-serial adapter for PPS input? Yes, it is.

[Ian Lepore]

On Mon, 2019-08-19 at 17:09 +0930, O'Connor, Daniel wrote:
> > On 12 Aug 2019, at 09:09, O'Connor, Daniel 
> > wrote:
> > > always get lost on single-core processors which are in cpu_idle()
> > > at
> > > the time the hardclock interrupt happens.  (But that's fixable by
> > > just
> > > increasing the number of timehands, I think at least 4 are
> > > required.)
> > 
> > OK, how do I increase the number of clock hands?
> 
> I am going to try this diff but buildkernel is going to take a
> while...
> 
> diff --git a/sys/kern/kern_tc.c b/sys/kern/kern_tc.c
> index 2656fb4d2..00440b6a2 100644
> --- a/sys/kern/kern_tc.c
> +++ b/sys/kern/kern_tc.c
> @@ -83,8 +83,48 @@ struct timehands {
>   struct timehands*th_next;
>  };
> 
> -static struct timehands th0;
> +static struct timehands th2;
>  static struct timehands th1 = {
> + .th_next = 
> +};
> +
> +static struct timehands th3;
> +static struct timehands th2 = {
> + .th_next = 
> +};
> +
> +static struct timehands th4;
> +static struct timehands th3 = {
> + .th_next = 
> +};
> +
> +static struct timehands th5;
> +static struct timehands th4 = {
> + .th_next = 
> +};
> +
> +static struct timehands th6;
> +static struct timehands th5 = {
> + .th_next = 
> +};
> +
> +static struct timehands th7;
> +static struct timehands th6 = {
> + .th_next = 
> +};
> +
> +static struct timehands th8;
> +static struct timehands th7 = {
> + .th_next = 
> +};
> +
> +static struct timehands th9;
> +static struct timehands th8 = {
> + .th_next = 
> +};
> +
> +static struct timehands th0;
> +static struct timehands th9 = {
>   .th_next = 
>  };
>  static struct timehands th0 = {
> 

Oh, I'm sorry, I forgot to respond about this.  Yeah, that patch would
do it.  I think a minimum of 4 sets of timehands are needed for pps
capture on a single-core system with a latching timecounter like
dmtpps.

-- Ian

___
freebsd-usb@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Re: Is it a good idea to use a usb-serial adapter for PPS input? Yes, it is.

[Ian Lepore]

On Mon, 2019-08-05 at 15:28 +0930, O'Connor, Daniel wrote:
> Hi Ian,
> 
> Firstly, this is a very cool test - thank you for running it :)
> 
> > On 3 Aug 2019, at 06:46, Ian Lepore  wrote:
> > PPS(2) is an FTDI 232R, a USB 1.1 serial adapter, connected to a port
> > on a USB 2.0 hub that's connected to a USB 2.0 host port on the
> > Wandboard.  
> > 
> > PPS(3) is an FTDI 4232H, a USB 2.0 serial adapter, connected to a port
> > on the same USB hub as PPS(2).  
> 
> 
> 
> > Most people are not worried about their kernel clock being 200
> > microseconds off from UTC, even if they're using the PPS signal from a
> > GPS receiver.  So I think most people should feel completely at ease
> > using a USB serial adapter as the input device for a PPS signal.  
> 
> Does the USB clock derive from the 10MHz Rb clock? If so that would mean you 
> would see a lot less jitter than a 'normal' user where the USB clock is not 
> locked too GPS.
> 

No, usb is derived from the same 24mhz crystal that clocks the cpus.  I
think usb and its need for clocks at 48 and 480mhz is why so many small
arm systems use a 24mhz main clock.

> Do you have a more detailed write up of things like the NTP configuration 
> file? I think I could replicate your test here although I have a Beaglebone 
> Black, not a Wanboard so I will need to check if it can take an external 
> clock. (We have GPS modules & Rb oscillators at work to create reference 
> clock for bi-static meteor applications).
> 

The same setup should be possible on a BBB.  There is a TCLKIN pin
mentioned in the manual.  Some searching on the web yields a few clues
that it might be possible to mux that to a pin on the P9 header [1]. 
There is already a dmtpps capture driver for TI, but I'm afraid it may
have bitrotted over the past couple years.  Also, even when it last
worked, it just barely worked, because the reduction of kernel
timecounters from 10 to 2 timehands causes the PPS capture to almost
always get lost on single-core processors which are in cpu_idle() at
the time the hardclock interrupt happens.  (But that's fixable by just
increasing the number of timehands, I think at least 4 are required.)

So all in all, it's doable, but it'll take a bit of work.  I can help
with the driver stuff.

The ntp config is pretty simple, it uses instances of the "atom" clock,
which is a bare-PPS refclock which needs to be paired with any network
peer to operate.  The network peer is used to obtain the initial time
of day, then the PPS signal is used to steer phase.  The network peer
must be marked 'prefer' for some reason, it's just an ntp rule.  In my
test setup I forced ntp to steer to the "perfect" pps signal by marking
all the others as "noselect", otherwise any of the atom clocks would be
eligible to be the system peer.

server iburst prefer

server 127.127.22.0  minpoll 4 maxpoll 4
fudge  127.127.22.0 stratum 0 refid gpt

server 127.127.22.1  minpoll 4 maxpoll 4 noselect
fudge  127.127.22.1 stratum 0 refid gpio

server 127.127.22.2  minpoll 4 maxpoll 4 noselect
fudge  127.127.22.2 stratum 0 refid usb1

server 127.127.22.3  minpoll 4 maxpoll 4 noselect
fudge  127.127.22.3 stratum 0 refid usb2


[1] 
http://e2e.ti.com/support/processors/f/791/t/406121?AM335x-TCLKIN-on-Linux-3-19

-- Ian

___
freebsd-usb@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Re: Understanding how USB transmission works

[Ian Lepore]

On Mon, 2020-03-02 at 16:19 -0500, Farhan Khan wrote:
> Hi all,
> 
> I am trying to understand how FreeBSD's usb transfers work compared
> to OpenBSD by using the rum(4) driver. I am a little confused how the
> FreeBSD side works.
> 
> On the OpenBSD side, it seems that after allocating the pipes, you
> use usbd_setup_xfer and usbd_transfer(). As an example, look at
> OpenBSD's /usr/src/sys/dev/usb/if_rum.c, starting on line 2027-2029,
> I believe that corresponds to FreeBSD's
> /usr/src/sys/dev/usb/wlan/if_rum.c, line 2607 (rum_setup_tx_list)
> which goes to 807. In this function, I see that it adds rum_tx_data
> (tx_data[i] to the end of tx_free. However, how does it actually send
> the data? I believe this occurs in the callback functions,
> specifically with the usbd_transfer_submit function, but I am not
> certain how that is triggered, especially when it is triggered by the
> driver, such as in a send function.
> 
> Please assist.
> Thank you!
> 
> Links below to make it easy to follow:
> OpenBSD:
> https://github.com/openbsd/src/blob/2e342c845e9966c26657b08851237fc18e7b5ff5/sys/dev/usb/if_rum.c#L2024
> 
> FreeBSD:
> 1. 
> https://github.com/freebsd/freebsd/blob/499b2b565264824f2139ebcb5d1c97404a17e7e6/sys/dev/usb/wlan/if_rum.c#L2607
> 2. 
> https://github.com/freebsd/freebsd/blob/499b2b565264824f2139ebcb5d1c97404a17e7e6/sys/dev/usb/wlan/if_rum.c#L807
> 

I think you're probably looking for:

https://github.com/freebsd/freebsd/blob/499b2b565264824f2139ebcb5d1c97404a17e7e6/sys/dev/usb/wlan/if_rum.c#L1623

Note that I don't know anything about the if_rum driver in general, I
just know to look for occurrances of usbd_transfer_start().

-- Ian



___
freebsd-usb@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Re: USB-dongle modem keeps changing from cuaU0 to cuaU1 and bck

[Ian Lepore]

On Tue, 2020-09-01 at 16:23 +0200, Willem Jan Withagen wrote:
> On 1-9-2020 16:10, Hans Petter Selasky wrote:
> > On 2020-09-01 15:54, Willem Jan Withagen wrote:
> > > Could it be because the dongle itself crashes?
> > 
> > Yes, if they reboot or there are disturbances on the USB cables, then 
> > a new index number may be assigned during re-enumeration.
> 
> There is no hub or something in between, and it is directly connected.
> So I'm guessing that the modem resets/reboots.
> 
> Let's see if devd can help.
> 
> It does not happen very often, but now already twice on a day that it 
> should have worked.
> 8-(
> 
> --WjW
> 

A typical scenario when this problem happens is:
 
 - cuaU0 is opened by an app.
 - Something Happens(tm) to make the device disconnect from the bus,
   but cuaU0 is still open by the app so the devfs node remains.
 - The transient problems clears, the bus is re-enumerated, but since
   cuaU0 is still in use by the app, cuaU1 gets assigned.
 - Eventually the app tries to read from cuaU0 and gets an error
   return from the read and closes the device, freeing cuaU0 in devfs.

If you use devd rules to assign a particular alias based on the
device's serial number or bus:hub:port tuples, the same underlying
problem is going to be there:  the app may still have the old device
open and hasn't yet noticed that it has disappeared.  If the way the
alias is assigned is to create a symlink, and that's done using ln -fs
then it may work out.  But there may be some need to have the devd rule
signal or kill/restart your app that's doing the monitoring.

-- Ian

___
freebsd-usb@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Re: arduino usb/com port issue

[Ian Lepore]

On Sun, 2020-05-31 at 22:11 +0200, Tomasz CEDRO wrote:
> On Sun, May 31, 2020 at 7:54 PM Hans Petter Selasky wrote:
> > 
> > [...]
> 
> I use MINICOM as the Terminal emulator. Type Ctrl+A then Z for command
> menu. Note that you will have to create a configuration for a given
> port in the first place (as root type `minicom -s /dev/cuaU0` set
> valid port name and parameters then save as the default configuration
> for that port).
> 

You can use cu(1) from the base system for that.  To connect to the
first usb-serial at speed 115,200 use:

   cu -l cuaU0 -s 115200

To disconnect, use the key sequence  ~ ^D

> In general on FreeBSD COM port over USB (aka Virtual-COM-Port) is
> handled by `ucom` kernel module (type `kldstat` to list loaded kernel
> modules), also it may use `umodem` or even `u3g` module. Those modules
> are loaded by `devd` system daemon based on USB descriptors when you
> plug a device. I just found a bug in pyOCD (Python module for ARM CPU
> debug) that prevents running GDB Server when `ucom` module is loaded
> for the VCP port on that board. pyOCD tries to unload the kernel
> module by default to gain access to the VCP using LibUSB

There should be no need to unload ucom to access the low-level usb
device via libusb.  I typically have anywhere from 5-8 usb-serial
adapters connected at once, it would be crazy to unload ucom and lose
access to all of them just to use one of them with libusb.

It is important, however, to avoid accessing /dev/cuaU# or /dev/ttyU#
at the same time that some application is using libusb (or libftdi) to
access that same device.  That would cause ucom and the work being done
via libusb to conflict with each other.

-- Ian

___
freebsd-usb@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"