From owner-freebsd-arm@FreeBSD.ORG Mon Feb 11 17:03:25 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C67C4120 for ; Mon, 11 Feb 2013 17:03:25 +0000 (UTC) (envelope-from iain@g7iii.net) Received: from hal.g7iii.net (unknown [IPv6:2600:3c02::f03c:91ff:feae:1cbe]) by mx1.freebsd.org (Postfix) with ESMTP id A7781F16 for ; Mon, 11 Feb 2013 17:03:25 +0000 (UTC) Received: from [192.168.39.76] (157.17.187.81.in-addr.arpa [81.187.17.157]) by hal.g7iii.net (Postfix) with ESMTP id E04DD208F5 for ; Mon, 11 Feb 2013 17:03:23 +0000 (UTC) Message-ID: <5119245A.5070704@g7iii.net> Date: Mon, 11 Feb 2013 17:03:22 +0000 From: Iain Young User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: building RaspPi Images References: <5116CB50.9080303@ceetonetechnology.com> <7757848F-45C6-4DEF-A4A2-5F900EB10A06@kientzle.com> <20130210012052.4d7e1a46@ivory.local> <58DCA6BE-8C06-4F69-81A2-A3582FBB5B12@kientzle.com> <1360598511.4545.92.camel@revolution.hippie.lan> <1360600007.4545.98.camel@revolution.hippie.lan> In-Reply-To: <1360600007.4545.98.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 17:03:25 -0000 On 11/02/13 16:26, Ian Lepore wrote: > On Mon, 2013-02-11 at 09:10 -0700, Warner Losh wrote: [SNIP] >>>> The real solution here is to get the FDT plumbed through from the boards primary boot strap code into our code. Linux requires that this be passed in via like r2 for Linux to boot. We should make use of that too. >>>> >>>> Warner >>> >>> I'm seeing an essential conflict here in the mission of FDT data. If >>> changing the FDT is the way an end user customizes things like pinmux >>> assignments ("I need these pins for gpio, not another uart"), then how >>> can we just accept a cannonical hardware description from low-level boot >>> code we have no control over? >> >> If you are going to do crazy things like this, then you supply your own custom FDT. If you use the board in its stock configuration, then you use the thing from the boot loader. If you hack the board, you have to hack the FDT to match... > > That's a massively unsatisfying answer. It makes sense for something > like a DreamPlug that's sold as a consumer unit; the phrase "stock > config" makes some sense there. > > What's the stock configuration of a BeagleBoard? Pretty much every ball > on the chip is brought out to one of two headers on the board so that > you can use the board for virtually anything you want. Note: Linux also allows you to change the pinmux stuff once you've booted (It brings them up with their "default" mux setting, then you can change it by poking around in /sys/kernel/debug/omap_max) For example, to enable UART3_CTS on pin 36 of P8, you do: echo 26 >/sys/kernel/debug/omap_mux/lcd_data10 I'm not aware FreeBSD has any such mechanism at present. Iain (who's svn co of /usr/src has finally finished, and will now start buildworld and buildkernel after that before testing his patch to enable UARTS1-4)