PaNiC Random Rant (or how we used to call it: .plan)
lcdproc 0.5.3 released and ubuntu package for picoLCD
A new version(0.5.3) of lcdproc has been released. This release has a lot of improvements for picoLCD and other drivers.
I made a quick ubuntu package for picoLCD (models 20x2 and 20x4) which can be downloaded from the link below. This package has only the picoLCD driver and the configuration is made for picoLCD (note that ServerScreen is set to off to fix some problems with mythtv).
To start lcdproc execute /etc/init.d/LCDd start and start any client you want (lcdproc, lcdvc etc).
If you intend to use the IR functionality don't forget to add :
To start lirc manually you can use: lircd --driver=udp --listen=8765
Using video RAM ...
Since I was playing with some jffs images, I wanted to quickly write to a "dummy" mtd device and test the image from there. I remembered some time ago on slashdot there was an interesting article on how to use the video ram as storage. As I couldn't find it anymore I decided to try it myself.
Usually mounting jffs images requires some steps and the mtd2block kernel module:
losetup /dev/loop0 rootfs.jffs2
modprobe block2mtd block2mtd=/dev/loop0,131072
mount -t jffs2 -o ro /dev/mtdblock0 /mnt/loop0
Using the video ram:
1. Find out the starting address of video memory:
> lspci -v
2:00.0 VGA compatible controller: nVidia Corporation G94 [GeForce 9600 GT] (rev a1)
Subsystem: LeadTek Research Inc. Device 2ac1
Flags: bus master, fast devsel, latency 0, IRQ 18
Memory at fd000000 (32-bit, non-prefetchable) [size=16M]
Memory at d0000000 (64-bit, prefetchable) [size=256M]
Memory at fa000000 (64-bit, non-prefetchable) [size=32M]
I/O ports at ec00 [size=128]
[virtual] Expansion ROM at feb80000 [disabled] [size=512K]
As above the video memory starts at 0xd0000000
2. Map the video ram into a mtd block
> modprobe slram map=VRAM,0xd2000000,+0x4000000
Note that I maped from 0xd0000000 + 32Mb to let some video memory to be used by framebuffer/X (if you use nv driver you can specify VideoRam 32765 in xorg.conf to limit the memory mappings).
The third parameter (+0x4000000) is the memory size (64Mb)
If everything is ok you should see something like this in dmesg log:
slram: Mapped from 0xf8f00000 to 0xfaf00000
slram: devname=VRAM, devstart=0xd2000000, devlength=0x2000000
devstart and devlength depend on your parameters.
Doing cat /proc/mtd should output:
mtd0: 02000000 00004000 "VRAM"
3. Add the kernel mtd modules and create the mtdblock devices
mknod /dev/mtdblock0 b 31 0
mknod /dev/mtd0 c 90 0
Now you can use the /dev/mtdblock0 to write jffs images or use it as a very fast swap (mkswap /dev/mtdblock0, swapon)
Notice that you can't create partitions directly in /dev/mtdblock0 with fdisk and use /dev/mtdblock0p1. Partitions are usually created in a device driver mapping or by specifing mtdparts= parameter at kernel boot.
Hijacking library calls
From time to time you might want to override a function call by a binary or library with your own supplied code. This might be useful for example binding a program to a certain address considering that the program doesn't have an option for that. It can also be used for debugging or other obscure tasks. The attached example it's pretty simple, it saves the real address of connect function from libc to a function pointer named real_connect, reads the address/port information from environment and issues the new parameters after the bind call has been performed to the real_connect function.
For your "library" to be preloaded it has to be added to /etc/ld.so.preload by simply doing:
echo "/path/to/libc-highjack.so" > /etc/ld.so.preload
To use it, before starting a program, export HIGHHACK_PORT and HIGHJACK_IP to the values that you need.
The compiling instructions are in the source code.