[yocto] [meta-rockchip] defconfig alternatives

["Yann Dirson" <yann.dirson@blade-group.com>]

Hi Trevor,

Le lun. 22 mars 2021 à 16:50, Trevor Woerner <twoerner@gmail.com> a écrit :
> > BTW, I'm also unclear on what to do next to better support those
> > boards: with the default
> > kernel config only a subset of the hardware is supported, and for
> > state-of-the-art hw
> > support we'll also need patches not yet in upstream kernel (from eg.
> > armbian and libreelec).
> >
> > I feel it would be good to provide defconfig files for those machines,
> > but then there are
> > several options to handle that.  Would a minimal hw-focused defconfig
> > suitable for
> > `KCONFIG_MODE = "--allnoconfig"` be a good option ?
>
> I feel exactly the same way.
>
> By default all arm64 kernels are configured with the one, in-kernel, generic
> arm64 defconfig. That gives me a kernel that is over 11MB in size, and
> includes all sorts of useless drivers.
>
> I've been working off-and-on on a mechanism for meta-rockchip that would allow
> users to decide between the default in-kernel arm64 defconfig (which would
> be selected by doing nothing) or using a leaner defconfig that I have been
> tweaking specifically for each board. Currently I only have a lean defconfig
> for rock-pi-4b, but it was my hope to generate defconfigs for all supported
> boards.
>
> Ideally I had wanted to leverage the linux-yocto kmeta mechanism to generate
> defconfigs dynamically based on the specific machine and specific user
> preferences, but that didn't go as smoothly as I was hoping, then I got
> distracted by other things.
>
> I had created a spreadsheet with a comparison between the various boards that
> would have been a basis for the individual kmeta pieces. Maybe I'll find some
> more time to poke at it later this week. I could also push my WIP stuff to
> somewhere if you'd like to take a look.
>
> In any case, my point is, I'm very interested in something better than what
> currently exists :-)

On my side I have a minimal defconfig for our own board, which is very similar
to the nanopi-m4, which could be used as a starting point for the latter.


> One thing that I'd like to keep clear in meta-rockchip is to always allow the
> user to choose between upstream and "extras". My feeling is: the simplest
> build, if the user does nothing explicit, will always pull from pure upstream
> with no out-of-tree patches or vendor pieces. But I'm not opposed to having
> a mechanism whereby if the user does something explicit, they can choose to
> use a vendor tree or make use of out-of-tree patches for various things.

One possibility would be using a KERNEL_CONFIG_VARIANT variable, whose
values would select consistent sets of KBUILD_DEFCONFIG + KCONFIG_MODE
+ SRC_URI_append.  Standard variants could include "mainline" as the
default, and
maybe "customhw" which would bring just the hw features for the board
in allnoconfig
mode.

Or maybe we could try to fit such a selection mechanism in the PACKAGECONFIG
system, but I'm not sure it would really fit.



-- 
Yann Dirson <yann@blade-group.com>
Blade / Shadow -- http://shadow.tech