About board-specific files.*

Andrew Turner andrew at fubar.geek.nz
Sun Mar 3 03:31:50 UTC 2013


On Sat, 2 Mar 2013 16:20:54 -0700
Warner Losh <imp at bsdimp.com> wrote:

> 
> On Mar 2, 2013, at 2:05 PM, Tim Kientzle wrote:
> 
> > Now that I think I understand some of the issues in building
> > a GENERIC arm kernel, I'm starting to piece together
> > a kernel that has both RPi and BBone bits that I can
> > use as a testbed.
> > 
> > Next Problem:  A lot of the boards are using
> > board-specific files.* to control what files get
> > linked into the kernel.
> > 
> > This seems like a real problem for a GENERIC kernel,
> > so I propose merging them into sys/conf/files.arm.
> > 
> > Here's how I'm doing it right now for my current
> > experiments.  If anyone has a better idea, I'm
> > definitely interested.
> > 
> > Basically, I'm using "device bcm2835" to represent
> > all of the basic support for that particular SoC.
> > (An SoC is, after all, just another piece of hardware.)
> > 
> > Then the files marked "standard" in
> > arm/bcm2835/files.bcm2835 move to
> > files.arm as "optional bcm2835".
> > 
> > With this approach, the GENERIC arm kernel will
> > list the SoCs as devices:
> > 
> >     device bcm2835
> >     device am335x
> >     device omap4
> >    … etc …
> > 
> > That will bring in the basic support for those SoCs
> > (e.g., interrupt handler, gpio, clock management, etc).
> > Additional drivers (SDHCI, UART, USB, etc) will
> > be separate devices.
> > 
> > I think this makes sense, but I'm open to other ideas.
> 
> I think this is perfect. It is what atmel uses to bring in different
> atmel things. I don't think there are any atmel files specified as
> std any more, and if there are they could transition to this.  I know
> this isn't an issue for a GENERIC for armv6, since there is not way
> an armv4 and an armv6 kernel could be built today...

I don't think that is a problem. We can have two GENERIC kernels, i.e.
an arm and an armv6 kernel. Having two GENERIC like kernels doesn't
preclude having a single GENERIC in the future, quite the opposite. We
are unlikely to have a GENERIC kernel for any hardware that doesn't
have fdt, or some other way to detect which SoC & board we are running
on.

Andrew


More information about the freebsd-arm mailing list