Archive for December, 2005

The Linksys NSLU2

Thursday, December 29th, 2005

My Linksys NSLU2One of the things I got for Christmas this year was a Linksys NSLU2. It’s basically a device for attaching USB hard disks to for network attached storage (only accessible via SMB, aka Windows networking). So it’s basically a box with two USB 2.0 ports and a network interface. Not very interesting, eh? Well no, not until you realise that it runs Linux :-)

It’s actually quite easy to replace Linksys’ version of Linux with one that is accessible via SSH (a distro called OpenSlug) which makes it possible to install extra packages etc., then from there to get Debian (actually OpenDebianSlug) running on it!

So now I have a nice, silent Debian system. For some reason Linksys ship the device with the processor under-clocked, but it just requires a little targetted destruction to get it back to it’s original 266MHz. OK so that isn’t going to break any speed records, but it doesn’t mean that the device isn’t useful – far from it. People are using them for web servers, mail servers, Asterisk PBXs and iTunes servers. Should be fast enough for most simple tasks:

tiny:/home/user# cat /proc/cpuinfo
Processor : XScale-IXP42x Family rev 1 (v5b)
BogoMIPS : 263.78
Features : swp half thumb fastmult edsp
CPU implementer : 0×69
CPU architecture: 5TE
CPU variant : 0×0
CPU part : 0×41f
CPU revision : 1
Cache type : undefined 5
Cache clean : undefined 5
Cache lockdown : undefined 5
Cache format : Harvard
I size : 32768
I assoc : 32
I line length : 32
I sets : 32
D size : 32768
D assoc : 32
D line length : 32
D sets : 32

Hardware : Linksys NSLU2
Revision : 0000
Serial : 0000000000000000

So far I’ve installed an NFS server so I can actually use the device for network storage without having to mess with Samba. I’ve also bought a cheap USB webcam so I can experiment with having an Internet-connected webcam, possibly with streaming video. The possible uses for a silent Linux system with USB ports are almost endless…

Open Hardware

Wednesday, December 7th, 2005

One of the things I’m doing at Uni is digital systems design. This involves writing code in a hardware description language (Verilog in my case, which is like a cross between C and Pascal) which can then be burnt to an FPGA chip or sent away for fabrication onto a custom IC.

This is pretty cool because it allows someone like myself, who can succeed in screwing up anything they put a soldering iron near, to design and build hardware using source code.
A typical example is the following, which would be a very simple adder:

module adder (in1, in2, out);
input in1, in2;
output out;

assign out = in1 + in2;

endmodule

That simply declares two one-bit inputs and a one-bit output. It then specifies that the output should always be equal to in1 added to in2.
As hardware can be created with source code, this source code can of course be made free/open source. OpenCores is a site containing freely-licensed source code for hardware components, everything from ethernet controllers and hardware encryption devices to full microprocessors. Most seem to be licensed under the LGPL. The great thing is that people can go over to OpenCores and pick up ready-made, freely-usable modules which can be plugged into their projects. There’s quite possibly enough code on there for someone to build most of a computer in totally open hardware.

As if that wasn’t good enough, Sun have announced that they’re releasing the Verilog sources to their latest-and-greatest processor, the UltraSPARC T1. This code, when released, won’t actually be of much practical use to hobbyists looking to build open hardware though, since it is naturally HUGE and would require an FPGA costing upwards of £5k. FPGAs also aren’t terribly well-suited to such tasks: their main advantage is that they can be reprogrammed quickly (one minute you have a USB controller, next minute you have an encryption device) – they’re not designed for huge projects such as this. It would be possible for anyone to pick up the code and send it off for fabrication onto a real chip, but the costs (especially for a one-off or small batch) would be much more than buying a ready-made processor from Sun.
Where I think the real potential is is in the possibilities for people to take the code and build custom hardware with it. It would be possible for example to rip out many of the hardware instructions and build in MPEG encoding/decoding if you wanted a media device. The end-result would be a lot smaller, so the price of the required FPGA comes down drastically.

However what I think would be more useful is if Sun released the code for some of their older 32-bit or early 64-bit processors. These processors will naturally be much smaller and easier for hobbyists to handle. The fastest 32-bit processor they did I believe was 150MHz. That may not be useful for the average desktop system, but it would be very useful for people building embedded devices who can make it offer excellent performance for their specific task by extending the instruction set.

I don’t however understand quite why Sun have done this. There are not many people out there with sufficient skills to use the source code (in fact I believe there is a worldwide shortage of such people) so they aren’t going to get many (if any) third-parties contributing to the design of the processor. That said, there aren’t really many disadvantages in doing it: Intel and AMD aren’t going to learn very much, since SPARC is RISC and x86 is CISC. Also, it’s not as if there are many people in the world with sufficient resources to start mass-producing the processors on-the-cheap and undercuting Sun.
There’s an interesting blog entry which talks about some of the reasons behind it, which seem to centre around the idea that they’d like third-parties to be able to do interesting things and contribute to the design, but I’m not convinced these are the real reasons…

