Robert Amstadt writes:
>
> --==-===-----=====-=---=-==---===-=-=-===--===--==
> Mime-Version: 1.0
> Content-Type: text/plain; charset="us-ascii"
>
> Please forgive me if this subject has been covered before. I did a search
> through the mailing list and didn't come up with the answers that I was
> looking for.
>
> I am working on a project that uses custom built hardware based on an Intel
> 80C186EA chip. The system is very special purpose and has limited
> resources (256K RAM and 256K Flash). In the past we used absolutely no
> operating system to control the unit. Now we have redesigned the board and
> suddenly it has a floppy drive, 4 16550 UARTs, and a memory-only PCCard
> slot. Given all the extra functions, it has become attractive to look at
> putting a small embedded OS in the box. Being the glutten for punishment
> that I am, I want to take a look at the possiblity of trimming ELKS to fit.
> Here is a list of what I'd like to be able to do, if you wouldn't mind,
> I'd like to hear commentary on the possibility of making ELKS do these things:
>
> 1. No root filesystem. Kernel image and process images would be stored in
> Flash memory ready to run. The kernel would start the init process which
> would in turn start the other processes.
No too hard. You would need to re-write fs/exec.c so it loads binary
images from flash rather than from the filesystem. Essentially what you
have would be a very primitive read-only filesystem stored in flash.
>
> 2. Kernel is minimized to support the serial ports, DOS or Minix filesystem
> on floppy, and its standard job of context switching the running processes.
Almost all kernel features can be configured in a similar way. It is
possible right now to remove most of the features that you do not require
from the kernel.
>
> 3. Remote debugging. Has anyone looked at having the compiler generate gdb
> compatible symbol information? I then see creating a small process that
> runs in the target system with gdb communicating over a serial link. I
> seem to recall gdb having SOME support for 16-bit x86 code and support for
> remote debugging over a serial cable.
Don't know alot about this.
>
> 4. Multiple of the same executable could be run by sharing the CS and
> giving each instance of the program a seperate DS.
Already does this. Works very well.
>
> 5. Some form of message passing to allow processes to communicate with each
> other.
We have signals now, and basic pipes. What sort of IPC did you have in
mind?
>
> I realize that some of the above (especially the remote debugging) may be a
> tall order, but I would still appreciate your thoughts on the above
> requirements. My personal feeling is that this type of system is a really
> good fit for ELKS.
>
I think the machine you have in mind could run a minimised ELKS quite
well.
Al
