Date: Fri, 17 May 2013 08:45:44 -0400 From: Tim Kientzle <kientzle@FreeBSD.org> To: Rui Paulo <rpaulo@FreeBSD.org> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r250692 - head/sys/arm/conf Message-ID: <6C1AD894-149B-4E08-90DB-2BC3899A4CE8@FreeBSD.org> In-Reply-To: <F16C3146-B85F-41D4-ACE4-FC0335DD16F6@FreeBSD.org> References: <201305160351.r4G3p0uu047404@svn.freebsd.org> <30BAC0E1-9E8F-4FA4-A31E-C2AFAFDBCB95@freebsd.org> <F16C3146-B85F-41D4-ACE4-FC0335DD16F6@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On May 16, 2013, at 9:49 PM, Rui Paulo wrote: > On 2013/05/16, at 2:02, Tim Kientzle <kientzle@freebsd.org> wrote: >=20 >> I don't object, but I'm not sure why we need this. >>=20 >> I'd rather see a comment in the BEAGLEBONE >> config indicating that it can be used with >> beaglebone-black.dts. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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: >>=20 >> = https://github.com/kientzle/crochet-freebsd/tree/master/board/BeagleBone/f= iles >>=20 >> (There's also a copy of the compiled U-Boot and >> associated files at: >>=20 >> = http://people.freebsd.org/~kientzle/beaglebone-and-black-bootfiles.tgz >>=20 >> 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. ;-) >>=20 >> 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. >=20 >=20 > I understand your point, but what about drivers that only apply to the = BeagleBone Black, such as a driver for HDMI? Wouldn't that require a = separate 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?6C1AD894-149B-4E08-90DB-2BC3899A4CE8>