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

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

[Yann Dirson]

From: Yann Dirson <yann@blade-group.com>

This supports both the 2GB and 4GB versions of the board.  This is not
done with 2 different machine definitions since only u-boot has to
change between those two configurations, but with a NANOPIM4_HW variable
to set in local.conf.

Note I could only test the 2GB version.

---

 conf/machine/nanopi-m4.conf                   | 29 +++++++++++++++++++
 recipes-kernel/linux/linux-yocto-dev.bbappend |  1 +
 .../linux/linux-yocto-rt_%.bbappend           |  1 +
 .../linux/linux-yocto-tiny_%.bbappend         |  1 +
 recipes-kernel/linux/linux-yocto_%.bbappend   |  1 +
 5 files changed, 33 insertions(+)
 create mode 100644 conf/machine/nanopi-m4.conf

diff --git a/conf/machine/nanopi-m4.conf b/conf/machine/nanopi-m4.conf
new file mode 100644
index 0000000..64a962e
--- /dev/null
+++ b/conf/machine/nanopi-m4.conf
@@ -0,0 +1,29 @@
+# Copyright (C) 2021 Blade SAS
+
+#@TYPE: Machine
+#@NAME: NanoPi M4
+#@DESCRIPTION: NanoPi M4 RK3399 board from FriendlyElec, 2GB and 4GB variants
+
+# specify NANOPIM4_HW="" in local.conf for the 4GB version
+NANOPIM4_HW ?= "-2gb"
+
+require include/rk3399.inc
+
+KERNEL_DEVICETREE = "rockchip/rk3399-nanopi-m4.dtb"
+UBOOT_MACHINE = "nanopi-m4${NANOPIM4_HW}-rk3399_defconfig"
+
+RK_BOOT_DEVICE = "mmcblk1"
+WKS_FILE ?= "rock-pi-4.wks"
+IMAGE_FSTYPES += "wic"
+
+WKS_FILE_DEPENDS ?= " \
+    mtools-native \
+    dosfstools-native \
+    virtual/bootloader \
+    virtual/kernel \
+    "
+IMAGE_BOOT_FILES ?= "\
+    ${KERNEL_IMAGETYPE} \
+    "
+
+SERIAL_CONSOLES = "1500000;ttyS2"
diff --git a/recipes-kernel/linux/linux-yocto-dev.bbappend b/recipes-kernel/linux/linux-yocto-dev.bbappend
index e5ea197..3eca360 100644
--- a/recipes-kernel/linux/linux-yocto-dev.bbappend
+++ b/recipes-kernel/linux/linux-yocto-dev.bbappend
@@ -6,3 +6,4 @@ COMPATIBLE_MACHINE_vyasa-rk3288 = "vyasa-rk3288"
 COMPATIBLE_MACHINE_tinker-board = "tinker-board"
 COMPATIBLE_MACHINE_tinker-board-s = "tinker-board-s"
 COMPATIBLE_MACHINE_rock-pi-4 = "rock-pi-4"
+COMPATIBLE_MACHINE_nanopi-m4 = "nanopi-m4"
diff --git a/recipes-kernel/linux/linux-yocto-rt_%.bbappend b/recipes-kernel/linux/linux-yocto-rt_%.bbappend
index e5ea197..3eca360 100644
--- a/recipes-kernel/linux/linux-yocto-rt_%.bbappend
+++ b/recipes-kernel/linux/linux-yocto-rt_%.bbappend
@@ -6,3 +6,4 @@ COMPATIBLE_MACHINE_vyasa-rk3288 = "vyasa-rk3288"
 COMPATIBLE_MACHINE_tinker-board = "tinker-board"
 COMPATIBLE_MACHINE_tinker-board-s = "tinker-board-s"
 COMPATIBLE_MACHINE_rock-pi-4 = "rock-pi-4"
+COMPATIBLE_MACHINE_nanopi-m4 = "nanopi-m4"
diff --git a/recipes-kernel/linux/linux-yocto-tiny_%.bbappend b/recipes-kernel/linux/linux-yocto-tiny_%.bbappend
index e5ea197..3eca360 100644
--- a/recipes-kernel/linux/linux-yocto-tiny_%.bbappend
+++ b/recipes-kernel/linux/linux-yocto-tiny_%.bbappend
@@ -6,3 +6,4 @@ COMPATIBLE_MACHINE_vyasa-rk3288 = "vyasa-rk3288"
 COMPATIBLE_MACHINE_tinker-board = "tinker-board"
 COMPATIBLE_MACHINE_tinker-board-s = "tinker-board-s"
 COMPATIBLE_MACHINE_rock-pi-4 = "rock-pi-4"
