New Overlay for Syscomp Design

I recently used my digital storage oscilloscope and  function generator for the first time since retrieving all of my electronics from storage after returning from Germany. These are really handy devices for examining low-frequency (pre-micro) electronics. After I wrote a couple of ebuilds to install the Open Instrumentation Project software, I thought I'd make the ebuilds publicly available.

Syscomp Design is incidentally run by a former professor of mine from Ryerson, Peter Hiscocks. I thoroughly enjoyed his course on microprocessor / microelectronic interfacing, and luckily did so before he went into early retirement. On a somewhat unrelated note, we're both part of the TLUG :) It's good to see that Prof. Hiscocks is keeping himself busy these days - Syscomp just released a new device that obseletes both of the units I bought 3 years ago! Although he mentioned that the older oscilloscope circuit has more dedicated storage space and time resolution.

If anyone would like to check out the overlay using layman, then you should be able to do it with the following command

layman -o http://virtb.visibleassets.com:2080/layman.conf -a syscomp

After that, you should be able to do the following (as root)

for i in dso101 cgr101 wgm101; do
echo "sci-electronics/$i" >> /etc/portage/package.keywords
done
emerge -av1 dso101 cgr101 wgm101

I've contributed two patches (one for wgm and another cgr) which allow for more flexible storage of the program files in /usr/lib.

Enjoy!

EEE 702 Has Poor Graphics Performance

I've owned my EEE 8G for quite a long time and also fully customized the software on it as a binary Gentoo distribution. However, one thing that I've found noticeably lacking is the performance of full-screen video. The video device on the EEE is an Intel 915 Mobile Graphics chip, which I believe uses shared memory.

If you know of a way to improve the video framerate of the EEE, then please post your Xorg.conf and related mesa / intel driver versions.

Thane Heins' Demos on 'Back EMF'

The interpretation of the results obtained by Thane Heins are under quite a bit of debate. Many people doubt their own eyes because they seem to think that he's create 'free energy'. Even a prof at MIT is 'stumped'.

Another engineer friend of mine who's well versed in electric motors is going to try to replicate the experiment and hopefully see exactly where the extra energy is coming from. Many people have been able to charge a battery from their self-built apparatus.

Results of search "Thane Heins" on YouTube.com

My FreeRunner Debug Board v3 Has Arrived

Well, I finally received the Debug Board v3 that I've been hounding Koolu for ever since I received my FreeRunner. The Dboard, as it's sometimes called, provides a JTAG interface to the Neo FreeRunner from OpenMoko / FIC and can also be interfaced with any other ARM device via the unpopulated 20-pin JTAG header at the bottom of the image. I'm particularly interested in trying out BeagleBoard debugging with my Dboard after I build a 20-pin to 14-pin adapter.

It's a good thing that I ordered my Dboard from OpenMoko directly because Koolu has publicly stated that they will not be offering the Debug Board to their customers because the FreeRunner is unbrickable. Although, by assuming that the Debug Board's only use is for bootloader debugging, it precludes all sorts of other uses for the board such as step-debugging with GDB through static firmware images, kernel debugging, or the potential of debugging, say, Android, NetBSD or any other OS.

I'm happy now that I have mine anyway. I hope that they don't stop mass production of the Dboard either, because it might be a more versatile alternative than the FlySwatter, although both offer freely available schematics.

If anyone out there has experience JTAG debugging with both the FlySwatter and the Debug Board v3, then I would be very happy to hear comments detailing the pros and cons of each.

TS-7800: Linux RAID NAS for the Home User?

Update-20100328: Seeing as how Marvell are essentially the only ARM licensees who have gigabit ethernet technology, this device would decidedly make a really cool control board for the USRP2 from Ettus Research, Inc. Luckily, I've been doing some hacking with libusrp2 lately ;-)

I've had my TS-7800 for quite some time now, and I haven't really done anything fantastic with it yet, although, my original plans were to use it quite suitably as a NAS. The TS-7800 uses the Marvell Feroceon MV88F5182 CPU, and while lacking vector floating point (VFP) support, it is perfect for use as a storage controller.

This would be used by Erin & myself for fault-tolerant storage of important data.

Now, when I say fault-tolerant, I'm speaking of a redundant array of inexpensive disks (RAID). The TS-7800 does not come with a hardware RAID controller, as they are very expensive and usually only found in bulky server equipment, but any linux appliance is perfectly capable of acting as a software RAID controller.

