From owner-freebsd-arm@FreeBSD.ORG Mon Feb 11 18:05:01 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 EB17A99B for ; Mon, 11 Feb 2013 18:05:01 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com [209.85.214.174]) by mx1.freebsd.org (Postfix) with ESMTP id B462B1D8 for ; Mon, 11 Feb 2013 18:05:01 +0000 (UTC) Received: by mail-ob0-f174.google.com with SMTP id 16so6372959obc.33 for ; Mon, 11 Feb 2013 10:04:54 -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=M4PJGqpRvM2lYaEJto3BN24ugqY9bDCoxDlOuVvVYIk=; b=bjMfHjDZoxiY7zTo/Jncl7P5DzJnJjIKPlBYxzR/oIXGmu5Z9QeV1vJyonw3xmvlw3 Z4XYktfVb8LyUMNihwMcCsffaSOfpyUE6HI6ibz9hbaDUHVi4XE3NIUfmanifp105Tyx rnCM2jOqkSpCGzRmk/+WVavdcrLlzjFn9EhA3jOawJhzC9GtrP4rl0EqIAxGsw8NpITo 4l9usC7tHrPFcbtlhW1xC2pKH6/fVpNfrCsrZYE+qyQhsgz28LKTyZbg98yxp+g2+aDJ f2WpMFaao4RH2QaUajGB0zc6GL1qLaIEvdJg/6W/seAMu1IczXtseteSrpNmTIolLOsI 6s0g== X-Received: by 10.60.4.35 with SMTP id h3mr11478634oeh.123.1360605894885; Mon, 11 Feb 2013 10:04:54 -0800 (PST) Received: from fusionlt2834a.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id v2sm49759048obl.10.2013.02.11.10.04.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Feb 2013 10:04:53 -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: <3F4CD7E5-17D4-4315-86BD-605F5C0040DC@kientzle.com> Date: Mon, 11 Feb 2013 11:04:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <780B5A66-2727-4E16-B912-93AAD7FDE21B@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> <3F4CD7E5-17D4-4315-86BD-605F5C0040DC@kientzle.com> To: Tim Kientzle X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQlim5fi265UD3S907XmqogrA7Q2Rj0IC4Y6WxsuV7wCACc/Ct2s/fFLwzhdUpaJT94J2XV5 Cc: freebsd-arm@freebsd.org, Brett Wynkoop , Ian Lepore 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:05:02 -0000 On Feb 11, 2013, at 10:14 AM, Tim Kientzle wrote: >>>> 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 > Here are several answers: >=20 > 1) The immediate result of this change will make > it *easier* to change the FDT. Right now, most people > are recompiling the kernel just to tweak the FDT. > This change moves it out into a separate standalone > file in the boot partition. (You still need to compile > the DTS, but you can at least change it and reboot > without touching the kernel.) This is good. > 2) We're still debating the role of the FDT vis a vis > end user customization. Personally, I would like > to find some more dynamic approach to handling > pinmux at runtime. (E.g., if you want to use a pin > for gpio, you do this: > $ gpioctl 1 7 out # Set gpio 1 7 for output, including pinmux = change > $ gpioctl 1 7 on > Similarly, I think that enabling uart2 should automatically > adjust the pinmux appropriately. These are also good, but we have a long ways to go in the kernel to get = there. And there are limits to how far you can push this envelope. However, enabling uart2 is also done through the FDT, at least in linux, = but it takes care of these pesky details for the most part. > 3) IIUC, the FDT concept came from the PowerPC > world, where the FDT is provided by the ROM. > It's not really a tool for customizing the system; it's a tool > for describing the hardware available. It is a tool to describe how the hardware is configured as well. It is = the only place where you can find how things are wired together. That's = its primary purpose. If you are customizing your hardware, you are = wiring it together differently. > 4) Ubldr already has tools for adjusting the FDT > dynamically at boot time. I just committed the > online help for this "help fdt". So you can indeed > adjust the FDT via loader.rc. That works today, even > when the FDT is compiled into the kernel. >=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 >> I think the basic problem here is a desire to treat u-boot as if it = were >> a PC BIOS, but it lacks some of what a traditional BIOS allows a user = to >> do in terms of configuring optional hardware and storing that config. >=20 > Right now, we're using U-Boot for exactly two things: > * Boot loader driver. Rather than writing board-specific > drivers for ubldr for every board, we get to leverage U-Boot. > * Providing the *default* FDT. >=20 > The code I circulated yesterday uses the following logic to find > the FDT: > 1) If an FDT was loaded into ubldr, use that. (E.g., "load -t dtb = filename") > 2) If U-Boot provided an FDT, use that. > 3) If the kernel has a compiled-in FDT, use that. Yes, I like that. Warner=