+COMPATIBLE_MACHINE_nanopi-m4 = "nanopi-m4"
diff --git a/recipes-kernel/linux/linux-yocto_%.bbappend b/recipes-kernel/linux/linux-yocto_%.bbappend
index e5ea197..3eca360 100644
--- a/recipes-kernel/linux/linux-yocto_%.bbappend
+++ b/recipes-kernel/linux/linux-yocto_%.bbappend
@@ -6,3 +6,4 @@ COMPATIBLE_MACHINE_vyasa-rk3288 = "vyasa-rk3288"
 COMPATIBLE_MACHINE_tinker-board = "tinker-board"
 COMPATIBLE_MACHINE_tinker-board-s = "tinker-board-s"
 COMPATIBLE_MACHINE_rock-pi-4 = "rock-pi-4"
+COMPATIBLE_MACHINE_nanopi-m4 = "nanopi-m4"
-- 
2.30.2

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

[Trevor Woerner]

Hi Yann,

Thanks for your contribution! :-)

On Mon 2021-03-22 @ 02:42:12 PM, yann.dirson@blade-group.com wrote:
> This supports both the 2GB and 4GB versions of the board.  This is not
> done with 2 different machine definitions since only u-boot has to
> change between those two configurations, but with a NANOPIM4_HW variable
> to set in local.conf.

Traditionally in meta-rockchip this is done using two separate machine files
with all the common things factored into a common include file. See
tinker-board and tinker-board-s as well as all the rock-pi-4* definitions for
examples.

I would prefer if the same thing was done here.

That way it shows up as distinct machines in the layer index (for example) and
makes it easier for users to determine whether or not their specific board is
supported. Otherwise the full list of supported boards ends up getting
buried and people have to dig around in the config files to find support
information.

Would you have time to re-spin the commit to add 2 boards (or just add the one
you can test)? I see there's also a nanopi-m4b, but I can't find a simple
comparison between the various nanopi-m4's. If you do, please add an entry in
the README file as well.

Otherwise I can take a look later today.

Best regards,
	Trevor

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

[Yann Dirson]

Hi Trevor,

Le lun. 22 mars 2021 à 15:47, Trevor Woerner <twoerner@gmail.com> a écrit :
> On Mon 2021-03-22 @ 02:42:12 PM, yann.dirson@blade-group.com wrote:
> > This supports both the 2GB and 4GB versions of the board.  This is not
> > done with 2 different machine definitions since only u-boot has to
> > change between those two configurations, but with a NANOPIM4_HW variable
> > to set in local.conf.
>
> Traditionally in meta-rockchip this is done using two separate machine files
> with all the common things factored into a common include file. See
> tinker-board and tinker-board-s as well as all the rock-pi-4* definitions for
> examples.
>
> I would prefer if the same thing was done here.

