Re: [yocto] [meta-rockchip] defconfig alternatives

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

 = "Hi Trevor,

Le mer. 24 mars 2021 à 01:41, Trevor Woerner <twoerner@gmail.com> a écrit :
>
> On Tue 2021-03-23 @ 12:59:24 PM, Yann Dirson wrote:
> > 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.
>
> The above (if I'm reading it correctly) sounds quite similar to something I
> had already started a while back. So I'll go ahead and publish this
> work-in-progress. Maybe if I'm lucky it might spark some conversation with
> other BSP maintainers.
>
> https://github.com/twoerner/meta-rockchip__twoerner/tree/rockchip-kernel-config-WIP
>
> Here is the text I've added to the README, which I think helps clarify some of
> my points:
>
>         Kernel configuration:
>         --------------------
>         When it comes to configuring the kernel, allow the user to choose between:
>                 1. using the in-kernel defconfig
>                 2. using an in-layer defconfig + config fragments
>
>         The in-kernel defconfig is a very generic configuration meant to build a
>         kernel that could (theoretically) be run on a wide variety of devices of
>         the same architecture. I.e. a kernel built for one aarch64 machine (e.g.
>         the Qualcomm-based DragonBoard 410c) could be used without modification on
>         a completely different aarch64 machine (e.g. an Amlogic-based Odroid-C4). As
>         you can imagine, the in-kernel configuration generates a very large kernel.
>         Currently the in-kernel defconfig produces a kernel that is roughly 12MB.
>
>         The in-layer defconfig + config fragments is meant to trim down the kernel
>         configuration to remove all the hardware settings that aren't relevant to the
>         specific MACHINE being built. I.e. a kernel built for the rock-pi-4b wouldn't
>         include, for example, Qualcomm-specific drivers or code.
>
>         Currently, option #2 is only available for the following MACHINE(s):
>                 - rock-pi-4b
>
>         The user indicates their intent via the RK_KERNEL_CONFIG_TYPE variable. If
>         the user does nothing, the default behaviour is to use the in-kernel
>         defconfig. If the user sets
>                 RK_KERNEL_CONFIG_TYPE = "inlayer"
>         then the in-layer defconfig + config fragments will be used.
>
> At this point I don't have everything that I'm wishing for. I had started to
> try to add everything that I've wanted, but it wasn't working, so I pulled
> back and only committed the parts that I was able to get working.
>
> Right now the user can toggle between the generic in-kernel defconfig, or a
> leaner defconfig that I've defined by playing with the RK_KERNEL_CONFIG_TYPE
> variable (in local.conf, for example). Right now I've only done that for the
> rock-pi-4b, but ideally I'd add others as time goes on.
>
> I think it'll always be good to allow users to choose between the in-kernel
> defconfig and something custom. We'll always want to be able to say "does it
> work with the in-kernel defconfig?".
>
> But better yet, instead of one big monolithic defconfig per board, ideally the
> meta-rockchip BSP layer would contain a whole bunch of little kernel config
> fragments for turning on just one thing. For example, there would be a kernel
> config fragment for turning on basic Rockchip support, another one to enable
> the RK808 pmic, and another one for the RK805 pmic. Others config fragments
> would enable various ethernet options, wifi, bluetooth, etc. One would enable
> the ES8388 audio codec (found on the rock2-square) and another would enable
> just the ES8316 audio codec (the one found on the rock-pi-4).
>
> Then, various parts on the configuration would enable the relevant kernel
> config fragments. Simply selecting, for example, rock-pi-e, would include
> the include/rk3328.inc, which would pull in basic rockchip/rk3328 support
> and some other default things. The rock-pi-e.conf would pull in the correct
> networking/bt options, and select the RK805 pmic. Eventually all the little
> fragments would be pulled in that would be necessary to generate the whole
> defconfig for this board.
>
> That's the dream, anyway :-/

That sound fine :)

I think we can even do something like this with just standard-looking
overrides and no
specific anonymous python.  I'm thinking of something like (including
non-arm things, after all
there's no reason to reserve such a mechanism to the arm/rk world):

# how the kernel defconfigs are named
KBUILD_DEFCONFIG_inkernel = "defconfig"
KBUILD_DEFCONFIG_inkernel_x86-64 = "x86_64_defconfig"
# how the layer defconfigs are named
KBUILD_DEFCONFIG_inlayer = "defconfig"

RK_KERNEL_CONFIG_TYPE = "inlayer"

KBUILD_DEFCONFIG = "${KBUILD_DEFCONFIG_${RK_KERNEL_CONFIG_TYPE}}"

RK_KERNEL_CONFIG_URIS_inkernel = ""
RK_KERNEL_CONFIG_URIS_inlayer = "file://defconfig file://soc.cfg
file://board.cfg"

SRC_URI_append = "${RK_KERNEL_CONFIG_URIS_${RK_KERNEL_CONFIG_TYPE}}"


Then we could have in the recipe files:
- a single defconfig for all rockchip
- per-soc, eg. rk3399/soc.cfg
- per-machine, eg. nanopi-m4/board.cfg

How does that sound ?

>
> Technically, this information could be gleaned from the device tree for this
> board… :-S
>
> Then we'll need to take a look at all the DT overlays to see how to
> incorporate them as well. Most of these boards have the "Raspberry Pi" 40-pin
> interface, so users will expect to be able to reconfigure the pins for the
> various alternate devices.
--
Yann Dirson <yann@blade-group.com>
Blade / Shadow -- http://shadow.tech