[meta-rockchip] SOQuartz: add

The SOQuartz is a RK3566 based compute module and parts of Quartz64 series

Specs:
- Rockchip RK3566 Quad-core ARM Cortex-A55@1.8GHz
- Mali-G52 2EE Bifrost GPU@800MHz
- Raspberry Pi 4 CM form factor
- RAM Memory Variants: 2GB, 4GB, 8GB LPDDR4.
- optional eMMC from 8GB to 128GB
- optional 128Mb SPI Flash
- 10/100/1000Mbps Ethernet
- WiFi 802.11 b/g/n/ac with Bluetooth 5.0

Exposed preripherals:
- 1x HDMI
- 2x DSI
- 1x eDP
- 1x LVDS
- 1x CSI 4-line
- 1x Ethernet
- 1x USB 2.0 OTG
- 1x SD
- 1x PCIe 1-line
- 28x GPIO

Signed-off-by: Paul M. B. Bendixen <pbe@trifork.com>

Hi Paul,

Please do not attach the patch to the mail but have the patch be the 
mail (the commit title the subject of the mail and the diff the body of 
the mail), this way we can provide feedback inline and do not need to 
open and download a file.

c.f. 
https://docs.yoctoproject.org/contributor-guide/submit-changes.html#sending-patches-via-email

WKS_FILE ?= "rockchip.wks"

is unnecessary because it's already the default in rk3566.inc that you 
cinlude.


Maybe we also want

MACHINE_EXTRA_RRECOMMENDS += "kernel-modules"

in there so that kernel modules are installed by default in 
non-core-image-minimal images?

Could be nice to add a link to the SOQuartz product page as well :)

I see that there are (currently) three possible motherboards for that 
SoM, CM4-IO, Model A and Blade. I don't know how Trevor wants to handle 
that though?
- Different machine config? If so, the machine conf file should probably 
be named after the full config and not just the SoM.
- Multiple Device Trees included in the image? Then we need 
KERNEL_DEVICETREE with the three DTBs in there.

Considering that we have a different defconfig for each variant in 
U-Boot, I would lean more towards the first option. Do you know if 
there's any way to detect to which motherboard the SoM is connected at 
runtime? Maybe we could have one U-Boot binary for all three variants 
and load the proper DTB at runtime, based on what we can detect.

Cheers,
Quentin

On 13.11.2024 10.39, Quentin Schulz via lists.yoctoproject.org wrote:
> Hi Paul,
>
> Please do not attach the patch to the mail but have the patch be the 
> mail (the commit title the subject of the mail and the diff the body 
> of the mail), this way we can provide feedback inline and do not need 
> to open and download a file.
>
Ok will do.

> c.f. 
> https://docs.yoctoproject.org/contributor-guide/submit-changes.html#sending-patches-via-email
>
> WKS_FILE ?= "rockchip.wks"
>
> is unnecessary because it's already the default in rk3566.inc that you 
> cinlude.
>
Cool, thanks. I missed that
>
> Maybe we also want
>
> MACHINE_EXTRA_RRECOMMENDS += "kernel-modules"
>
> in there so that kernel modules are installed by default in 
> non-core-image-minimal images?
>
Yes, but the functioning of the machine does not depend on modules in 
the default case, so I thought it better to omit it in the base case?

> Could be nice to add a link to the SOQuartz product page as well :)
>
Yes, this is an oversight on my part.

> I see that there are (currently) three possible motherboards for that 
> SoM, CM4-IO, Model A and Blade. I don't know how Trevor wants to 
> handle that though?
> - Different machine config? If so, the machine conf file should 
> probably be named after the full config and not just the SoM.
> - Multiple Device Trees included in the image? Then we need 
> KERNEL_DEVICETREE with the three DTBs in there.
>
> Considering that we have a different defconfig for each variant in 
> U-Boot, I would lean more towards the first option. Do you know if 
> there's any way to detect to which motherboard the SoM is connected at 
> runtime? Maybe we could have one U-Boot binary for all three variants 
> and load the proper DTB at runtime, based on what we can detect.
>
To my knowledge there is no way to determine what baseboard is used and 
it is also very likely (since this is what we are doing ;) )
that one would use the module as a starting point and create ones own 
baseboard.

