* Re: What is embedded linux ?
2000-08-16 22:03 What is embedded linux ? Pravin Pathak
@ 2000-08-16 23:54 ` Wolfgang Denk
2000-08-17 0:29 ` Graham Stoney
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: Wolfgang Denk @ 2000-08-16 23:54 UTC (permalink / raw)
To: Pravin Pathak; +Cc: linuxppc-embedded
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/
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: What is embedded linux ?
2000-08-16 22:03 What is embedded linux ? Pravin Pathak
` (2 preceding siblings ...)
2000-08-18 4:26 ` Dan Malek
@ 2000-08-18 14:25 ` kentborg
3 siblings, 0 replies; 5+ messages in thread
From: kentborg @ 2000-08-18 14:25 UTC (permalink / raw)
To: pkpathak; +Cc: linuxppc-embedded
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/
^ permalink raw reply [flat|nested] 5+ messages in thread