Forums

embedded linux development : how to start

Started by John Black March 11, 2004
Hi,
    I am considering going to embedded linux development as this seems
hotter and hotter each day, I wondering what is the best approach here.
    I once wrote some programs on RedHat on my Pentiem 2 PC, but that's
just implementing some algorithms on fairly high level, so I am very new
to embedded linux.
    I am not new to embedded programming though as I have worked on some
hardware test on some development board, I wrote the hardware test code
and some simple driver.
    But I am not familiar with Linux, and I know there are various
versions, such as Monti Vista, uCLINUX, etc., and the board I have come
with these 2 versions, so I might start with them.
    Then what should be my first project? Write a Linux UART driver and
enjoy "Hello World"? Or begin with somewhat bigger one like PCI driver?
Is PCI driver too daunting? My friend warn me of that.
    I googled "linux kernel" and got a tutorial about Linux kernel, "The
Linux Kernel" by David A Rusling, its version is 2.0.33, is this version
too old? IS there any other good tutorial about Linux kernel and device
driver development?
    Is there any workshop of developing Linux driver?
    Any suggestion is appreciated!

>IS there any other good tutorial about Linux kernel and device >driver development?
There is the book "Writing Linux Device Drivers" from O'Reilly. The second edition is based on the 2.4 kernel and has information a the end of each chapter on compatability issues with 2.0 and 2.2. You will have to see what kernel version that the 2 versions you have are based on. O'Reilly also has "Understanding the Linux Kernel" which goes over the basic data structures and how things happen in Linux. The second edition is based on the 2.4 Kernel.
> I am considering going to embedded linux development as this seems > hotter and hotter each day, I wondering what is the best approach here.
IMHO, many people who approach this issue don't take the path of least resistance. They dive straight into embedded Linux distros. IMH(but "expert")O, your first step should be to understand fully how a regular x86 Linux installation is built. Understand the entire boot process from jump-out-of-BIOS to shell prompt. To embed Linux, you must first understand Linux and the dozens (or hundreds) of add-on components that normally comprise a functional Linux system. Embedded Linux distributions can properly be considered derivatives of "normal" Linux running on general-purpose computers, and 75% of embedded Linux documentation reads like this: function: void froogle(int a) Behaves exactly like the _FROOGLE syscall in the standard Linux kernel, except that it is unpreemptible and guaranteed to return within 15ms. #define DISCLAIMER_ADVERTISING I'm writing a book that deals with this topic :) #undef DISCLAIMER_ADVERTISING I think you would be best served by building an embedded application - say a home MP3 player (yes, I know - it's been done to death) - based on an x86 SBC and Linux. Start at the LinuxFromScratch project. Build the system from scratch. This information carries you a LONG way up the learning curve for "really embedded" Linux. You can't build on knowledge you don't have.
John Black wrote:
> Hi, > I am considering going to embedded linux development as this seems > hotter and hotter each day, I wondering what is the best approach here. > I once wrote some programs on RedHat on my Pentiem 2 PC, but that's > just implementing some algorithms on fairly high level, so I am very new > to embedded linux. > I am not new to embedded programming though as I have worked on some > hardware test on some development board, I wrote the hardware test code > and some simple driver. > But I am not familiar with Linux, and I know there are various > versions, such as Monti Vista, uCLINUX, etc., and the board I have come > with these 2 versions, so I might start with them. > Then what should be my first project? Write a Linux UART driver and > enjoy "Hello World"? Or begin with somewhat bigger one like PCI driver? > Is PCI driver too daunting? My friend warn me of that. > I googled "linux kernel" and got a tutorial about Linux kernel, "The > Linux Kernel" by David A Rusling, its version is 2.0.33, is this version > too old? IS there any other good tutorial about Linux kernel and device > driver development? > Is there any workshop of developing Linux driver? > Any suggestion is appreciated! >
Regarding device drivers, Rubinni's book recommended by Gary Kato is a good point to start (not a uninanimity though.) As for building embedded systems based on Linux, I strongly recommend Karim Yaghmour's book. It's definetely worth the bucks spent: http://www.oreilly.com/catalog/belinuxsys/ HTH. Elder.
Lewin A.R.W. Edwards wrote:
> components that normally comprise a functional Linux system. Embedded > Linux distributions can properly be considered derivatives of "normal" > Linux running on general-purpose computers, and 75% of embedded Linux > documentation reads like this: > > function: void froogle(int a) > Behaves exactly like the _FROOGLE syscall in the standard Linux > kernel, except that it is unpreemptible and guaranteed to return > within 15ms.
How could that be? AFAIK there is no distinction between embedded and general purpose distros other than a stripped down root file system + utilities (maybe based on busybox). I would apreciate deeper clarification and/or links on this subject as it does interest me.
> > #define DISCLAIMER_ADVERTISING > I'm writing a book that deals with this topic :) > #undef DISCLAIMER_ADVERTISING >
That interests me too. When will your book be released? Regards. Elder.
Hi,

