From owner-svn-src-all@FreeBSD.ORG Fri May 17 14:44:41 2013 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 16564227; Fri, 17 May 2013 14:44:41 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 064A4FA; Fri, 17 May 2013 14:44:39 +0000 (UTC) Received: by mail-wi0-f175.google.com with SMTP id hn14so515318wib.8 for ; Fri, 17 May 2013 07:44:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=UhcAbtNlZx4zjROh8oGNzQFMyw4ZZkuNoKuBEwO2+GU=; b=eJq0x1Rrz0xzmZ/nwA8blW5IqDH9x5GoPEszPmzqNDUKpwWfRddTqSzqTd4RN+uMFN zpyPPCPw05IUzBzB0J3qmJ6D8QN7N9QUPH8A2EKWe5Bw5FiVhjpJweu10yDJTbnQIKX1 xTvrswMWdZxltxk0BYwez2g4Cj4xS0FUYjxSQtCLHp7/A3zGvIQuRtXXc3JCK/BeyEqR phOjbFib7Jmr54XEQ3+c8M4Pz2d2Bu9o9k1MITx34lilY/61had4nL+bBvZYI2JySwn0 LOCYv5QMLwvVvkiloZSG+4bNdKIkCk5XpUQi11UHUwho8qJOXBOm0Jvm71Gm/D79xws8 10Aw== MIME-Version: 1.0 X-Received: by 10.181.13.169 with SMTP id ez9mr17748446wid.8.1368801467765; Fri, 17 May 2013 07:37:47 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.58.138 with HTTP; Fri, 17 May 2013 07:37:47 -0700 (PDT) In-Reply-To: <6C1AD894-149B-4E08-90DB-2BC3899A4CE8@FreeBSD.org> References: <201305160351.r4G3p0uu047404@svn.freebsd.org> <30BAC0E1-9E8F-4FA4-A31E-C2AFAFDBCB95@freebsd.org> <6C1AD894-149B-4E08-90DB-2BC3899A4CE8@FreeBSD.org> Date: Fri, 17 May 2013 07:37:47 -0700 X-Google-Sender-Auth: 336nueMKCX-B2FDY8HgnQA_AGQc Message-ID: Subject: Re: svn commit: r250692 - head/sys/arm/conf From: Adrian Chadd To: Tim Kientzle Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Rui Paulo X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 14:44:41 -0000 .. if there were only a way we could glue together different elf binaries into some kind of "archive" that let people load a set of modules as part of a kernel. We could call it initrd (ew) or something. adrian On 17 May 2013 05:45, Tim Kientzle wrote: > > On May 16, 2013, at 9:49 PM, Rui Paulo wrote: > >> On 2013/05/16, at 2:02, Tim Kientzle wrote: >> >>> I don't object, but I'm not sure why we need this. >>> >>> I'd rather see a comment in the BEAGLEBONE >>> config indicating that it can be used with >>> beaglebone-black.dts. >>> >>> Generally, I want us to move away from compiled-in >>> DTBs. The BEAGLEBONE config works just fine on either >>> one and it's what I plan to continue using going forward. >>> >>> Part of the boot loader's job is to load the correct DTB. >>> The images built by Crochet today already do this >>> and produce images that boot on either old or new >>> BeagleBone using the BEAGLEBONE config. >>> >>> U-Boot already has logic to detect the board, >>> load the correct DTB, and the same BEAGLEBONE >>> kernel then runs just fine. Here are the U-Boot >>> patches if you'd like to do this as well: >>> >>> https://github.com/kientzle/crochet-freebsd/tree/master/board/BeagleBon= e/files >>> >>> (There's also a copy of the compiled U-Boot and >>> associated files at: >>> >>> http://people.freebsd.org/~kientzle/beaglebone-and-black-bootfiles.tgz >>> >>> Moving forward, I'd like to see us generally consolidate ARM >>> kernel configurations. I have some (still very experimental) >>> ideas for combining the RPi and BeagleBone kernels >>> into a single kernel, but with my limited time, that will >>> be a fairly long-term project. If anyone's at BSDCan >>> who would like to talk about it=85. I'll be at the >>> "Beyond BuildWorld" session on Thursday=85. ;-) >>> >>> Yes, this is certainly useful for people net booting >>> the BeagleBone Black for developing kernel drivers, >>> but I'm not sure why we would bother having it >>> checked-in. >> >> >> I understand your point, but what about drivers that only apply to the B= eagleBone Black, such as a driver for HDMI? Wouldn't that require a separat= e kernel config file or are we expecting to use only kernel modules? > > Such a driver should be in the BeagleBone kernel config > but will only get turned on (by the FDT) on appropriate > boards. > > Yes, people who need small kernels for various reasons > will definitely need to hand-tune their kernel configs > to leave out drivers they don't want (such as an HDMI > driver on a BeagleBone white). But that doesn't mean > we need separate kernel configs in the tree for every > possible combination of hardware. That's what FDT is for. > > The proliferation of kernel configs is getting to be > a headache. > * "make universe" has to build all kernels, so we're > better off with fewer bulkier kernel configs. > * To more rapidly support new systems, we want to > be able to mix-and-match existing drivers. Right now, > drivers originally developed for different SoCs don't > even compile together, so we can't effectively leverage > existing code. There's a *lot* of cut-and-paste copying > of code in our ARM tree right now. I have some ideas > about how to unify some of the ARMv6 kernels and I'm > hoping to start gradually working on that over the next > few months. > > Ideally, I'd like to have a handful of "GENERIC" kernel > configs in the tree, each supporting a range of SoCs. > This will give us confidence that large sets of drivers > do all compile and play reasonably well together. It > will also make it feasible for people working on generic > driver infrastructure to get some real traction on things > like generic irq routing and pinmux support. (Brooks has > some interesting ideas about IRQ routing and Warner > has talked about better ways to do pinmux mapping.) > > It's easy for folks to trim configs if they need to do so > for particular applications. > > Tim >