Date: Wed, 4 Oct 2017 08:17:45 -0600 From: Warner Losh <imp@bsdimp.com> To: Russell Haley <russ.haley@gmail.com> Cc: Ian Lepore <ian@freebsd.org>, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: GENERIC kernel (was Re: BeagleBone Crochet Build Problem) Message-ID: <CANCZdfpXOX%2B4-G3HkEKC35oDoS8yR1WEvrRiW9cf51PpXFQkjw@mail.gmail.com> In-Reply-To: <CABx9NuT1Jd5YuibU%2Bousg5JgiOwBQkw7txsR9vB90Gix622Xdw@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> <CANCZdfqCtnjB4vXo7nQ7yH6uuaegT6jCxLtb5dbusqKtQ9jD=g@mail.gmail.com> <CABx9NuT1Jd5YuibU%2Bousg5JgiOwBQkw7txsR9vB90Gix622Xdw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Oct 3, 2017 at 11:52 PM, Russell Haley <russ.haley@gmail.com> wrote:
> On Tue, Oct 3, 2017 at 10:12 PM, Warner Losh <imp@bsdimp.com> wrote:
> >
> >
> > 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
> Can you point me to an example of the PNP tags or where to get more
> info? Would that mean modifying the DTS files (which I believe are now
> replicated from GNU libraries)?
>
Sure. Look for SIMPLEBUS_PNP_INFO. Usually, you can point it at the compat
table. See sys/arm/ti/aintc.c:
...
/* List of compatible strings for FDT tree */
static struct ofw_compat_data compat_data[] = {
{"ti,am33xx-intc", 1},
{"ti,omap2-intc", 1},
{NULL, 0},
};
...
SIMPLEBUS_PNP_INFO(compat_data);
Without that data, you can't have a minimal kernel that then loads the
minimum modules.
There's some things that can't be kld-loaded, though. The biggest one
that's likely to be a hassle is console drivers. They have to exist before
the kld modules are linked into the kernel.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfpXOX%2B4-G3HkEKC35oDoS8yR1WEvrRiW9cf51PpXFQkjw>