From owner-freebsd-arm@FreeBSD.ORG Mon Feb 11 17:42:45 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 3553469C for ; Mon, 11 Feb 2013 17:42:45 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id ED77B101 for ; Mon, 11 Feb 2013 17:42:44 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r1BHghdI067273 for ; Mon, 11 Feb 2013 10:42:44 -0700 (MST) (envelope-from ian@FreeBSD.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r1BHgfAC039827; Mon, 11 Feb 2013 10:42:41 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: building RaspPi Images From: Ian Lepore To: Tim Kientzle In-Reply-To: <3F4CD7E5-17D4-4315-86BD-605F5C0040DC@kientzle.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> Content-Type: text/plain; charset="us-ascii" Date: Mon, 11 Feb 2013 10:42:41 -0700 Message-ID: <1360604561.4545.115.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org, Brett Wynkoop 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:42:45 -0000 On Mon, 2013-02-11 at 09:14 -0800, 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? > > Here are several answers: > > 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.) > I actually find it much easier to recompile the kernel than any of the other alternatives I've run into, but I understand that an end user would see it differently. I also find that while I'm trying to be open-minded about fdt in general, I still find it much more cumbersome to work with than the old hints system. The very fact that you need a special compiler to change the fdt data is part of that. In general, the fdt data seems to be good at describing hardware relationships that are hard to express with simple hints, such as how pins that generate interrupts are mapped between various devices and interrupt controllers. But it seems to be hard to use when the nature of the customizations are simple choices. > 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. > I whole-heartedly agree with that last sentence, but it's about a zillion miles from where our code is now. I'm not even sure it's fully possible, it just seems like a nice generic ideal "I asked for a uart, so the uart driver should enable power, enable clocks, and assign pins to make that happen." The problem crops up when "assign pins" has several sets of pins to choose from for a given device, and I know at least the Atmel SoCs do this a lot. > 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. > > 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. > I'll look into this, although when I was playing with it a couple weeks ago, I was having a hard time doing *anything* with loader.rc at all. That got me involved in trying to get the forth code running so that we'd have the full btx-loader goodness in the arm world with loader.conf files that we're all familiar with already. That was going pretty well except for our kernels not having proper elf headers, and I started to sidetrack to fix that, and then $work happened and I haven't gotten back to any of it yet. -- Ian > >> 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. > > > 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. > > 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. > > 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.