The TS-7800 only supports two SATA connected drives, which means that if I only include these two devices in my software RAID configuration, the RAID level is limited to RAID 0 ("striping", improves speed, no redundant storage), or RAID 1 ("mirroring", data redundancy, slight speed overhead). Of course, I would choose the second option to have our data stored reliably. In that case, my capacity would be half of the total disk capacity.

If I were only including two SATA connected drives in my configuration, my RAID configuration would be limited. However, if I chose to make use of more devices connected via the TS-7800's USB ports, then I could have a RAID 5 configuration (striped, with parity). Just like a RAID 1 configuration, no data is lost if one disk is damaged. Unlike the RAID 1 configuration, rebuilding the damaged disk means more than simply copying the information from the other disk. Furthermore, if I implemented this and mixed SATA / USB disks, then there would surely be a performance hit when reading from / writing to a USB disk, which would slow down the array as a whole since operations would be striped across all disks in a RAID 5 configuration. RAID 5 also performs poorly in software when small files are being repeatedly updated because of the parity calculation requirement.

I think, in the end, I'll choose to use two 500 GB SATA disks, 3.5" in size just because the price is so relatively low, such as these, and start off with a simple RAID 1 configuration. Later on, if I feel the need to upgrade the capacity of the disks, or the raid array itself, I can hopefully buy some more similar disks and connect two more via USB, in spite of the slowdown that it might cause.

BeagleBoard Notes

My BeagleBoard recently arrived from DigiKey and after resoldering an RS232 connector and downloading the binary images, I was good to go.

If you're planning on only using the BeagleBoard as a USB gadget, connected to a PC, where the PC acts as the USB master, then you do not need to worry about a USB Mini A cable.

If you would like to network the BeagleBoard and a PC through the USB OTG port, then a USB Mini A cable is not necessary. You would use a regular USB Mini B cable which is the type used for most digital cameras.

Toolchain for the Neo FreeRunner

Well, it's been a while, hasn't it !?

Erin, Jules, & I were all quite busy over the last few weeks - we travelled all over the lower half of Ontario, and then went camping at Bruce Peninsula National Park & on Manintoulin Island.

(Note to self, make Google map containing a trail of our route + photos)

We're now back in Montreal, and it's pretty intense. I have 4 exams coming up in the next 3 weeks and will surely have my hands full for all of them. Hopefully the examination board at the Uni-Kiel allows me to write the exams remotely from Montreal, given my special circumstances (baby, f/t job, etc), so that I don't have an overly-demanding schedule when I return in March / April.

Soooo wie so, I was pleased to receive my new Neo FreeRunner mobile phone when I got back to Montreal. Last week I upgraded the firmware to om2008.8 which has a slick, webkit-based UI. After having used it for a week, I can honestly say that this guy will be the iPhone killer, for anyone who likes to do extreme things with mobile devices at least.

My EEE PC is doing very well, and another one is on the way for Erin. I was hoping that it would get here in time for her birthday, but it seems that there is an 8-10 week shipping delay from the Royal Bank!!! Daaaamn!!!

In a few days, I'm expecting to receive a BeagleBoard in the mail along with a 15.1" touchscreen panel - I can't wait ;-) Then is a cipherlabs 9400 handheld for industrial scanning. I'll be putting linux on that too.

I really have to say, though, that I'm really starting to feel the lack of a graphical package manager for Gentoo-based mobile devices. Seeing how it's my job now to implement a web-based, distributed (pushing) package management system, I don't think it will be very hard for me to implement a mobile (pulling / normal) graphical package manager.

There's another guy on the gentoo-embedded list from Portugal, named Ângelo (a.k.a. miknix), who is also aiming to do the same thing with the HTC Wizard (also a pretty sweet-looking handheld w/ integrated keyboard).

Anyway, if there are any Gentoo users out there who would like to download an i686-pc-linux-gnu -> armv4tl-softfloat-linux-gnueabi cross-toolchain suitable for OpenMoko cross-compilation, then check out my latest toolchain. Please don't forget to read the README file.

I guess the next cross toolchain I come up with will target the armv7a-c6x-linux-gnueabi BeagleBoard, which also happens to have Jazelle Technology (something I have wanted to experiment with for a while!).