Re: [meta-rockchip] defconfig alternatives
On Tue 2021-03-23 @ 12:59:24 PM, Yann Dirson wrote:
Hi Trevor,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.
Here is the text I've added to the README, which I think helps clarify some of
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):
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
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.