PfSense on a Celestix S-X MSA 4000
-
What is the state of support for the Varitronix display in lcdproc?
I think that’s part of the problem in that I don’t see any support for Varitronix display in lcdproc. :'(
In LCDproc file what would be the settings for:
ugen1.2: <vendor 0x0cb6="">at usbus1
ukbd0: <vendor 0="" 2="" 0x0cb6="" keyboard="" +="" lcd,="" class="" 0,="" rev="" 1.10="" 1.00,="" addr="">on usbus1Device=/dev/ugen1.2
I hope i've this correct?
Here is all the USB info i can find ;)
[2.1-RELEASE][root@pfSense.localdomain]/dev(2): ls acpi crypto fd mem ttyu0.init ttyv8 ugen3.1 ad4 ctty fido nfslock ttyu0.lock ttyv9 ugen4.1 ad4s1 cuau0 geom.ctl null ttyu1 ttyva ukbd0 ad4s1a cuau0.init io pci ttyu1.init ttyvb urandom ad4s1b cuau0.lock kbd0 pf ttyu1.lock ttyvc usb agpgart cuau1 kbd1 ptmx ttyv0 ttyvd usbctl ata cuau1.init kbd2 random ttyv1 ttyve xpt0 atkbd0 cuau1.lock kbdmux0 speaker ttyv2 ttyvf zero audit dcons klog stderr ttyv3 ufsid zfs bpf devctl kmem stdin ttyv4 ugen0.1 bpf0 devstat led stdout ttyv5 ugen1.1 console dgdb md0 sysmouse ttyv6 ugen1.2 consolectl dumpdev mdctl ttyu0 ttyv7 ugen2.1 [2.1-RELEASE][root@pfSense.localdomain]/dev(3): 2.1-RELEASE][root@pfSense.localdomain]/dev(3): dmesg | grep usb usbus0: <intel 82801g="" (ich7)="" usb="" controller="" usb-a="">on uhci0 usbus1: <intel 82801g="" (ich7)="" usb="" controller="" usb-b="">on uhci1 usbus2: <intel 82801g="" (ich7)="" usb="" controller="" usb-c="">on uhci2 usbus3: <intel 82801g="" (ich7)="" usb="" controller="" usb-d="">on uhci3 usbus4: EHCI version 1.0 usbus4: <intel 82801gb="" r="" (ich7)="" usb="" 2.0="" controller="">on ehci0 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 480Mbps High Speed USB v2.0 ugen0.1: <intel>at usbus0 uhub0: <intel 1="" 9="" uhci="" root="" hub,="" class="" 0,="" rev="" 1.00="" 1.00,="" addr="">on usbus0 ugen1.1: <intel>at usbus1 uhub1: <intel 1="" 9="" uhci="" root="" hub,="" class="" 0,="" rev="" 1.00="" 1.00,="" addr="">on usbus1 ugen2.1: <intel>at usbus2 uhub2: <intel 1="" 9="" uhci="" root="" hub,="" class="" 0,="" rev="" 1.00="" 1.00,="" addr="">on usbus2 ugen3.1: <intel>at usbus3 uhub3: <intel 1="" 9="" uhci="" root="" hub,="" class="" 0,="" rev="" 1.00="" 1.00,="" addr="">on usbus3 ugen4.1: <intel>at usbus4 uhub4: <intel 1="" 9="" ehci="" root="" hub,="" class="" 0,="" rev="" 2.00="" 1.00,="" addr="">on usbus4 Root mount waiting for: usbus4 usbus3 usbus2 usbus1 usbus0 Root mount waiting for: usbus4 Root mount waiting for: usbus4 ugen1.2: <vendor 0x0cb6="">at usbus1 ukbd0: <vendor 0="" 2="" 0x0cb6="" keyboard="" +="" lcd,="" class="" 0,="" rev="" 1.10="" 1.00,="" addr="">on usbus1 [2.1-RELEASE][root@pfSense.localdomain]/dev(4): [2.1-RELEASE][root@pfSense.localdomain]/dev(5): pciconf -lv uhci0@pci0:0:29:0: class=0x0c0300 card=0x27c88086 chip=0x27c88086 rev=0x01 hdr=0x00 class = serial bus subclass = USB uhci1@pci0:0:29:1: class=0x0c0300 card=0x27c98086 chip=0x27c98086 rev=0x01 hdr=0x00 class = serial bus subclass = USB uhci2@pci0:0:29:2: class=0x0c0300 card=0x27ca8086 chip=0x27ca8086 rev=0x01 hdr=0x00 class = serial bus subclass = USB uhci3@pci0:0:29:3: class=0x0c0300 card=0x27ca8086 chip=0x27cb8086 rev=0x01 hdr=0x00 class = serial bus subclass = USB ehci0@pci0:0:29:7: class=0x0c0320 card=0x27cc8086 chip=0x27cc8086 rev=0x01 hdr=0x00 class = serial bus subclass = USB [2.1-RELEASE][root@pfSense.localdomain]/dev(6): [2.1-RELEASE][root@pfSense.localdomain]/dev(6): usbconfig ugen0.1: <uhci root="" hub="" intel="">at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen1.1: <uhci root="" hub="" intel="">at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen2.1: <uhci root="" hub="" intel="">at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen3.1: <uhci root="" hub="" intel="">at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen4.1: <ehci root="" hub="" intel="">at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE ugen1.2: <keyboard +="" lcd="" vendor="" 0x0cb6="">at usbus1, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON [2.1-RELEASE][root@pfSense.localdomain]/dev(7): [2.1-RELEASE][root@pfSense.localdomain]/dev(7): pciconf -l -cv uhci0@pci0:0:29:0: class=0x0c0300 card=0x27c88086 chip=0x27c88086 rev=0x01 hdr=0x00 class = serial bus subclass = USB uhci1@pci0:0:29:1: class=0x0c0300 card=0x27c98086 chip=0x27c98086 rev=0x01 hdr=0x00 class = serial bus subclass = USB uhci2@pci0:0:29:2: class=0x0c0300 card=0x27ca8086 chip=0x27ca8086 rev=0x01 hdr=0x00 class = serial bus subclass = USB uhci3@pci0:0:29:3: class=0x0c0300 card=0x27ca8086 chip=0x27cb8086 rev=0x01 hdr=0x00 class = serial bus subclass = USB ehci0@pci0:0:29:7: class=0x0c0320 card=0x27cc8086 chip=0x27cc8086 rev=0x01 hdr=0x00 class = serial bus subclass = USB cap 01[50] = powerspec 2 supports D0 D3 current D0 [2.1-RELEASE][root@pfSense.localdomain]/dev(8):</keyboard></ehci></uhci></uhci></uhci></uhci></vendor></vendor></intel></intel></intel></intel></intel></intel></intel></intel></intel></intel></intel></intel></intel></intel></intel> ```</vendor></vendor> -
Hmm tricky. The datasheet for the Varitronix MDLS40263, PDF, appears to show that the onbaord controller chip requires some custom 8bit data protocol. May be less custom than I think, most LCDs seem to use something like this. I think it will all depend on how much custom code Celestix have put on the chip on their board. If it's all passed through and done in the driver then there is always a chance. If it's custom code in the chip then we have no idea how to talk to it.
Edit: The LCDproc HD44780 driver appears to support the NT3881D IC in that display:
@http://lcdproc.omnipotent.net/hardware.php3:hd44780 All displays using HD44780 and compatible controllers (like KS0066, KS0070, KS0076, LC7985, NT3881, SED1278, ST7066)
It's likely a matter of figuring how the chip on the Celestix board separates the various devices, control knob, LEDs, lcd data lines.
It seems other manufacturers have used that microcontroller for similar purposes. Google throws up some interesting results.
Steve
Edit: This looks promising:
http://www.freebsd.org/cgi/man.cgi?query=ucycom&apropos=0&sektion=4&manpath=FreeBSD+8.3-RELEASE&arch=default&format=html
It would require some mods to make it recognise the USB IDs. -
Hello, just bought a couple of celestix appliances on an auction. I just spend a few minutes to start one of them with a VGA monitor connected. I noticed That the system is booting up by first going into a GRUB bootloader. In this boot menu one can choose an recovery option. Choosing the recovery option the system boots into linux, with on the screen just a USB device driver. The lcd with jog dial shows a menu for the last good configuration or a restore of a Windows server 2003.
So to me it Seems there should be a linux driver for the LCD/jog module on the hard disk.
Good luck
Marc
-
Interesting. The Linux driver's probably not much good to us in freebsd but if they're using lcdproc it will give some good clues.
Steve
-
I think LCDProc i's not needed. it looks if they are only using shell scripts for the whole IO communication with the display.
These scripts in /etc/init.d are calling a function "lcd_functions" in /etc/hardware/current where current is a variable ScorpioII Scorpio X ( al versions of the celestix appliances. And as a big suprise the function itself is not a compiled programm but a sh script!!!
Ok this scripts calls a program in the Bin directory (Scorpio_readkey) that is communicating to a /dev/ttyX and has been compiled in GCC: (GNU) 3.2.2 20030109 (Debian prerelease)
–---------------
DEV="/dev/usb/scorpioLCD1"
chvt 2lcd_write()
{
STR1=echo $* | cut -b1-80
LASTSTR=$STR1
STR=printf "%-80s" "$STR1"
echo -n "$STR" > $DEV
}format_line()
{
INSTR=$1
INHILITE=$2if [ -n "$INSTR" ]
then
LEN=echo $INSTR | wc -mCheck if string is longer than 36 characters
if [ $LEN -gt 36 ]
then
START=$(($LEN-16))
P1=echo $INSTR | cut -b 1-17
P2=echo $INSTR | cut -b $START-
STR="$P1…$P2"
else
STRx=echo $INSTR | cut -b 1-36
STR=printf "%-36s" "$STRx"
fiif [ $INHILITE -eq 1 ]
then
STR="$STR <<"
else
STR="$STR "
fi
else
STR=printf "%40s" " "
fi
echo -n "$STR"
}draw_menu()
{
TOPx=$1
shiftHILITE=$1
shiftwhile [ $TOPx -gt 0 ]
do
shift
TOPx=$(($TOPx-1))
doneY=1
lcd_clsif [ $HILITE -eq 1 ]
then
STR1=format_line "$1" 1
STR2=format_line "$2" 0
else
STR1=format_line "$1" 0
STR2=format_line "$2" 1
fiecho -n "${STR1}${STR2}" > $DEV
}lcd_menu()
{
DEF=1
HILITE=1
TOP=0
NUM=$#MENUSTR=
while [ -n "$1" ]
do
MENUSTR="$MENUSTR "$1""
shift
donewhile [ 1 ]
do
eval draw_menu $TOP $HILITE $MENUSTRKEY=
/bin/scorpio_readkey -1
case $KEY in
right)
if [ $DEF -gt 1 ]
then
DEF=$(($DEF-1))
if [ $DEF -le $TOP ]
then
TOP=$(($TOP-1))
fi
fi
HILITE=1
;;push)
break
;;left)
if [ $DEF -lt $NUM ]
then
DEF=$(($DEF+1))
if [ $HILITE -eq 2 ]
then
TOP=$(($TOP+1))
fi
fi
HILITE=2
;;
esac
done
echo $DEF
}lcd_cls()
{
STR=printf "%80s" " "
echo -n "$STR" > $DEV
}lcd_msg()
{
msg=echo "$1" | cut -b1-4
if [ ${#LASTSTR} -gt 74 ]
then
LASTSTR=echo -n $LASTSTR | cut -b1-74
STR="$LASTSTR[$msg]"
else
N=$((80 - ${#LASTSTR} - 6))
STR=printf "$LASTSTR%${N}s[$msg]" " "
fi
echo -n "$STR" > $DEV
}lcd_ok()
{
lcd_msg " OK "
}lcd_fail()
{
printf "\a"
lcd_msg "FAIL"
}lcd_wait()
{
lcd_msg "WAIT"
}
–-------------------------------
Confirm_restore.orig script#!/bin/sh
###############################
Confirm Restore
###############################
if [ -f "/etc/hardware/current/lcd_functions" ]
then
. /etc/hardware/current/lcd_functions
fiif [ -f "/etc/product.spec" ]
then
. /etc/product.spec
fiif grep -q "LGVSAVE" /proc/cmdline ; then
/etc/init.d/last_good_version_save
reboot
fiif grep -q "LGVRESTORE" /proc/cmdline ; then
/etc/init.d/last_good_version_restore
reboot
fiLGVAVAIL=
ls /rescue/LGV* 2>/dev/null | grep -q LGV && echo YESconfirmation() {
# Shows a Proceed prompt,
# Args: 1 (Yes - Default then No),
# 2 (No - Default then Yes),
# Others: 2 Assumed
# Returns: TRUE (0) if Default is selected, else FALSE (1)
OPTION=$1
DEFAULT="Proceed? "
OTHERLN=" "
if [ "$OPTION" = "1" ] ; then
DEFAULT="${DEFAULT}Yes"
OTHERLN="${OTHERLN} No"
else
DEFAULT="${DEFAULT} No"
OTHERLN="${OTHERLN}Yes"
fi
choice=lcd_menu "$DEFAULT" "$OTHERLN"
if [ "X$choice" = "X1" ] ; then
return 0
else
return 1
fi
}restore_menu_default() {
choice=lcd_menu "Cancel Restore" "Restore System"
if [ "X$choice" = "X1" ] ; then
operation_cancelled "Restore"
else
/etc/init.d/partimage
fi
}operation_cancelled() {
lcd_write "$* is Cancelled. Rebooting in 3 seconds."
sleep 3
reboot
exit 1
}restore_menu_full() {
# Now we check to see if there are extra images that we can
# install
if [ -z "$EXTRAIMAGES" ] ; then
restore_menu_default
else
# There are spare items that we can install
# Check installable items
IMAGES=""
for f in $EXTRAIMAGES ; do
if echo $f | grep -q -e ".000$" ; then
IMAGES="$IMAGES $f"
fi
done
if [ -z "$IMAGES" ] ; then
restore_menu_default
else
/etc/init.d/partimage $IMAGES
fi
fi
}grep -q "noprompt" /proc/cmdline
if [ "X$?" != "X0" ]
then
choice=lcd_menu "Cancel Backup/Restore" "Backup System" "Restore System"
if [ "X$choice" = "X1" ]
then
operation_cancelled "Backup/Restore"
elif [ "X$choice" = "X2" ] ; then
lcd_write "Backing up system"
/etc/init.d/last_good_version_save
reboot
exit 1
elif [ "X$choice" = "X3" ] ; then
if [ "$LGVAVAIL" = "YES" ] ; then
choice=lcd_menu "Cancel Restore" "Restore Last Good Version" "Restore System"
if [ "X$choice" = "X1" ] ; then
operation_cancelled "Restore"
elif [ "X$choice" = "X2" ] ; then
lcd_write "Restoring system"
/etc/init.d/last_good_version_restore
reboot
exit 1
else
restore_menu_full
fi
else
restore_menu_full
fi
fi
else
/etc/init.d/partimage
fi
–-------------------------------------Next to this all it seems that they load load two specific drivers:
Mount proc
if [ ! -f /proc/cpuinfo ]
then
mount -t proc none /proc
fiLoad USB Driver
echo Loading USB Driver
#modprobe usbcore
#modprobe usb-uhci
#modprobe input
#modprobe hidLoad LCD Driver
modprobe scorpioLCD
modprobe led
#sleep 3Load Keyboard Driver
#modprobe keybdev
Load Network Driver
#modprobe e1000
Load File System Driver
#modprobe jbd
#modprobe ext3Seems that there are some posibilities.
Marc
-
Ah, nice investigative work. :)
Its a shame they're not using lcdproc. That way we would know exactly how the driver has to work.
Interesting that they have separated the lcd and led drivers.Interesting that the keydriver appears to be using a serial port. The chip they are using seems to be commonly used as a USB-serial converter so that could make sense. It is recognised as a keyboard by freebsd already though.
ukbd0: <vendor 0="" 2="" 0x0cb6="" keyboard="" +="" lcd,="" class="" 0,="" rev="" 1.10="" 1.00,="" addr=""> on usbus1</vendor>I guess a good test would be to just read ukbd0 while operating the knob and see what happens.
Steve
-
Excellent work guys,
I almost had given up on getting the LCD to work, but there could be light at the end of the tunnel. :)just read ukbd0 while operating the knob and see what happens.
Could you suggest how to go about that and I’ll give it ago?
Another good feature of these devices is the speed of the fans are controlled by the CPU temperature, unlike some WatchGuard Firebox boxes. ;)
On another note, does anybody know how to remap the network interface ports so they match the front panel?
em0: <intel(r) 1000="" pro="" network="" connection="" 7.3.2="">port 0x8f00-0x8f1f mem 0xfd6e0000-0xfd6fffff irq 16 at device 0.0 on pci1 em0: Using an MSI interrupt em0: [FILTER] pcib2: <acpi pci-pci="" bridge="">irq 17 at device 28.1 on pci0 pci2: <acpi pci="" bus="">on pcib2 em1: <intel(r) 1000="" pro="" network="" connection="" 7.3.2="">port 0x7f00-0x7f1f mem 0xfd2e0000-0xfd2fffff irq 17 at device 0.0 on pci2 em1: Using an MSI interrupt em1: [FILTER] pcib3: <acpi pci-pci="" bridge="">irq 18 at device 28.2 on pci0 pci3: <acpi pci="" bus="">on pcib3 em2: <intel(r) 1000="" pro="" network="" connection="" 7.3.2="">port 0xdf00-0xdf1f mem 0xfdee0000-0xfdefffff irq 18 at device 0.0 on pci3 em2: Using an MSI interrupt em2: [FILTER] pcib4: <acpi pci-pci="" bridge="">irq 19 at device 28.3 on pci0 pci4: <acpi pci="" bus="">on pcib4 em3: <intel(r) 1000="" pro="" network="" connection="" 7.3.2="">port 0xcf00-0xcf1f mem 0xfdce0000-0xfdcfffff irq 19 at device 0.0 on pci4 em3: Using an MSI interrupt em3: [FILTER] pcib5: <acpi pci-pci="" bridge="">irq 16 at device 28.4 on pci0 pci5: <acpi pci="" bus="">on pcib5 em4: <intel(r) 1000="" pro="" network="" connection="" 7.3.2="">port 0xaf00-0xaf1f mem 0xfdae0000-0xfdafffff irq 16 at device 0.0 on pci5 em4: Using an MSI interrupt em4: [FILTER] pcib6: <acpi pci-pci="" bridge="">irq 17 at device 28.5 on pci0 pci6: <acpi pci="" bus="">on pcib6 em5: <intel(r) 1000="" pro="" network="" connection="" 7.3.2="">port 0x9f00-0x9f1f mem 0xfd8e0000-0xfd8fffff irq 17 at device 0.0 on pci6 em5: Using an MSI interrupt em5: [FILTER]</intel(r)></acpi></acpi></intel(r)></acpi></acpi></intel(r)></acpi></acpi></intel(r)></acpi></acpi></intel(r)></acpi></acpi></intel(r)>This is what I am after:-
ifconfig em5 name em0
ifconfig em4 name em1
ifconfig em3 name em2
ifconfig em2 name em3
ifconfig em1 name em4
ifconfig em0 name em5Also tried, Create file /etc/rc.conf.local
ifconfig_em0_name="LAN"
ifconfig_em1_name="WAN"
ifconfig_em2_name="DMZ1"
ifconfig_em3_name="DMZ2"
ifconfig_em4_name="DMZ3"
ifconfig_em5_name="DMZ4"This doesn’t appear to work unless I’m doing something wrong!
Thanks in advance for your help.
-
You can just rename the interfaces in the webgui.
You can't use normal FreeBSD conf files in pfSense. All the configuration is stored in a single file, config.xml. At boot scripts use that information to write out the various config files, if you manually modify then they will be overwritten the next make you make a change. You can edit the config.xml file directly to make a series of changes but it's open to errors which could cause you all sorts of problems. ;)The keyboard is an interesting question, I've never tried. You appear to have three keyboards detected on that box. In /dev you have kbd0-2. My boxes here have no keyboards. Do you actually have a real keyboard attached? It appears you can get some info from each using the kbdcontrol command:
kbdcontrol -i < /dev/kbd1Some useful tests here: http://people.freebsd.org/~yokota/ukbd-howto.txt
Steve
-
Have just got my hands on a MSA3000 and I'm also interested in getting the LCD/jog wheel running with pfSense. Sadly my unit arrived without HDD so I don't have a working Windows system to drive the LCD otherwise I could have hooked up a logic analyser to see what messages the driver receives from the PC.
nanobot do you still have access to the executables and kernel modules? I wonder if we might be able to decompile the scorpioLCD and led kernel modules and get a bit of information as to how the PC talks to the LCD driver…?
-
It's very unlikely that the Celestix engineers designed a completely new custom protocol and display for their box. It's probably using common protocols and likely off the shelf components. It may have some custom firmware to drive the control wheel and leds.
At least some of the hardware appears to be using standard USB-serial converters so the first thing I would try would be to recompile the USB-Serial driver to recognise the USB IDs of the hardware in the box and see if you can talk to it from a terminal or read anything it's sending.Steve
-
I agree it's probably nothing too complicated or proprietary. It enumerates as a USB HID device, the jog wheel sends out key codes when it's rotated or clicked - that's the easy bit! This is what Ubuntu makes of the device:
Bus 003 Device 002: ID 0cb6:0002 Celestix Networks, Pte., Ltd Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x0cb6 Celestix Networks, Pte., Ltd idProduct 0x0002 bcdDevice 1.00 iManufacturer 1 CELESTIX NETWORKS iProduct 2 KEYBOARD + LCD iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 34 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 50mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 1 Boot Interface Subclass bInterfaceProtocol 1 Keyboard iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.00 bCountryCode 0 Not supported bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 62 Report Descriptor: (length is 62) Item(Global): Usage Page, data= [ 0x01 ] 1 Generic Desktop Controls Item(Local ): Usage, data= [ 0x06 ] 6 Keyboard Item(Main ): Collection, data= [ 0x01 ] 1 Application Item(Global): Report ID, data= [ 0x01 ] 1 Item(Global): Usage Page, data= [ 0x07 ] 7 Keyboard Item(Local ): Usage Minimum, data= [ 0xe0 ] 224 Control Left Item(Local ): Usage Maximum, data= [ 0xe7 ] 231 GUI Right Item(Global): Logical Minimum, data= [ 0x00 ] 0 Item(Global): Logical Maximum, data= [ 0x01 ] 1 Item(Global): Report Size, data= [ 0x01 ] 1 Item(Global): Report Count, data= [ 0x08 ] 8 Item(Main ): Input, data= [ 0x02 ] 2 Data Variable Absolute No_Wrap Linear Preferred_State No_Null_Position Non_Volatile Bitfield Item(Global): Report Size, data= [ 0x08 ] 8 Item(Global): Report Count, data= [ 0x01 ] 1 Item(Global): Logical Minimum, data= [ 0x00 ] 0 Item(Global): Logical Maximum, data= [ 0x68 ] 104 Item(Global): Usage Page, data= [ 0x07 ] 7 Keyboard Item(Local ): Usage Minimum, data= [ 0x00 ] 0 No Event Item(Local ): Usage Maximum, data= [ 0x68 ] 104 F13 Item(Main ): Input, data= [ 0x00 ] 0 Data Array Absolute No_Wrap Linear Preferred_State No_Null_Position Non_Volatile Bitfield Item(Main ): End Collection, data=none Item(Global): Usage Page, data= [ 0x14 ] 20 Alphanumeric Display Item(Local ): Usage, data= [ 0x01 ] 1 Alphanumeric Display Item(Main ): Collection, data= [ 0x01 ] 1 Application Item(Global): Report ID, data= [ 0x02 ] 2 Item(Local ): Usage, data= [ 0x2c ] 44 Display Data Item(Global): Logical Minimum, data= [ 0x80 ] 128 Item(Global): Logical Maximum, data= [ 0x7f ] 127 Item(Global): Report Size, data= [ 0x08 ] 8 Item(Global): Report Count, data= [ 0x58 ] 88 Item(Main ): Output, data= [ 0x02 ] 2 Data Variable Absolute No_Wrap Linear Preferred_State No_Null_Position Non_Volatile Bitfield Item(Main ): End Collection, data=none Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 10 Device Status: 0x0000 (Bus Powered)There seem to be very few LCDs using a Cypress driver, I saw that the IOWarrior did and that's supported within LCDProc, I tried recompiling it to match the USB VID:PID of the Celestix device but it did not work. I guess that would have been too easy!
So I'm at a little bit of a loss at the moment, I haven't done any USB driver development before. I can't imagine the driver is that complex, but at the same time I don't know how to send character / raw data to a USB HID device. I've started looking at pyusb but it's very low level stuff…
-
What I would do I were trying to design this…..
Use a standard keyboard controller IC for the jog wheel and LEDs (num,caps and scroll lock).
Use a standard USB-serial converter and connect that to a serial LCD.You have two USB devices there yes? One is detected as a keyboard already. There are programs in existence that use keyboard LEDs as indicators, it must be possible to try setting them manually. That should be an easy enough test.
The other USB device seen as ugen1.2 in the first posts here is probably the serial converter. I would try to recompile the cypress driver to recognise the USB vendor and product IDs used by it. If that works then try various LCDproc settings to talk to the LCD across it.Steve
Edit: I can't find a FreeBSD equivalent but in Ubuntu you can try using the setleds command.
-
Actually it's just a single USB device (combined keyboard and LCD). The problem is there doesn't seem to be any standard way to interface with displays over HID, so without a working system to sniff it is next to impossible to reverse engineer the protocol they have used on the cypress microprocessor.
Probably the easiest solution, certainly time wise, would be to replace the microprocessor with something LCDproc does support, such as an FTDI FT232 chip. This would probably mean losing the jog wheel, though there should be a pin spare for the activity LED at least…
-
On another subject I've been tinkering with different CPUs as the P4 3GHz mine came with by standard isn't the most energy efficient chip, and I know that some of the higher spec MSA boxes come with core 2 duo chips (E6420 I believe). I've tested the following:
Core2duo E6420 SLA4T (2.13GHz, 1066 FSB, 4M) - boots but unstable
Core2duo E6320 SLA4U (1.86MHz, 1066 FSB, 4M) - boots but unstable
Core2duo E4400 SLA98 (2.00GHz, 800 FSB, 2M) - boots, stable, BIOS reports incorrect speed?The E4400 gets reported at the BIOS as 50x10 = 500MHz! This is also reported in the OS I'm using to test (Ubuntu) but performance suggests it's actually running at the 2GHz. Doesn't look like it will be possible to run powerd in this sort of state however. You can set the FSB in the BIOS but this seems to get divided down by 4 for some reason with the E4400.
Not quite sure why the E6x20 1066 FSB chips aren't stable. It does take a lot to make them crash, I've been running memtest, mprime torture tests but the 'stress' command seems to reliably kill them given a few cycles. When they crash the system just halts, no input or output but the display remains frozen, very odd. The E4400 has been running with both mprime and the odd stress command for several hours now stable and has topped out at a core temp of 66c. All were tested with known good 2x 1Gb and 2x512Mb PC5300.
The stress command I have been using is
stress --cpu 8 --io 4 --vm 2 --vm-bytes 128M --timeout 10sAll these oddities suggest to me a BIOS issue, though I cannot find an update for it (perhaps unsurprisingly, it being a custom motherboard). If time permits I may try to extract the existing BIOS and see if there is anything that can be unlocked settings wise.
-
I found the datasheets for the display they indicates that the module is using a "NT3881 or equivalent" display driver chip. on the LCDproc hardware page it indicates that that controller is compatible and supported under the hd44780.
http://media.digikey.com/pdf/Data%20Sheets/Varitronix%20PDFs/MDLS40263-01%20Specification.pdf
http://lcdproc.omnipotent.net/hardware.php3
http://media.digikey.com/pdf/Data%20Sheets/Varitronix%20PDFs/MDL(S)40263.pdf
http://media.digikey.com/pdf/Data%20Sheets/Varitronix%20PDFs/Varitronix%20LCD%20Initialization%20Instructions.pdf -
Controlling the LCD itself is probably not a problem, there are drivers already in LCDproc for various hd44780 modes. The problem is controlling whatever it is connected to. It appears as a single USB device that does the leds and control wheel as well as the LCD.
Steve
-
Following…
-
Here's the pinout of the LCD module:
+--------------------+ PIN FUNCTION | 02 04 06 08 10 | +---+ +--------+ | | 01 USB 5v | 01 03 05 07 09 | 02 USB D- +--------| |--------+ 03 USB D+ 04 USB GND Connector on PCB 05 LED Green (Power) 06 LED Red (Fault) 07 LED Ambert (Disk) ++ 08 System Power (short to GND to boot machine) +--------------------+ 09 3v | 01 03 05 07 09 | 10 State detect ("System On" -> "System Ready") | | | 02 04 06 08 10 | USB is only enabled when "Ready" state is achieved +--------------------+ When module is outside of system, short pin 10 to any LED to force "Ready" state and USB communication Connector on cable -
If you want to replace the Cavium Nitrox miniPCI card you could go by using a
Soekris vpn1411 miniPCI card that is supported by pfSense. -
I have a couple of Celestix boxes with intact stock software. Will be posting USB captures soon, stay tuned…
