From owner-freebsd-current@FreeBSD.ORG Mon May 29 17:38:14 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7AFE416A434; Mon, 29 May 2006 17:38:14 +0000 (UTC) (envelope-from root@parse.com) Received: from amd64.ott.parse.com (ottawa-hs-206-191-28-202.s-ip.magma.ca [206.191.28.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08F6143D46; Mon, 29 May 2006 17:38:11 +0000 (GMT) (envelope-from root@parse.com) Received: from amd64.ott.parse.com (localhost.parse.com [127.0.0.1]) by amd64.ott.parse.com (8.13.4/8.13.1) with ESMTP id k4THaPcr012015; Mon, 29 May 2006 13:36:27 -0400 (EDT) (envelope-from root@parse.com) Received: (from root@localhost) by amd64.ott.parse.com (8.13.4/8.13.1/Submit) id k4THaOGc012014; Mon, 29 May 2006 13:36:24 -0400 (EDT) (envelope-from root) From: Robert Krten Message-Id: <200605291736.k4THaOGc012014@amd64.ott.parse.com> To: phk@phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 29 May 2006 13:36:24 -0400 (EDT) In-Reply-To: <2538.1148556253@critter.freebsd.dk> from "Poul-Henning Kamp" at May 25, 2006 01:24:13 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 29 May 2006 20:24:09 +0000 Cc: small@freebsd.org, current@freebsd.org Subject: Re: FreeBSD's embedded agenda X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2006 17:38:14 -0000 Poul-Henning Kamp sez... [snip; getting into this late due to some weird mailing list delays] > FreeBSD is a great operating system for embedded use and people all over > the world use this to their advantage. Judging on what I have heard over my career in embedded development, *BSD (let alone FreeBSD) is almost completely unknown in the embedded market. WindRiver, GreenHills, QNX, ... and possibly some Linuxs are the owners of that marketplace. [Maybe the notable exception is Juniper Networks; I've heard they're a big BSD shop] > At the developer summit in Ottawa this month (right before the > wonderful BSDcan conference) we spent a lot of time talking about > what we as developers can do to further this market segment. It's got to be as simple and well-supported as the OSs mentioned above. It's got to have success stories, PR, etc. It's got to have a base of experts that *know* embedded. There must be a commonality between the "embedded edition" and the "desktop edition" -- self-hosted development is ORDERS of magnitude more efficient than cross platform development, so the "desktop" version should present itself as a really "fat" embedded system... [snip] > Overall Focus > ------------- > > I think we found three main areas where we need to do some work: > platforms, packaging and evangelism. Agree 100%; I'd also seriously add: d) port kits What I mean by that is creating a set of libraries, tools, documentation, whatever it takes, that will help someone coming from a VxWorks or QNX or whatever environment to get started and become productive in a FreeBSD environment ASAP. [snip] > What can you do ? > > If you work with embedded FreeBSD, I think the best you can do is to > chime in to small@freebsd.org, tell us what you are doing (as far as > company policy will allow you), and if you have any ideas, wishes, > problems, let us hear about them. Well, my current project is QNX-based, but I've been asking myself, "why can't we use FreeBSD on this one?" Apart from the fact that it's a medical device, and we are 2 years into it :-) Let me describe it briefly -- it's a 500MHz Celeron processor, 16 MB CF, 64MB RAM, VGA, Ethernet, and a 48 digital I/O card + serial ports. The OS and all applications are on the order of 3MB. The CF is used for logging of "interesting internal software events" as well as a database of irradiated products. The software controls two motors, monitors a dozen inputs, and communicates with the user via a 4 x 20 Vacuum Fluorescent Display and a 14 button keypad over a weird Datapac 3201-like serial protocol (ETX/STX/ACK/NAK/ENQ type of stuff). It accepts an IBM-PC/AT compatible keyboard, with a barcode scanner. There is 50kLOC divided into half a dozen major processes, all communicating via IPC. I'm not going to take up more list space with details, see the top entry of my resume at www.parse.com/resume.html for more info. There you'll also see the kind of stuff I've been working on for the last 20 years. What if we were to port this to FreeBSD, or if we were to have started the project in FreeBSD in the beginning? Well, the following things are "critical" for our system -- FreeBSD addresses some of them, and is "at the edge" for others: a) fast boot time -- there's a stupidly-designed microcontroller on one of the systems (legacy; can't change) that needs to be tickled within 13s of power up. Using the current Celeron processor, with a special "fast boot" bios from the manufacturer, and having customized the kernel, and hacked the OS bootloader, we're down to 10s. b) small sizes -- this is less of a constraint than it used to be, but the size of everything affects bootup time. c) realtime response d) certified for use in medical devices The last requirement is peculiar to this device and can probably be omitted from the "general list" of embedded requirements. There's been a lot of discussion on this list about filesystems and flash adaptation layers and all that. The CF cards that we're using are M-Systems 32 MB EIDE "plugs" (they plug right into the motherboard's EIDE connector) and we did extensive life-cycle testing on them with no apparent degradation. (This could be a misleading statement -- we don't write to the flash that often, so our simulation of "5 years worth of life cycle" consisted of on the order of 1 million open/write/close cycles on a few files). Since it's almost impossible to get any "real" answers from M-systems (or any other vendor, most likely) about what they do for wear-leveling etc, we simply said "Fine, how does a representative sample of their devices compare over our expected lifecycle?" Another serious issue to consider with wear-leveling is that some of the algorithms are patented, so there's a whole nasty IP issue to contend with. In another life, I did data acquisition for an aluminium smelter, worked on a control system for a chlorine plant, conveyor controls, embedded telecoms work, etc, etc. An "embedded edition" of FreeBSD is definitely required... [snip] As far as PR goes, maybe what someone needs to do is make a checklist against the other market leaders in the embedded marketplace. Something that PHB types could look at and go "Golly, this has everything!" -- POSIX compliance, realtime support, drivers, protocols, development tools, support, etc. Someone should look at the other embedded players and see how they handle BSPs -- Board Support Packages. These are the "take these ten things and mix them together and voila, you have a working reference board". [snip] > It would be great if we could park a couple of developers full time > on embedded FreeBSD in the future, but that would take some serious > financial support from the user community, if you think your company > could be persuaded to help with this, get in touch with the FreeBSD > foundation. I would love to work on embedding FreeBSD; unfortunately, doing what I do, I have a money-driven scheduling algorithm. This means I'd either need to convince a "sugar daddy" employer that this would be a "Good Thing(TM)" or there'd have to be a sufficient infrastructure in place that it would be a no brainer, or someone would have to pay for development... Anyway, just sharing some random thoughts :-) Cheers, -RK -- Robert Krten, PARSE Software Devices Realtime Systems Architecture, Consulting, Books and Training at www.parse.com Looking for Digital Equipment Corp. PDP-1 through PDP-15 minicomputers!