To have it work in ESXi it’s enough to:

1. Get a multi-LUN aware SCSI controller. Notice that many RAID controllers can’t handle multi-lun targets. I’ve used an Adaptec 29320.
2. Run the following on ESXi:

   esxcli storage nmp satp rule add --satp VMW_SATP_LOCAL --driver="aic79xx" --description="Specific rule for Adaptec Card"

3. Issue a bus rescan

After that you should be able to see both the tape and the autoloader, as show in the following image:

[proguard] Error: Can't read [/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/lib/rt.jar] (No such file or directory)

That happens because the Java bundled with MacOSX doesn’t provide a standard library configuration, that is the rt.jar has been moved and renamed to classes.jar. To fix the issue simply symlink rt.jar to the corresponding classes.jar file:

localhost:~ root# cd /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/lib/
localhost:lib root# ln -sf ../../Classes/classes.jar rt.jar


[root@zimbra ~]#  iscsiadm -m discovery -t sendtargets -p 192.168.64.10
192.168.64.10:3260,1 iqn.2011-01.org.cyberz:storage:mail
192.168.64.106:3260,1 iqn.2011-01.org.cyberz:storage:mail
...
[root@zimbra ~]#

That is, the iSCSI target was bound to all the avaible interfaces (including ip addresses of zones).

To avoid this behavior it’s enough to create a “target portal group”, assign a specific interface to it and then bind targets to the tpg. Follows an example:

root@scytale:~# itadm create-tpg tpg-scytale 192.168.64.10:3260
root@scytale:~# itadm list-target
TARGET NAME                                                  STATE    SESSIONS
iqn.2011-01.org.cyberz:storage:mail                          online   1
root@scytale:~# itadm modify-target -t tpg-scytale iqn.2011-01.org.cyberz:storage:mail
Target iqn.2011-01.org.cyberz:storage:mail successfully modified
root@scytale:~#

TP-Link TL-WR743ND is the PoE brother of the common TL-WR741ND wireless router which is supported flawlessly by openwrt. Since I’ve got one WR743ND, I wanted to convert it into a useful OpenWRT router but I figured out that, unfortunately, the WR743ND is not supported by OpenWRT (at least officially). Given the similarity to the supported WR741ND, I’ve decided to hack it a bit to get it work with OpenWRT.

The first step is to get a working serial console. The procedure is similar to the one shown in the openwrt’s page dedicated to the WR741ND with the exception that (at least on the WR743ND which I got) the capacitor C496 and the resistor R610 were missing, so it was necessary to:

1. Shortcut the C496 pins
2. Solder a 2.7K resistor in place of R610 (I think short circuit would work as well — untested)

Follows a photo (low resolution, sorry) indicating where the soldering should be made:

Be aware that this hack requires some attention given the tiny dimension of SMD components.

Next step is to connect to the console via a serial cable and level converter. In my case I’ve assembled some circuitry with a MAX232 which was externally powered with 5v. Since the TX pin of the router is providing a positive level at 3.3v there is no issue with the MAX232 which is able to recognize the logic level, on contrary with the RX line we should care to not send +5v to the router which is using 3.3v logic levels (it may burn the router?). To accomplish that I’ve used a zener diode shunt to clamp the signal at 3.3v.

The whole thing was connected via a Profilic 232-to-USB adapter.

To test  the serial link connection, just boot the router and blind type tpl when the autoboot prompt is shown. The U-Boot loader will show a > prompt:

U-Boot 1.1.4 (Jan 18 2010 - 14:26:54)

AP91 (ar7240) U-boot
DRAM:
sri
#### TAP VALUE 1 = a, 2 = b
32 MB
id read 0x100000ff
flash size 4194304, sector count = 64
Flash:  4 MB
Using default environment