In this case one would have to recreate the machine in their own setup 
instead of just building on this one.

I guess what I'd go for would be to have the SoM machine and possibly 
have further machines for each model (there are _a lot_ more than three) 
based on  this one overloading the defconfig.

> Cheers,
> Quentin

Thanks,
Paul

Hi Paul,

On 11/13/24 10:52 AM, Paul M. Bendixen via lists.yoctoproject.org wrote:
> [You don't often get email from pbe=trifork.com@lists.yoctoproject.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> On 13.11.2024 10.39, Quentin Schulz via lists.yoctoproject.org wrote:
>> Hi Paul,
>>
>> Please do not attach the patch to the mail but have the patch be the
>> mail (the commit title the subject of the mail and the diff the body
>> of the mail), this way we can provide feedback inline and do not need
>> to open and download a file.
>>
> Ok will do.
> 
>> c.f.
>> https://docs.yoctoproject.org/contributor-guide/submit-changes.html#sending-patches-via-email
>>
>> WKS_FILE ?= "rockchip.wks"
>>
>> is unnecessary because it's already the default in rk3566.inc that you
>> cinlude.
>>
> Cool, thanks. I missed that
>>
>> Maybe we also want
>>
>> MACHINE_EXTRA_RRECOMMENDS += "kernel-modules"
>>
>> in there so that kernel modules are installed by default in
>> non-core-image-minimal images?
>>
> Yes, but the functioning of the machine does not depend on modules in
> the default case, so I thought it better to omit it in the base case?
> 

People usually want something that works out of the box. And actually, 
the upstream Linux kernel defconfig for Aarch64 machines does make 
extensive use of modules. I think most recent additions of machine conf 
file do enable it.

>> Could be nice to add a link to the SOQuartz product page as well :)
>>
> Yes, this is an oversight on my part.
> 
>> I see that there are (currently) three possible motherboards for that
>> SoM, CM4-IO, Model A and Blade. I don't know how Trevor wants to
>> handle that though?
>> - Different machine config? If so, the machine conf file should
>> probably be named after the full config and not just the SoM.
>> - Multiple Device Trees included in the image? Then we need
>> KERNEL_DEVICETREE with the three DTBs in there.
>>
>> Considering that we have a different defconfig for each variant in
>> U-Boot, I would lean more towards the first option. Do you know if
>> there's any way to detect to which motherboard the SoM is connected at
>> runtime? Maybe we could have one U-Boot binary for all three variants
>> and load the proper DTB at runtime, based on what we can detect.
>>
> To my knowledge there is no way to determine what baseboard is used and
> it is also very likely (since this is what we are doing ;) )
> that one would use the module as a starting point and create ones own
> baseboard.
> 
> In this case one would have to recreate the machine in their own setup
> instead of just building on this one.
> 
> I guess what I'd go for would be to have the SoM machine and possibly
> have further machines for each model (there are _a lot_ more than three)
> based on  this one overloading the defconfig.
> 

The thing is... I'm not entirely sure it makes sense to have a SOQuartz 
SoM machine config file.

My company sells modules with one baseboard. Considering that most 
people building their own baseboard won't upstream it, they will need 
different kernel and U-Boot recipes, with different configs and DTBs 
which is essentially the whole content of the machine configuration file.

So if we're going this route, we can simply have one machine conf file 
which is for one SOQuartz on a particular baseboard (CM4-IO it seems in 
this patch) but make it explicit in the different file names and 
contents that it's for that particular combination. We can still add a 
comment hinting at how to support a new combination though :)

Cheers,
Quentin

On 13 Nov 2024, at 10:08, Quentin Schulz via lists.yoctoproject.org <quentin.schulz=cherry.de@lists.yoctoproject.org> wrote:
>
> The thing is... I'm not entirely sure it makes sense to have a SOQuartz SoM machine config file.
>
> My company sells modules with one baseboard. Considering that most people building their own baseboard won't upstream it, they will need different kernel and U-Boot recipes, with different configs and DTBs which is essentially the whole content of the machine configuration file.

FWIW, I agree that there’s no real point in having a _machine configuration_ for a SoM.  A common .inc file (and potentially, a machine override) so that it’s trivial to write a machine makes more sense.

Ross
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

