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 <[email protected]> a écrit : > > = "Hi Trevor, > > Le mer. 24 mars 2021 à 01:41, Trevor Woerner <[email protected]> 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 <[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 :-/ > > 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 <[email protected]> > Blade / Shadow -- http://shadow.tech > > > -- Yann Dirson <[email protected]> Blade / Shadow -- http://shadow.tech
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52999): https://lists.yoctoproject.org/g/yocto/message/52999 Mute This Topic: https://lists.yoctoproject.org/mt/81548786/21656 Group Owner: [email protected] Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
