Date: Fri, 17 May 2013 07:37:47 -0700 From: Adrian Chadd <adrian@freebsd.org> To: Tim Kientzle <kientzle@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Rui Paulo <rpaulo@freebsd.org> Subject: Re: svn commit: r250692 - head/sys/arm/conf Message-ID: <CAJ-VmompqNUKQbjdvG4Rm48Kd3APxJ0KoX8rfVSe0XjG6FR=mQ@mail.gmail.com> In-Reply-To: <6C1AD894-149B-4E08-90DB-2BC3899A4CE8@FreeBSD.org> References: <201305160351.r4G3p0uu047404@svn.freebsd.org> <30BAC0E1-9E8F-4FA4-A31E-C2AFAFDBCB95@freebsd.org> <F16C3146-B85F-41D4-ACE4-FC0335DD16F6@FreeBSD.org> <6C1AD894-149B-4E08-90DB-2BC3899A4CE8@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
.. 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 <kientzle@freebsd.org> wrote: > > On May 16, 2013, at 9:49 PM, Rui Paulo wrote: > >> On 2013/05/16, at 2:02, Tim Kientzle <kientzle@freebsd.org> 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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmompqNUKQbjdvG4Rm48Kd3APxJ0KoX8rfVSe0XjG6FR=mQ>