Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Embedded Linux

9 views
Skip to first unread message

Trond Solem

unread,
Oct 25, 1994, 9:30:50 AM10/25/94
to
Is it possible to strip out the disk/filesystem code from Linux so it may
run on a embedded controller(386,2Mb RAM, 1Mb (E)EPROM, two rs232, ethernet)?

I want the 32bit kernel with communication support, but I don't want to
have any disks. The programs it will run fits into less than 1Mb of ram.

Is it too much of a hazzle, or what?

Other OS that can do the job? (must have IP)


Trond
-------
tr...@multimaster.no

Andreas Kostyrka ( yacc )

unread,
Oct 28, 1994, 9:25:34 AM10/28/94
to
Trond Solem (tr...@multimaster.no) wrote:
: Is it possible to strip out the disk/filesystem code from Linux so it may

: run on a embedded controller(386,2Mb RAM, 1Mb (E)EPROM, two rs232, ethernet)?

: I want the 32bit kernel with communication support, but I don't want to
: have any disks. The programs it will run fits into less than 1Mb of ram.

You could try to configurate the kernel without disk support, but
you will need the minix stuff, so you can have a root ramdisk.

point is, that you need a root file system, I think I remember from my
OS-design class that the concept of a file & filename -> ``/'' is
fundamental for UNIX.

: Is it too much of a hazzle, or what?

Alan Cox

unread,
Oct 31, 1994, 7:26:15 AM10/31/94
to
In article <4D8quc...@multimaster.no> tr...@multimaster.no (Trond Solem) writes:
>Is it possible to strip out the disk/filesystem code from Linux so it may
>run on a embedded controller(386,2Mb RAM, 1Mb (E)EPROM, two rs232, ethernet)?

You need a filesystem/disk. However nothing stops that being the RAM disk
(or a RAM disk tweaked to be the EEPROM) you then compile with only minixfs
(nice and small) and with all the disks turned off (you need to clobber
the floppy driver by hand unless you have some kernel patches).

>Is it too much of a hazzle, or what?

Its probably not that hard but you might want to look at the 'real' commercial
alternatives such as QNX or OS/9 that may do it better.

