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

[O'Connor, Daniel]

> On 23 Jul 2016, at 02:05, O. Hartmann  wrote:
> 
> I tried to load any available USB serial port/adaptor driver available to 
> make this
> sensor attach as a ttyU? as it does in Linux (/dev/ttyUSB), but no luck so 
> far. I'm not
> familiar with serial consoles or the derial capabilities of FreeBSD, so i 
> might have
> overseen something essential. I'd like to access the sensor to retrieve 
> temperature data,
> even if it is in a crude way. Poking around with USB, I found that the sensor 
> device does
> release some informations, so hopefully there is a way to make it look like a 
> tty, see my
> attempts to get some informations out of the device below.

Do you know what driver picks it up in Linux?
It's pretty likely you just need to add an entry in one of the existing drivers 
to tell it about this device.

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
 -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

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

Re: Call for Testing: Switching back to our BSD licensed dtc(1)

[Warner Losh]

On Fri, Jul 22, 2016 at 1:03 AM, David Chisnall  wrote:
> On 22 Jul 2016, at 03:40, Warner Losh  wrote:
>>
>> On Wed, Jul 20, 2016 at 9:51 AM, David Chisnall  wrote:
>>> On 20 Jul 2016, at 16:46, Warner Losh  wrote:

 I've been trying to get the final spec for it. Right now it's a
 disorganized series
 of patches, some of which have been merge some that haven't. I'll send you 
 a
 copy when I can find something better than "here's the code."
>>>
>>> Thanks.  From the information I can find, it looks as if most of the 
>>> machinery required to implement it is already in dtc, so it should 
>>> (hopefully) just be a matter of adding a new keyword to detect plugins, a 
>>> scan to find the cross-references (or possibly reusing the existing one) 
>>> and then a little bit of extra logic.
>>
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/overlay-notes.txt
>> has the specs.
>
> Hmm, that’s even less complete than the docs that I’d found.

Can you share that then?

>From that, it seems as if the only thing that dtc needs to do is support the 
>/plugin/ syntax and emit a section describing unresolved references?

I believe so, yes.

>Or is dtc also expected to be able to do the merging?

I think that's TBD. We'll need, at the very least, an update libfdt
from upstream that knows how to do the merging, as well as changes to
/boot/loader to be able to pick and choose which plugins to add to the
base. If we can do all that with the BSDL DTC and it passes all the
other GPL test cases, then we may have a winner and we can get started
integrating plugin support to /boot/loader. I know my RPi would be
happier if it had a 'standard' DTB with a plugin for whatever 1-wire
stuff I'm playing with today.

Warner
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-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-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Digi Watchport/T temperature sensor as /dev/ttyU

[O. Hartmann]

For temperature monitoring, we have a bunch of Digi Watchport/T sensors: 

http://ftp1.digi.com/support/documentation/9406_H.pdf

They work well with CentOS 5/6 systems and there is also a Nagios plugin, 
written in
Perl, which makes those sensors usable with Nagios/Icinga/Icinga2: 
 
https://exchange.nagios.org/directory/Plugins/System-Metrics/Environmental/check_watchptTemp/details

When attached to FreeBSD 12-CURRENT, the sensor is seen as a generic USB 
device, for
instance

ugen2.7:  at usbus2, cfg=0 md=HOST spd=FULL 
(12Mbps)
pwr=ON (80mA)

I tried to load any available USB serial port/adaptor driver available to make 
this
sensor attach as a ttyU? as it does in Linux (/dev/ttyUSB), but no luck so far. 
I'm not
familiar with serial consoles or the derial capabilities of FreeBSD, so i might 
have
overseen something essential. I'd like to access the sensor to retrieve 
temperature data,
even if it is in a crude way. Poking around with USB, I found that the sensor 
device does
release some informations, so hopefully there is a way to make it look like a 
tty, see my
attempts to get some informations out of the device below.

If someone has some help, hints or advice, I'd appreciate an email (please CC 
me, I do
not subscribe the QUESTION list).

Thanks in advance,

Oliver


# usbconfig -u 2 -a 7 dump_device_desc
ugen2.7:  at usbus2, cfg=0 md=HOST spd=FULL 
(12Mbps)
pwr=ON (80mA)

  bLength = 0x0012 
  bDescriptorType = 0x0001 
  bcdUSB = 0x0110 
  bDeviceClass = 0x00ff  
  bDeviceSubClass = 0x 
  bDeviceProtocol = 0x00ff 
  bMaxPacketSize0 = 0x0008 
  idVendor = 0x1608 
  idProduct = 0x0304 
  bcdDevice = 0x0100 
  iManufacturer = 0x0001  
  iProduct = 0x0002  
  iSerialNumber = 0x0003  
  bNumConfigurations = 0x0001 


