SliTaz Linux and the eBox-3300
(Last updated 2 Feb 2012)


I was looking for a small embedded Linux to host on an eBox-3300 PC.  This is the story of my adventures with SliTaz Linux and this tiny PC.


SliTaz Linux
I chose SliTaz 3.0 Linux (www.slitaz.org) after looking through the most recommended offerings on the web.  My platform is quite limited (933 MHz Vortex x86 CPU, 256 MB RAM, 2 GB compact flash card as ATA drive), so I needed something very small, and they don't get much smaller than SliTaz.  The shipped version includes Xort/Xvesa with the OpenBox desktop, Midori (WebKit) web browser, lighttpd web server, Dropbear SSH client and server, SQLite, and a bunch of other stuff, all in an ISO image of about 30 MB (expands to about 100 MB).  SliTaz will boot from a USB drive and includes a simple utility for setting up any boot device (not just a USB drive).

SliTaz offers a number of options at the boot prompt; the default off the ISO image boots into a 1024x768x24 (if I remember correctly, I've changed this since initial install) screen running X.  You will be prompted to select a language and a keymap during the boot process, but you can later add "kmap=us lang=en" to the kernel line in /boot/grub/menu.lst to automate these selections, letting you do an unattended boot.

SliTaz' package installer, available from the taskbar at the bottom right or from the system icon at the bottom left of the taskbar, works pretty well.  This GUI app lets you search for available packages by name or description, and installation of the package and all depenedencies is straightfoward, at least for the few I tested.  There is also a command-line installer, Tazpkg, which works if you know what commands to use for the installation.

By default, SliTaz offers the Firefox web browser.  However, FF is a real pig on RAM (if you only have 256 MB, and that's all I have) and wouldn't run more than a few seconds without crashing out.  I should add that the crash was very clean and the SliTaz desktop worked perfectly afterwards, but a crash is still a crash.

My solution was to install Midori, a very small footprint browser built on the WebKit platform.  Installing Midori involved running the package installer and selecting Midori by name for installation.  However, the default install of Midori has all extensions enabled.  This caused two issues.  First, it took several seconds (10+) to load Midori, which is still WAY better than the load time for FF.  Second, Midori still crashed after a few minutes of browsing.  After such a crash, I entered the "free" command in an Xterm window and saw that the system had about 35 MB of free RAM, which evidently is not enough.

The next time I started Midori, it presented a dialog explaining that the previous run had ended badly and offered me the chance to turn off all extensions, which I did.  This time the load took only about a second or so.  I opened Midori's extensions panel and saw that all of the available extensions had been deselected and greyed out.  This light version of Midori has not crashed after days of use.

I also wanted to play around with Python, so I went back to the SliTaz package installer and installed Python 2.5.1.  (Note that you can also install Python 3.0 if you choose.)  After the install, I could open an Xterm window and type "python" at the prompt to run the interpreter.  I also right-clicked on the desktop, selected Desktop Files & Icons/Add new icon, chose python from the dialog box, and clicked Add.  This put an icon on my desktop for launching Python.

By default, SliTaz shows a scrolling CPU usage meter at the bottom right of the taskbar.  I check this a lot, because this box is not the fastest PC to run anything on and SliTaz would sometimes appear to be frozen.  A glance at the usage meter would show the CPU was maxed out, which meant SliTaz was really busy.  When the usage dropped below 100%, SliTaz always came back.  If the usage is maxed, just wait a bit; SliTaz will get back to you.


eBox-3300
This is a really cute, little (and I mean "little") PC.  The well-built, all metal enclosure measures 4.5" by 4.5" by 1.5" excluding connectors, draws no more than 10W from a 5VDC-only power supply, and will bolt directly to the back of most LCD monitors, using the wall-mount bracket mounting holes.

The eBox comes in several flavors, depending on the type and amount of memory, I/O ports, and drive options.  The version I used has 256 MB RAM (unexpandable), two RS-232 ports, Compact Flash (CF) slot, microSD slot, three USB connectors (two on front), Ethernet, and a sound system.

Here are the obligatory pics:

Rear panel of the eBox-3300

Here is the rear panel of the eBox-3300, showing the connectors available.  The spacing is a bit tight, especially if your VGA cable has a fat connector on the end.

Front panel of the eBox-3300

Here is the front of the eBox-3300, showing the two USB connectors and the CF slot; the microSD card fits into a tiny slot immediately below the large CF slot.  On the PCB, visible inside the CF slot to the right, is a tiny switch that lets you select secondary master or slave for the CF card, useful if you want to boot from the card or use it as a slave drive.

The eBox-3300 in use

Here is the eBox-3300 running SliTaz.  The large blob of white tape on the front of the eBox-3300 is a piece of tape I use as a handle so I can remove the CF card if needed.

The eBox-3300 is popular among some in the robotics community, who can run light Linux distros on it yet still control speciality I/O.  One group in particular with a lot of good eBox-3300 info is www.robosavvy.com; in particular, check this link: http://robosavvy.com/forum/viewforum.php?f=17.  Note that the eBox variant they use has a lot of I/O added, but some of the more general issues you will likely hit with any eBox-3300 have already been addressed by this group.

For example, I was trying to resolve an issue between SliTaz and the eBox regarding booting from USB.  While thrashing, I went into the eBox BIOS and switched off USB Legacy support.  All reboot attempts from that point on failed, even if there was no USB boot device available.  Worse, I could no longer enter the BIOS!  What's up with that??  I even plugged a P/S2 keyboard into the back connector, rather than use a USB keyboard; no joy.  And no key sequence I tried restored my access to the BIOS.

I sent an email request to DMP, the company that makes the eBox-3300, describing my issue.  They replied that I should take the box back to the distributor; yeah, right.  Thankfully, I had continued my web search and found the answer on the robosavvy site.  The magic trick is to hold down the End key while you power up the eBox-3300.  This resets at least some of the BIOS settings, including the USB Legacy support flag.  I sent the DMP customer service expert an email explaining how you can recover from this condition but I haven't heard anything back yet.  :-)


Putting it together
I started out with an ISO CDROM of the SliTaz install.  I booted this as a live CD in a large desktop PC.  I had a SanDisk 4GB USB drive in the PC and used the SliTaz LiveUSB tool, available from the system icon in the bottom left on the taskbar, to install SliTaz on the USB drive.

I then put the USB drive in the eBox-3300, hooked up a display, USB mouse, P/S2 keyboard, and power supply, then fired the mother up.  The first problem I hit involved the eBox-3300 boot sequence and boot devices.

My eBox-3300 came with a "Disk on Module" (DOM) board mounted inside.  This is a tiny PCB with a 512 MB flash drive, plugged into the eBox' internal 2.5" IDE connector.  This flash drive was constantly interfering with my boot sequence, partly because the eBox kept trying to boot from it (there was no bootable image on it) and partly because SliTaz would stumble over identifiying this device if I was able to boot from the USB drive.  I finally opened up the eBox-3300 and removed the DOM board.

The next issue with the eBox-3300 came up whenever I changed ANY device it could conceivably boot from.  Plug in a USB flash drive, the boot order got messed up.  Plug in a CF card, the boot order got messed up.  At one point, it tried booting from a non-existent device, and one time all of the boot devices had been disabled.  I have not yet figured out the pattern, but the simplest approach seems to be to get the boot sequence the way you like it, then NEVER CHANGE ANYTHING!

The next issue involved booting from a USB drive specifically.  Posts on the web indicate known issues with the eBox' ability to boot from USB devices in HiSpeed (60 MB/s).  The recommendation was to use the BIOS setting to set the USB 2.0 Controller Mode to FullSpeed (1.2 MB/s).  I tried this, but the boot times from USB flash drive were glacial.  Time to move to booting from CF.

I booted one last time from USB flash drive, this time with a SanDisk 2 GB CF card in the slot (and yes, I had to dork around with the boot sequence AGAIN, even though I was booting from the same device).  I used the SliTaz Installer (from the SliTaz system icon) to install the OS on /dev/hdc1; /dev/hda is the USB flash drive.  After the installation finished, I shutdown the eBox, pulled the USB flash drive, powered up the eBox, reconfigured the boot devices again, and booted into SliTaz.  The SliTaz boot log showed a boot time of 9 seconds.  From power on to login prompt is actually about 25 seconds, which is still not shabby.

I used a SanDisk CF card for this project, just like I use anytime I want to boot an embedded PC.  I have tried other brands, such as Transcend and Kingston, and always had problems.  I don't know the details under the hood, but if a CF card will work, SanDisk always works.  However, in places where a SanDisk works, other brands often fail.  Yes, the SanDisk cards cost more, but to me, the reliablilty is worth the extra money.

If you boot your system from a USB drive, remember that SliTaz loads the root file system image into RAM and runs from there.  This has two consequences.  First, you are going to use up a lot more RAM than if you run from a device that appears to be IDE, such as a CF card.  Second, if you make changes to the system, such as installing Python or editing a text file, those changes will NOT be saved to the root file system image unless you specifically force the change.  This means that the next time you reboot, your changes or installs will be gone.

To update your root file system image on the USB drive, use the Logout option on the system icon.  When booted from a USB drive, the logout dialog box will include an option to save changes to the file system.  Check this box, then proceed with the reboot or shutdown.  You will see a screen pop up with options for the save; I answered No in both cases.  The system will then spend quite a lot of time (as in minutes) creating and saving the new root file system image before finally shutting down.  This time, when you reboot, your changes will be in place.

I did run into one quirk with the eBox-3300 regarding keyboards.  For some reason, I could not get a USB mouse and USB keyboard to work properly together; the mouse would work fine but the keyboard would fail to work properly after booting to the desktop.  I don't know if this was a USB driver issue within SliTaz or some issue inside the eBox hardware/BIOS.  The workaround was to dig out one of those green USB-to-P/S2 adapter plugs from my junkbox, plug that into the P/S2 keyboard port on the back of the eBox-3300, then plug the USB keyboard into that.  Works like a champ.


Conclusion
This is a very nice combination of useability and low current draw.  There is a lot I like about the SliTaz distro, including its excellent package installer and the dev team's focus on small, fast, lightweight apps.  And despite its BIOS idiosyncracies, the eBox-3300 is a great little PC.  If you need a small embedded system for work or play, I would certainly recommend this pair.


 


Home