In any case it will certainly be very interesting to see what community projects spring up around this and whether it’ll prompt any more companies to think about opening their hardware (probably not, but you never know).

Edit: Since I posted this someone from Sun told me that 32-bit microSPARC code is already available, under their Community Source Licensing scheme. Why didn’t I hear about this before?!

Video editing impossible on Linux?

Saturday, December 3rd, 2005

I’ve recently realised that MythTV is getting very close to filling my 200GB drive, so I’ve decided that I need to burn some stuff to DVD. This seems straightforward, the problem is that I need to edit each file to chop the ads out (MythTV has ad-detection and the ability to transcode and cut them out, but it only ever detects ads where there aren’t any). I’ve looked at every video editing tool I can find and none of them seem to be capable of doing the very simple task of letting me select and delete a section of video from an MPEG file. Here’s what I’ve tried:

  • Cinelerra: over-complicated interface, but most importantly it crashed when I tried to select a section of video I wanted to delete. Useless.
  • Kino: can only open DV files which FFmpeg seemingly can’t convert to without screwing with the video size and aspect ratio.
  • LiVES: 64-bit compilation broken.
  • kfilm: 64-bit binary has broken dependencies (requires libraries that don’t exist) and running make causes it to unexpectedly download a copy of FFmpeg (!) which doesn’t compile in any case.
  • PiTiVi: latest stable release has a bug which stops it running and the CVS has a dependancy which requires a newer version of GStreamer than my distro has. I’m not upgrading my whole distribution to an unstable development version just so I can run a video editor – the stable version is unstable enough as it is. Compiling GStreamer from source requires manually compiling about 10 different packages, which is not reasonable.
  • OpenVIP: uses a non-standard compilation process which gives screen-fulls of unhelpful output seemingly without doing anything useful. Couldn’t make sense of it.
  • kdenlive: again, only seems to support DV which is no use to me. Compile was broken too – the bug concerned seems to be fixed in CVS (which doesn’t compile due to other problems) but I created a patch to fix it in case other people encounter it before there’s a new release (current is 0.2.4).
  • LVE: lots of silly compile-time requirements – must be in a particular directory, must have a copy of FFmpeg source in a specific place, etc. FFmpeg doesn’t compile in any case because of the options passed to it by LVE’s make file – gave up.

So that’s it – every video editing tool I could find, none of which could meet my very basic requirements.
Situations such as this are very depressing to say the least.

Finally fixed

Thursday, December 1st, 2005

I’ve finally taken the time to fix all the bugs my site has had since I first wrote it a year or so ago.
People with low screen resolutions will now find that the links on the index page now dynamically resize nicely instead of running into each other or going off the bottom of the screen.
I.E. users (you should be ashamed of yourselves) will be pleased to note that the sidebar no longer overlaps the navigation bar or header and is now displayed in the right place.
Konqueror users will note that the sidebar on the rest of the site (not the blog) now has links underlined like they should be so you can distinguish between text and links (that was/is a Konqueror bug, but I’ve worked around it).
Users of all browsers should be pleased to see that words on the blog are now spaced out properly, instead of occasionally being displayed with no space between them.

I’ve also changed all the main site URLs. Before they were index.php?pagename=whatever, now they’re index.php?p=whatever. I don’t know why I decided to make life more tedious by using pagename in the first place. Redirects are in place, but if you do have any links to my site anywhere please update them.

I’ve also moved the site from HTML to XHTML and if you’re using a decent browser (i.e. not I.E.) it’s being served with an application/xhtml+xml MIME type. The blog isn’t however, as Wordpress is doing silly things and not generating standards compliant code (which I can’t fix) so it’s still served as text/html to stop errors being shown.
I.E. flatly refused to play nicely with any of the several possible XHTML MIME types and just displayed the raw XML instead of the pages, so it is being served text/html

Also lots of changes behind the scenes to clean-up my code and make things more efficient, so some parts of the site (especially the photo album, which I literially hacked together with a few copy-and-pastes from another project I was working on) should now load quicker. There have been a few minor content updates, but not many.

I’m going to be really silly and proclaim that I’ve actually fixed ALL the bugs the site had and that it is now displaying perfectly in every browser. I’m sure I’ll regret that ;-)
If you do notice ANY bugs, especially broken or outdated links (pagename= instead of p=) or if your browser prompts you to download pages on the main site instead of displaying them, please let me know ASAP.