svn commit: r250692 - head/sys/arm/conf

[Adrian Chadd]

.. 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 at freebsd.org> wrote:
>
> On May 16, 2013, at 9:49 PM, Rui Paulo wrote:
>
>> On 2013/05/16, at 2:02, Tim Kientzle <kientzle at 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/BeagleBone/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….  I'll be at the
>>> "Beyond BuildWorld" session on Thursday….  ;-)
>>>
>>> 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 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
>