Date: Tue, 3 Oct 2017 23:12:06 -0600 From: Warner Losh <imp@bsdimp.com> To: Russell Haley <russ.haley@gmail.com> Cc: Ian Lepore <ian@freebsd.org>, freebsd-arm@freebsd.org Subject: Re: GENERIC kernel (was Re: BeagleBone Crochet Build Problem) Message-ID: <CANCZdfqCtnjB4vXo7nQ7yH6uuaegT6jCxLtb5dbusqKtQ9jD=g@mail.gmail.com> In-Reply-To: <CABx9NuTnvPK7awiNF%2B7-CuuyuuBbuN=pKO_h25r0eVf3HLP=dw@mail.gmail.com> References: <176dbdd5-1a32-06b2-7dd8-0647cc0fbe20@acm.org> <1506954050.22078.55.camel@freebsd.org> <CABx9NuS9XAfWNHM1fAFKV8byhWyv=jXS_W%2BNO3Y6s-CtEQdp6A@mail.gmail.com> <1506962766.22078.69.camel@freebsd.org> <20171003170053.GB2918@lonesome.com> <8eb57091-0b6f-3f0a-8c80-997b951a383f@acm.org> <CANCZdfr%2B7Kpz5Qqz46NHWV=9PgNGhf7nDo4m3UxN1pA6fzgjSA@mail.gmail.com> <1507068609.86205.81.camel@freebsd.org> <CANCZdfo0z%2B-NacmAwh3kB9cpFKzx%2B7emR7hEko8K63otiEXsNA@mail.gmail.com> <CABx9NuTnvPK7awiNF%2B7-CuuyuuBbuN=pKO_h25r0eVf3HLP=dw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Oct 3, 2017 9:50 PM, "Russell Haley" <russ.haley@gmail.com> wrote: On Tue, Oct 3, 2017 at 3:55 PM, Warner Losh <imp@bsdimp.com> wrote: > On Tue, Oct 3, 2017 at 4:10 PM, Ian Lepore <ian@freebsd.org> wrote: > >> On Tue, 2017-10-03 at 14:55 -0600, Warner Losh wrote: >> > On Tue, Oct 3, 2017 at 2:03 PM, Thomas Laus <lausts@acm.org> wrote: >> > >> > > >> > > On 10/03/17 13:00, Mark Linimon wrote: >> > > > >> > > > On Mon, Oct 02, 2017 at 10:46:06AM -0600, Ian Lepore wrote: >> > > > > >> > > > > Why are we working towards a GENERIC kernel for arm? >> > > > My intuition would be: >> > > > >> > > > - easier to tell new FreeBSD users how to start >> > > > - less work for Release Engineering to make targets >> > > > >> > > > OTOH I'm not doing the work so I don't get to set the >> > > > direction :-) >> > > > >> > > > My _opinion_ is that we still seem to have a steeper >> > > > curve for our new users than is necessary. I intend to >> > > > think about that more this fall. >> > > > >> > > That is probably 'wishful thinking' for the very distant future. Most >> > > of the common ARM SOC's have very different capabilities between each >> > > other. Each also requires a unique U-Boot partition that gets read >> > > before the FreeBSD kernel is loaded. >> > > >> > While this is true, how to create them can be described generically. You >> > put these bits in this physical location, or on that partition and away >> you >> > go. The pre-boot environment is indeed different, but it's highly >> desirable >> > to have everything after that identical. It ensures uniformity in a >> highly >> > fragmented segment of our user base. Different kernels, even generated >> from >> > the same sources, run the risk of being subtly different from each other, >> > leading to less coverage between the boards. We've had issues related to >> > this in the past from time to time. >> > >> > I'm working on a program I'm calling "spin" which will take a description >> > of what to use (eg, u-boot for the banana ramma board plus FreeBSD 12.3R) >> > and it will create a bootable image knowing nothing more. If it also has >> to >> > know which of a bazillion kernels to use, that makes things more >> > complicated. >> > >> > We want more uniformity, not less. Much of the differences we have today >> > are arbitrary (and often wrong). >> > >> > >> > > >> > > I strongly favor the current approach that has a custom kernel >> > > configuration file and U-Boot for each SOC. All of the common ARM >> > > systems have a limited amount of real estate to store FreeBSD kernel >> and >> > > base system because it all must fit on a SD memory card. Having a >> > > GENERIC kernel that covers all SOC variants would consume flash space >> > > that will never be used. >> > >> > Nobody is saying that you can't do this. Just that GENERIC will be the >> > union of all these kernel and be what you get by default. Since nobody >> has >> > quantified the differences, I'm having trouble getting worked up over the >> > somewhat trivial difference in size (especially compared to most SD cards >> > today). >> > >> > Warner >> >> Well, I guess I'll stop pretending there's any chance this freight >> train can be stopped. I find the advantages mentioned so far dubious >> at best, specious at worst, except for the single item "packaged base". >> I don't know much about how that stuff is structured, but I can see >> how having lots of different kernels might be difficult for packaging. >> >> But we absolutely have to solve the problem of making it easy for >> people to create custom kernel configs. "Include GENERIC and add some >> nodevice/nooption lines" is just not going to work. Right now I use >> "include IMX6" and then some nodevice/nooption lines, and that works >> fine. >> >> So if IMX6 goes away as a standalone buildable config, there needs to >> be some other thing like it that can be included. The idea that keeps >> nudging me is that our GENERIC should look like: >> >> include std.armv6 >> include std.armdebug >> include std.a10 >> include std.a20 >> include std.bcm2835 >> include std.imx6 >> ... >> >> Now anybody can create a custom config by including std.armv6, >> std.armdebug if they want it, and their soc's std file. (The >> std.armdebug is also for re@, so that it's easy for them to adjust when >> making releases.) >> >> The problem is that I'm so backed up with other obbligations and >> problem reports not getting dealt with and of course $work, so I never >> find any time to give a scheme like this a try. >> > > I welcome others to try to do this. You'll find it is a bit like peeling an > onion. You don't have orthogonal classes so much as a venn diagram. I want > to support ALL SoCs for the bcm2835 family? Or I just want to support one > specific one. Allwinner makes this especially noticeable since it has a > large family of things. And then do you slice the supported devices up via > busses (only include those devices on PCI bus) vs device type (only include > network devices). But then you get people wanting to have just wireless > devices, or just USB wireless devices. You quickly discover a combinatoric > explosion if you want to do this generically. > > I'll see if I can find some time take a shot at doing it just at the SoC > level, but doing it generically gets really ugly really quickly.... Solving > that specific problem doesn't look too awful. > > Warner My ignorance on this subject allows me to ask an obtuse question: Is there no way to do something more dynamic and maintainable with kldload and ubldr using scripts? As Warner has pointed out, there are more arm variants, more manufacturers/SOM makers and more board variants every year. Stuffing everything in and then "un-including" everything doesn't sound maintainable. Even Ians suggestion may get cumbersome in a short time. What if we actually do get good support for Qualcom chips? Think of how many phone makers are there? Someone would need to tag all the Fdt Drivers with PNP info first. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfqCtnjB4vXo7nQ7yH6uuaegT6jCxLtb5dbusqKtQ9jD=g>