In:    serial
Out:   serial
Err:   serial
Net:   ag7240_enet_initialize...
No valid address in Flash. Using fixed address
: cfg1 0xf cfg2 0x7014
eth0: 00:03:7f:09:0b:ad
eth0 up
No valid address in Flash. Using fixed address
: cfg1 0xf cfg2 0x7214
eth1: 00:03:7f:09:0b:ad
ATHRS26: resetting s26
ATHRS26: s26 reset done
eth1 up
eth0, eth1
Autobooting in 1 seconds
tlp
ar7240>

Now that the console is working it’s time to proceed with the flashing. Download openwrt-ar71xx-tl-wr741nd-v1-squashfs-factory.bin from the OpenWRT website and have it published by a tftp server in your local network. Then connect the router to such a network and issue the following commands (here the tftp server is 192.168.1.45):

ar7240> setenv ipaddr 192.168.1.60
ar7240> setenv serverip 192.168.1.45
ar7240> printenv
bootargs=console=ttyS0,115200 root=31:02 rootfstype=jffs2 init=/sbin/init mtdparts=ar7240-nor0:256k(u-boot),64k(u-boot-env),2752k(rootfs),896k(uImage),64k(NVRAM),64k(ART)
bootcmd=bootm 0x9f020000
bootdelay=1
baudrate=115200
ethaddr=0x00:0xaa:0xbb:0xcc:0xdd:0xee
stdin=serial
stdout=serial
stderr=serial
ethact=eth0
serverip=192.168.1.45
ipaddr=192.168.1.60

Environment size: 357/65532 bytes
ar7240> tftpboot 0x80000000 openwrt-ar71xx-tl-wr741nd-v1-squashfs-factory.bin
dup 1 speed 1000
Using eth1 device
TFTP from server 192.168.1.45; our IP address is 192.168.1.60
Filename 'openwrt-ar71xx-tl-wr741nd-v1-squashfs-factory.bin'.
Load address: 0x80000000
Loading: #################################################################
 #################################################################
 #################################################################
 #################################################################
 #################################################################
 #################################################################
 #################################################################
 #################################################################
 #################################################################
 #################################################################
 #################################################################
 ######################################################
done
Bytes transferred = 3932160 (3c0000 hex)
ar7240> erase 0x9f020000 +0x3c0000

First 0x2 last 0x3d sector size 0x10000
 61
Erased 60 sectors
ar7240> cp.b 0x80000000 0x9f020000 0x3c0000
Copy to Flash... write addr: 9f020000
done
ar7240> bootm 0x9f020000
## Booting image at 9f020000 ...
 Uncompressing Kernel Image ... OK

Starting kernel ...

Linux version 2.6.32.10 (openwrt@wrt1.marcant.net) (gcc version 4.3.3 (GCC) ) #20 Tue Apr 6 15:01:26 CEST 2010
bootconsole [early0] enabled
CPU revision is: 00019374 (MIPS 24Kc)
Atheros AR7240 rev 2, CPU:350.000 MHz, AHB:175.000 MHz, DDR:350.000 MHz
Determined physical RAM map:
 memory: 02000000 @ 00000000 (usable)
Initrd not found or empty - disabling initrd
Zone PFN ranges:
 Normal   0x00000000 -> 0x00002000
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
 0: 0x00000000 -> 0x00002000
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 8128
Kernel command line: rootfstype=squashfs,yaffs,jffs2 noinitrd console=ttyS0,115200 board=TL-WR741ND
PID hash table entries: 128 (order: -3, 512 bytes)
Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)

Enjoy your new OpenWRT router!

NOTE: in case you would like to use the WT743ND as an access point and not as a router, OpenWRT documentation suggest to simply ignore the WAN interface and connect the AP via a LAN port. Unfortunately If you’re willing to use PoE the WAN port is the only port capable to receive power! In my case I successfully connected the PoE pins from the WAN to the first LAN port, having the router powered-on via PoE on the first LAN port (thus acting as an access point).


