LCDProc 0.5.4-dev

stephenw10

Ok, it's simply the values are the wrong way around in the code:

case LPC_DEVICE_82801GBGR: 	/* XTM: W83627THG SuperIO */
	shift = 0x48;		/* offset for GPIO BASE */
	level = SIO_EFIR;	/* SuperIO chip is hard wired */
	level2 = SIO_EFDR;	/* to LPC ports 2E and 2F */
	p->red_bit = 0x10;
	p->grn_bit = 0x20;
	break;

My original findings:
@stephenw10:

Then the led can be controlled via CRF1:

Control Register F1     Bit5 Bit4	Arm/Disarm LED
0x00			0 0		Off
0x10			0 1		Green
0x20			1 0		Red
0x30			1 1		Off

Easy fix! :)

Steve

menacingm

My process for updating the driver was pretty simple. Sopped the LCDproc service from the Web Configurator, SSHd into my box and navigated to /usr/local/lib/lcdproc. Renamed sdeclcd.so to sdeclcd2.so and wget the new build. Checked permissions on sdeclcd.so and it needed a chmod +x. Then I was able to start up LCDProc from the webconfigurator with no problems. Haven't rebooted yet so I'll give that a go now and let you all know how it goes.

menacingm

I can confirm that although it was set to start at boot, the service didn't start after a reboot. It did however start right up manually from the webconfigurator. Here are the logs:

Apr 27 20:31:56	LCDd: LCDd version 0.5.5 starting
Apr 27 20:31:56	LCDd: Using Configuration File: /usr/local/etc/LCDd.conf
Apr 27 20:31:56	LCDd: Listening for queries on 127.0.0.1:13666
Apr 27 20:31:56	php: lcdproc: Start client procedure. Error counter: (0)
Apr 27 20:31:57	LCDd: Connect from host 127.0.0.1:9995 on socket 11
Apr 27 20:31:58	apinger: rrdtool respawning too fast, waiting 300s.
Apr 27 20:33:44	php: lcdproc: Sync: Begin package sync
Apr 27 20:33:44	check_reload_status: Syncing firewall
Apr 27 20:33:44	php: lcdproc: Sync: Restarting the service
Apr 27 20:33:45	LCDd: Client on socket 11 disconnected
Apr 27 20:33:45	LCDd: sock_send: socket write error
Apr 27 20:33:45	LCDd: sock_send: socket write error
Apr 27 20:33:45	LCDd: sock_send: socket write error
Apr 27 20:33:45	LCDd: sock_send: socket write error
Apr 27 20:33:45	LCDd: sock_send: socket write error
Apr 27 20:33:45	LCDd: sock_send: socket write error
Apr 27 20:33:45	LCDd: sock_send: socket write error
Apr 27 20:33:45	LCDd: sock_send: socket write error
Apr 27 20:33:45	LCDd: sock_send: socket write error
Apr 27 20:33:45	LCDd: sock_send: socket write error
Apr 27 20:33:45	LCDd: sock_send: socket write error
Apr 27 20:33:45	LCDd: sock_send: socket write error
Apr 27 20:33:45	LCDd: sock_send: socket write error
Apr 27 20:33:45	LCDd: sock_send: socket write error
Apr 27 20:33:45	LCDd: sock_send: socket write error
Apr 27 20:33:45	LCDd: Server shutting down on SIGTERM
Apr 27 20:33:46	LCDd: sdeclcd: cannot release IO-permission for 0x02E!
Apr 27 20:33:46	LCDd: sdeclcd: cannot release IO-permission for 0x02F!
Apr 27 20:33:46	LCDd: sdeclcd: cannot release IO-permission for 0x378!
Apr 27 20:33:49	php: lcdproc: Sync: End package sync
Apr 27 20:33:49	LCDd: LCDd version 0.5.5 starting
Apr 27 20:33:49	LCDd: Using Configuration File: /usr/local/etc/LCDd.conf
Apr 27 20:33:49	LCDd: Listening for queries on 127.0.0.1:13666
Apr 27 20:33:50	php: lcdproc: Start client procedure. Error counter: (0)
Apr 27 20:33:51	LCDd: Connect from host 127.0.0.1:3180 on socket 11

