What is embedded linux ?

What is embedded linux ?

[Pravin Pathak]

Hi All !
I have a silly question. How does embedded linux works without disk
support ?
I mean from where it loads shell and other application task images
without any file system
support ? For VxWOrks/pSOS have a single object file. How about Embedded
Linux ?
I am confused on this matter. Or it always need some kind of file
support like NFS to boot ?

Pravin


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: What is embedded linux ?

[Wolfgang Denk]

Hi Pravin,

in message <399B0FCD.A6E0A6BE@dnrc.bell-labs.com> you wrote:
>
> I have a silly question. How does embedded linux works without disk
> support ?

There are many ways: loading over ethernet, from flash, ...

> I mean from where it loads shell and other application task images
> without any file system

What makes you think there is no filesystem support?

> support ? For VxWOrks/pSOS have a single object file. How about Embedded
> Linux ?
> I am confused on this matter. Or it always need some kind of file
> support like NFS to boot ?

Usually you will always want to have some filesystem support. Unix is
pretty much build around the idea  of  mounting  some  type  of  root
device  -  so  you  will  usually  always find a root directory, most
probably also a /dev/ directory in it, etc.

There are many ways  to  build  such  a  system.  a  NFS  based  root
filesystem  is one; another is uising a ramdisk image which is loaded
with the kernel from some boot device (flash, network, ...).

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Given a choice between two theories, take the one which is funnier.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: What is embedded linux ?

[Graham Stoney]

Pravin Pathak writes:
> I have a silly question. How does embedded linux works without disk
> support ?   I mean from where it loads shell and other application task
> images without any file system support?

It's not a silly question really.  The answer is that they're loaded from a
filesystem as normal, but the filesystem resides on some non-disk media.  Of
course it depends on your application; some embedded systems have a disk, but
many don't. For more info, see the section in the HOWTO at:
    http://members.xoom.com/greyhams/linux/PowerPC-Embedded-HOWTO-12.html

> For VxWOrks/pSOS have a single object file.

And the academics used to criticise the Linux kernel for being monolithic! :-).

Regards,
Graham
--
Graham Stoney
Principal Hardware/Software Engineer
Canon Information Systems Research Australia
Ph: +61 2 9805 2909  Fax: +61 2 9805 2929

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: What is embedded linux ?

[Dan Malek]

Pravin Pathak wrote:
>
> Hi All !
> I have a silly question. How does embedded linux works without disk
> support ?

Don't confuse disk with file system......

> I mean from where it loads shell and other application task images
> without any file system
> support ?

Don't confuse disk with file system.....

> .... For VxWOrks/pSOS have a single object file. How about Embedded
> Linux ?

There are both a number of possible file systems (the structure of the
persistent data) and possible storage devices (the place where the
data is actually stored).

You can use the standard Linux ext2 file system on a ramdisk or in
flash, one of the flash file systems that will update flash sectors
and potentially compress the data, or even a file system on a
compact flash (or PCMCIA) device.

You can compress a ram disk as part of a flash image, and have it
automatically uncompressed and loaded into ram when the system boots.

There are many options and your choice depends upon your requirements.

> I am confused on this matter. Or it always need some kind of file
> support like NFS to boot ?

The NFS is used as a root file system because it is convenient for
development and also consistent across most platforms because everyone
supports Ethernet.  It isn't required, but is certainly the fastest
development path.


	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: What is embedded linux ?

[kentborg]

Pravin Pathak <pkpathak@dnrc.bell-labs.com> asked how embedded Linux
can work without a disk.

And, as others have already posted, it is quite possible to have a
rather traditional file system even if there is no spinning magnetic
media supporting it.

He also wrote:
>...from where it loads shell and other application task images... For
>VxWOrks/pSOS have a single object file.

Our current designs are also based on this traditional embedded
architecture.  The program sits in ROM, and when the program counter
points to it, it runs.

>How about Embedded Linux?

Linux programs also execute when the program counter eventually points
to them.  And, in an embedded system, that software might well sit in
some sort of directly accessable ROM.  BUT, in all versions of
embedded Linux that I have heard of, there is no way to set the
program counter to point to ROM and execute software *in*place*, it
must first be copied into RAM buffers.  (And compete with other uses
of buffer space.)

Frequently this is a quite sensible approach: Software can be
compressed to fit in a small, slow, narrow, inexpensive part, and the
first increment of RAM might be 8 MB and more than ample.  After all,
Unix started life as with disk space being significantly larger than
RAM, so embedded uses without any disk have been tended towards
systems flush with RAM.

However, there are situations (such as ours) where RAM is tight.  In
our systems the embedded software is large and already going to live
in fast, wide flash parts.  Our software is about as big as its
minimum RAM requirements.  In our case the cost of the RAM is a
significant part of total product cost which must be kept low,
doubling our minimum RAM needs as the price of going to Linux is
unattractive.  Plus, in our price/performance sensitive case we need
to spend wisely all of the computrons the CPU can put out.  To spend
the time to frequently copy to RAM is expensive, and to spend the
money on enough extra RAM to only do that copying once is still
uncertain, for the point at which we might run low on RAM is also a
point when we want the system to be both fast and deterministic.
Starting to page at that point--even from a fast source--is scary.

Alas, there is apparently no Linux code in existence that does what we
need.

To do this, from what I have learned so far, would take the following
(substantive comments from any who know better would be much
appreciated):

1) Development tools to create an object file type that is directly
   executable.

   At first glance this sounds easy, but dynamic libraries are a major
   catch.  Static linking would get around this, but then object sizes
   would balloon for anything but monolithic code, and one of the
   reasons for going to Linux is to not be monolithic.

   One way to use dynamic linking would be to also put those routines
   (formerly thought to be dynamic) in their own directly executable
   files, at known addresses, and for the software that uses them, to
   have done the dynamic "fixup" in advance.  This way these routines
   would remain single shared copies.

   For development stages it would be nice, when possible, to have
   traditionally loaded programs also link to those shared routines
   that have already been stored in directly executable form, but I
   don't think it would be strictly necessary.  It depends upon how
   easy it would be to implement this, it might fall out for free or
   nearly free.  If so, cool.

2) Driver for a file system that handles this kind of
   executable-in-place file.

   Uses of this file system would skip the traditional copying into
   buffer space and pointing the CPU at it, rather I figure it would
   set up something that looked very much like a memory mapped file,
   but where the entire file is resident and so there is never going
   to be a page fault.  If there is never a page fault, there is never
   a need to page in a missing portion of the file, it merely executes
   in place.  There is never going to be any non-deterministic
   fighting for buffer space on the part of this executable.

   Any application code that wishes to efficiently access large
   in-place data files could do so, but would have to know it would be
   doing so and not use standard IO functions (which are inherently
   buffered).

Certainly the current use-the-buffers-Luke philosophy of embedded
Linux works (and works well) for many applications, but not for all.
(Yes, I *have* done the math.  It is not appropriate for us.)
Especially if avoiding it is only a Simple Matter of Programming.


-kb, the Kent who hasn't had the time (yet) to learn enough and
implement the above hypotheticals.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/