From owner-cvs-doc@FreeBSD.ORG Fri May 12 14:50:47 2006 Return-Path: X-Original-To: cvs-doc@FreeBSD.org Delivered-To: cvs-doc@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 83D9816A6DA; Fri, 12 May 2006 14:50:47 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id F387343D70; Fri, 12 May 2006 14:50:46 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k4CEnhva066368; Fri, 12 May 2006 08:49:44 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 12 May 2006 10:49:54 -0400 (EDT) Message-Id: <20060512.104954.118629167.imp@bsdimp.com> To: scottl@samsco.org From: "M. Warner Losh" In-Reply-To: <44641993.5090403@samsco.org> References: <200605111952.57682.jhb@freebsd.org> <20060512.001308.126925417.imp@bsdimp.com> <44641993.5090403@samsco.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: bmah@FreeBSD.org, andre@FreeBSD.org, cvs-doc@FreeBSD.org, jhb@FreeBSD.org, cvs-all@FreeBSD.org, doc-committers@FreeBSD.org Subject: Re: FreeBSD/arm X-BeenThere: cvs-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the doc and www trees List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2006 14:50:49 -0000 In message: <44641993.5090403@samsco.org> Scott Long writes: : M. Warner Losh wrote: : > arm was in 6.0 : > : > Warner : : I think what John meant was that there is no release engineering for : ARM. You and I and several others have talked on and off about this : for a while, but I'd like to make it formal here.... : : Thanks to the work of Olivier Houchard, Warner Losh, John-Mark Gurney, : and others whom I'm probably forgetting, FreeBSD is gaining a working : and viable framework for supporting the ARM platform. However, saying : that ARM is supported is a complicated statement, unlike saying that : amd64 is supported. With ARM, there is no one true commodity reference : platform. Instead, there are choices of cores, buses, and peripherals. : Some systems are single chip with very specific components, some are a : bit more open and flexible. Think of it as an a-la-carte system. So, : saying that there is ARM support is not a universal statement and must : be qualified. What FreeBSD provides for ARM: : : - A toolchain capable of generating ARM binaries, kernels, and bootstrap : bits in both native and cross-compile modes. : - Basic bootstrap and operational support for ARM9 and some preliminary : support for XScale and StrongARM. : - Glue device support for a couple of specific prototype and development : ARM boards. I believe that this includes PCI and PC-102 bus support. : - Device driver support for a specific selection of platform-specific : devices. : : What these amount to is a framework that companies and hobbyists can use : to support the ARM9, XScale, and StrongARM solution of thier choosing. : Since every ARM system is different, there are likely to be pieces that : will need to be added and/or fixed in order to support a specific : system, but what exists now does work on at least one AT91-series system : and can be used as a functional model for other systems. : : That this is a framework and not a complete platform, the normal FreeBSD : support model is different as a result. Since there is no universal : consumer ARM platform, it is unlikely that there will be any release : engineering support. There also is likely to be little, if any, package : building or documentation support, other than what interested developers : contribute on their own. There is also not an expectation that the : general developer community will target ARM with feature additions or : changes that happen to other platforms. I'm sure that every effort will : be made to keep API changes within the kernel and userland consistent : across all platforms, but the ultimate responsibility of keeping ARM : working lies with the developers that are interested in it. : : That said, the ARM work has been growning almost exponentially in recent : months. It is a very valuable addition to FreeBSD, as it opens our OS : to a much larger world of embedded appliances and applications. FreeBSD : provides features such as netgraph that are unique among other embedded : OS's and provide value and opportunities for interested users. So to : all those involved, bravo! If this is a long way of saying 'we should list it on the main page,' I agree. :-) One thing that the project will need to define in the coming months is what to do about embedded architectures. ARM is approaching Tier 1 status for an embedded system as work progresses. Others will no doubt one day follow. Another thing that would be useful for the project is to document how to create images for these systems. Presently, this is complex and tedious. That's also a problem. NetBSD has better cross build support than we do today (we do a great job of building the base cross, but a poorer job at allowing other things to be cross built, especially for scripted builds). We need some web pages so that it shows up on Google and Yahoo searches. We need to focus on certain readily available boards, and recommend them on our web pages. We also need better vendor relations. We have 13 years of vendor relationship building in the i386/amd64/sparc world. However, the vendor relationships in the embedded world is less mature. We need multiple developers interfacing with the vendors, as well as with each other. Fortunately, it seems that we've reached critical mass with the FreeBSD embedded developers. I can count at least 10 here at BSDCan. In the past, we've used the 10 developer rule: If there's 10 developers that routinely do something, then it is well supported. If we can keep that level of interest and build on it, then FreeBSD's use in the embedded nitch will continue to expand.. Warner