Alan
--
..-----------,,----------------------------,,----------------------------,,
// Alan Cox // iia...@www.linux.org.uk // GW4PTS@GB7SWN.#45.GBR.EU //
``----------'`----------------------------'`----------------------------''

Message has been deleted

Richard Hussong

unread,
Nov 3, 1994, 12:55:53 AM11/3/94
to
Trond Solem (tr...@multimaster.no) wrote:
: Is it possible to strip out the disk/filesystem code from Linux so it may


If you can buy a commercial product, there are at least two reasonable
386/486 OSes that fit your description. The one more like UNIX is VxWorks,
from Wind River Systems; the other is OS-9000, from Microware. They are
both designed for embedded systems, and happy to run without disks. I am
sure there are others as well, but those are the two I have some experience
with. I have no idea how much they cost, or any other nitty-gritty business
details; I am just an engineer.

+++---------------------------------------------+++

Richard Hussong rhus...@world.std.com

+++---------------------------------------------+++

Trond Solem

unread,
Nov 3, 1994, 5:38:15 AM11/3/94
to
don...@mxd120.rh.psu.edu (Matthew Donadio) writes:

> Alan Cox (iia...@iifeak.swan.ac.uk) wrote:
> : Its probably not that hard but you might want to look at the 'real'


> : commercial alternatives such as QNX or OS/9 that may do it better.
>

> Not to mention that you probably won't get any good real-time
> performance.
>

What does that mean? Do you mean REAL BAD performance, or a bit better than
DOS?

Trond
-------
tr...@multimaster.no

Doug Dejulio

unread,
Nov 3, 1994, 10:49:30 AM11/3/94
to
In article <g7P8uc...@multimaster.no>,

Real-time performance is a specific, special kind of performance. A
machine that's good for real-time performance could perform *really
badly* when you compare it to a non-real-time machine, and still be
better for real-time performance.

Basically, with real-time programming, you're *guaranteeing* that a
particular operation will happen within a particular amount of time.
It doesn't matter what that amount of time *is*, as long as you
guarantee it ahead of time.

So, an operating system that can guarantee that it will always, every
time, finish executing a particular subroutine in five seconds or less
is better for real-time purposes than an operating system that 99% of
the time finishes it in under half a second, but *sometimes* takes an
unpredictable amount of time.

Linux is not real-time. With virtual memory and scheduling and stuff
like that, Linux can't make guarantees about how long any operation is
going to take (unless it's an operation within the kernel, and even
then sometimes not).

Real-time is important for embedded applications -- if the computer in
your brake system on your car starts to slow down because of swapping
or something, you crash and you die. It's more important to be
predictable than to be fast, in this arena.

--
Doug DeJulio
mailto:dd...@pitt.edu
http://www.pitt.edu/~ddj/

Malcolm Northcott; W 956 8758

unread,
Nov 3, 1994, 4:24:47 PM11/3/94
to

I dont know anything about OS-9000, but we use VxWorks quite a bit.
It is a very excelent product, can't say enough good things about it,
but at about $25,000 VxWorks is definately beyond the reach of 99.9%
of potential customers.
There is no sign that Wind River (owners of VxWorks) have seen the
writing on the wall Re: Microsoft getting into the RT market, so I'd be
surprised to see reasonable pricing any time soon. Damn shame if
you ask me, looks like another good product thats going to be
self-sacrificed to Microsoft.
Anyway getting back to the point, I dont think VxWorks for the PC
architecture has been released yet.
We are thinking of trying to run Linux on a STD bus to control some
motors, a sufficiently soft RT requirement (since we are using intelligent
servo controllers) that the Linux latency is probably not going to be
a problem. The plan is to try and use a EPROM floppy disk emulator
to boot Linux. The main reason for doing this is that it would
give us simple access to TCP/IP for easy routing of motor commands.
If anyone has tried this before we'd like to hear from you.

Malcolm Northcott no...@uhifa.ifa.hawaii.edu

Trond Solem

unread,
Nov 4, 1994, 3:56:15 AM11/4/94
to
dd...@pitt.edu (Doug Dejulio) writes:

I intend to disable the swapping, hard-disk amd floppy disk, so a lot of
timeconsuming operations are removed. I need the multitasking kernel with
communication, and maybe a filesystem in FLASH-memory. Are there any other
things in Linux/unix that may run 'forever' without giving control back
to the kernel?

>
> Real-time is important for embedded applications -- if the computer in
> your brake system on your car starts to slow down because of swapping
> or something, you crash and you die. It's more important to be
> predictable than to be fast, in this arena.

Yes, I agree, but I am currently using a real-time kernel under DOS and
sometimes nothing can be predicted. :(

I dont't need real-time down to miliseconds, but i need to run a PLC program
at least every 0.1 second. All routines is supposed to be so short that they
will complete in about 0.02 - 0.05 seconds. If a unix-like OS can't handle
this, then I have to look for other systems.

The fact that Linux has TCP/IP/PPP/SLIP communication is more important than
detecting that a digital input is on in less than 0.001 second.

Besides that, I don't like to program in C. If I want trouble, I program in
assembler. Otherwise I program in Modula-2, which is available for Linux.

Trond
-------
tr...@multimaster.no

wd

unread,
Nov 4, 1994, 3:48:40 PM11/4/94
to
tr...@multimaster.no (Trond Solem) writes:

>timeconsuming operations are removed. I need the multitasking kernel with
>communication, and maybe a filesystem in FLASH-memory. Are there any other

That's not so easy. Remember that FLASH memory has a limited number
of write cycles. All "normal" file systems tend to write some blocks
very often (super block, inodes, bit maps etc.) - I don't know of any
file system that was designed to run in FLASH memory.

Wolfgang

Private: (+49)-89-952275 w...@denx.muc.de
Office: (+49)-89-722-41782 w...@uebemc.siemens.de
A supercomputer is a machine that runs an endless loop in 2 seconds.

Vinod G Kulkarni

unread,
Nov 4, 1994, 11:11:42 PM11/4/94
to
Trond Solem (tr...@multimaster.no) wrote:

: I dont't need real-time down to miliseconds, but i need to run a PLC program


: at least every 0.1 second. All routines is supposed to be so short that they
: will complete in about 0.02 - 0.05 seconds. If a unix-like OS can't handle
: this, then I have to look for other systems.

: The fact that Linux has TCP/IP/PPP/SLIP communication is more important than
: detecting that a digital input is on in less than 0.001 second.

Given the following conditions, isn't it possible to get real time performance?
1. When the process is loaded in memory, it is never swapped out.
2. The scheduler *always* returns the control to the process every
"t" milli seconds.
So at least for the said application, it should be simple modifications
to kernel to get the required real time performance.
After all, how does the PC speaker sound driver work? Doesn't he make
changes to scheduler?

Vinod
--
--Vinod.G.Kulkarni. ,---------------------------------------
Research scholar, |"People often find it easier to be result
Dept. of CSE, IIT Bombay, | of the past than the cause of the -
INDIA. (vi...@cse.iitb.ernet.in)|___________________________- future.___

Trond Solem

unread,
Nov 7, 1994, 5:07:18 AM11/7/94
to
no...@uhifa.ifa.hawaii.edu ( Malcolm Northcott; W 956 8758) writes:

> In article <CyoGH...@world.std.com>, rhus...@world.std.com (Richard Husson

> |> Trond Solem (tr...@multimaster.no) wrote:
> |> : Is it possible to strip out the disk/filesystem code from Linux so it ma

> |> : run on a embedded controller(386,2Mb RAM, 1Mb (E)EPROM, two rs232,
> |> : ethernet)?
> |>
> |> : I want the 32bit kernel with communication support, but I don't want to
> |> : have any disks. The programs it will run fits into less than 1Mb of ram.
> |>

snip

> We are thinking of trying to run Linux on a STD bus to control some
> motors, a sufficiently soft RT requirement (since we are using intelligent
> servo controllers) that the Linux latency is probably not going to be
> a problem. The plan is to try and use a EPROM floppy disk emulator
> to boot Linux. The main reason for doing this is that it would
> give us simple access to TCP/IP for easy routing of motor commands.
> If anyone has tried this before we'd like to hear from you.
>
> Malcolm Northcott no...@uhifa.ifa.hawaii.edu

Thats somewhat in the same lane as we thinks. We want to route
control-messages to various controller boards located several miles from each
other. Some may be connected with a leased line, others to a ethernet, others
are dial-up connections. TCP/IP/PPP seems to be the key to success here. We
are discussing how to boot Linux (or other OS), and have reached the point
where we are going to prom the kernel and run the other stuff from a in-place
filesystem in flash-memory. Processor will be the Intel 386EX.

All kind of information/tips/tricks is welcome!


Trond
-------
tr...@multimaster.no

Stano Meduna

unread,
Nov 8, 1994, 8:53:02 AM11/8/94
to
Vinod G Kulkarni (vi...@cse.iitb.ernet.in) wrote:
: Trond Solem (tr...@multimaster.no) wrote:

: : I dont't need real-time down to miliseconds, but i need to run a PLC program
: : at least every 0.1 second. All routines is supposed to be so short that they
: : will complete in about 0.02 - 0.05 seconds. If a unix-like OS can't handle
: : this, then I have to look for other systems.

: : The fact that Linux has TCP/IP/PPP/SLIP communication is more important than
: : detecting that a digital input is on in less than 0.001 second.

: Given the following conditions, isn't it possible to get real time performance?
: 1. When the process is loaded in memory, it is never swapped out.
: 2. The scheduler *always* returns the control to the process every
: "t" milli seconds.
: So at least for the said application, it should be simple modifications
: to kernel to get the required real time performance.
: After all, how does the PC speaker sound driver work? Doesn't he make
: changes to scheduler?

I think that in UNIX-like system there can be a problem to
guarantee a control to be given to a process every 0.1 sec. The
user process is not the only one in the system, if there is some
network communication, things are even more complicated.

UNIX scheduling is not a straight process - the priority of the
process changes with time etc. You have following possibilities:

- do all your time-critical work in the kernel using timeout
callbacks etc. There probably is a guarantee that a timer
interrupt will be called at least 10-times in a second :-)
But you can't do anything you want directly in the kernel
(you have no process-context, no C-library, kernel calls
can be non-reentrant etc.). If you can precisely define the
time-critical parts, you can implement them in a driver and
leave rest of the work (e.g. IP communication) to user process.

- or you must fiddle with process management, which is not an
easy work unless you are kernel guru


I don't see a problem in embedding Linux - root filesystem
can be basically in EPROM, variable parts on the RAM-disk.
But real-time programming is really something completely
different than classical UNIX-programming.

I used a nice product called C-EXEC two years ago for an
embedded communication application, but there was no IP
available.

Regards
--
Stano

Message has been deleted
Message has been deleted
Message has been deleted
Message has been deleted

Henry Ware

unread,
Nov 10, 1994, 10:59:56 PM11/10/94
to
Those of you who need such a system might consider looking at VSTa.
I beleive its a free, microkernel based, quasiPOSIX compliant OS,
designed for embedded x86 systems.

Try: ftp.cygnus.com:/pub/embedded/vsta/

I don't think it has any networking capability. It does have emacs, gcc,
etc.

Cheers,
Henry
--
"There is only one basic human right, the right | There are three types of
to do as you damn well please. And with it comes | people: those who can
the only basic human duty, the duty to take the | count and those who can't.
consequences" -P.J. O'Rourke | Linux: the choice of a GNU generation | PGP-ok

Michael Morrison

unread,
Nov 11, 1994, 10:15:28 AM11/11/94
to
In article <CypnH...@news.Hawaii.Edu> no...@uhifa.ifa.hawaii.edu ( Malcolm Northcott; W 956 8758) writes:
>In article <CyoGH...@world.std.com>, rhus...@world.std.com (Richard Hussong) writes:
>|> Trond Solem (tr...@multimaster.no) wrote:
>|> : Is it possible to strip out the disk/filesystem code from Linux so it may
>|> : run on a embedded controller(386,2Mb RAM, 1Mb (E)EPROM, two rs232,
>|> : ethernet)?
>|>
[...]

>|> sure there are others as well, but those are the two I have some experience
>|> with. I have no idea how much they cost, or any other nitty-gritty business
>|> details; I am just an engineer.
>|>
>|> +++---------------------------------------------+++
>|>
>|> Richard Hussong rhus...@world.std.com
>|>
>|> +++---------------------------------------------+++
>
>I dont know anything about OS-9000, but we use VxWorks quite a bit.
>It is a very excelent product, can't say enough good things about it,
>but at about $25,000 VxWorks is definately beyond the reach of 99.9%
>of potential customers.

VxWorks is most definitely NOT unix as we know it. We have it on a machine
here, and I am continually annoyed with it. (I am not sure whether
this is a function of how it was ported or not, so this stuff may not apply)
(we did not port it)

1) Command lines assume that anything after the first word is a symbol. Any
Non-symbols need to be quoted. ie:
$ ls /tmp/stuff
## Unknown symbol '/tmp'
$ ls "/tmp/stuff"
(works)
2) Multiple arguments need to be separated by commas:
$ cp "/tmp/file","/tmp/file2"
3) On our machine, hitting 'ctrl-x' anywhere causes the machine to reboot
without being able to bail out.
4) No vi, and the microemacs appears to be different than 'standard' microemacs.
5) Blatant security bug in the nfs software (or OS) that allows anyone to
become any user they wish by typing 1 command line.
6) accidently typing
$ >command
instead of
$ <command
"MAY" cause the hard drive to be filled with zeros.

[... etc ...]

I don't know anything about the programming environment of VxWorks. It may be
nice, however the interactive side seems to have some problems.


--
Mike Morrison morr...@ccad.uiowa.edu
Software Engineer
Iowa Driving Simulator Linux: The choice of a GNU Generation.
University of Iowa Long Live the Amiga!

Molnar Ingo

unread,
Nov 14, 1994, 5:20:45 PM11/14/94
to
Rob Janssen (r...@pe1chl.ampr.org) wrote:
: In <39gqsn$s...@goliat.eik.bme.hu> mi...@R2.sch.bme.hu (Molnar Ingo) writes:

: >There is no mechanism to keep the kernel from executing forever. If there
: >are enough hardware-interrupts waiting to be served, interrupt handler routines
: >are interrupted and they are interrupted again and again ... This is because
: >only critical regions of code are cli-ed.

: Did you actually study the operation of the PIC and the code in irq.c/irq.h
: before you wrote this?

: Rob

You are right. Both fast interrupts and late-occuring bottom-half routines are
atomic. (bottom halves can get interrupted, but are atomic to themself)
This means that there is a finite worst-case time in which the kernel finishes
execution.
--
--------------------------
| MIngo (-: Ingo Molnar |
| mi...@hercules.elte.hu |
--------------------------

0 new messages