> How could that be? AFAIK there is no distinction between embedded and > general purpose distros other than a stripped down root file system + > utilities (maybe based on busybox). I would apreciate deeper
There are two major issues here. 1. People randomly searching for "embedded linux" tend to go immediately to Linux-based software environments that include realtime extensions (such as RTLinux) or special system-specific modifications (such as ucLinux). It is MUCH EASIER for someone with "bare metal assembly of Linux components" skills to understand these special variants than someone who is approaching the problem with zero knowledge. 2. "Embedded Linux" products tend to be on alien processors, or in quite constrained systems. It is therefore usually impossible to build the software environment on the actual target hardware. This is another hurdle that is best sidestepped by the beginner. Developing on a PC, for a PC, means compile-n-run simplicity. My essential point is that the easiest stepping stone is to learn as much as possible on an x86 desktop system, building a distribution by hand out of vanilla components. The student can then progress to distro cookery with more exotic Linux additives and seasonings. You have to walk before you can waltz.
> That interests me too. When will your book be released?
I'm a couple of weeks behind on delivering drafts to my reviewers; several factors (like looking for a job!) have conspired in this regard :(. It is probably going to be published in the fourth quarter of this year. My MS deadline is 5/31/04 and there's typically 3-6 months of publishing leadtime.
Elder Costa wrote:
> Lewin A.R.W. Edwards wrote: > >> components that normally comprise a functional Linux system. >> Embedded Linux distributions can properly be considered >> derivatives of "normal" Linux running on general-purpose >> computers, and 75% of embedded Linux documentation reads like >> this: >> >> function: void froogle(int a) >> Behaves exactly like the _FROOGLE syscall in the standard >> Linux kernel, except that it is unpreemptible and guaranteed >> to return within 15ms. > > How could that be? AFAIK there is no distinction between > embedded and general purpose distros other than a stripped down > root file system + utilities (maybe based on busybox). I would > apreciate deeper clarification and/or links on this subject as > it does interest me.
In this case, for example, syscall _FROOGLE may be premptable (i.e. maybe it leaves interrupts enabled), and may take an indefinite time to return, perhaps by waiting until some external condition is satisfied. froogle() apparently times out and somehow signals such after 15 ms. All this makes it rather awkward to call _FROOGLE if you want to guarantee something else can be handled every 20 ms. -- Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net) Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net> USE worldnet address!
CBFalconer wrote:
> Elder Costa wrote: > >>Lewin A.R.W. Edwards wrote: >> >> >>>components that normally comprise a functional Linux system. >>>Embedded Linux distributions can properly be considered >>>derivatives of "normal" Linux running on general-purpose >>>computers, and 75% of embedded Linux documentation reads like >>>this: >>> >>>function: void froogle(int a) >>>Behaves exactly like the _FROOGLE syscall in the standard >>>Linux kernel, except that it is unpreemptible and guaranteed >>>to return within 15ms. >> >>How could that be? AFAIK there is no distinction between >>embedded and general purpose distros other than a stripped down >>root file system + utilities (maybe based on busybox). I would >>apreciate deeper clarification and/or links on this subject as >>it does interest me. > > > In this case, for example, syscall _FROOGLE may be premptable > (i.e. maybe it leaves interrupts enabled), and may take an > indefinite time to return, perhaps by waiting until some external > condition is satisfied. froogle() apparently times out and somehow > signals such after 15 ms. All this makes it rather awkward to > call _FROOGLE if you want to guarantee something else can be > handled every 20 ms. >
All in all, I must presume from Lewin statement and yours that embedded distros agressively use modified utilities/libraries? OK, we have busybox and uClibc but, besides being stripped down/optimized, do they change their behaviour compared to ther bloated cousins to guarantee that deadline? I other terms, does embedded distros' glibcs behave differently from their desktop counterparts? TIA. Elder.
larwe@larwe.com (Lewin A.R.W. Edwards) writes:

