[[Perhaps we should move part of this thread to netbsd-advocacy as it is
not entirely about technical issues.]]
At Fri, 26 Mar 2010 13:49:17 -0500, Jack Atkinson
<doxalogos%gmail.com@localhost> wrote:
Subject: Roadblocks to further widespread adoption of NetBSD in embedded
systems (at least in my neck of the woods)
>
> However, I cannot recommend NetBSD to them at this
> time, because of these areas that are lacking:
>
> (listed by highest priority)
> 1. Official PowerQuicc support in the NetBSD tree along with drivers for
> CPM module. (PowerPC is not quite the same, but a good starting point)
Is your client looking at the QorIQ PowerPC e500-based platform too?
> 2. No flash support for NOR flash (NAND lacking is well, but NOR is more
> important for this company based on current deployed hardware)
Depending on the exact devices, and the level of support required, I
think there may be BSD-licensed drivers already available in some cases,
i.e. in other BSDs, though it's pretty low-level basic stuff suitable
only for stuffing new firmware images down, maybe saving configs,
etc. but no true filesystem support or wear-levelling layers, etc.
Eg. FreeBSD's cfi driver, and apparently there are some old and new NAND
driver projects for FreeBSD as well (one by the late John Birrell).
John claimed "writing NAND drivers for FreeBSD using GEOM is a trivial
matter. It only taking a few days or a week at most."
There's also sdhc(4) and sdmmc(4) coming in NetBSD-6, and m25p(4) for
SPI-connected NOR FLASH already in NetBSD-4.
> 3. Better remote debugging over ethernet (kernel included). I may be
> wrong on this, but I haven't seen a lot of info on how to do this for
> NetBSD.
> 4. Ability to build a small kernel with small subset of userland
> utilities much like BusyBox on Linux, but not GPL.
Very easy to do with crunchgen, as Herb mentioned, and most of the
framework is already there to do it with the existing Makefiles and
build scripts (at least for i386). It is how the install media works
for some platforms, including i386.
As a bit of an experiment I've recently just managed to stuff almost
everything in the base system into a single crunchgen binary that
together with a (tuned) i386 kernel is less than 8 megabytes
(compressed) file, and expands when running into a 12MB memory
filesystem where the crunchgen binary inside is just 7.8MB with the only
major things missing being BIND and Postfix, and AMD and NFS-server (and
YP and PAM), I think. I only had to write a couple of new Makefiles and
a configuration file to feed the ramdisk/crunchgen builder tools. A
couple more weeks worth of work and I could have the basis for a
complete system for a CPE/router/firewall box (ala m0n0wall, openwrt, or
nanobsd) that booted from FLASH, safely stored its /etc on a separate
FLASH partition, etc. all on some little embedded PC board, like the
ALIX.2 I'm testing it on.
I.e. this part is trivial as it more or less exists already. :-)
> 5. Better real time support (it's getting there by 6.0 and technically
> really a low priority due to more control plane software development the
> company does)
>
> I say this not to complain, but maybe to help point out these major
> issues from another company's perspective. If the above areas had full
> support in the tree, I could almost guarantee it would become adopted.
> I want to encourage the embedded side of the NetBSD community to commit
> to these areas more. Personally, I hope to contribute to one of these
> areas in my own spare time, particularly in the PowerQuicc area (ref
> boards and debuggers are expensive!).
I echo your sentiments about working more on embedded systems support in
the public code base. NetBSD has a good history of being successfully
used as a foundation for many embedded systems projects, but sadly many
of the companies who have used it are often unable or unwilling to fully
contribute their efforts back to the public code base. All too often
the "unable" part is due to hardware companies desperately protecting
their trade secrets with overly broad NDAs that prevent source for
software that drives their hardware from ever being released. Sometimes
it seems as if the "unwilling" part comes from the desire to capitalize
on expensive development efforts without considering the potential
payback from sharing. It's the whole "open-source" argument from all
sides and from top to bottom. :-)
From your client's business perspective I think the initial question
might be to ask how much of what they would pay for QNX licensing are
they willing to pay to developers in order to be able to make use of
NetBSD, and over how long are they able to amortise this cost?
--
Greg A. Woods
Planix, Inc.
<woods%planix.com@localhost> +1 416 218 0099 http://www.planix.com/
Attachment:
pgporj7XIICXf.pgp
Description: PGP signature