# usbconfig -u 2 -a 7 dump_all_config_desc
ugen2.7:  at usbus2, cfg=0 md=HOST spd=FULL 
(12Mbps)
pwr=ON (80mA)


 Configuration index 0

bLength = 0x0009 
bDescriptorType = 0x0002 
wTotalLength = 0x0027 
bNumInterfaces = 0x0001 
bConfigurationValue = 0x0001 
iConfiguration = 0x  
bmAttributes = 0x00a0 
bMaxPower = 0x0028 

Interface 0
  bLength = 0x0009 
  bDescriptorType = 0x0004 
  bInterfaceNumber = 0x 
  bAlternateSetting = 0x 
  bNumEndpoints = 0x0003 
  bInterfaceClass = 0x00ff  
  bInterfaceSubClass = 0x 
  bInterfaceProtocol = 0x00ff 
  iInterface = 0x  

 Endpoint 0
bLength = 0x0007 
bDescriptorType = 0x0005 
bEndpointAddress = 0x0081  
bmAttributes = 0x0002  
wMaxPacketSize = 0x0040 
bInterval = 0x 
bRefresh = 0x 
bSynchAddress = 0x 

 Endpoint 1
bLength = 0x0007 
bDescriptorType = 0x0005 
bEndpointAddress = 0x0001  
bmAttributes = 0x0002  
wMaxPacketSize = 0x0040 
bInterval = 0x 
bRefresh = 0x 
bSynchAddress = 0x 

 Endpoint 2
bLength = 0x0007 
bDescriptorType = 0x0005 
bEndpointAddress = 0x0087  
bmAttributes = 0x0003  
wMaxPacketSize = 0x0008 
bInterval = 0x0001 
bRefresh = 0x 
bSynchAddress = 0x 



pgpPEEqtm5ZKv.pgp
Description: OpenPGP digital signature

Build failed in Jenkins: FreeBSD_HEAD #487

[jenkins-admin]

See 

--
[...truncated 320374 lines...]
[192.168.10.2] out: lib/libarchive/functional_test:test_read_format_gtar_lzma  
->  passed  [0.105s]
[192.168.10.2] out: lib/libarchive/functional_test:test_read_format_gtar_sparse 
 ->  passed  [0.264s]
[192.168.10.2] out: 
lib/libarchive/functional_test:test_read_format_gtar_sparse_skip_entry  ->  
passed  [0.096s]
[192.168.10.2] out: lib/libarchive/functional_test:test_read_format_iso_Z  ->  
passed  [0.091s]
[192.168.10.2] out: 
lib/libarchive/functional_test:test_read_format_iso_multi_extent  ->  passed  
[0.092s]
[192.168.10.2] out: lib/libarchive/functional_test:test_read_format_iso_xorriso 
 ->  passed  [0.091s]
[192.168.10.2] out: 
lib/libarchive/functional_test:test_read_format_isojoliet_bz2  ->  passed  
[0.090s]
[192.168.10.2] out: 
lib/libarchive/functional_test:test_read_format_isojoliet_long  ->  passed  
[0.095s]
[192.168.10.2] out: 
lib/libarchive/functional_test:test_read_format_isojoliet_rr  ->  passed  
[0.092s]
[192.168.10.2] out: 
lib/libarchive/functional_test:test_read_format_isojoliet_versioned  ->  passed 
 [0.092s]