# sh eagle-lin-5.10.0.run
eagle-lin-5.10.0.run: /tmp/eagle-setup.3778/eagle-5.10.0/bin/eagle: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory


To get the thing done it’s enough to install the proper 32 bit libraries. On Fedora use yum to update the openssl package and then install the needed packages:


# yum update openssl
# yum install glibc.i686 libXrender.i686 libXrandr.i686 libXcursor.i686 freetype.i686 fontconfig.i686 libXi.i686 libpng.i686 openssl.i686 crypto.i686 libjpeg-turbo.i686 libstdc++.i686


Eagle is compiled with openssl 0.9.8, Fedora 14 ships with openssl 1.0, so we need to cheat a bit with symlinks:


# ln -s /usr/lib/libssl.so.10 /usr/lib/libssl.so.0.9.8
# ln -s /lib/libcrypto.so.10 /lib/libcrypto.so.0.9.8


Now your system is ready to run the Eagle installer.

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

1. The ncrs driver is not shipped with x64 kernel (yet it is for 32 bit version)
2. The default alias for PCI device 1000:000f (the Sym22801 card) is ncrs
3. 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"

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.

(Update on 18 Sep 2010)

Finally I had some time to assembly the prototype board of the anemometer. Follows the schematic and the board layout:

The board is rather simple and is based on a PCF8574 providing to the I²C the output of a CD 4040 counter. A dip switch is provided to select the PCF8574 address and some leds for power on and wind activity.

Some photos of the prototype follow:

The DIP switch was not soldered thus the circuit will have the address 0×27. After blowing the anemometer the green led was blinking and a scan on the i2c bus showed that the PCF 8574 was correctly detected. It was time to put the anemometer on the roof:

(Update on 27 Sep 2010)

After the hardware, it came the time to write the software. Due to the disappointing I²C support of perl (CPAN couldn’t find Device::SMBus), I’ve decided to switch to C(++) to get the thing done using the i2c-dev interface available from Linux kernel. The program, named windlogd (wind-logger-daemon) reads the counter values and output the current speed, as show in the following:

[root@kynes windlogd]# ./windlogd -s 0x27 -d /dev/i2c-1
Thu Oct 21 10:53:56 2010: samples 108,  92: freq 5.333 Hz, wind speed 3.378 m/s
Thu Oct 21 10:53:59 2010: samples 124, 108: freq 5.333 Hz, wind speed 3.378 m/s
Thu Oct 21 10:54:02 2010: samples 140, 124: freq 5.333 Hz, wind speed 3.378 m/s
Thu Oct 21 10:54:05 2010: samples 160, 140: freq 6.667 Hz, wind speed 4.156 m/s

The transfer function between the anemometer is defined in the source (see the TF_* defines). The -d argument sets the bus to be used (defaults to i2c-0), while -s is mandatory and is the device address (can be expressed both in decimal and hexadecimal using the 0x prefix).

You can download the source (for Linux) here.

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 <iostream>
#include "event.h"

enum { HELLO /* event type */ };

using namespace CyberzOrg::Event;

struct HelloEmitter
 : Emitter<
  Event<HELLO, void (const std::string &)>
 >
{ };

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>(hello).connect(callback); // connect signal handler (callback)
 getSignal<HELLO>(hello)("hello world"); // fire signal

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

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

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.

The SVGPan library features:

1. Panning (pan à la Google maps) (click on the white background and pan)
2. Zooming (using the mouse wheel)
3. Element dragging (click on a drawing element and drag it somewhere else)
4. 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:

<script xlink:href="SVGPan.js"/>
<g id="viewport" transform="translate(200,200)">...

You may also try another SVG example (triple integral, from Wikipedia).

Zeng Xiaohui has provided a patch to support the mouse wheel on Safari/Chrome and fixed the browser scrollbar issue as well. Both patches have been merged into the latest version of SVGPan.

The source of this project is now hosted on Google Code, so there you can find the latest version.

If you found this code useful please consider donating!