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