From owner-freebsd-arm@FreeBSD.ORG Mon Feb 11 18:01:28 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 428E592B for ; Mon, 11 Feb 2013 18:01:28 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f177.google.com (mail-ob0-f177.google.com [209.85.214.177]) by mx1.freebsd.org (Postfix) with ESMTP id E9D5C1B5 for ; Mon, 11 Feb 2013 18:01:27 +0000 (UTC) Received: by mail-ob0-f177.google.com with SMTP id wc18so6416894obb.36 for ; Mon, 11 Feb 2013 10:01:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=Gdx68cN2hZ5WNkGWe/Arv93VU30+lvX7rLv+RWcRjOo=; b=jG8Vl1PSwHFxceSfnHAYzVn1yIiKpNwvhTuCsM943ElQIrIrMT4BgwBtu0JMPH2kBR NwrpQkT3DSYrnm1/ah7n5Nb7eEzlYKbbk0IpSmza89O7taINjgObn4V94ziTrfgO6miy wwB3J8d5FaLwLLhNFIsOA8PXXLibZBHD5zHe6DbUOlcIkPTxjvDv6vn3GVP81SUs84Er S42mZYqLIDv41hZbBy2EGnDw75Vaibr80YVuPUa/lpXSeVe4qrK/M408hrW3BR1cVMUh 1TxUE1po+iVFp9XmV0osyBaX6SkCWvj/OYU6mOJy75H09rxt5fm9GFIpbd4+QxMmZxte lxbw== X-Received: by 10.60.26.137 with SMTP id l9mr11395706oeg.17.1360605686922; Mon, 11 Feb 2013 10:01:26 -0800 (PST) Received: from fusionlt2834a.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id v8sm49771186obj.1.2013.02.11.10.01.25 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Feb 2013 10:01:25 -0800 (PST) Sender: Warner Losh Subject: Re: building RaspPi Images Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <5119245A.5070704@g7iii.net> Date: Mon, 11 Feb 2013 11:01:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <21D847EF-A61F-4612-A301-D2FC1D3AFAB1@bsdimp.com> 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> <5119245A.5070704@g7iii.net> To: Iain Young X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQn7lomCTUfQrxiMtP+4JjTeoli8uG5u+cmW5jlAsAUg3V5SVUFqBakV8fn2drcUYYMtHwdg Cc: freebsd-arm@freebsd.org 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 18:01:28 -0000 On Feb 11, 2013, at 10:03 AM, Iain Young wrote: > On 11/02/13 16:26, Ian Lepore wrote: >> On Mon, 2013-02-11 at 09:10 -0700, Warner Losh wrote: >=20 > [SNIP] >=20 >>>>> 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. >>>>>=20 >>>>> Warner >>>>=20 >>>> 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? >>>=20 >>> 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... >>=20 >> 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. >>=20 >> 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. >=20 > 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) >=20 > For example, to enable UART3_CTS on pin 36 of P8, you do: >=20 > echo 26 >/sys/kernel/debug/omap_mux/lcd_data10 >=20 > I'm not aware FreeBSD has any such mechanism at present. Yea, we're late to the pinmux/pinctl/gpio party here :( Warner=