>My essential point is that the easiest stepping stone is to learn as >much as possible on an x86 desktop system, building a distribution by >hand out of vanilla components. The student can then progress to >distro cookery with more exotic Linux additives and seasonings. You >have to walk before you can waltz.
On the other hand there is a high risk to start learning the wrong things. First, methods. If you start with a standard Linux distribution you will easily be tempted to create an "embedded" version by removing stuff you don't need - and you will end up with a beast that is much, much larger than necessary just because of certain interdependencies that are not easy to break any more. To sbuild embedded systems, you should build bottom up, adding only those things where you exactly know what you need them for. In other words: Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away. - Antoine de Saint-Exupery Second, architecture. The x86 is just a braindead architecture, and you will get used to restrictions like those imposed on the boot procedure by the BIOS. You will not be able to imagine clever things that are possible with other boot loaders (like U-Boot) on other architectures (like PowerPC, ARM, MIPS, ...). In other words: it is very difficult to leave such a PC-centric view of the world if allyou've ever seen is a PC. Just my $0.02 Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Web: www.denx.de "Life, loathe it or ignore it, you can't like it." - Marvin the paranoid android
Elder Costa <elder.costa@terra.com.br> wrote in message news:<c2s3o8$20dp5o$1@ID-217921.news.uni-berlin.de>...
> CBFalconer wrote: > > Elder Costa wrote: > All in all, I must presume from Lewin statement and yours that embedded > distros agressively use modified utilities/libraries? OK, we have > busybox and uClibc but, besides being stripped down/optimized, do they > change their behaviour compared to ther bloated cousins to guarantee > that deadline? I other terms, does embedded distros' glibcs behave > differently from their desktop counterparts?
AFAIK the busybox is a utility application not a modified library. uClibc certainly is a modified library though, and yes, it's extensively stripped-down: it's aimed at embedded CPUs without memory-management units (MMUs), so it doesn't support memory protection or virtual memory. It's surprisingly useful, but unless you pick a target system that's very limited in price and features I'd recommend a different library. If you plan to run Java on embedded GNU/Linux, for example, I strongly suggest opting for thread support from the start - have a look at SnapGear's embedded kernel and toolchain for systems with MMUs. You mentioned MontaVista earlier. It's lovely software, but AFAICT the source can no longer be downloaded without a customer login. That's within the constraints of the GPL, and MontaVista contributes a lot to Open Source, but I prefer to support vendors who give their sources away to everyone. Given you're a GNU/Linux newbie, I endorse the earlier suggestion about starting with a full-fat installation till you're familiar with how it works. You'll need one eventually anyway, because once you start on an embedded target you're best to cross-develop for it from a full-fat installation. Google for Bill Gatliff's site and read his documents about how GNU/Linux starts up and so on - they're invaluable.