Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 2 Mar 2013 16:20:54 -0700
From:      Warner Losh <imp@bsdimp.com>
To:        Tim Kientzle <kientzle@freebsd.org>
Cc:        freebsd-arm@freebsd.org
Subject:   Re: About board-specific files.*
Message-ID:  <58FF3A9F-2782-429F-BE82-27728E8D209D@bsdimp.com>
In-Reply-To: <FB7CD2D3-12A6-452B-BEBD-DE0B4B01A626@freebsd.org>
References:  <FB7CD2D3-12A6-452B-BEBD-DE0B4B01A626@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help

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.
>=20
> Next Problem:  A lot of the boards are using
> board-specific files.* to control what files get
> linked into the kernel.
>=20
> This seems like a real problem for a GENERIC kernel,
> so I propose merging them into sys/conf/files.arm.
>=20
> Here's how I'm doing it right now for my current
> experiments.  If anyone has a better idea, I'm
> definitely interested.
>=20
> 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.)
>=20
> Then the files marked "standard" in
> arm/bcm2835/files.bcm2835 move to
> files.arm as "optional bcm2835".
>=20
> With this approach, the GENERIC arm kernel will
> list the SoCs as devices:
>=20
>     device bcm2835
>     device am335x
>     device omap4
>    =85 etc =85
>=20
> 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.
>=20
> 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...

Warner=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?58FF3A9F-2782-429F-BE82-27728E8D209D>