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/
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/
Pravin Pathak [off-list ref] 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/