Regular reader [MS3FGX] recently wrote a guide to compiling OpenWRT from source. You may be wondering why directions for compiling an open source program warrant this kind of attention. The size and scope of the package make it difficult to traverse the options available to you at each point in the process, but [MS3FGX] adds clarity by discussion as much as possible along the way.

OpenWRT is an open source alternative firmware package that runs on may routers. It started as a way to unlock the potential of the Linksys WRT54G. But the versatility of the user interface, and the accessibility of the Linux kernel made it a must-have for any router. This is part of what has complicated the build process. There are many different architectures supported and you’ve got to configure the package to build for your specific hardware (or risk a bad firmware flash!).

You’ll need some hefty hardware to ease the processing time. The source package is about 300 MB but after compilation the disk usage will reach into the Gigabyte range. [MS3FGX] used a 6-core processor for compilation and it still took over 20 minutes for a bare-bones distribution. No wonder pre-built binaries are the only thing we’ve ever tried. But this is a good way to introduce yourself to the inner workings of the package and might make for a frustrating fun weekend project.

Ah, the beauty of spreading the guts of some hackable hardware across your workbench. This happens to be the circuit board and LCD screen from a Parrot DF3120 digital picture frame. The device is pretty powerful, considering you can still find them available for around $25. You’ll get a 3.5″ screen, ARM9 processor with 8MB or RAM, Bluetooth, a tilt sensor, and more. It seem that [BusError], [Sprite_tm], [Claude], and few others really went to town and spilled all of the secrets this device has to offer.

Their goal of the hack was to get their own Linux kernel running. It is possible to reprogram the processor using its JTAG interface. And if you really want to drill down to the good stuff, there’s access to all of the BGA pins on the bottom of the board thanks to a grid of micro vias. But the device can be tricked into flashing your own firmware just by altering a stock upgrade image.

You can get a pretty good idea of what there is to do once you’ve replaced the firmware from the video after the break. A RAM upgrade (using a chip from an old PC133 stick) lets the video run smoothly as it’s controlled via a Wii remote.

[Thanks Dans34]

[Ricard Dias] wrote in to tell us about his guide for developing Linux applications on a Mac. He really enjoys the development environment provided by XCode, and it doesn’t take much to make it work as an all-in-one solution for Linux development.

The real trick here is the use of SSH to access a Linux environment. In this example he uses Ubuntu running as a virtual machine, but also mentions that the same thing can be done just as easily with a separate box as long as it is on the same network as the Mac. SSHFS (the SSH Filesystem) lets him mount the development directory on the Linux box locally. This is where the XCode project and files will be stored, but building the program will be done by the Linux machine via a script calling the make comand via SSH. To test out the newly built program, [L] tunnels in using X11 forwarding for ssh, and the application will be shown as a window in OSX, even though it is running on the Ubuntu machine.

We love SSH and use it all the time. It’s amazing how hand it can be.

