embedded linux development : how to start

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.