Alicia da Conceicao wrote:
> 
> Alicia da Conceicao wrote:
> >>> Linux, or more specifically uClinux and other variations,
> >>> support embedded systems with no MMU (Memory Management
> >>> Units).  How hard would it be to port NetBSD to them non-MMU's
> >>> systems?  What steps, work would be needed?  Has anyone else
> >>> attempted this, or is working on this now?
> Perry E. Metzger wrote:
> >> We (Wasabi Systems) have thought about it a few times, but it is
> >> becoming so cheap to have an MMU in a system that we're not sure it is
> >> worth the effort. Were enough people interested (especially, I hate to
> >> put it this way, paying customers -- we do have to eat) we might be
> >> willing to give it a go. However, we haven't had much serious interest
> >> and (as I've said) as hardware costs for MMUs fall it becomes less and
> >> less interesting as projects go.
> > Wes Peters write:
> > Plus, even embedded developers are beginning to realize that features
> > like process memory protection are a good idea.  When the incremental
> > hardware cost is so small and the resulting software engineering
> > benefit so large, it becomes pretty easy to justify using a processor
> > with an MMU.
> 
> Well, adding an MMU will add about an extra (US)$20 to the cost of
> an embedded system. 

I don't know whose behind you pulled that number out of, but it
certainly doesn't jive with pricing on Xscale family processors.

> Considering that Future Shop Canada was
> selling SMC Barricades with 1 port WAN + 4 port LAN DSL/Cable-Modem
> routers for (CA)$69, less then (US)$50 during their boxing week
> sale, the extra $20 cost for an MMU makes a critical difference in
> the embedded space.  Currently uClinux is the only opensource
> Unix-OS for the embedded space.  All of the other embedded OS's
> like Windriver and Windows Embedded XP are commercial. 

You seem to have missed eCOS and RTEMS in there, both of which are
free for commercial use and offer friendly licensing terms.  Given
the lack of memory protection in uClinux, the only advantage it
offers over eCOS or RTEMS is the familiar programming environment,
at the cost of significantly more memory and processor overhead
and a license model that is not friendly to commercial products.

> Keep in
> mind we are talking about systems where the entire kernel and
> userland fits in less than 2MB of flash memory, and have only
> 2-4 MB of RAM to run everything.

eCOS or RTEMS can be shoveled into < 256K of flash and run out of
flash.  Depending on your application, you might be able to use
only the resources present on the chip.

> Anyways my question wasn't whether or not it was commerically
> viable for Wasabi Systems to develop a NetBSD MMU-less port.
> The folks at Wasabi are incredible brilliant, and I have great
> respect for them, but it may be more benifical to have people
> experienced with very small embedded systems to work on a NetBSD
> port, since it might be commerically beneficial for them to do
> so, as oppose to paying licencing fees to Windriver.

Or it might just be better to educate yourself about alternative
systems that are more suitable for such a small environment, and
to make sure NetBSD is a well-supported development platform
for those systems.

-- 
                                 Boats love me
                                 Sails fear me
Wes Peters <wes@dobox.com>                                     System Architect
http://www.dobox.com/                                                DoBox Inc.