Date: Sun, 03 Mar 2013 16:31:39 +1300 From: Andrew Turner <andrew@fubar.geek.nz> To: Warner Losh <imp@bsdimp.com> Cc: freebsd-arm@freebsd.org Subject: Re: About board-specific files.* Message-ID: <20130303163139.3af41ae5@bender> In-Reply-To: <58FF3A9F-2782-429F-BE82-27728E8D209D@bsdimp.com> References: <FB7CD2D3-12A6-452B-BEBD-DE0B4B01A626@freebsd.org> <58FF3A9F-2782-429F-BE82-27728E8D209D@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 2 Mar 2013 16:20:54 -0700 Warner Losh <imp@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130303163139.3af41ae5>