embedded linux development : how to start

Dubya the ecovandal wrote:
> 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.

Have you noticed the slashed "utilities/libraries" above? :-)

> 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

Aren't you mixing it up with uClinux?

> to support vendors who give their sources away to everyone. Given
> you're a GNU/Linux newbie, I endorse the earlier suggestion about

Who is this "you" you are writing to? I still have many things to learn 
but I wouldn't fit myselfe as "newbie".

Regards.

Elder.

> >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
> 
> To sbuild embedded systems, you should build bottom up,  adding  only
> those  things where you exactly know what you need them for. In other

Agreed.

> Perfection is reached, not when there is no longer anything  to  add,

I used to have this quote up on my wall at my old job. Almost nobody
knows that he designed aircraft.

> 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

On the other hand it is an architecture that is well understood. It
allows the user to concentrate on the _Linux_ rather than wasting time
trying to bring up the system.

> 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.

I respectfully disagree. Although the points you raised are valid, I
believe they are outweighed by the fact that "embedded Linux" is 75%
(or more) an intersecting set with "regular Linux" and knowledge of
the latter is required learning for the former. For learning purposes,
trainer-wheels are acceptable, I'm not suggesting one should practice
for the Tour de France wearing them. The learning curve for an
embedded distribution - having to learn an unfamiliar bootloader,
weird filesystem layout, special code required to initialize
proprietary things - is made much less steep if the user already has a
better-than-average understanding of regular GP Linux.

On 11 Mar 2004 17:47:17 GMT, garykato@aol.com (Gary Kato) wrote:

>>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.
>

The whole "Writing Linux Device Drivers" is downloadable in a number
of formats. There are pointers to the URL on O'Reillys web site. 

Regards
   Anton Erasmus

Elder Costa <elder.costa@terra.com.br> 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?

There are many different variants of embedded Linux, but one of the main
differences is between the real-time and non-real-time variants. The
non-real-time variants are generally similar to the full-size distributions,
albeit stripped down to varying degrees.

Real-time variants will have the sort of library changes described
previously.

Elder Costa <elder.costa@terra.com.br> wrote in message news:<c2v2o8$21lep5$1@ID-217921.news.uni-berlin.de>...
> > 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
> 
> Aren't you mixing it up with uClinux?

uClibc is the accompanying library, written under the same
constraints.


> > to support vendors who give their sources away to everyone. Given
> > you're a GNU/Linux newbie, I endorse the earlier suggestion about
> 
> Who is this "you" you are writing to? I still have many things to learn 
> but I wouldn't fit myselfe as "newbie".

No doubt "newbie" is open to interpretation, but two posts back you
wrote "AFAIK there is no distinction between embedded and
general purpose distros other than a stripped down root file system + 
utilities" which is a bit of a giveaway. No offence intended though -
I was only trying to help.

Hi All!

Dubya the ecovandal wrote:
> Elder Costa <elder.costa@terra.com.br> wrote in message
> news:<c2v2o8$21lep5$1@ID-217921.news.uni-berlin.de>...
>> > 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
>> 
>> Aren't you mixing it up with uClinux?
> 
> uClibc is the accompanying library, written under the same
> constraints.
Nope! That's just plain wrong!

I'm using uClibc in my regular work and believe me it *has* a MCU. uClibc
supports mem.protection/virtual mem (vfork() _and_ fork())
and I use threads all of the time...
It may be that uClinux uses a version of uClibc but again:
uClibc has nothing to do with uClinux and its contraints!

And btw: Somewhere (in this Thread?) someone told to not use uClibc with
Java. I can report that uClibc works like a charm with kaffee (JVM) and
happily delivers Java server pages...

Salut, J&#4294967295;rg

-- 
gpg/pgp key # 0xe40a9d7a
fingerprint d4f8 b448 835b 7bcf 4161  ce35 7e8b ab47 e40a 9d7a

Joerg Schmitz-Linneweber <jsl@sth.ruhr-uni-bochum.de> wrote in message news:<c36fke$24cdb3$1@ID-197345.news.uni-berlin.de>...
> Hi All!
> 
> Dubya the ecovandal wrote:
> > Elder Costa <elder.costa@terra.com.br> wrote in message
> > news:<c2v2o8$21lep5$1@ID-217921.news.uni-berlin.de>...
> >> > 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
> >> 
> >> Aren't you mixing it up with uClinux?
> > 
> > uClibc is the accompanying library, written under the same
> > constraints.
> Nope! That's just plain wrong!
> 
> I'm using uClibc in my regular work and believe me it *has* a MCU.

You're quite right - my apologies. I haven't looked at it for a long
time, and the FAQ's quite clear that "These days, uClibc also works
just fine on normal Linux systems".


> And btw: Somewhere (in this Thread?) someone told to not use uClibc with
> Java. I can report that uClibc works like a charm with kaffee (JVM) and
> happily delivers Java server pages...

Not sure where that came up but thanks, I've been wondering about it.

John Black <black@eed.com> wrote in message news:<4050A164.B08EBA72@eed.com>...
> Hi,

>     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.

I face a similar predicament. The "Linux Device Drivers" book
suggested is considered authoritative by many; coupled with
author&#8217;s articles on lwn.net about porting modules to the 2.6 it
indeed is useful.

I couldn&#8217;t learn much off it. One day, I stumbled upon a LCD
device driver project on sourceforge.net which taught/is teaching me a
lot. I had interfaced a Hitachi LCD with a PIC16F877 as part of lab
work in my class. So LCD was a well-understood piece of hardware for
me, I went through the source code of the driver and learnt many
things. Now if I re-read LDD I think I would learn much more of it.

I think this particular way to learn about device driver is the best.
You take a small/understandable piece of hardware and write/read a
driver for it. The LCD is, imho, the right amount of
complexity/simplicity.

As for the other board support issues &#8211; running Linux on exotic
hardware. I agree with the staying closer to home approach. Learn to
run a lean Linux distro-less-system on your x86 first.

May serendipity take pity on you, on all of us. 

Regards
Sukrit
--
holysmoke [at] symonds [dot] net
www.symonds.net/~holysmoke