My thoughts on this after working on this for the nanopi-m4 have changed a bit: it looks like the existing kmeta system already provides us with everything we need: - the kmeta BSP mechanism already provides the way to declare all the platform features in "hardware features" - a minimal kernel can then be obtained with KCONFIG_MODE="--allnoconfig" and KBUILD_DEFCONFIG="", with some support from PREFERRED_PROVIDER_virtual/kernel="linux-yocto-tiny" Above this, downstream layers can easily add the additional features they need, by appending kmeta features as needed, or their own .cfg snippets if no existing feature matches. Did i overlook some use-case that would not be covered ? Le jeu. 25 mars 2021 à 18:11, Yann Dirson via lists.yoctoproject.org <yann.dirson=blade-group.com@...> a écrit :
= "Hi Trevor,
Le mer. 24 mars 2021 à 01:41, Trevor Woerner <twoerner@...> 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@...> 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 / Shadow -- http://shadow.tech
-- Yann Dirson <yann@...> Blade / Shadow -- http://shadow.tech
|
