Hardware Reference
In-Depth Information
If you are using the Slug as the basis for a much larger home automation server, then this provides greater scope
in the upgrade path, because it gives you access to the many thousands of packages provided by the OpenEmbedded
project on which SlugOS is based. But doing so requires that you devote some, or all, of one of your connected hard
drives to the operating system, which is a process that requires you to install a small system into the flash memory and
then bootstrap the operating system onto the hard drive. In doing so, SlugOS permits the use of a 2.6-based kernel as
well as RAID and NFS functionality.
When using an external USB drive to hold the operating system, always use a hard drive (as opposed to a memory
stick). This is because some applications (such as MySQL) create a lot of memory writes to the swap file, and because
flash memory becomes unusable after about 100,000 writes, this can happen sooner rather than later. You could,
alternatively, assign the swap file to a second (hard) drive, allowing the operating system to boot and run from
a read-only memory stick.
Developing on the Slug
To write your own software for the Slug, you should start with SlugOS because this gives you access to the standard
development tools, which run on the device allowing the code to be written, compiled, and tested on the Slug.
This is known as
native development
. First you need to run the following command, along with the other standard
build packages (all detailed at
www.nslu2-linux.org/wiki/HowTo/SlugOSNativeCompileEnvironment
), before
developing your code as normal:
ipkg install slugos-native
Without a screen, however, you will not be able to use GUI debuggers such as
kdbg
, which can be a scary downgrade
for some. It is perfectly possible to run the machine headless, however, as you can connect remotely through
ssh
or
telnet
. This is preferable because the speed of the machine makes a GUI approach impractical for large applications.
You would more likely write and test your application for your desktop machine and then, when it's ready, cross-compile
for the Slug.
Cross compilation
is a process whereby a compiler running on machine A is able to produce code suitable
for machine B. To do this, you need a new set of compilers, tools, headers, and libraries (known together as
the
toolchain
) that are built purposely for the other architecture. These are stored separate from your existing
development files since they would otherwise conflict with those running your machine. The compilation process
then occurs as normal (through either
make
or a variant of
gcc
, such as
armeb-linux-gnu-gcc
) to produce a suitable
executable file, or
elf
in Linux parlance.
The best introduction for the installation of these tools is at
www.nslu2-linux.org/wiki/DebianSlug/CrossCompiling
.
Note that if you're using only existing packages, compilation tools are not necessary in any form, and you can rely
solely on the prebuilt packages.
Hacking Game Consoles
Game consoles are great for playing games. Old game console are great for playing old games—and hacking into
Linux machines! As the previous generation of machines becomes cheap and technologically obsolete, old game
consoles provide a good embedded platform for media players, web servers, control units, and the like because they
always have suitable connectors for a TV and look natural in the living room. In this section, you will learn how these
machines can be bent to your will, rather than specific uses for them.
It is not smooth sailing, alas, because the manufacturers do not make the compilers or development
environments available to anyone outside the computer games industry, and even then it is only with strict
nondisclosure agreements (NDAs).
1
Although this should be enough to satisfy an overzealous legal department,
!N
.$!ISALEGALDOCUMENTFORMEDBYCOMPANIESTOPREVENTYOUFROMTALKINGABOUTTHEIRTECHNOLOGYORIDEASWITHANYONEELSE
Search WWH ::
Custom Search