GENERIC kernel (was Re: BeagleBone Crochet Build Problem)

[Russell Haley]

On Tue, Oct 3, 2017 at 3:55 PM, Warner Losh <imp at bsdimp.com> wrote:
> On Tue, Oct 3, 2017 at 4:10 PM, Ian Lepore <ian at 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 at 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?

Russ