Re: [yocto] [meta-rockchip][PATCH] Add machine definitions for NanoPi-M4 boards

["Trevor Woerner" <twoerner@gmail.com>]

Hi Yann,

Thanks for the patch updates. I'll look at them soon.

On Mon 2021-03-22 @ 04:31:01 PM, Yann Dirson wrote:
> 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 :-)

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.

Best regards,
	Trevor