stephenw10

Ah, disappointing but not unexpected. :(

If you run 'ps aux|grep lcd' or 'ps aux|grep LCD' (there is a switch to make it ignore case but I can't remember it!) you may find it has started several instances of lcdd or is hung up waiting for a php instance to close.
Edit: It's 'ps aux|grep -i lcd'

Brak had some code the he said worked OK but I never got around to testing it. It's really ridiculous, IMHO, that the packages are restarted so many times at boot especially as something like this never needs to be restarted.

Steve

menacingm

Brak's lcdproc.inc only made things worse. Didn't fix the startup issues and on reboot a few other services didn't startup.

stephenw10

Damn. :(
There is some underlying problem here. It seems to be only an issue with the sdeclcd driver which means most people don't have a problem.
There is nothing obvious in the driver that might be introducing a delay. I have to say that reading through François' code is a joy. Compared to my own feeble efforts his is so professional. ::)

Did you try a longer LED sequence?

Steve

fmertz

@stephenw10:

Ok, it's simply the values are the wrong way around in the code:

case LPC_DEVICE_82801GBGR: 	/* XTM: W83627THG SuperIO */
	shift = 0x48;		/* offset for GPIO BASE */
	level = SIO_EFIR;	/* SuperIO chip is hard wired */
	level2 = SIO_EFDR;	/* to LPC ports 2E and 2F */
	p->red_bit = 0x10;
	p->grn_bit = 0x20;
	break;

My original findings:
@stephenw10:

Then the led can be controlled via CRF1:

Control Register F1     Bit5 Bit4	Arm/Disarm LED
0x00			0 0		Off
0x10			0 1		Green
0x20			1 0		Red
0x30			1 1		Off

Easy fix! :)

Steve

Thanks for the heads up. I'll update the code accordingly. Not a bad first run, really, considering this was coded "off the spec"…

fmertz

@stephenw10:

There is nothing obvious in the driver that might be introducing a delay. I have to say that reading through François' code is a joy. Compared to my own feeble efforts his is so professional. ::)

Thanks for the kind words about the code. The idea was to make it clean enough to make it acceptable for the upstream project, and make it available to all, whether I am the maintainer or not. It seemed like a shame to have all that gold information posted on this forum in terms of discoveries, and the countless hours of research that to go with them, without someone collecting it and regurgitating it in proper code form so it never goes extinct. Glad to hear someone is actually reading through it, though. ;)

Altogether, the LCD spec called for a very specific initialization sequence that takes more time. FWIW, the old code did not seem to properly reset the LCD when things went wrong, and a full reboot was necessary to clear things up. When this new sequence was implemented in the new code, just restarting the LCDproc package was enough to reset the LCD. The new delay is coded as:


	sdec_exec_wait(SDEC_FN_FUNCTION_SET | SDEC_OPT_8_BIT, 15000);

15000 micro seconds, 15ms.

Altogether, drivers control hardware, and should be allowed to have whatever timing quirks are required by the device they control. This includes slow initialization sequences, etc. Maybe the controller code needs to be looked at again. The errors from the driver code complaining of not being able to release the I/O ports might indicate there are multiple copies of this driver in memory…

menacingm

Stephen & Francois, glad to have you 2 brilliant minds working on this.

I haven't tried the new driver with the new delay and value order yet, running some development projects behind the pfsense box and need it up and stable for a few more weeks.

Stephen, did you get a chance to test to see if this corrects the SDECLCD driver boot initialization errors?

Francois, has the new SDECLCD driver reached a point where it can be committed to the next point release of lcdproc-dev?

Thanks guys

stephenw10

It's been accepted upstream so I don't see why not.
I still haven't been able to get it to start cleanly and reliably. To work around this I proposed running the new driver but starting it using the shellcmd package. This avoids more than one start. I've been running several boxes like that for a few weeks with no issues. See: http://forum.pfsense.org/index.php/topic,7920.msg344513.html#msg344513

Steve

jimp

The SDECLCD driver is in the current lcdproc-dev package after I bumped it this week by request. I don't have one any LCDs to try it with, but the correct binary appears to be there now (on 32 and 64 bit) included in the main lcdproc binaries, not pulled in separately anymore.

menacingm

I can confirm the latest LCDProc-Dev/Watchguard SDECLCD driver release available through the official PFSense package install still suffers from the same issues. Key mapping is not correct on the Watchguard XTM5 series and the service fails to start on boot.

I'm not sure if the binary jimp is referring to has been pushed to the official package yet, but I will tinker and report back.

Stephen,

I'm having some trouble getting the right shellcmd to start/restart the LCDProc service. Would you mind sharing that ShellCmd?

Thanks,

stephenw10

It's detailed in the post I linked to above.

Two interesting developments have happened recently that may help here.
JimP's watchdog package. It may be able to restart the service correctly after boot and if it fails. Though I suspect it only monitors the daemon and not the client.
The rc startup patches may help lcdproc-dev start correctly at boot.

Steve

Topper727

I have the CrystalFontz 735 Display which emulates the 635 and will go Graphic here in the very near future.

I am wondering why the LED's on the display don't light using LcdProc. What can I do?

stephenw10

You mean the backlight or some other LEDs?

Steve

kilthro

@stephenw10:

You mean the backlight or some other LEDs?

Steve

The leds down the side of the front of the unit.

@Topper727:

I have the CrystalFontz 735 Display which emulates the 635 and will go Graphic here in the very near future.

I am wondering why the LED's on the display don't light using LcdProc. What can I do?

You can get them to work.
I am still using this process/edits to the files and mine work. Not sure if much is diff between the 635/735 besides different type of lcd..

You may be able to apply this to get them to work.

http://forum.pfsense.org/index.php/topic,44034.msg302352.html#msg302352

Topper727

There is 4 dual color LED's on the left side of the 735 that I have. In PFSENSE LCDPROC I see :

Enable Output LEDs
Enable the Output LEDs present on some LCD panels. This feature is currently supported by the CFontz633 driver only.
Each LED can be off or show two colors: RED (alarm) or GREEN (everything ok) and shows:
LED1: NICs status (green: ok, red: at least one nic down);
LED2: CARP status (green: master, red: backup, off: CARP not implemented);
LED3: CPU status (green < 50, red > 50%);
LED4: Gateway status (green: ok, red: at least one gateway not responding, off: no gateway configured).

The cFontz633 is no longer included in LCDProc builds, so I use the Crystalfontz packet. This works good, buttons work and display shows information. But the 4 LED's on the left side do not show any thing.

Topper727

I found the fix.. In /usr/local/pkg/lcdproc_client.php

down near line 469 you see the following

Change the
if ($value && $lcdproc_config['driver'] == "CFontz633")
to
if ($value && $lcdproc_config['driver'] == "CFontzPacket")

that makes them work
I know this is just fooling it to think it is the 633 driver when your using the Packet one. I am not the developer or maintain this but could make all the changes needed to make it right and submit if need.

it does seem to not be perfect though. All lan /wan is up and red shows for that LED and all gateways up but no LED .. sometimes the gateway one lights up then the lan/wan one will go green.. so some bug in code maybe?

IMAG0013.jpg_thumb

Topper727

I got it going for most part. I can't get result from Gateway #4 LED just green it lights always. But others work. Fixed some typos in the lcdproc_client.php file. I submitted it to github and here is link

https://github.com/pfsense/pfsense-packages/pull/532

I did not change the code in major way or the what LED does what.. Just made it work.

http://www.youtube.com/watch?v=uYdyLdrT_PI

IMAG0027.jpg_thumb

stephenw10

Nice. :)
You almost certainly shouldn't have a gateway on LAN, off topic though. Do you have another thread going to discuss that?

Steve