On Tue 2021-03-23 @ 12:59:24 PM, Yann Dirson wrote: > Hi Trevor, > > Le lun. 22 mars 2021 à 16:50, Trevor Woerner <[email protected]> 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 :-/ 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.
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52829): https://lists.yoctoproject.org/g/yocto/message/52829 Mute This Topic: https://lists.yoctoproject.org/mt/81548786/21656 Group Owner: [email protected] Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
