From owner-freebsd-arm@FreeBSD.ORG Thu Jan 26 08:07:27 2012 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A69D51065672 for ; Thu, 26 Jan 2012 08:07:27 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 478868FC0C for ; Thu, 26 Jan 2012 08:07:27 +0000 (UTC) Received: from [10.0.0.63] (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id q0Q82SGQ023450 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Thu, 26 Jan 2012 01:02:30 -0700 (MST) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <214BF14D-33BA-4D3D-B043-31008E24F7AE@kientzle.com> Date: Thu, 26 Jan 2012 01:02:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <43F1CB8E-8034-4658-9D38-E1F66202521C@bsdimp.com> References: <23CB6C35-9450-40BA-9FA3-37C44B328CA8@freebsd.org> <8042D895-3B3D-431E-ADCC-A150BDC838ED@kientzle.com> <7E53112E-DE29-4145-B597-D39AA77252C5@kientzle.com> <101D3416-6B61-4840-A89E-4CF91B0BB8BC@kientzle.com> <214BF14D-33BA-4D3D-B043-31008E24F7AE@kientzle.com> To: Tim Kientzle X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Thu, 26 Jan 2012 01:02:30 -0700 (MST) Cc: arm@FreeBSD.org Subject: Re: FreeBSD and BeagleBone X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 08:07:27 -0000 On Jan 25, 2012, at 10:34 PM, Tim Kientzle wrote: > On Jan 25, 2012, at 2:06 PM, Rafal Jaworowski wrote: >> On 2012-01-22, at 00:29, Tim Kientzle wrote: >>=20 >>>=20 >>> P.S. Is it worth trying to generalize the ubldr Makefile >>> to accept some form of link address specification? >>=20 >> In general yes, the challenge is how to do this in a smart and = flexible way: loader/ubldr is built as part of the world which you don't = want to entagle with platform specific knobs. On the other hand a = configurable like this is specific to some board (not even a chip, soc = or a familiy, anybody can have their U-Boot configured differently = underneath..), so the question is how to convey this knowledge. >=20 > I know Warner has some ideas for organizing the tree to include > board information. If each board has a directory, then > you could build a custom ubldr for each board. That > feels a little heavyweight to me, though. The basic idea I had was expanded from what Sam did originally with the = Avila support. Each SoC would have a directory and under that there'd = be a 'boards' directory. This directory would have a number of files. = Each file would have a structure that would link into a list of boards = (or more than one). This structure would contain a 'probe' or 'match' = routine that would be called to discover which of these board structures = matched. The one that matched would then be used to fill in other = details into the SoC's structure. things like clock speed, pin wiring, = etc. Much of that is now covered by FDT, and one field could be a = 'replacement fdt' file since most ARM boot loaders don't present a FDT = to the kernel. This would get away from having too many things hard-wired via #defines = and move instead to having more computed at run time via a structure = dereference, maybe with a little math. This would also allow us to have = one kernel that booted on all AT91RM9200 boards, or possibly all atmel = ARM boards or maybe even all armv4, armv5 and armv6 boards depending on = how far we take this idea. > The closest thing to a board description we have is > the kernel config. That reflects the hardware and layout > of the board being targeted. Is there some way to have > ubldr made by buildkernel instead of buildworld? We already do that for aicasm unconditionally. It might take a bit of = tricky logic to do this conditionally. Well, the unconditional stuff is = just for modules, we do it conditionally based on what's in the kernel, = so there's a path blazed there already since this utility wouldn't be = needed to build a module. > Another approach might be to provide a build script that > accepts arguments and spits out a compiled ubldr to > match those parameters. Maybe something like: >=20 > $ cd /usr/src/sys/tools/ubldr-build > $ ./ubldr-build arm.arm -l 0x80010000 -o ubldr.beagle We already have makefile targets for compressed kernels, this could = easily be another of them. Warner