On 13.11.2024 11.40, Ross Burton via lists.yoctoproject.org wrote:
> On 13 Nov 2024, at 10:08, Quentin Schulz via lists.yoctoproject.org <quentin.schulz=cherry.de@lists.yoctoproject.org> wrote:
>> The thing is... I'm not entirely sure it makes sense to have a SOQuartz SoM machine config file.
>>
>> My company sells modules with one baseboard. Considering that most people building their own baseboard won't upstream it, they will need different kernel and U-Boot recipes, with different configs and DTBs which is essentially the whole content of the machine configuration file.
> FWIW, I agree that there’s no real point in having a _machine configuration_ for a SoM.  A common .inc file (and potentially, a machine override) so that it’s trivial to write a machine makes more sense.

Ok, I've tried to incorporate the feedback into the following, this 
could possibly serve as a starting point for someone else,
but otherwise it could also just be dropped.

I've moved the SOQuartz to an .inc file and added the model-a baseboard 
as a machine

> Ross
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#796): https://lists.yoctoproject.org/g/yocto-patches/message/796
> Mute This Topic: https://lists.yoctoproject.org/mt/109551419/9116071
> Group Owner: yocto-patches+owner@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/yocto-patches/leave/13741902/9116071/1253603286/xyzzy [pbe@trifork.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>
----

The SOQuartz is a RK3566 based compute module and parts of Quartz64 series
The Model-A base board is one possible board that supports it

Website:
     https://pine64.org/devices/soquartz/
Wiki:
     https://wiki.pine64.org/wiki/SOQuartz

Specs:
- Rockchip RK3566 Quad-core ARM Cortex-A55@1.8GHz
- Mali-G52 2EE Bifrost GPU@800MHz
- Raspberry Pi 4 CM form factor
- RAM Memory Variants: 2GB, 4GB, 8GB LPDDR4.
- optional eMMC from 8GB to 128GB
- optional 128Mb SPI Flash
- 10/100/1000Mbps Ethernet
- WiFi 802.11 b/g/n/ac with Bluetooth 5.0

Exposed preripherals:
- 1x HDMI
- 2x DSI
- 1x eDP
- 1x LVDS
- 1x CSI 4-line
- 1x Ethernet
- 1x USB 2.0 OTG
- 1x SD
- 1x PCIe 1-line
- 28x GPIO

Model-A baseboard:
- 1x microSD - bootable
- 1x HDMI Port
- 2x USB A 2.0 Host
- 1x USB C 2.0 Host
- 1x 5 pin USB expansion
- 1x Ethernet w. PoE
- 1x 40 pole Pi2 compatible GPIO
- 1x MiPi-CSI 2 lanes
- 1x MiPi-CSI 4 lanes
- 1x MiPi-DSI 2 lanes
- 1x MiPi-DSI 4 lanes
- 1x PCIe open ended

Signed-off-by: Paul M. B. Bendixen <pbe@trifork.com>
---
  README                                      |  1 +
  conf/machine/include/soquartz.inc           | 14 ++++++++++++++
  conf/machine/soquartz-model-a.conf          | 12 ++++++++++++
  recipes-kernel/linux/linux-yocto_%.bbappend |  1 +
  4 files changed, 28 insertions(+)
  create mode 100644 conf/machine/include/soquartz.inc
  create mode 100644 conf/machine/soquartz-model-a.conf

diff --git a/README b/README
index 09f8691..85ab2ec 100644
--- a/README
+++ b/README
@@ -45,6 +45,7 @@ Status of supported boards:
              rock-pi-e
              rock-pi-s
              rock64
+            soquartz (on model A base board)

      builds:
          32-bit:
diff --git a/conf/machine/include/soquartz.inc 
b/conf/machine/include/soquartz.inc
new file mode 100644
index 0000000..bb6f3fc
--- /dev/null
+++ b/conf/machine/include/soquartz.inc
@@ -0,0 +1,14 @@
+#Copyright (C) Trifork A/S 2024
+# Released under the MIT license (see COPYING.MIT for the terms)
+
+# Common override for basing a SOQuartz design on
+
+MACHINEOVERRIDES =. "soquartz:"
+
+require conf/machine/include/rk3566.inc
+
+
+UBOOT_MACHINE ?= "soquartz-cm4-rk3566_defconfig"
+KERNEL_DEVICETREE ?= "rockchip/rk3566-soquartz-cm4.dtb"
+
+MACHINE_EXTRA_RRECOMMENDS += "kernel-modules"
diff --git a/conf/machine/soquartz-model-a.conf 
b/conf/machine/soquartz-model-a.conf
new file mode 100644
index 0000000..0b2802c
--- /dev/null
+++ b/conf/machine/soquartz-model-a.conf
@@ -0,0 +1,12 @@
+#Copyright (C) Trifork A/S 2024
+# Released under the MIT license (see COPYING.MIT for the terms)
+
+#@TYPE: Machine
+#@NAME: SOQuartz on Model A base board
+#@DESCRIPTION: SOQuartz is a series of Compute Module by Pine64, the 
Model-A baseboard provides standard connectors for the compute module
+#https://https://wiki.pine64.org/wiki/SOQuartz
+
+require conf/machine/include/soquartz.inc
+
+KERNEL_DEVICETREE = "rockchip/rk3566-soquartz-model-a.dtb"
+UBOOT_MACHINE = "soquartz-model-a-rk3566_defconfig"
diff --git a/recipes-kernel/linux/linux-yocto_%.bbappend 
b/recipes-kernel/linux/linux-yocto_%.bbappend
index 5528bab..56ec9d7 100644
--- a/recipes-kernel/linux/linux-yocto_%.bbappend
+++ b/recipes-kernel/linux/linux-yocto_%.bbappend
@@ -22,6 +22,7 @@ COMPATIBLE_MACHINE:rock-3a = "rock-3a"
  COMPATIBLE_MACHINE:rock-4c-plus = "rock-4c-plus"
  COMPATIBLE_MACHINE:rock-5a = "rock-5a"
  COMPATIBLE_MACHINE:rock-5b = "rock-5b"
+COMPATIBLE_MACHINE:soquartz = "soquartz"

  SRC_URI:append = " 
file://rockchip-kmeta;type=kmeta;name=rockchip-kmeta;destsuffix=rockchip-kmeta"
  SRC_URI:append:nanopi-r4s = " file://nanopi-r4s.scc"
-- 
2.43.0

Hi Paul,

Please send the new patch as a separate mail (v2 here) so people who 
aren't directly included in the discussion can follow and know which 
diff is the latest and greatest :) Since I'm going to make feedback for 
a v3, please do that for the v3 whenever it's ready, thanks! Let us know 
if you need help with that.