[Chris'] family made the mistake of giving him a hackable Christmas gift. We’d bet they didn’t see much of him for the rest of the day as he set about rooting this Android wristwatch.

This thing has some pretty powerful hardware under the hood. It’s sporting an OMAP3 processor running at 600 MHz along with 256 MB of RAM. [Chris] needed to get his hands on a firmware image in order to look for security holes. He found a way to spoof the update application in order to intercept an upgrade image from the Internet.

He dumped the firmware locations and got to work searching for a way to exploit the device. Details are a bit scarce about want exactly he did, but you can download his modified image, letting you root your own Motorola Actv using the Android Debug Bridge.

We’ve embedded a demo video after the break. The OS is pretty snappy on the tiny device. We’re not sure what will come of this functionality, but we assume [Chris] was really only interested in the challenge of rooting process itself.

This LED lamp, which uses a soda cup as a lampshade, is Internet enabled thanks to a Linux board (translated). To say the system is overpowered would be a gross understatement. But at least there’s plenty of room for growth.

The lamp is really just a hardware extension for the Linux board. A half-dozen colored LEDs are driven by an ATmega8 and a few transistors. A Fox LX832 board pushes color instructions to the microcontroller via the i2c protocol. [Gibus] chose this board because it has a built-in Ethernet port which makes it perfect for communicating via a smart phone browser. This is where the majority of the work on the project happened. He coded a Flash application that lets you select color, hue, and saturation data from any device that doesn’t run iOS. These commands are processed by a C application running on the Linux board. See a demo of the web app, and the resulting color changes in the clip after the break.

[Andrew] was getting ready to print out an assignment when his Samsung printer suddenly started blinking a red error light at him. Unable to find any documentation explaining the issue, he called Samsung directly and found that it was indicating the toner cartridge was nearly empty.

He held down the button that prints a test page, which came out just fine despite the printer’s insistence that there was not enough toner left. Annoyed at the fact that he felt Samsung was trying to strong arm him into buying another pricey toner cartridge, he looked for a way around the restriction.

He discovered that his printer’s software allowed him to specify a custom test page document, though it required that the document be in PostScript format. After a few shell commands, he had his document converted and was on to bigger and better things.

While a bit time consuming, his workaround should let him get by on this toner cartridge at least for a little while longer. We imagine that since he’s using Linux, the process could probably be scripted to save time, though we’re not sure if the same can be said for Windows-based PCs.

Yes, the Kinect is over one year old now, and after some initial unhappiness from [Microsoft], it’s become a hacker’s best friend. [Eric] decided to celebrate this with an Article all about how it works.  If you’re new to this piece of hardware and want to get into working with it, this should be a good hacking introduction.  If you’ve been reading [HAD] lately, you will have noticed this information being used to “build a Kinect bot for 500 bones.”

Some interesting facts in this article include that the Kinect measures 307200 distance point, known as a “point cloud” in the gaming area. From this, it’s able to construct a 3D image of the environment around it and allow interaction. Such interesting hardware didn’t take long to hack after Adafruit announced a $3000.00 bounty to open it up to the masses.  This only took four days to do, making one wonder why, with their incredible resources, [Microsoft] wouldn’t either more effectively lock it down or officially open it to be hacked and modified to begin with. Our vote would be to officially open it up, but no one consulted us on the decision.

While watching his thin client boot up [Nav] noticed that it’s using some type of Linux kernel. He wondered if it were possible to run a full-blow desktop distribution on the device. A little poking around he got a Debian desktop distribution running on a thin client.

The hardware he’s working with is an HP t5325. It’s meant to be a dumb client, connecting to a backend machine like a Windows Terminal Server or via SSH. But it’s got a 1.2 GHz ARM processor and [Nav's] preliminary investigations revealed the it’s running a version of Debian for ARM. He used CTRL-C during the boot sequence to derail that process and dump him to a shell. The login was easy enough to guess as the username and password are both ‘root’.

Once he’s got that root access it was slash and burn time. He got rid of the HP-specific setup and made way for additional Debian modules like the apt system. This isn’t trivial, but he’s worked out a bunch of sticking points which makes the process easier. With the repository tools loaded you can install Xserver and Gnome for a full-blown desktop on the embedded hardware.

Some hard work has gone into making it possible to develop for the STM32 Discovery board using a Linux system. The board boasts an ARM Cortex-M3 processor, which can be programmed via the mini-USB port on the side. But the company only supports development through their IDE’s which don’t run natively on Linux. The stlink project aims to solve this, providing a toolchain, and making it possible to flash the microcontroller via the USB connection.

The github project linked above also includes a tutorial to get you started (pdf). In addition to a walk through on compiling the software packages, it includes a simple blink program that you can use to test out your hardware. GDB, the familiar open-source debugger, is used to flash the chip. This is a bare-bones tutorial so if you end up posting about your experiences using this toolchain with the Discovery boards we’d love to hear about it.

[Thanks Texane]

The Chumby One comes in a nice little case and features an ARM powered board with a touchscreen interface. [Bobby] thought is was a good starting point, but wanted a more portable version to use as a wireless file transfer device for photography. WFT is a connectivity enhancement for digital cameras that allows pictures to be pushed to other devices over a wireless network.

In order to improve the portability of the hardware [Bobby] ditched the power-hungry WiFi adapter that comes with the device. The newer and more efficient USB dongle that he’s using as a replacement makes switching to a rechargeable camera battery a viable option. With the battery and dongle soldered to the board he ditched the rest of the hardware (save the touchscreen) and began work on his own enclosure. You can see the version above is just a little rough around the edges, he cut it by hand from the Google Sketchup design. But since he plans to make a few more copies of this hardware for friends he will probably use a service to laser cut those cases for him.

The new hardware needs drivers, and [Bobby] has lots of instructions on how to compile your own. This includes setting up the toolchain, compiling the kernel, as well as building the drivers themselves.

When [Bunny] moved into his apartment in Singapore he was surprised to find that a huge building project was just getting started on the other side of the block. Being the curious sort, he was always interested in what was going on, but just looking in on the project occasionally wasn’t enough. Instead, he set up a camera and made a time-lapse video.

This isn’t hard, you can find a slew of intervalometer projects which we’ve covered over the years. But being that [Bunnie] is one of the designers of the Chumby One, and frequently performs hacks on the hardware, it’s no surprise that he chose to use that hardware for the project.

Luckily, he’s sharing the steps he used to get Chumby capturing images. He mentions the hardest part is finding a compatible USB camera. If you have one that works with a 2008 Linux kernel you should be fine. The rest is done with shell scripts. Mplayer captures the images when the script is called from a cron job. Once all the frames are captured, he used mencoder to stitch the JPEGs into a movie. See the result after the break.

In part one I showed you that you could install a linux distro on a new computer and transplant it into a 386 computer in a short amount of time and with little effort. Now it is time to move on to bigger and beefier machines like 486′s, Pentiums and better.

I am going to break this quick tutorial down into sections based on installed RAM. While this won’t be a “how to” for all old PCs in the world I hope to at least send you in the right direction. I will mention a few distributions mainly for the super low ram machines. Its not my intent to start a distrubution war, and I have not personally sat down with every single one to make a educated assessment. However, you’re more than welcome to chime in.

Join us after the break and see what options you have for that old “boat anchor” sitting in the closet!

Less than 16 megs of ram:

This is where my second laptop comes in. It is an old first run Pentium running at 90Mhz with 8 megs of ram. On machines with <16 megs of ram there is not much choice out there.

Much like the 386 install, you can use an older distribution, but you do have a couple of other options. One is DSL linux, which is no longer being supported outside of its community. Another is Deli linux, which is also not supported anymore, but has a fork called DeLicate. Since DeLicate does not have an installer, you need to install DeLicate 8 first and then upgrade through the package manager.

DeLicate and its fork have 2.4 kernels, which is still pretty new for modern applications. It will boot on 4 meg machines and if you fiddle with swap space you can even install it directly on your target hardware.

Since my old laptop does not have a CD ROM drive or a functioning floppy disk I put the hard disk in my desktop computer and booted the installer from a CD. With only 8 megs of ram I can get Xwindows up and running ok, but any activity and the system turns into a swap zombie.

(after about a half an hour here is gnumeric)

netBSD should work with 8 megs of ram, though every time I have tried this, it locks at boot on the target machine.

16 to 32 megs of ram:

Same as above, except you’re going to have a much better time running Xwindows and a windows manager. Again, you can either run an older mainstream distribution that will boot or you can run deli.

The BSD’s of the world should work fine on these machines as well, if you want the newest possible software.

The Heavyweights, 48 megs of ram or more:

If your machine has 48 megs of ram or more you have it pretty easy. Almost all distributions will boot and run without problem from this point on. Which distribution you choose totally depends on the power of your machine. For example, a lightweight ubuntu remix should run well on a Pentium 3, but you might not want to run that on your Pentium MMX.

Some of the standard distributions that I have had good luck with in the past include: Debian, Slackware, Tiny Core, gentoo, puppy and a million more. If you want a distribution that comes off of the cd with modern useful apps already installed, you might want to look at connochaetos or slitaz, which will function well in 80MB or 128MB of ram.

Most distros still allow hard disk installs and network installs if you can not boot from floppy or CD ROM.  In the worst case you just pop your target drive into a more modern machine and install from a cd or usb stick.

I hope this helps your old machines find a second wind. We would love to see them. If you have dusted off an old boat anchor and got linux running on it, please share it with us in the fourms!

Thanks for reading and happy retro computing.

The “cheap” and “easy” way in about an hour! A question that pop’s up from time to time is “I somehow ended up with an archaic old laptop / computer, can it run Linux?” Well of course it can, but that totally depends! On what? Well machine CPU, CPU speed, hard disk space, RAM and most importantly what you are expecting it to do.

Okay, why a Intel 386? Well number one I own a 386, but more importantly its the absolute bottom Intel CPU you can run Linux on. While it wont be able to do much, it will give you a basic system to kick around and “get to know” the insides of Linux without a million things installed and the worry of breaking it.

Unfortunately a 386 requires some special moves as the actual chip was dropped from almost all distributions long ago. All of the modern distributions I have looked at require at least a 486 CPU. This tutorial will be strictly for installing a basic bare bones Linux on a 386. Have a 486? Pentium? Faster? Never fear I will be covering that in a part II later this week.

Linux on a 386 in about an hour? Madness you might think, it probably takes Linux longer to boot on a 386 (and in some cases you are correct)! Want to know the trick? Simple, cheat!

Join me after the break for the parts and steps needed to get you started.

First we need a target machine, here is mine. It is a DEC PC325SL, which translates out to intel386SL (which is a 386SX CPU in a highly integrated package where much of the support hardware is also inside the chip) running at 25Mhz with 4MB of ram and 120MB of hard disk space. It also has 256K video memory and 640×480 color VGA display. If you can swing it, a 386DX CPU or a 386S(X/L) with a 387 math co-processor is recommended, no it doesn’t really matter if its an Intel, AMD, etc. It also needs an IDE disk up to 2G, sorry MFM drives.

Next we need a distribution that will actually work with a 386 CPU. This is where it gets to be confusing. Everyone still has a distribution called i386, but support for the 386 was dropped a while ago. I looked at some of my favorites, Debian, Slackware, FreeBSD, and NetBSD (which I know are not Linux but hey.) Here is what I found out:

Debian stopped support with 3 so anything earlier is ok.

Slackware stopped around the same time in release 9.

FreeBSD states that it requires a 386DX, but then says most 386 laptops are ok via math emulation, but in a more current readme it states that you need a 486 (confused?)

NetBSD says it should work on all 386′s but I never made it that far.

Well of course I am not a super Linux guru, and can really only futz around without running off to a forum or a book, so I went with Debian. Originally version 2.2 as it was the newest version that machine could run, and yes in fact it did. The problem is it took over an hour to boot with a year 2000 generic kernel and when it finally did it refused to move past the package installer.

You could spend a lot of time trimming and optimizing to get it running great, but I am facing a brutal truth here, and that is the best I could run is still over a decade out of date and its going to require a lot of work. So I just simply stepped back in time a bit further to find something a bit more appropriate.

In the end I used Debian 1.3.1, which is a mid 1990′s Linux, and that’s really the point. Use whatever you like but its going to have to be pretty old or require a ton of work, which at that point you might be better off doing it from scratch.

Tools for the cheat install:

x86 compatible Host PC with an IDE/ATA port, and a standard BIOS capable of booting into DOS. I used my dual core AMD A2X2 with a nvidia chip-set so its pretty safe to say most PC’s will. It also needs an Internet connection and some form of Linux installed or booted (I use mint)

CD ROM or USB stick you can boot from with a windows 98 emergency boot disk (EBD from here on), or since MS DOS does not know how to access USB or SATA CD ROM’s, I used a old IDE drive with a 100Mb FAT16 partition on it.

IDE to 3.5 IDE pin adapter, they are cheap and handy I suggest you have one, just make sure you plug it in correctly you can kill your drive (as in magic smoke kill).

That should do it, lets get started

Step One:

Turn off your Host PC, plug in a spare IDE hard disk set as slave. To keep my self from borking my computers main drive I went ahead and unplugged it from the SATA port. Check BIOS to make sure its detected and that you are booting from your CD drive first, Insert the Windows EBD save changes and let the computer boot from the EBD.

You will see a Windows boot disk menu, choose to “start without cd rom support”. Once at the DOS prompt use FDISK to setup a 100 or so meg partition, be sure to tell FDISK no when it asks you if you want large disk support to ensure a FAT16 partition.

Exit FDISK, reboot with the EBD and use FORMAT C: (make sure that is the correct drive if you have others plugged into the system), then Eject the EBD. In my case I then plugged my SATA hard drive back in and set BIOS to boot from that disk and went on into Linux Mint, though you could leave your main drive unattached and use a live CD Linux.

I know that linux can make a FAT16 partition. I was having trouble with the EBD reading it while figuring this all out, so I just started making the partition with the OS that really needs it most.

Step Two:

Boot your Host PC into Linux, I am using (again) Linux Mint but It does not matter, it just has to be able to get on line, and mount a FAT16 partition. Point your web browser to the Debian archive and goto the following folder Debian-1.3.1/main/disks-i386/1997-10-13/

Download the following files

base1_3.tgz

resc1440.bin

drv1440.bin

linux

loadlin.exe

root.bin

and copy them to your FAT16 partition.

Optional Step:

My 386 came with 120 meg disk, That might be large enough to squeeze a basic Linux system on, but I also wanted a little room for a MS DOS partition so I upgraded to a 540 meg hard drive. Of course 386′s and other <1994 machines have a bios limitation of 1024 cylinders limiting the drive to 500 megs. This computer is even more picky limiting my choices down to 2 DEC approved drives, the 120 meg or a 240 meg (probably sold as an option). In order to use this drive so that both DOS and Linux can live happily on it, I must use a drive overlay (ick). So far I have been avoiding the use of floppies, but I do have floppies, and the drive on the machine works fine.

I found a old copy of Western Digital EZ Drive 9.03, I also used a MS-DOS6.22 boot floppy image. EZ drive is simple but even if you do not want a DOS partition, you HAVE to have one or else EZ drive will scream “no boot partition” and halt. So make at least 1 MSDOS partition at the start of the drive, even if its only a megabyte in size.

Step 3:

Remove the hard disk from the 386 and attach it to your host PC, it should be MASTER on Channel 0 and the drive with the FAT16 partition we put the install files on. should be the SLAVE on Channel 0. Enter your PC bios and find your 386′s drive, and be sure to turn off LBA. If you are using a drive overlay set your bios where it boots from the 386 drive first.

Reboot the Host PC (I disconnected my main drive for now as well), if you are using a drive overlay let it boot the hard disk first, then tell the overlay to boot from drive A, insert your Windows EBD into your CD drive and it will eventually load. If you are not using an overlay just boot from the Windows EBD. When you come up to the EBD boot menu use the arrow keys to stop the timer, then hold SHIFT and press F5 which will just dump you directly to a command prompt.

Find the drive with the linux install files on it and run:

loadlin linux root=/dev/ram initrd=root.bin

The debian installer should fire right up, follow the menus until you come to the disk partitioner. Create 2 partitions, 1 as type 82 (linux swap) at about 16-32 megs big, and the other should be set up as you like as your space. I just used the remainder of the disk and it defaulted to a linux type. Write the changes and continue on with the installer. Also be sure to use the right disk, it should be /dev/hda

The installer should continue and eventually ask you to install lilo, which is fine on the MBR, then reboot. Remove any disks still left in the Host PC and Debian should start. Now you have to go though another round of configuration questions. Eventually you will get to the dselect package manager (which I hate). Once you figure out how to exit dselect you should still be root. Type in halt and the system should start shutting down, if you are logged into your user account you need to use su and enter the root password first to halt the machine.

Step 4:

Once everything is down, remove your 386 drive from the Host PC and place it back into the 386, with a little luck it should start up just fine. Though there is nothing but the bare basics installed, there is still a ton of stuff to check out and poke around through. Outside of reading this and getting everything prepared it should take about an hour.

Getting software packages into the machine, right now I am just downloading the deb files from the Debian archive on my mac and coping them over via floppy disks. Another option would be to use minicom and a null modem cable. If you are really lucky you can get networking going. I downloaded the entire binary-i386 folder for Debian 1.3.1 and its about 400MB, and while I am not trying to load the machine up, some things like a menu driven text editor (fte) and mouse support are nice.

Have fun and be sure to tune in for part II which involves my 8MB Pentium 90 laptop for linux after 386, you might find it surprising.

[Tiakson] just wrapped up the construction of a quadcopter which piqued our interest due to the unexpected mix of hardware he used.

A good portion of the copter is made up of the essential bits we have come to expect from a quad rotor system. Instead of using an Xbee or hobby wireless controller however, [Tiakson] opted to use an old Fonera router running OpenWRT to control the system. He wrote special software that allows him to direct the quadcopter using an HTML 5 interface, adding a few kernel tweaks along the way that enabled him to emulate I2C ports over GPIO pins.

The Fonera takes in data from Wii nunchuck and Motion+ sensors, relaying commands to the on-board PIC 16F976 microcontroller. The PIC is used to manage the electronic speed controller modules using PWM, which the Fonera could not handle on its own.

This is a great use for a old router, and the cost is obviously far cheaper than buying off the shelf wireless control modules. We would love to hear how much extra weight the Fonera adds, as well as if there is any controller lag introduced by the web-based interface.

Continue reading to see a quick demo video of the quadcopter in action.

[Nathan] had an small router kicking around and thought that he might as well put it to good use. He had always been interested in getting a better handle on his espresso machine, and figured that the router would be a perfect Linux-based PID controller.

He installed OpenWRT on the router, then disassembled it in order to get access to the router’s GPIO pins. He built a small PCB that allows him to get temperature info from the machine to the router using i2c. [Nathan] put together a PID package for OpenWRT, allowing him to control the machine over SSH, though he may build in a user-friendly web interface sometime in the future.

He says that most espresso machine PID controllers he has seen come in the form of big ugly boxes slapped on the side of the machine’s case, though we have to disagree with him on that point. Opinions aside, he is going for a minimalist design, and while he says that he is only about half way through the project, we think things are looking promising so far.

When everything is said and done, we hope to get a much closer look at all of his code, schematics, and more information on the router he used as well.