[192.168.10.2] out: lib/libarchive/functional_test:test_read_format_isorr_bz2  
->  passed  [0.093s]
[192.168.10.2] out: lib/libarchive/functional_test:test_read_format_isorr_ce  
->  passed  [0.088s]
[192.168.10.2] out: 
lib/libarchive/functional_test:test_read_format_isorr_new_bz2  ->  passed  
[0.091s]
[192.168.10.2] out: 
lib/libarchive/functional_test:test_read_format_isorr_rr_moved  ->  passed  
[0.152s]
[192.168.10.2] out: 
lib/libarchive/functional_test:test_read_format_isozisofs_bz2  ->  passed  
[0.093s]
[192.168.10.2] out: lib/libarchive/functional_test:test_read_format_lha  ->  
passed  [0.119s]
[192.168.10.2] out: 
lib/libarchive/functional_test:test_read_format_lha_bugfix_0  ->  passed  
[0.089s]
[192.168.10.2] out: 
lib/libarchive/functional_test:test_read_format_lha_filename  ->  passed  
[0.099s]
[192.168.10.2] out: lib/libarchive/functional_test:test_read_format_mtree  ->  
passed  [0.596s]
[192.168.10.2] out: 
lib/libarchive/functional_test:test_read_format_mtree_filenames_only  ->  
passed  [0.092s]
[192.168.10.2] out: 
lib/libarchive/functional_test:test_read_format_mtree_nochange  ->  passed  
[0.097s]
[192.168.10.2] out: 
lib/libarchive/functional_test:test_read_format_mtree_nomagic_v1_form  ->  
passed  [0.092s]
[192.168.10.2] out: 
lib/libarchive/functional_test:test_read_format_mtree_nomagic_v2_form  ->  
passed  [0.093s]
[192.168.10.2] out: 
lib/libarchive/functional_test:test_read_format_mtree_nomagic_v2_netbsd_form  
->  passed  [0.094s]
[192.168.10.2] out: 
lib/libarchive/functional_test:test_read_format_mtree_nonexistent_contents_file 
 ->  passed  [0.086s]
[192.168.10.2] out: lib/libarchive/functional_test:test_read_format_pax_bz2  -> 
 passed  [0.096s]
[192.168.10.2] out: lib/libarchive/functional_test:test_read_format_rar_basic  
->  passed  [0.298s]
[192.168.10.2] out: lib/libarchive/functional_test:test_read_format_rar_binary  
->  passed  [0.373s]
[192.168.10.2] out: 
lib/libarchive/functional_test:test_read_format_rar_compress_best  ->  passed  
[0.235s]
[192.168.10.2] out: 
lib/libarchive/functional_test:test_read_format_rar_compress_normal  ->  passed 
 [0.095s]
[192.168.10.2] out: 
lib/libarchive/functional_test:test_read_format_rar_encryption_data  ->  passed 
 [0.099s]
[192.168.10.2] out: 
lib/libarchive/functional_test:test_read_format_rar_encryption_header  ->  
passed  [0.092s]
[192.168.10.2] out: 
lib/libarchive/functional_test:test_read_format_rar_encryption_partially  ->  
passed  [0.095s]
[192.168.10.2] out: 
lib/libarchive/functional_test:test_read_format_rar_invalid1  ->  passed  
[0.094s]
[192.168.10.2] out: 
lib/libarchive/functional_test:test_read_format_rar_multi_lzss_blocks  ->  
passed  [0.141s]
[192.168.10.2] out: 
lib/libarchive/functional_test:test_read_format_rar_multivolume  ->  passed  
[0.823s]
[192.168.10.2] out: 
lib/libarchive/functional_test:test_read_format_rar_multivolume_seek_data  ->  
passed  [0.101s]
[192.168.10.2] out: 
lib/libarchive/functional_test:test_read_format_rar_multivolume_seek_multiple_files
  ->  passed  [0.108s]
[192.168.10.2] out: 
lib/libarchive/functional_test:test_read_format_rar_multivolume_skip  ->  
passed  [0.096s]
[192.168.10.2] out: 
lib/libarchive/functional_test:test_read_format_rar_multivolume_stored_file  -> 
 passed  [0.093s]
[192.168.10.2] out: 
lib/libarchive/functional_test:test_read_format_rar_multivolume_stored_file_skip
  ->  passed  [0.096s]
[192.168.10.2] out: 
lib/libarchive/functional_test:test_read_format_rar_multivolume_uncompressed_files
  ->  passed  [0.144s]
[192.168.10.2] out: lib/libarchive/functional_test:test_read_format_rar_noeof  
->  passed  [0.091s]
[192.168.10.2] out: 
lib/libarchive/functional_test:test_read_format_rar_ppmd_lzss_conversion  ->  
passed  [0.960s]
[192.168.10.2] out: 

11.0 -r303168 for TARGET_ARCH=powerpc: etc/mtree/BSD.lib32.dist usr/lib32/i18n/ usr/lib32/dtrace/ usr/lib32/ involved

[Mark Millard]

Context: amd64 11.0 -r303168 cross build sequence WITH_META_MODE=yes of 
TARGET_ARCH=powerpc (non-64), buildworld then installworld and mergemaster to a 
local directory:

