About board-specific files.*

[Warner Losh]

On Mar 2, 2013, at 8:31 PM, Andrew Turner wrote:

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

Yes. I'd love to see Atmel move to FDT, but my time for hacking that lately has meant almost no progress.  For other, older armv4/5 parts, those could be part of LINT, but not GENERIC, or we can drop support for them...

Warner

Warner