On 11/14/24 3:15 PM, Paul M. Bendixen via lists.yoctoproject.org wrote:
> [You don't often get email from pbe=trifork.com@lists.yoctoproject.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> On 13.11.2024 11.40, Ross Burton via lists.yoctoproject.org wrote:
>> On 13 Nov 2024, at 10:08, Quentin Schulz via lists.yoctoproject.org <quentin.schulz=cherry.de@lists.yoctoproject.org> wrote:
>>> The thing is... I'm not entirely sure it makes sense to have a SOQuartz SoM machine config file.
>>>
>>> My company sells modules with one baseboard. Considering that most people building their own baseboard won't upstream it, they will need different kernel and U-Boot recipes, with different configs and DTBs which is essentially the whole content of the machine configuration file.
>> FWIW, I agree that there’s no real point in having a _machine configuration_ for a SoM.  A common .inc file (and potentially, a machine override) so that it’s trivial to write a machine makes more sense.
> 
> Ok, I've tried to incorporate the feedback into the following, this
> could possibly serve as a starting point for someone else,
> but otherwise it could also just be dropped.
> 
> I've moved the SOQuartz to an .inc file and added the model-a baseboard
> as a machine
> 
>> Ross
>> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
>>
>>
>>
>>
>>
> ----
> 
> The SOQuartz is a RK3566 based compute module and parts of Quartz64 series
> The Model-A base board is one possible board that supports it
> 
> Website:
>       https://pine64.org/devices/soquartz/
> Wiki:
>       https://wiki.pine64.org/wiki/SOQuartz
> 
> Specs:
> - Rockchip RK3566 Quad-core ARM Cortex-A55@1.8GHz
> - Mali-G52 2EE Bifrost GPU@800MHz
> - Raspberry Pi 4 CM form factor
> - RAM Memory Variants: 2GB, 4GB, 8GB LPDDR4.
> - optional eMMC from 8GB to 128GB
> - optional 128Mb SPI Flash
> - 10/100/1000Mbps Ethernet
> - WiFi 802.11 b/g/n/ac with Bluetooth 5.0
> 
> Exposed preripherals:
> - 1x HDMI
> - 2x DSI
> - 1x eDP
> - 1x LVDS
> - 1x CSI 4-line
> - 1x Ethernet
> - 1x USB 2.0 OTG
> - 1x SD
> - 1x PCIe 1-line
> - 28x GPIO
> 
> Model-A baseboard:
> - 1x microSD - bootable
> - 1x HDMI Port
> - 2x USB A 2.0 Host
> - 1x USB C 2.0 Host
> - 1x 5 pin USB expansion
> - 1x Ethernet w. PoE
> - 1x 40 pole Pi2 compatible GPIO
> - 1x MiPi-CSI 2 lanes
> - 1x MiPi-CSI 4 lanes
> - 1x MiPi-DSI 2 lanes
> - 1x MiPi-DSI 4 lanes
> - 1x PCIe open ended
> 
> Signed-off-by: Paul M. B. Bendixen <pbe@trifork.com>
> ---
>    README                                      |  1 +
>    conf/machine/include/soquartz.inc           | 14 ++++++++++++++
>    conf/machine/soquartz-model-a.conf          | 12 ++++++++++++
>    recipes-kernel/linux/linux-yocto_%.bbappend |  1 +
>    4 files changed, 28 insertions(+)
>    create mode 100644 conf/machine/include/soquartz.inc
>    create mode 100644 conf/machine/soquartz-model-a.conf
> 
> diff --git a/README b/README
> index 09f8691..85ab2ec 100644
> --- a/README
> +++ b/README
> @@ -45,6 +45,7 @@ Status of supported boards:
>                rock-pi-e
>                rock-pi-s
>                rock64
> +            soquartz (on model A base board)
> 
>        builds:
>            32-bit:
> diff --git a/conf/machine/include/soquartz.inc
> b/conf/machine/include/soquartz.inc
> new file mode 100644
> index 0000000..bb6f3fc
> --- /dev/null
> +++ b/conf/machine/include/soquartz.inc
> @@ -0,0 +1,14 @@
> +#Copyright (C) Trifork A/S 2024
> +# Released under the MIT license (see COPYING.MIT for the terms)
> +
> +# Common override for basing a SOQuartz design on
> +
> +MACHINEOVERRIDES =. "soquartz:"
> +
> +require conf/machine/include/rk3566.inc
> +
> +
> +UBOOT_MACHINE ?= "soquartz-cm4-rk3566_defconfig"
> +KERNEL_DEVICETREE ?= "rockchip/rk3566-soquartz-cm4.dtb"
> +

The two lines above don't make sense for a SoM so please don't define 
them. You may want to add them as comment and explain that to add 
support for a new baseboard, typically setting only those two variables 
would be necessary.

> +MACHINE_EXTRA_RRECOMMENDS += "kernel-modules"
> diff --git a/conf/machine/soquartz-model-a.conf
> b/conf/machine/soquartz-model-a.conf
> new file mode 100644
> index 0000000..0b2802c
> --- /dev/null
> +++ b/conf/machine/soquartz-model-a.conf
> @@ -0,0 +1,12 @@
> +#Copyright (C) Trifork A/S 2024
> +# Released under the MIT license (see COPYING.MIT for the terms)
> +
> +#@TYPE: Machine
> +#@NAME: SOQuartz on Model A base board
> +#@DESCRIPTION: SOQuartz is a series of Compute Module by Pine64, the
> Model-A baseboard provides standard connectors for the compute module
> +#https://https://wiki.pine64.org/wiki/SOQuartz

I think one "https://" should be enough :)

I would here post the link to the Modell-A baseboard section, e.g.
https://wiki.pine64.org/wiki/SOQuartz#SOQuartz_Model-A_Baseboard_Features

and move https://wiki.pine64.org/wiki/SOQuartz link to the SoM's .inc?

Looks good to me otherwise!

Cheers,
Quentin