mergemaster produced . . .

> *** You chose the automatic install option for files that did not
> exist on your system.  The following were installed for you:
>   /usr/obj/DESTDIRs/clang-powerpc-installworld/etc/mtree/BSD.lib32.dist

The later delete-old delete-old-libs produced . . .

> >>> Removing old files (only deletes safe to delete libs)
> remove /usr/obj/DESTDIRs/clang-powerpc-installworld/etc/mtree/BSD.lib32.dist? 
> y
> >>> Old files removed
> >>> Removing old directories
> /usr/obj/DESTDIRs/clang-powerpc-installworld/usr/share/locale/kk_KZ.UTF-8
> /usr/obj/DESTDIRs/clang-powerpc-installworld/usr/lib32/i18n
> /usr/obj/DESTDIRs/clang-powerpc-installworld/usr/lib32/dtrace
> /usr/obj/DESTDIRs/clang-powerpc-installworld/usr/lib32
> >>> Old directories removed
> To remove old libraries run 'make delete-old-libs'.
> >>> Removing old libraries
> Please be sure no application still uses those libraries, else you
> can not start such an application. Consult UPDATING for more
> information regarding how to cope with the removal/revision bump
> of a specific library.
> >>> Old libraries removed

For some reason "lib32" is involved a little bit when no such is needed.

Context details:

The prior build had been for -r302457 .

# more ~/src.configs/src.conf.powerpc-clang-bootstrap.amd64-host 
TO_TYPE=powerpc
#
KERNCONF=GENERICvtsc-NODEBUG
TARGET=${TO_TYPE}
.if ${.MAKE.LEVEL} == 0
TARGET_ARCH=${TO_TYPE}
.export TARGET_ARCH
.endif
#
WITH_CROSS_COMPILER=
WITHOUT_SYSTEM_COMPILER=
#
WITH_LIBCPLUSPLUS=
WITH_BINUTILS_BOOTSTRAP=
WITH_CLANG_BOOTSTRAP=
WITH_CLANG=
WITH_CLANG_IS_CC=
WITH_CLANG_FULL=
WITH_CLANG_EXTRAS=
# lldb requires missing atomic 8-byte operations for powerpc (non-64)
WITHOUT_LLDB=
#
WITH_BOOT=
WITHOUT_LIB32=
#
WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=
WITHOUT_GCC_BOOTSTRAP=
WITHOUT_GCC=
WITHOUT_GCC_IS_CC=
WITHOUT_GNUCXX=
#
NO_WERROR=
#WERROR=
MALLOC_PRODUCTION=
#
WITH_DEBUG_FILES=


make.conf empty.


Side note:

WARNING to avoid bad implications: clang 3.8.0 produces code that violates the 
powerpc (32-bit) ABI FreeBSD requires relative to stack handling. There are 
other problems as well, such as exception handling. To actually use the 
buildworld result I'd use a kernel modified to have a so-called "red-zone" for 
signal delivery. clang can not yet build the kernel so that part would be gcc 
4.2.1 based. This does not deal with the exception handling issues or other 
things but can be fairly useful. (I'm weeks away from having powerpc or 
powerpc64 access again.)

===
Mark Millard
markmi at dsl-only.net

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

Re: Call for Testing: Switching back to our BSD licensed dtc(1)

[David Chisnall]

On 22 Jul 2016, at 03:40, Warner Losh  wrote:
> 
> On Wed, Jul 20, 2016 at 9:51 AM, David Chisnall  wrote:
>> On 20 Jul 2016, at 16:46, Warner Losh  wrote:
>>> 
>>> I've been trying to get the final spec for it. Right now it's a
>>> disorganized series
>>> of patches, some of which have been merge some that haven't. I'll send you a
>>> copy when I can find something better than "here's the code."
>> 
>> Thanks.  From the information I can find, it looks as if most of the 
>> machinery required to implement it is already in dtc, so it should 
>> (hopefully) just be a matter of adding a new keyword to detect plugins, a 
>> scan to find the cross-references (or possibly reusing the existing one) and 
>> then a little bit of extra logic.
> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/overlay-notes.txt
> has the specs.

Hmm, that’s even less complete than the docs that I’d found.  From that, it 
seems as if the only thing that dtc needs to do is support the /plugin/ syntax 
and emit a section describing unresolved references?  Or is dtc also expected 
to be able to do the merging?

David




smime.p7s
Description: S/MIME cryptographic signature