If you're playing with the idea of getting into embedded linux, you might start with the most basic question:  what does embedded Linux mean?  In the not so distant past that was a little easier to define.  An embedded board was typically physically smaller or at least used a very custom layout, used a low power processor or microcontroller and had limited computing resources like memory or storage.  Custom layouts mean that it would cost oodles of money to build each board, so getting your hands on one was an expensive proposition left to companies with very specific intentions.  The radar boards we make where I work are like that.  Very expensive for each board.

That's changed a lot recently.  Many ARM chips have plenty of horsepower and boards can have up to a GIG of memory or more using technologies like PoP (Package on Package) for mounting chips on top of each other.  You can even get quad-core ARM processors on tiny little boards with USB, wired network and hdmi output.  General purpose systems unlike a general purpose desktop, yet very similar too.  Cool stuff.

So how do you define embedded Linux?  Well, the trick these days is probably asking yourself if you have to cross compile software for your target platform.  If you can compile a Linux kernel on the board and it doesn't take a full day to complete, then it's not exactly embedded.  It's essentially a desktop.  But then if you compile on the board and all it has is flash memory, you're not doing yourself any favors and you should probably be cross compiling.

So what does it mean to cross compile for an embedded platform?  Embedded systems, like desktops or servers, need four things to run application software:  a compiler toolchain, a bootloader, a Linux kernel and a root file system.  The toolchain is a collection of software that includes a compiler and utilities for manipulating binaries.  A gcc compiler can be compiled to run on your desktop or server but that creates binaries that run on a different type of machine, which is referred to as the target system.  That's a cross compiler.  The toolchain adds libraries and tools needed along with the compiler to build programs to run on the target machine.

Once you have a toolchain you may need to use it to create a bootloader.  The bootloader prepares the hardware for the operating system, aka the Linux kernel.  There may be more than one bootloader for a system.  intel systems have BIOS, or if you're unlucky enough to have a recent Intel board, UEFI.  That's a first stage bootloader.  grub would be a second stage bootloader.  They work together to get Linux booted.   On ARM systems such as most mobile phone and tablets the bootloader may be u-boot.  The raspberry pi has a proprietary bootloader that actually uses the GPU instead of the CPU.  Things are gettin' weird out there.

After the bootloader runs, it eventually loads the Linux kernel.  The kernel, in turn, loads a root file system.  The root file system is the basic directory structure containing libraries, configuration files and data needed for basic operation.  You application sits in the root file system somewhere.  Where you put it and how the root file system gets it started is one of the places you'll spend a lot of time in your embedded project.  The bootloader, kernel and root file system, along with your application, all need to be compiled using the cross toolchain.

Since most embedded boards have limited memory and limited storage, usually in the form of on-board nand or NOR flash but more often these days in the form of SD flash cards, what you put into your root file system is important.  You typically don't want extra crap in there, first because it takes up space but also because you don't want users to muck up your very specific device purpose.  Which leads me to the big question.

What they heck are you doing putting ubuntu on an embedded board for?  To make a tiny desktop?  That's very creative of you.

There are embedded distributions such as OpenEmbedded and angstrom that let you very finely tune your root file system.  buildroot does the same thing but uses a different method to achieve a similar result.  Most embedded systems root file systems start with busybox, which is a lightweight set of GNU utilities originally intended for resource-limiited systems.  My own BeagleBox an pibox are simply meta-builds, that is, build systems that wrap tools like Buildroot and the Linux kernel to create a custom embedded platform.  In other words, of the four software components I mentioned, three are pretty easy to build yourself.

That leaves the toolchain.  Getting the right toolchain is important in order to squeeze the best performance out of your embedded system.  Since gcc and friends are used for most systems, the trick is to find someone to tweak the gcc build to get the most out of it.  That's what people like Mentor graphics (aka CodeSourcery) do.  And Linaro, a group who adds features to GCC and friends that specifically help ARM systems.

It used to be hard to find a good toolchain.  And even harder to build your own.  Now there is Crosstool-NG, which makes building the toolchain yourself only slightly harder than understanding how to build a root file system with Buildroot or even to configure the Linux kernel.  And groups like Linaro are working with these open source projects (crosstool-NG, Buildroot, etc.) to make it even easier.

So that's what embedded Linux is all about.  Four software components, customized to a target platform intended for a specific purpose.  In the end, you end up with your own custom Linux distribution.  And isn't that just the coolest thing you can think of?