Subject: Re: Quick and dirty embedded OS
To: NetBSD Tech-embed <>
From: Brian Rose <>
List: tech-embed
Date: 10/19/2004 13:50:39
Allen Briggs wrote:

> On Tue, Oct 19, 2004 at 06:00:17PM +0200, Werner Backes wrote:
>>Brian Rose wrote:
>>>Are there any howtos on how to get NetBSD onto a low end PDA (like the 
>>>Palm M series)?
>>I don't think this is possible without major code changes because NetBSD
>>currently needs an MMU (memory management unit) which most "low end
>>CPUs" don't have.
> However, look at the hpcarm and hpcmips ports for handhelds that are
> supported to one degree or another.  There are plenty of ARM/StrongARM
> and MIPS handhelds out there that do use an MMU...
> -allen

I apologize in advance for the barrage of questions. But I am a bit 
uninformed as to the ramifications of not having a MMU.

I vaguely remember seeing a table that listed all of the platforms that 
NetBSD ran on, the memory configuration, if it booted, if it supported X, 
etc. That table now seems to be broken up among the various ports.

Also, how do you know if a platform has an MMU? Do any PDA type devices use 
external (to the processor) MMU's?

Is there any work being done to get NetBSD running on non-MMU machines, 
like uCLinux?

My understanding is that the MMU serves two functions.
(1) To provide the system processes with their own view of memory, such 
that each process feels that it has access to the entire address space.

(2) To provide an apparant memory greater than the installed physical RAM.

For embedded devices, (2) could be solved by not making a swap partition 
and essentially setting it to 0 (like a boot floppy image), correct? As for 
(1), is there any way to work around this? My guess is that emulating an 
MMU in software would eat up so much of the processor's time, that 
performance would be killed (if it is possible at all).

If (1) is discarded is it possible to still have multiple threads in the 
single process address space?

It'd be nice to compete with the Penguin on some of these small devices.


Brian (needing an education in the finer details of operating systems)