cyberz.org

Solaris 10 x64 and Symbios SYM22801 (and other LSI SCSI controllers)

andrea — Sat, 24 Jul 2010 19:33:13 +0000

Today I’ve discovered that the very common Symbios 22801 (aka Symbios Logic 53c875) SCSI controller is (unexpectedly) failing to be recognized by Solaris 10 on x64 hardware. In fact I was in the middle of the upgrade of my home backup infrastructure from an old DLT 20/40 to a newer DLT 40/80 to be connected to a Symbios card inside my Solaris box. Unfortunately after the reboot, the new card was unseen.

After some research on google I was able to find out that:

The ncrs driver is not shipped with x64 kernel (yet it is for 32 bit version)
The default alias for PCI device 1000:000f (the Sym22801 card) is ncrs
Another driver which supports the 53c875 controller, called glm, is shipped with Solaris 10 and available for both 32 and 64bit versions

So, it is enough to point the 1000:000f alias to the glm driver, instead of ncrs, to have the controller recognized. That can be easily accomplished changing the following entry in /etc/driver_aliases:

ncrs "pci1000,f"
to
glm "pci1000,f"

After that it is enough to reboot Solaris with device reconfiguration turned on (touch /reconfigure before rebooting) and check that the controller is recognized (prtconf or cfgadm -al can be used for that).

Update: I had again the same issue with an LSI Logic 53C1010-66 Ultra160 SCSI dual HBA. In this case the missing driver is symhisl, whereas the line to tweak in /etc/driver_aliases is:

symhisl "pci1000,21"
to
glm "pci1000,21"

I2C Anemometer: cheap wind data logger (Work In Progress)

andrea — Sat, 19 Jun 2010 18:26:02 +0000

Lately I’ve been wondering if a wind-generator could help me lower my electricity bill (since my home server burns continuously some hundred watts per hour) in my town, Ponzano Romano. So I came up to the idea that wind data logging is absolutely a must for any further reasoning about wind – that is I need an anemometer. On internet prices for those devices may vary, but I was unable to find anything below 150€ which I think is a bit too much for what is just an experiment for fun.

From the very interesting forum energeticaambiente a post pointed me to the electronic italian magazine “Nuova Elettronica” that posted the following (relatively cheap) anemometer kit:

The kit is fine but is not meeting my requirements for data logging, that is I have the need of a constant wind speed recording into my server; since it’s possible to buy only the anemometer (without the logic board) I went that way.

Moreover not so long time ago I’ve built some I2C circuitry (look at the post on this website), so I thought that a I2C wind logger interface to the anemometer from Nuova Elettronica (which costs 30€) would be easy and very cheap to build, bringing total cost of the solution to around 40€. In case you need to assemble even the I2C-to-Parport adapter, then you need to add few € for it, but the total cost should be no more than 50€.

This is the schema that I plan to build:

For those who may be interested, there’s another cheap anemometer by APRS World which is for sale at $65.

(some days after)

Anemometer calibration

After buying the anemometer I found out with disappointment that nor Nuova Elettronica nor the vendor (Master Motion Ahead) are publicly releasing the relation between the wind speed and the frequency; and my information request to both was kindly ignored. Nuova Elettronica’s kit employes a microcontroller to count the number of pulses and convert them to wind speed, so obviously they know the relation I’ve asked for. So, at this point, two alternatives showed up:

Buy the rest of Nuova Elettronica kit and guess the speed/frequency relationship testing the kit with a known frequency generator.
Calibrate the anemometer on my own.

Since the alternative 1 would raise the project budget of 30€, I opted for the 2nd: the whole process involves a car tour for some kilometers on a calm day (no wind) with the anemometer on top of the vehicle, monitored by my laptop. Since my laptop doesn’t have a parallel port, I figured out an alternative reading method for the calibration via the serial port (I already have an USB to RS232 converter which I use for serial console access with laptop). An old bluetooth GPS receiver (I have one from the pre-GPS smartphone era) will be used to acquire position/speed of the vehicle. I have in mind a short go and back trip in constant speed that would eventually neutralize the effect of a constant speed, uniform wind (if any – I plan to do that when there is NO wind at all).

(Update on 26 June 2010)

