About board-specific files.*

[Warner Losh]

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...

Warner