Damned that was how I did my first patch, I just felt it was much
better this way :(

Digging up that original commit re rerolling.


Wouldn't it be useful to have a standard way to specify such hardware
variants, that
would be recognized as such by the layer index ?



-- 
Yann Dirson <yann@blade-group.com>
Blade / Shadow -- http://shadow.tech

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

[Yann Dirson]

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 ?

Le lun. 22 mars 2021 à 16:00, Yann Dirson via lists.yoctoproject.org
<yann.dirson=blade-group.com@lists.yoctoproject.org> a écrit :
>
> Hi Trevor,
>
> Le lun. 22 mars 2021 à 15:47, Trevor Woerner <twoerner@gmail.com> a écrit :
> > On Mon 2021-03-22 @ 02:42:12 PM, yann.dirson@blade-group.com wrote:
> > > This supports both the 2GB and 4GB versions of the board.  This is not
> > > done with 2 different machine definitions since only u-boot has to
> > > change between those two configurations, but with a NANOPIM4_HW variable
> > > to set in local.conf.
> >
> > Traditionally in meta-rockchip this is done using two separate machine files
> > with all the common things factored into a common include file. See
> > tinker-board and tinker-board-s as well as all the rock-pi-4* definitions for
> > examples.
> >
> > I would prefer if the same thing was done here.
>
> Damned that was how I did my first patch, I just felt it was much
> better this way :(
>
> Digging up that original commit re rerolling.
>
>
> Wouldn't it be useful to have a standard way to specify such hardware
> variants, that
> would be recognized as such by the layer index ?
>
>
>
> --
> Yann Dirson <yann@blade-group.com>
> Blade / Shadow -- http://shadow.tech
>
> 
>


-- 
Yann Dirson <yann@blade-group.com>
Blade / Shadow -- http://shadow.tech

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

[Trevor Woerner]

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

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

[Trevor Woerner]

On Mon, Mar 22, 2021 at 11:00 AM Yann Dirson
<yann.dirson@blade-group.com> wrote:
> Wouldn't it be useful to have a standard way to specify such hardware
> variants, that
> would be recognized as such by the layer index ?

Sure it would! But then you'd have to get all the BSP layer
maintainers to agree on that format and use it… :-/

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

[Joshua Watt]

[-- Attachment #1: Type: text/plain, Size: 1412 bytes --]


On 3/22/21 9:59 AM, Yann Dirson wrote:
> Hi Trevor,
>
> Le lun. 22 mars 2021 à 15:47, Trevor Woerner <twoerner@gmail.com> a écrit :
>> On Mon 2021-03-22 @ 02:42:12 PM, yann.dirson@blade-group.com wrote:
>>> This supports both the 2GB and 4GB versions of the board.  This is not
>>> done with 2 different machine definitions since only u-boot has to
>>> change between those two configurations, but with a NANOPIM4_HW variable
>>> to set in local.conf.
>> Traditionally in meta-rockchip this is done using two separate machine files
>> with all the common things factored into a common include file. See
>> tinker-board and tinker-board-s as well as all the rock-pi-4* definitions for
>> examples.
>>
>> I would prefer if the same thing was done here.
> Damned that was how I did my first patch, I just felt it was much
> better this way :(
>
> Digging up that original commit re rerolling.
>
>
> Wouldn't it be useful to have a standard way to specify such hardware
> variants, that
> would be recognized as such by the layer index ?

FWIW, I'd rather u-boot could automatcially detect what variant of the 
board it's running on and do the right thing (usually, just selecting 
the proper DTB from the FIT image). The only reason I did not do this on 
the rock-pi-4 is because there doesn't appear to be a way for u-boot to 
detect which variant it's on :/

>
>
>
>
> 
>

[-- Attachment #2: Type: text/html, Size: 2537 bytes --]

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

[Yann Dirson]

Hi Joshua,

Le lun. 22 mars 2021 à 19:24, Joshua Watt <jpewhacker@gmail.com> a écrit :
>
>
> On 3/22/21 9:59 AM, Yann Dirson wrote:
>
> Hi Trevor,
>
> Le lun. 22 mars 2021 à 15:47, Trevor Woerner <twoerner@gmail.com> a écrit :
>
> On Mon 2021-03-22 @ 02:42:12 PM, yann.dirson@blade-group.com wrote:
>
> This supports both the 2GB and 4GB versions of the board.  This is not
> done with 2 different machine definitions since only u-boot has to
> change between those two configurations, but with a NANOPIM4_HW variable
> to set in local.conf.
>
> Traditionally in meta-rockchip this is done using two separate machine files
> with all the common things factored into a common include file. See
> tinker-board and tinker-board-s as well as all the rock-pi-4* definitions for
> examples.
>
> I would prefer if the same thing was done here.
>
> Damned that was how I did my first patch, I just felt it was much
> better this way :(
>
> Digging up that original commit re rerolling.
>
>
> Wouldn't it be useful to have a standard way to specify such hardware
> variants, that
> would be recognized as such by the layer index ?
>
> FWIW, I'd rather u-boot could automatcially detect what variant of the board it's running on and do the right thing (usually, just selecting the proper DTB from the FIT image). The only reason I did not do this on the rock-pi-4 is because there doesn't appear to be a way for u-boot to detect which variant it's on :/

Wait, it's only the dtb used by u-boot which is different in this
case, the kernel uses a single dtb for both variants.
Those probably get embedded inside the bootloader, in any case they
are not those embedded in the fitImage.

 #include "rk3399-nanopi4-u-boot.dtsi"
-#include "rk3399-sdram-ddr3-1866.dtsi"
+#include "rk3399-sdram-lpddr3-samsung-4GB-1866.dtsi"

I have no clue how easily the two boards could be told one from the
other (let alone if that can be done safely),
and I feel that would rather be uboot-side work, rather than something
to be solved on the yocto side.

>
>
>
>
> 
>


-- 
Yann Dirson <yann@blade-group.com>
Blade / Shadow -- http://shadow.tech

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

[Joshua Watt]

On 3/22/21 2:30 PM, Yann Dirson wrote:
> Hi Joshua,
>
> Le lun. 22 mars 2021 à 19:24, Joshua Watt <jpewhacker@gmail.com> a écrit :
>>
>> On 3/22/21 9:59 AM, Yann Dirson wrote:
>>
>> Hi Trevor,
>>
>> Le lun. 22 mars 2021 à 15:47, Trevor Woerner <twoerner@gmail.com> a écrit :
>>
>> On Mon 2021-03-22 @ 02:42:12 PM, yann.dirson@blade-group.com wrote:
>>
>> This supports both the 2GB and 4GB versions of the board.  This is not
>> done with 2 different machine definitions since only u-boot has to
>> change between those two configurations, but with a NANOPIM4_HW variable
>> to set in local.conf.
>>
>> Traditionally in meta-rockchip this is done using two separate machine files
>> with all the common things factored into a common include file. See
>> tinker-board and tinker-board-s as well as all the rock-pi-4* definitions for
>> examples.
>>
>> I would prefer if the same thing was done here.
>>
>> Damned that was how I did my first patch, I just felt it was much
>> better this way :(
>>
>> Digging up that original commit re rerolling.
>>
>>
>> Wouldn't it be useful to have a standard way to specify such hardware
>> variants, that
>> would be recognized as such by the layer index ?
>>
>> FWIW, I'd rather u-boot could automatcially detect what variant of the board it's running on and do the right thing (usually, just selecting the proper DTB from the FIT image). The only reason I did not do this on the rock-pi-4 is because there doesn't appear to be a way for u-boot to detect which variant it's on :/
> Wait, it's only the dtb used by u-boot which is different in this
> case, the kernel uses a single dtb for both variants.
> Those probably get embedded inside the bootloader, in any case they
> are not those embedded in the fitImage.
>
>   #include "rk3399-nanopi4-u-boot.dtsi"
> -#include "rk3399-sdram-ddr3-1866.dtsi"
> +#include "rk3399-sdram-lpddr3-samsung-4GB-1866.dtsi"
>
> I have no clue how easily the two boards could be told one from the
> other (let alone if that can be done safely),
> and I feel that would rather be uboot-side work, rather than something
> to be solved on the yocto side.

Ah, I was referring to the DTB used by the Kernel (which u-boot can 
switch), not the DTB used by u-boot itself (which AFAIK is compiled into 
u-boot and cannot be changed).



>
>>
>>
>>
>> 
>>
>

[yocto] [meta-rockchip] defconfig alternatives

[Yann Dirson]

Hi Trevor,

Le lun. 22 mars 2021 à 16:50, Trevor Woerner <twoerner@gmail.com> 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.



-- 
Yann Dirson <yann@blade-group.com>
Blade / Shadow -- http://shadow.tech

Re: [yocto] [meta-rockchip] defconfig alternatives

[Trevor Woerner]

On Tue 2021-03-23 @ 12:59:24 PM, Yann Dirson wrote:
> Hi Trevor,
> 
> Le lun. 22 mars 2021 à 16:50, Trevor Woerner <twoerner@gmail.com> 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.

Re: [yocto] [meta-rockchip] defconfig alternatives

[Yann Dirson]

 = "Hi Trevor,

Le mer. 24 mars 2021 à 01:41, Trevor Woerner <twoerner@gmail.com> 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@gmail.com> 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-group.com>
Blade / Shadow -- http://shadow.tech

Re: [yocto] [meta-rockchip] defconfig alternatives

[Yann Dirson]

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@lists.yoctoproject.org> a écrit :
>
>  = "Hi Trevor,
>
> Le mer. 24 mars 2021 à 01:41, Trevor Woerner <twoerner@gmail.com> 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@gmail.com> 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-group.com>
> Blade / Shadow -- http://shadow.tech
>
> 
>


--
Yann Dirson <yann@blade-group.com>
Blade / Shadow -- http://shadow.tech