Today I had some free time to experiment what was the idea of the anemometer RS232 reading + gps positioning. I managed to install gpsd on my laptop (MacOSX), and I was lucky to find out gpsdX, a precompiled dmg package, thus avoiding compilation hell. Perl’s Net::GPSD relieved the data acquisition from gpsd, making the whole job trivial.

Then I made some tests with the USB to Serial adapter noticing that the RI pin can be kept high with a 1k pull-up resistor to RTS and ground (by the anemometer) to pin GND, all when a simple program is monitoring /dev/tty.usbserial for changes on the RI pin (using the TIOCMGET ioctl).

So I assembled some piece of software to make the whole thing work together:

riLogger is a simple C program that polls the serial state and notifies another program (which in this case will be windSpeed) sending a SIGUSR1 when the Ring Indicator bit changes.
windSpeed acquires data from gpsd, and counts the anemometer rounds (which are received as SIGUSR1 from riLogger), producing a CSV file containing both.

CyberzOrg::Event library: typesafe event handling in C++

andrea — Tue, 25 May 2010 21:22:05 +0000

The following article is date back to Thu Dec 14 22:12:44 CET 2006

Event is a little library built on top of boost::signal and boost::mpl that allows the user to declare in a simple way an object that can emit events and allow connection of (type-safe) callbacks as event handler to them. Usage is pretty straightforward, as shown in test/hello.cc:

#include 
#include "event.h"

enum { HELLO /* event type */ };

using namespace CyberzOrg::Event;

struct HelloEmitter
 : Emitter<
  Event
 >
{ };

void callback(const std::string &s) {
 std::cout << "Event HELLO: " << s << std::endl;
}

int main() {
 HelloEmitter hello;

 // preferred syntax (useful if event emitter has the event table depending on itself,
 // in such case getSignal method is not directly visible).
 getSignal(hello).connect(callback); // connect signal handler (callback)
 getSignal(hello)("hello world"); // fire signal

 // easy syntax
 hello.getSignal().connect(callback); // connect signal handler (callback)
 hello.getSignal()("hello world"); // fire signal
}

You can look at sources or download a tarball. Any feedback is well accepted.

Controlling the HP NetServer 5/133 LS2 LCD

andrea — Fri, 21 May 2010 23:37:59 +0000

The following article is dated back to Sat Dec 6 20:15:41 CET 2003

Some time ago, I got an old HP NetServer 5/133 LS2 (that I revived with FreeBSD):

After giving some progress informations during the boot process, I noticed that the front LCD display gets stuck with useless informations when the system is up and running, as shown here:

Since I wanted to put some meaningful text into the LCD, I started investigating around for a way to accomplish that.

I figured out (in HP’s forum) that there is some utility called LSECU that could help me. In fact the LSECU utility allows the user to setup some custom static string in the BIOS, but I was looking for a way to control the LCD from UNIX in order to show realtime status informations, so after some failed researches, I started thinking how to get it on my own.

Obviously the NetServer’s BIOS contains the code to change the LCD text because of the multiple updates being issued at boot time. So I started from the BIOS: googling a bit I found out that on the i386 architecture the BIOS starts at memory address 0xf0000 (and its size is 64k): so I wrote the following program to extract the BIOS to stdout.

int main() { FILE *f = fopen("/dev/mem", "r"); char bios[0xffff]; assert(f); fseek(f, 0xf0000, SEEK_CUR); fread(bios, 1, sizeof(bios), f); fwrite(bios, 1, sizeof(bios), stdout); }

Obviously only root can run that code (at -1 securelevel). Once I got the BIOS on a file, I went to Windows and downloaded some disassembler programs, as some friends of mine suggested (thanks to sand, Smilzo and tripz), and disassembled it. At first I looked for the string that was first showed by the BIOS, and I was able to find it at offset 0x6f26. Then I started looking for anything using that offset and got:

0000265D: 8CC8 mov ax,cs 0000265F: 8ED8 mov ds,ax 00002661: BE6F26 mov si,0266F 00002664: E888FE call 0000024EF -------- (5)

I don’t know much about x86 assembler, but this seems a call to function. Going to 0x24ef I found:

000024EF: 56 push si 000024F0: 50 push ax 000024F1: 9C pushf 000024F2: FC cld 000024F3: AC lodsb 000024F4: 0AC0 or al,al 000024F6: 7405 je 0000024FD -------- (3) 000024F8: E88EFF call 000002489 -------- (4) 000024FB: EBF6 jmps 0000024F3 -------- (5) 000024FD: 9D popf 000024FE: 58 pop ax 00002500: C3 retn

This function seems to iterate through the string until its gets null. At each iteration the current character is loaded in al, and the 0×2489 function is called. The 0×2489 function looks like:

00002489: 52 push dx 0000248A: E8DCFF call 000002469 -------- (1) ...

Just pushes dx and calls 0×2469 that contains:

00002469: 50 push ax 0000246A: 33C0 xor ax,ax 0000246C: B402 mov ah,002 0000246E: E862FF call 0000023D3 -------- (1) 00002471: 720D jb 000002480 -------- (2) 00002473: 8AF0 mov dh,al 00002475: 80E60F and dh,00F 00002478: 8AD0 mov dl,al 0000247A: C0FA06 sar dl,006 0000247D: 80E201 and dl,001 00002480: 58 pop ax 00002481: C3 retn

This function does some stuff with ax and then calls 0x23d3:

000023D3: 51 push cx 000023D4: 52 push dx 000023D5: 50 push ax 000023D6: B90600 mov cx,00006 000023D9: E8BCF1 call 000001598 -------- (1) 000023DC: 58 pop ax 000023DD: BA000E mov dx,00E00 000023E0: 80FC00 cmp ah,000 000023E3: 7418 je 0000023FD -------- (2) 000023E5: 80FC02 cmp ah,002 000023E8: 7410 je 0000023FA -------- (3) 000023EA: BA040E mov dx,00E04 000023ED: 80FC01 cmp ah,001 000023F0: 740B je 0000023FD -------- (4) 000023F2: 80FC03 cmp ah,003 000023F5: 7403 je 0000023FA -------- (5) 000023F7: F9 stc 000023F8: EB04 jmps 0000023FE -------- (6) 000023FA: EC in al,dx 000023FB: EB01 jmps 0000023FE -------- (7) 000023FD: EE out dx,al 000023FE: 5A pop dx 000023FF: 59 pop cx 00002400: C3 retn

Finally I got what I was looking for: some data bus I/O operations (in and out). Looking at the code, it seems that I/O on LCD uses two I/O ports, 0xe00 and 0xe04 (as you can see these values are loaded into the dx register and then used by the in/out ops).

Given the I/O addresses, I could start writing something. With a little random data test, I was able to put some nonsense characters to the LCD:

Now It was time to understand how to write correctly data. It looked easier to me to open the NetServer instead than reversing the whole protocol from the BIOS code, so I took out the control panel…

…to get the LCD driver IC, after removing that metal block:

The IC is HD44780A00, a processor of the well documented and widely used HD44780 family. Using the HD44780 datasheet it was easy to discover that 0xe00 is used to send commands and 0xe04 is used to send data to the device, so I’ve written lcdw, a little program to write directly on your display. Using lcdw, it’s easy to put on the LCD some nice infos about system’s current status, like uptime or load average, as example:

You can download here the sources of lcdw.

SVGPan: a Javascript SVG (Viewer) Pan/Zoom/Drag library

andrea — Tue, 08 Dec 2009 18:37:34 +0000

Some time ago the need for a browser-compatible vectorial language pushed me to consider the SVG markup language (I won’t say anything about Internet Explorer – it’s just unsupported there). The language itself is great, but, as a beginner, I was so disappointed about the fact that on the Internet I couldn’t find ANY library ready to use for panning and zooming features that I had to write one from scratch.

The SVGPan library features:

Panning (pan à la Google maps) (click on the white background and pan)
Zooming (using the mouse wheel)
Element dragging (click on a drawing element and drag it somewhere else)
Combinations of the above like zooming while dragging

The resulting javascript library is published here, in the hope that someone can find it useful. The library itself is very small and easy to use; and it’s licensed under the BSD license. You can try a demo here

No SVG support at all!

You can also open the demo in a new page and download the SVGPan library here.

The library itself requires a root group to be identified by the id viewport, which confines the SVGPan library effects, and the import of the javascript code as well. For example, to adapt the tiger drawing, it was necessary to add the following: