From owner-freebsd-arm@FreeBSD.ORG Tue Mar 26 14:55:35 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 831764E8 for ; Tue, 26 Mar 2013 14:55:35 +0000 (UTC) (envelope-from george@ceetonetechnology.com) Received: from feynman.konjz.org (feynman.konjz.org [64.147.119.39]) by mx1.freebsd.org (Postfix) with ESMTP id 3EC3123F for ; Tue, 26 Mar 2013 14:55:34 +0000 (UTC) Received: from [192.168.1.104] (pool-173-77-66-223.nycmny.east.verizon.net [173.77.66.223]) (authenticated bits=0) by feynman.konjz.org (8.14.6/8.14.4) with ESMTP id r2QEirBg069498 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 26 Mar 2013 10:44:59 -0400 (EDT) (envelope-from george@ceetonetechnology.com) Message-ID: <5151B454.9090402@ceetonetechnology.com> Date: Tue, 26 Mar 2013 10:44:36 -0400 From: George Rosamond User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/20130312 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: RFC: "Crochet" build tool References: <5DFA61DB-70E4-4C3D-ACA0-995A175706C8@neville-neil.com> In-Reply-To: <5DFA61DB-70E4-4C3D-ACA0-995A175706C8@neville-neil.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Names: BAYES_00,FH_HOST_EQ_VERIZON_P,RDNS_DYNAMIC X-Mail-Provider: KonjZ X-Scanned-By: MIMEDefang 2.73 on 64.147.119.39 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: george@ceetonetechnology.com List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 14:55:35 -0000 On 03/26/13 10:15, George Neville-Neil wrote: > > On Mar 25, 2013, at 1:35 , Tim Kientzle wrote: > >> I've gone through another non-trivial round of refactoring >> for my build tool. Feedback appreciated. >> >> Most obviously, I've renamed the tool "Crochet" (to remove >> any implication that it is BeagleBone specific) and >> migrated it to a different github repository: >> >> https://github.com/kientzle/crochet-freebsd >> >> Config files from the earlier beaglebsd should still work. >> >> The biggest internal change: I've completely rethought >> how partitioning is handled. Instead of creating and populating >> each partition, it's now structured as: >> * Create all partitions >> * Mount all partitions >> * Populate each logical filesystem (boot and freebsd) >> >> In particular, it should be much easier to do complex >> partitioning with this structure. I've also added a few >> more customization hooks, refactored some of the board >> code, improved error handling, and added a lot more >> documentation. >> >> I've spent the last week verifying that this version can >> build bootable images for RaspberryPi, BeagleBone, >> and Pandaboard ES. (I don't have any other boards >> to try with.) >> >> It also has two special board definitions: >> * NewBoardExample is a skeleton that can be cloned >> and used as a (thoroughly-commented) starting point >> for new board definitions. >> * BeagleBonePlusRaspberryPi is a proof-of-concept >> for a single image that can boot on more than one board. >> (There's a chunk of kernel work yet to be done before >> this really works. This just proves out the boot bits.) >> >> Tim >> >> P.S. The name "crochet" was developed partly by searching >> for " FreeBSD" for a bunch of different candidate names. >> After only a week, my github repository is already the top three >> Google hits for "crochet freebsd," so the name seems to be working. >> > > Hi Tim, > > I think this is some good stuff, but, I am wondering, can we figure out a better way > to integrate this into the main FreeBSD tree? We have, over the years, had various ways > of building images for embedded FreeBSD, such as pico and nanobsd etc. The > thing that would really help most is to make all this main stream and "just part of the > build" even if it's just putting the scripts in some simple interior location. Have > you given much thought to that? > > That being said, I'll try this set of scripts out soon. > Integrating into base would be nice. My question would be: just for ARM, or as Tim mentions in his script, potentially for other architectures also? If so what would be benefit/difference with NanoBSD if Tim's script was used for other architectures? For embedded-type systems on i386, I always built my own and never got into Nano. g