Date: Fri, 12 May 2006 10:49:54 -0400 (EDT) From: "M. Warner Losh" <imp@bsdimp.com> To: scottl@samsco.org 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 Message-ID: <20060512.104954.118629167.imp@bsdimp.com> In-Reply-To: <44641993.5090403@samsco.org> References: <200605111952.57682.jhb@freebsd.org> <20060512.001308.126925417.imp@bsdimp.com> <44641993.5090403@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <44641993.5090403@samsco.org>
Scott Long <scottl@samsco.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060512.104954.118629167.imp>