On 6/15/21 8:21 AM, Alexander Kanavin wrote:

On Tue, 15 Jun 2021 at 10:55, Alexander Kanavin <alex.kanavin@... <mailto:alex.kanavin@...>> wrote:
On Tue, 15 Jun 2021 at 10:48, Richard Purdie
<richard.purdie@...
<mailto:richard.purdie@...>> wrote:
I appreciate the desire simply to delete/disable anything that
causes issues
but in this case I draw the line and my answer is no. It works
fine in the
vast majority of usage.
But where are the benchmarks that show it's actually beneficial? And
commitment from someone to maintain it and address open issues
(there are more than just this one)?
I went ahead and ran some quick benchmarks myself. Specifically:
1. Running 'free' after things have settled down at boot:
a) without prelink
core-image-sato-sdk
               total        used        free      shared  buff/cache available
Mem:          489352      152104      236284         472      100964  323824
core-image-ptest-fast
              total        used        free      shared  buff/cache available
Mem:        1004680       43456      927688         256       33536  941156
b) with prelink
core-image-sato-sdk
               total        used        free      shared  buff/cache available
Mem:          489352      153048      235544         468      100760  322900
core-image-ptest-fast
              total        used        free      shared  buff/cache available
Mem:        1004680       44444      928128         256       32108  940168
2. Running -c testimage
a) without prelink
core-image-sato-sdk () - Ran 66 tests in 96.693s
core-image-sato-sdk () - Ran 66 tests in 96.469s
core-image-sato-sdk () - Ran 66 tests in 94.994s
core-image-ptest-fast () - Ran 66 tests in 583.767s
core-image-ptest-fast () - Ran 66 tests in 576.564s
core-image-ptest-fast () - Ran 66 tests in 576.797s
b) with prelink
core-image-sato-sdk () - Ran 66 tests in 96.390s
core-image-sato-sdk () - Ran 66 tests in 96.615s
core-image-sato-sdk () - Ran 66 tests in 95.596s
core-image-ptest-fast () - Ran 66 tests in 576.248s
core-image-ptest-fast () - Ran 66 tests in 574.618s
core-image-ptest-fast () - Ran 66 tests in 576.760s

I think the advantage is not on high end CPUs but more on less powerful ones, so perhaps trying it on something like rpi0 or lower would be good

So the memory usage is actually *better* without prelink. And any timing benefits are lost in statistical noise, in these tests at least.
So I do not think it is wrong to question the usefulness of this feature. I'd like to hear Mark's take on this, as prelink-cross is primarily his work, he's put a lot of effort into it, and I would want to know where the benefits are. Note that Red Hat abandoned prelink in 2013, and prelink-cross likewise hasn't seen any commits for two years.

Alex

From: Yann Dirson <yann@...>

This is a RK3328 board from Pine64.
Board details at https://wiki.pine64.org/wiki/ROCK64.

Default image is built to boot from SD-card. Building an image for
eMMC requires to set RK_BOOT_DEVICE=3D"mmcblk0".

Signed-off-by: Yann Dirson <yann@...>
---

This is just basic initial support without a kernel BSP. As is the
board boots with a serial console.

Note I had to create the SoC definition for rk3328, and rather than
setting serial at 115200 there just to have the board definition
override it with rockchip-standard 1500000 I've set the latter right
in rk3328.inc.

Changes in v3:
- add board to README
- use rock-pi-e.wks rather than rock-pi-4.wks (identical contents today)
- put copyright info straight

Changes in v2:
- include Ayufan's patch for mmc aliases so presence of eMMC won't
prevent booting from SD

README | 1 +
conf/machine/include/rk3328.inc | 25 +++++++++++++++
conf/machine/rock64.conf | 31 +++++++++++++++++++
...an-dtsi-rk3328-add-mmc0-mmc1-aliases.patch | 27 ++++++++++++++++
recipes-kernel/linux/linux-yocto%.bbappend | 6 ++++
5 files changed, 90 insertions(+)
create mode 100644 conf/machine/include/rk3328.inc
create mode 100644 conf/machine/rock64.conf
create mode 100644 recipes-kernel/linux/files/0001-ayufan-dtsi-rk3328-ad=
d-mmc0-mmc1-aliases.patch

diff --git a/README b/README
index b825eba..cec1b53 100644
--- a/README
+++ b/README
@@ -24,6 +24,7 @@ Status of supported boards:
rock-pi-4a
rock-pi-4b
rock-pi-4c
+ rock64
tinker-board
tinker-board-s
vyasa-rk3288
diff --git a/conf/machine/include/rk3328.inc b/conf/machine/include/rk332=
8.inc
new file mode 100644
index 0000000..a4bbc5d
--- /dev/null
+++ b/conf/machine/include/rk3328.inc
@@ -0,0 +1,25 @@
+# Copyright (C) 2021 Blade SAS
+# Released under the MIT license (see COPYING.MIT for the terms)
+
+SOC_FAMILY =3D "rk3328"
+
+DEFAULTTUNE ?=3D "cortexa53-crypto"
+
+require conf/machine/include/soc-family.inc
+require conf/machine/include/tune-cortexa53.inc
+require conf/machine/include/rockchip-defaults.inc
+
+KBUILD_DEFCONFIG ?=3D "defconfig"
+KERNEL_CLASSES =3D "kernel-fitimage"
+KERNEL_IMAGETYPE =3D "fitImage"
+
+TFA_PLATFORM =3D "rk3328"
+TFA_BUILD_TARGET =3D "bl31"
+
+UBOOT_SUFFIX ?=3D "itb"
+UBOOT_ENTRYPOINT ?=3D "0x06000000"
+
+SERIAL_CONSOLES =3D "1500000;ttyS2"
+
+PREFERRED_PROVIDER_virtual/bootloader ?=3D "u-boot"
+SPL_BINARY ?=3D "idbloader.img"
diff --git a/conf/machine/rock64.conf b/conf/machine/rock64.conf
new file mode 100644
index 0000000..acda018
--- /dev/null
+++ b/conf/machine/rock64.conf
@@ -0,0 +1,31 @@
+# Copyright (C) 2021 Blade SAS
+# Released under the MIT license (see COPYING.MIT for the terms)
+
+#@TYPE: Machine
+#@NAME: Rock64
+#@DESCRIPTION: Rock64 RK3328 board from Pine64
+
+require include/rk3328.inc
+
+MACHINE_FEATURES +=3D "usbhost serial"
+
+UBOOT_MACHINE =3D "rock64-rk3328_defconfig"
+KERNEL_DEVICETREE =3D "rockchip/rk3328-rock64.dtb"
+
+# set to mmcblk0 for booting from optional eMMC
+RK_BOOT_DEVICE ?=3D "mmcblk1"
+
+WKS_FILE ?=3D "rock-pi-e.wks"
+IMAGE_FSTYPES +=3D "wic wic.bmap"
+
+WKS_FILE_DEPENDS ?=3D " \
+ mtools-native \
+ dosfstools-native \
+ virtual/bootloader \
+ virtual/kernel \
+ "
+IMAGE_BOOT_FILES ?=3D "\
+ ${KERNEL_IMAGETYPE} \
+ "
+
+KBUILD_DEFCONFIG =3D "defconfig"
diff --git a/recipes-kernel/linux/files/0001-ayufan-dtsi-rk3328-add-mmc0-=
mmc1-aliases.patch b/recipes-kernel/linux/files/0001-ayufan-dtsi-rk3328-a=
dd-mmc0-mmc1-aliases.patch
new file mode 100644
index 0000000..1ad3b9e
--- /dev/null
+++ b/recipes-kernel/linux/files/0001-ayufan-dtsi-rk3328-add-mmc0-mmc1-al=
iases.patch
@@ -0,0 +1,27 @@
+From f10cfe01f753348d346374008b8e8f5f26ed94ab Mon Sep 17 00:00:00 2001
+From: Kamil Trzcinski <ayufan@...>
+Date: Mon, 28 Aug 2017 11:24:37 +0200
+Subject: [PATCH] ayufan: dtsi: rk3328: add mmc0/mmc1 aliases
+Upstream-Status: Pending [https://github.com/ayufan-rock64/linux-mainlin=
e-kernel/commit/f10cfe01f753348d346374008b8e8f5f26ed94ab]
+
+Change-Id: I82a5394df8a505f7d1496393621c1198895c88b0
+---
+ arch/arm64/boot/dts/rockchip/rk3328.dtsi | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/boot/=
dts/rockchip/rk3328.dtsi
+index 0afed15bc7ff..800f1c796882 100644
+--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
++++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+@@ -27,6 +27,8 @@
+ i2c1 =3D &i2c1;
+ i2c2 =3D &i2c2;
+ i2c3 =3D &i2c3;
++ mmc0 =3D &emmc;
++ mmc1 =3D &sdmmc;
+ ethernet0 =3D &gmac2io;
+ ethernet1 =3D &gmac2phy;
+ };
+--=20
+2.30.2
+
diff --git a/recipes-kernel/linux/linux-yocto%.bbappend b/recipes-kernel/=
linux/linux-yocto%.bbappend
index 7702e3f..3789c72 100644
--- a/recipes-kernel/linux/linux-yocto%.bbappend
+++ b/recipes-kernel/linux/linux-yocto%.bbappend
@@ -8,3 +8,9 @@ COMPATIBLE_MACHINE_tinker-board-s =3D "tinker-board-s"
COMPATIBLE_MACHINE_rock-pi-4 =3D "rock-pi-4"
COMPATIBLE_MACHINE_nanopi-m4 =3D "nanopi-m4"
COMPATIBLE_MACHINE_nanopi-m4-2gb =3D "nanopi-m4-2gb"
+COMPATIBLE_MACHINE_rock64 =3D "rock64"
+
+FILESEXTRAPATHS_prepend :=3D "${THISDIR}/files:"
+
+# indeed applicable to all rk3328 boards
+SRC_URI_append_rock64 =3D " file://0001-ayufan-dtsi-rk3328-add-mmc0-mmc1=
-aliases.patch"
--=20
2.30.2

Le mar. 15 juin 2021 à 10:16, Trevor Woerner <twoerner@...> a écrit :

On Tue 2021-06-15 @ 10:03:31 AM, Yann Dirson wrote:

Le lun. 14 juin 2021 à 18:19, Trevor Woerner <twoerner@...> a écrit :

Hi Yann,

Thanks for the contribution!

On Mon 2021-05-31 @ 04:00:58 PM, yann.dirson@... wrote:

From: Yann Dirson <yann@...>

This is a RK3328 board from Pine64.
Board details at https://wiki.pine64.org/wiki/ROCK64.

Default image is built to boot from SD-card. Building an image for
eMMC requires to set RK_BOOT_DEVICE="mmcblk0".

Signed-off-by: Yann Dirson <yann@...>
---

This is just basic initial support without a kernel BSP. As is the
board boots with a serial console.

Note I had to create the SoC definition for rk3328, and rather than
setting serial at 115200 there just to have the board definition
override it with rockchip-standard 1500000 I've set the latter right
in rk3328.inc.

Sounds good. I prefer the rockchip default of 1,500,000 anyway.

Changes in v2:
- include Ayufan's patch for mmc aliases so presence of eMMC won't
prevent booting from SD

conf/machine/include/rk3328.inc | 25 ++++++++++++++++
conf/machine/rock64.conf | 30 +++++++++++++++++++
...an-dtsi-rk3328-add-mmc0-mmc1-aliases.patch | 27 +++++++++++++++++
recipes-kernel/linux/linux-yocto%.bbappend | 6 ++++
4 files changed, 88 insertions(+)
create mode 100644 conf/machine/include/rk3328.inc
create mode 100644 conf/machine/rock64.conf
create mode 100644 recipes-kernel/linux/files/0001-ayufan-dtsi-rk3328-add-mmc0-mmc1-aliases.patch

diff --git a/conf/machine/include/rk3328.inc b/conf/machine/include/rk3328.inc
new file mode 100644
index 0000000..7d67627
--- /dev/null
+++ b/conf/machine/include/rk3328.inc
@@ -0,0 +1,25 @@
+# Copyright (C) 2020 Garmin Ltd. or its subsidaries

Odd that you'd be assigning the copyright to Garmin ;-)

Oh, right, copypaste rules around here, so Garmin does have a role but
something may be missing :)

+# Released under the MIT license (see COPYING.MIT for the terms)
+
+SOC_FAMILY = "rk3328"
+
+DEFAULTTUNE ?= "cortexa53-crypto"
+
+require conf/machine/include/soc-family.inc
+require conf/machine/include/tune-cortexa53.inc
+require conf/machine/include/rockchip-defaults.inc
+
+KBUILD_DEFCONFIG ?= "defconfig"
+KERNEL_CLASSES = "kernel-fitimage"
+KERNEL_IMAGETYPE = "fitImage"
+
+TFA_PLATFORM = "rk3328"
+TFA_BUILD_TARGET = "bl31"
+
+UBOOT_SUFFIX ?= "itb"
+UBOOT_ENTRYPOINT ?= "0x06000000"
+
+SERIAL_CONSOLES = "1500000;ttyS2"
+
+PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot"
+SPL_BINARY ?= "idbloader.img"
diff --git a/conf/machine/rock64.conf b/conf/machine/rock64.conf
new file mode 100644
index 0000000..38bc9fa
--- /dev/null
+++ b/conf/machine/rock64.conf
@@ -0,0 +1,30 @@
+# Copyright (C) 2021 Blade SAS

Can you also specify an OSS-friendly licence too?

+
+#@TYPE: Machine
+#@NAME: Rock64
+#@DESCRIPTION: Rock64 RK3328 board from Pine64
+
+require include/rk3328.inc
+
+MACHINE_FEATURES += "usbhost serial"
+
+UBOOT_MACHINE = "rock64-rk3328_defconfig"
+KERNEL_DEVICETREE = "rockchip/rk3328-rock64.dtb"
+
+# set to mmcblk0 for booting from optional eMMC
+RK_BOOT_DEVICE ?= "mmcblk1"
+
+WKS_FILE ?= "rock-pi-4.wks"

Personally I'd prefer to see a rock64 wic file which includes an rk3328
default, even if it is a copy of the rock-pi-4 layout.

In fact we already have rock-pi-e.wks doing this.

Right that was something I wondered how to deal with and forgot (and note that
for the nanopi-m4 I used the same file).

My reading of [1] is that all rockchip APs are using the same
partition table. I see
that the existing {rk3288,rk3399}-boot.wks only differ in the choice
of u-boot image,
and I'm wondering if using the SoC to distinguish between them is the
right choice,
as eg. upstream RK is not using the .itb format, and I suspect we
could use it as well
for rk3288 (I'm sure I have one in a drawer and could check that some day). Now
maybe the sate of things is different for 32bit SoCs, and I thought it
could make sense to
distinguish rockchip-32bit-boot.wks and rockchip-64bit-boot.wks, or maybe even
name them using the format, as something like rockchip-legacy-boot.wks
(well there
is probably a more descriptive name for that format) and rockchip-itb-boot.wks ?

Similarly, the .wks for 3288-based boards and for 3399-based ones only
differ by the
console baudrate, and the 3288-based .wks are all identical except for
some whitespace.
And in fact, it is not unthinkable for a given project to use
something else than a
single-partition layout, so those files are indeed closer to a
"default wks". Maybe we
could use more generic filenames there too (until we implement a way to avoid
hardcoding the baudrate here)

[1] http://opensource.rock-chips.com/wiki_Boot_option

True. We could definitely use some cleanup in this area. If you want to
propose something that's going to work, I'll add it.

Also, when adding a new board, please update the top-level README.

Let's do the minimum for now for this to get merged, and we'll improve
incrementally.
Eg. only now I realize, through the presence of rk3328-boot.wks, that
rock-pi-e is
indeed also based on that soc, and its machine def would benefit from
including the
same rk3328.inc.

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

From: Kai Kang <kai.kang@...>

/var/run is deprecated and set pid path with /run to store pid files for
the SSSD.

Signed-off-by: Kai Kang <kai.kang@...>
---
recipes-security/sssd/sssd_2.5.0.bb | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/recipes-security/sssd/sssd_2.5.0.bb b/recipes-security/sssd/sssd_2.5.0.bb
index 4c92519..c699527 100644
--- a/recipes-security/sssd/sssd_2.5.0.bb
+++ b/recipes-security/sssd/sssd_2.5.0.bb
@@ -63,6 +63,7 @@ EXTRA_OECONF += " \
--without-python2-bindings \
--without-secrets \
--with-xml-catalog-path=${STAGING_ETCDIR_NATIVE}/xml/catalog \
+ --with-pid-path=/run \
"

do_configure_prepend() {
@@ -88,8 +89,8 @@ do_install () {
echo "d /var/log/sssd 0750 - - - -" > ${D}${sysconfdir}/tmpfiles.d/sss.conf
fi

- # Remove /var/run as it is created on startup
- rm -rf ${D}${localstatedir}/run
+ # Remove /run as it is created on startup
+ rm -rf ${D}/run

rm -f ${D}${systemd_system_unitdir}/sssd-secrets.*
}
--
2.17.1

On Tue 2021-06-15 @ 10:03:31 AM, Yann Dirson wrote:

Le lun. 14 juin 2021 à 18:19, Trevor Woerner <twoerner@...> a écrit :

Hi Yann,

Thanks for the contribution!

On Mon 2021-05-31 @ 04:00:58 PM, yann.dirson@... wrote:

From: Yann Dirson <yann@...>

This is a RK3328 board from Pine64.
Board details at https://wiki.pine64.org/wiki/ROCK64.

Default image is built to boot from SD-card. Building an image for
eMMC requires to set RK_BOOT_DEVICE="mmcblk0".

Signed-off-by: Yann Dirson <yann@...>
---

This is just basic initial support without a kernel BSP. As is the
board boots with a serial console.

Note I had to create the SoC definition for rk3328, and rather than
setting serial at 115200 there just to have the board definition
override it with rockchip-standard 1500000 I've set the latter right
in rk3328.inc.

Sounds good. I prefer the rockchip default of 1,500,000 anyway.

Changes in v2:
- include Ayufan's patch for mmc aliases so presence of eMMC won't
prevent booting from SD

conf/machine/include/rk3328.inc | 25 ++++++++++++++++
conf/machine/rock64.conf | 30 +++++++++++++++++++
...an-dtsi-rk3328-add-mmc0-mmc1-aliases.patch | 27 +++++++++++++++++
recipes-kernel/linux/linux-yocto%.bbappend | 6 ++++
4 files changed, 88 insertions(+)
create mode 100644 conf/machine/include/rk3328.inc
create mode 100644 conf/machine/rock64.conf
create mode 100644 recipes-kernel/linux/files/0001-ayufan-dtsi-rk3328-add-mmc0-mmc1-aliases.patch

diff --git a/conf/machine/include/rk3328.inc b/conf/machine/include/rk3328.inc
new file mode 100644
index 0000000..7d67627
--- /dev/null
+++ b/conf/machine/include/rk3328.inc
@@ -0,0 +1,25 @@
+# Copyright (C) 2020 Garmin Ltd. or its subsidaries

Odd that you'd be assigning the copyright to Garmin ;-)

Oh, right, copypaste rules around here, so Garmin does have a role but
something may be missing :)

+# Released under the MIT license (see COPYING.MIT for the terms)
+
+SOC_FAMILY = "rk3328"
+
+DEFAULTTUNE ?= "cortexa53-crypto"
+
+require conf/machine/include/soc-family.inc
+require conf/machine/include/tune-cortexa53.inc
+require conf/machine/include/rockchip-defaults.inc
+
+KBUILD_DEFCONFIG ?= "defconfig"
+KERNEL_CLASSES = "kernel-fitimage"
+KERNEL_IMAGETYPE = "fitImage"
+
+TFA_PLATFORM = "rk3328"
+TFA_BUILD_TARGET = "bl31"
+
+UBOOT_SUFFIX ?= "itb"
+UBOOT_ENTRYPOINT ?= "0x06000000"
+
+SERIAL_CONSOLES = "1500000;ttyS2"
+
+PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot"
+SPL_BINARY ?= "idbloader.img"
diff --git a/conf/machine/rock64.conf b/conf/machine/rock64.conf
new file mode 100644
index 0000000..38bc9fa
--- /dev/null
+++ b/conf/machine/rock64.conf
@@ -0,0 +1,30 @@
+# Copyright (C) 2021 Blade SAS

Can you also specify an OSS-friendly licence too?

+
+#@TYPE: Machine
+#@NAME: Rock64
+#@DESCRIPTION: Rock64 RK3328 board from Pine64
+
+require include/rk3328.inc
+
+MACHINE_FEATURES += "usbhost serial"
+
+UBOOT_MACHINE = "rock64-rk3328_defconfig"
+KERNEL_DEVICETREE = "rockchip/rk3328-rock64.dtb"
+
+# set to mmcblk0 for booting from optional eMMC
+RK_BOOT_DEVICE ?= "mmcblk1"
+
+WKS_FILE ?= "rock-pi-4.wks"

Personally I'd prefer to see a rock64 wic file which includes an rk3328
default, even if it is a copy of the rock-pi-4 layout.

Right that was something I wondered how to deal with and forgot (and note that
for the nanopi-m4 I used the same file).

My reading of [1] is that all rockchip APs are using the same
partition table. I see
that the existing {rk3288,rk3399}-boot.wks only differ in the choice
of u-boot image,
and I'm wondering if using the SoC to distinguish between them is the
right choice,
as eg. upstream RK is not using the .itb format, and I suspect we
could use it as well
for rk3288 (I'm sure I have one in a drawer and could check that some day). Now
maybe the sate of things is different for 32bit SoCs, and I thought it
could make sense to
distinguish rockchip-32bit-boot.wks and rockchip-64bit-boot.wks, or maybe even
name them using the format, as something like rockchip-legacy-boot.wks
(well there
is probably a more descriptive name for that format) and rockchip-itb-boot.wks ?

Similarly, the .wks for 3288-based boards and for 3399-based ones only
differ by the
console baudrate, and the 3288-based .wks are all identical except for
some whitespace.
And in fact, it is not unthinkable for a given project to use
something else than a
single-partition layout, so those files are indeed closer to a
"default wks". Maybe we
could use more generic filenames there too (until we implement a way to avoid
hardcoding the baudrate here)

[1] http://opensource.rock-chips.com/wiki_Boot_option

True. We could definitely use some cleanup in this area. If you want to
propose something that's going to work, I'll add it.

Also, when adding a new board, please update the top-level README.

Thanks!

Le lun. 14 juin 2021 à 18:19, Trevor Woerner <twoerner@...> a écrit :

Hi Yann,

Thanks for the contribution!

On Mon 2021-05-31 @ 04:00:58 PM, yann.dirson@... wrote:

From: Yann Dirson <yann@...>

This is a RK3328 board from Pine64.
Board details at https://wiki.pine64.org/wiki/ROCK64.

Default image is built to boot from SD-card. Building an image for
eMMC requires to set RK_BOOT_DEVICE="mmcblk0".

Signed-off-by: Yann Dirson <yann@...>
---

This is just basic initial support without a kernel BSP. As is the
board boots with a serial console.

Note I had to create the SoC definition for rk3328, and rather than
setting serial at 115200 there just to have the board definition
override it with rockchip-standard 1500000 I've set the latter right
in rk3328.inc.

Sounds good. I prefer the rockchip default of 1,500,000 anyway.

Changes in v2:
- include Ayufan's patch for mmc aliases so presence of eMMC won't
prevent booting from SD

conf/machine/include/rk3328.inc | 25 ++++++++++++++++
conf/machine/rock64.conf | 30 +++++++++++++++++++
...an-dtsi-rk3328-add-mmc0-mmc1-aliases.patch | 27 +++++++++++++++++
recipes-kernel/linux/linux-yocto%.bbappend | 6 ++++
4 files changed, 88 insertions(+)
create mode 100644 conf/machine/include/rk3328.inc
create mode 100644 conf/machine/rock64.conf
create mode 100644 recipes-kernel/linux/files/0001-ayufan-dtsi-rk3328-add-mmc0-mmc1-aliases.patch

diff --git a/conf/machine/include/rk3328.inc b/conf/machine/include/rk3328.inc
new file mode 100644
index 0000000..7d67627
--- /dev/null
+++ b/conf/machine/include/rk3328.inc
@@ -0,0 +1,25 @@
+# Copyright (C) 2020 Garmin Ltd. or its subsidaries

Odd that you'd be assigning the copyright to Garmin ;-)

Oh, right, copypaste rules around here, so Garmin does have a role but
something may be missing :)

+# Released under the MIT license (see COPYING.MIT for the terms)
+
+SOC_FAMILY = "rk3328"
+
+DEFAULTTUNE ?= "cortexa53-crypto"
+
+require conf/machine/include/soc-family.inc
+require conf/machine/include/tune-cortexa53.inc
+require conf/machine/include/rockchip-defaults.inc
+
+KBUILD_DEFCONFIG ?= "defconfig"
+KERNEL_CLASSES = "kernel-fitimage"
+KERNEL_IMAGETYPE = "fitImage"
+
+TFA_PLATFORM = "rk3328"
+TFA_BUILD_TARGET = "bl31"
+
+UBOOT_SUFFIX ?= "itb"
+UBOOT_ENTRYPOINT ?= "0x06000000"
+
+SERIAL_CONSOLES = "1500000;ttyS2"
+
+PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot"
+SPL_BINARY ?= "idbloader.img"
diff --git a/conf/machine/rock64.conf b/conf/machine/rock64.conf
new file mode 100644
index 0000000..38bc9fa
--- /dev/null
+++ b/conf/machine/rock64.conf
@@ -0,0 +1,30 @@
+# Copyright (C) 2021 Blade SAS

Can you also specify an OSS-friendly licence too?

+
+#@TYPE: Machine
+#@NAME: Rock64
+#@DESCRIPTION: Rock64 RK3328 board from Pine64
+
+require include/rk3328.inc
+
+MACHINE_FEATURES += "usbhost serial"
+
+UBOOT_MACHINE = "rock64-rk3328_defconfig"
+KERNEL_DEVICETREE = "rockchip/rk3328-rock64.dtb"
+
+# set to mmcblk0 for booting from optional eMMC
+RK_BOOT_DEVICE ?= "mmcblk1"
+
+WKS_FILE ?= "rock-pi-4.wks"

Personally I'd prefer to see a rock64 wic file which includes an rk3328
default, even if it is a copy of the rock-pi-4 layout.

Right that was something I wondered how to deal with and forgot (and note that
for the nanopi-m4 I used the same file).

My reading of [1] is that all rockchip APs are using the same
partition table. I see
that the existing {rk3288,rk3399}-boot.wks only differ in the choice
of u-boot image,
and I'm wondering if using the SoC to distinguish between them is the
right choice,
as eg. upstream RK is not using the .itb format, and I suspect we
could use it as well
for rk3288 (I'm sure I have one in a drawer and could check that some day). Now
maybe the sate of things is different for 32bit SoCs, and I thought it
could make sense to
distinguish rockchip-32bit-boot.wks and rockchip-64bit-boot.wks, or maybe even
name them using the format, as something like rockchip-legacy-boot.wks
(well there
is probably a more descriptive name for that format) and rockchip-itb-boot.wks ?

Similarly, the .wks for 3288-based boards and for 3399-based ones only
differ by the
console baudrate, and the 3288-based .wks are all identical except for
some whitespace.
And in fact, it is not unthinkable for a given project to use
something else than a
single-partition layout, so those files are indeed closer to a
"default wks". Maybe we
could use more generic filenames there too (until we implement a way to avoid
hardcoding the baudrate here)

[1] http://opensource.rock-chips.com/wiki_Boot_option

+IMAGE_FSTYPES += "wic wic.bmap"
+
+WKS_FILE_DEPENDS ?= " \
+ mtools-native \
+ dosfstools-native \
+ virtual/bootloader \
+ virtual/kernel \
+ "
+IMAGE_BOOT_FILES ?= "\
+ ${KERNEL_IMAGETYPE} \
+ "
+
+KBUILD_DEFCONFIG = "defconfig"
diff --git a/recipes-kernel/linux/files/0001-ayufan-dtsi-rk3328-add-mmc0-mmc1-aliases.patch b/recipes-kernel/linux/files/0001-ayufan-dtsi-rk3328-add-mmc0-mmc1-aliases.patch
new file mode 100644
index 0000000..1ad3b9e
--- /dev/null
+++ b/recipes-kernel/linux/files/0001-ayufan-dtsi-rk3328-add-mmc0-mmc1-aliases.patch
@@ -0,0 +1,27 @@
+From f10cfe01f753348d346374008b8e8f5f26ed94ab Mon Sep 17 00:00:00 2001
+From: Kamil Trzcinski <ayufan@...>
+Date: Mon, 28 Aug 2017 11:24:37 +0200
+Subject: [PATCH] ayufan: dtsi: rk3328: add mmc0/mmc1 aliases
+Upstream-Status: Pending [https://github.com/ayufan-rock64/linux-mainline-kernel/commit/f10cfe01f753348d346374008b8e8f5f26ed94ab]
+
+Change-Id: I82a5394df8a505f7d1496393621c1198895c88b0
+---
+ arch/arm64/boot/dts/rockchip/rk3328.dtsi | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+index 0afed15bc7ff..800f1c796882 100644
+--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
++++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+@@ -27,6 +27,8 @@
+ i2c1 = &i2c1;
+ i2c2 = &i2c2;
+ i2c3 = &i2c3;
++ mmc0 = &emmc;
++ mmc1 = &sdmmc;
+ ethernet0 = &gmac2io;
+ ethernet1 = &gmac2phy;
+ };
+--
+2.30.2
+
diff --git a/recipes-kernel/linux/linux-yocto%.bbappend b/recipes-kernel/linux/linux-yocto%.bbappend
index 7702e3f..3789c72 100644
--- a/recipes-kernel/linux/linux-yocto%.bbappend
+++ b/recipes-kernel/linux/linux-yocto%.bbappend
@@ -8,3 +8,9 @@ COMPATIBLE_MACHINE_tinker-board-s = "tinker-board-s"
COMPATIBLE_MACHINE_rock-pi-4 = "rock-pi-4"
COMPATIBLE_MACHINE_nanopi-m4 = "nanopi-m4"
COMPATIBLE_MACHINE_nanopi-m4-2gb = "nanopi-m4-2gb"
+COMPATIBLE_MACHINE_rock64 = "rock64"
+
+FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
+
+# indeed applicable to all rk3328 boards

I have a roc-rk3328-cc ("renegade") board I should investigate adding. Then I
can see if this applies there as well.

+SRC_URI_append_rock64 = " file://0001-ayufan-dtsi-rk3328-add-mmc0-mmc1-aliases.patch"
--
2.30.2

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

This ensures that DISTRO_FEATURES can translates correctly
for qtbate packageconfigs and we can get right platforms enabled

Signed-off-by: Khem Raj <raj.khem@...>
---
conf/layer.conf | 5 +++++
.../qt5-layer/recipes-qt/qt5/qtbase_%.bbappend | 9 +++++++++
2 files changed, 14 insertions(+)
create mode 100644 dynamic-layers/qt5-layer/recipes-qt/qt5/qtbase_%.bbappend

diff --git a/conf/layer.conf b/conf/layer.conf
index b263b6f..f97fb69 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -16,3 +16,8 @@ BBFILE_PRIORITY_rockchip = "1"
LAYERVERSION_rockchip = "1"
LAYERSERIES_COMPAT_rockchip = "hardknott"
LAYERDEPENDS_rockchip = "core meta-arm"
+
+BBFILES_DYNAMIC += " \
+ qt5-layer:${LAYERDIR}/dynamic-layers/qt5-layer/*/*/*.bb \
+ qt5-layer:${LAYERDIR}/dynamic-layers/qt5-layer/*/*/*.bbappend \
+"
diff --git a/dynamic-layers/qt5-layer/recipes-qt/qt5/qtbase_%.bbappend b/dynamic-layers/qt5-layer/recipes-qt/qt5/qtbase_%.bbappend
new file mode 100644
index 0000000..a977229
--- /dev/null
+++ b/dynamic-layers/qt5-layer/recipes-qt/qt5/qtbase_%.bbappend
@@ -0,0 +1,9 @@
+PACKAGECONFIG_GL_rk3399 = "${@bb.utils.contains('DISTRO_FEATURES', 'x11 opengl', 'gl', \
+ bb.utils.contains('DISTRO_FEATURES', 'opengl', 'eglfs gles2', \
+ '', d), d)}"
+PACKAGECONFIG_GL_append_rk3399 = " kms gbm"
+
+PACKAGECONFIG_FONTS_rk3399 = "fontconfig"
+
+PACKAGECONFIG_append_rk3399 = " libinput examples tslib xkbcommon"
+PACKAGECONFIG_remove_rk3399 = "tests"
--
2.32.0

On Mon, 2021-06-14 at 21:31 +0000, Richard Leitner - SKIDATA wrote:

On Mon, Jun 14, 2021 at 09:29:05PM +0100, Richard Purdie wrote:

On Mon, 2021-06-14 at 20:20 +0000, Richard Leitner - SKIDATA wrote:

On Thu, Jun 10, 2021 at 10:57:46AM +0200, Alexander Kanavin wrote:

I have the tarball. I think we should toss it somewhere safe and update the
recipe, as it is unlikely the old mercurial repo is coming back.

Suggestions?

Sorry for the late reply, I was on vacation 😉.

Nothing that comes to my mind directly. Do you know of any hosting
possibilites from YP or OE-Core?

@Richard: Sorry for putting you in that conversation without warning...
But maybe you may guide us in a direction where to host/mirror some "legacy"
meta-java source tarballs?

If someone points me at the tarballs I can probably sort something out with
our source mirrors.

Thank you very much Richard!
The openjdk8 tarballs are now hosted at https://downloads.yoctoproject.org/mirror/sources/
with their local download names.

Unfortunately I currently don't have the time and resources to provide a
patch for fixing the URLs and adding the mirror.
So help is greatly appreciated!

In theory if these are the names the metadata was using and you have the standard
OE/Yocto source mirrors, this should "just work"...

Cheers,

Richard

On Mon, Jun 14, 2021 at 09:29:05PM +0100, Richard Purdie wrote:

On Mon, 2021-06-14 at 20:20 +0000, Richard Leitner - SKIDATA wrote:

On Thu, Jun 10, 2021 at 10:57:46AM +0200, Alexander Kanavin wrote:

I have the tarball. I think we should toss it somewhere safe and update the
recipe, as it is unlikely the old mercurial repo is coming back.

Suggestions?

Sorry for the late reply, I was on vacation 😉.

Nothing that comes to my mind directly. Do you know of any hosting
possibilites from YP or OE-Core?

@Richard: Sorry for putting you in that conversation without warning...
But maybe you may guide us in a direction where to host/mirror some "legacy"
meta-java source tarballs?

If someone points me at the tarballs I can probably sort something out with
our source mirrors.

Thank you very much Richard!
The openjdk8 tarballs are now hosted at https://downloads.yoctoproject.org/mirror/sources/
with their local download names.

Unfortunately I currently don't have the time and resources to provide a
patch for fixing the URLs and adding the mirror.
So help is greatly appreciated!

regards;rl

Cheers,

Richard

On Mon, Jun 14, 2021 at 09:29:05PM +0100, Richard Purdie wrote:

On Mon, 2021-06-14 at 20:20 +0000, Richard Leitner - SKIDATA wrote:

On Thu, Jun 10, 2021 at 10:57:46AM +0200, Alexander Kanavin wrote:

I have the tarball. I think we should toss it somewhere safe and update the
recipe, as it is unlikely the old mercurial repo is coming back.

Suggestions?

Sorry for the late reply, I was on vacation 😉.

Nothing that comes to my mind directly. Do you know of any hosting
possibilites from YP or OE-Core?

@Richard: Sorry for putting you in that conversation without warning...
But maybe you may guide us in a direction where to host/mirror some "legacy"
meta-java source tarballs?

If someone points me at the tarballs I can probably sort something out with
our source mirrors.

Thanks for that!

I'm currently uploading the tarballs and provide you the link as soon as
it's finished (sorry, really crappy uplink here 😕)

It's about 1GiB with following files affected:

openjdk8-242-corba-aarch64-shenandoah-jdk8u242-b07.tar.bz2
openjdk8-242-corba-jdk8u242-ga-aarch32-200120.tar.bz2
openjdk8-242-corba-jdk8u242-ga.tar.bz2
openjdk8-242-hotspot-aarch64-shenandoah-jdk8u242-b07.tar.bz2
openjdk8-242-hotspot-jdk8u242-ga-aarch32-200120.tar.bz2
openjdk8-242-hotspot-jdk8u242-ga.tar.bz2
openjdk8-242-jaxp-aarch64-shenandoah-jdk8u242-b07.tar.bz2
openjdk8-242-jaxp-jdk8u242-ga-aarch32-200120.tar.bz2
openjdk8-242-jaxp-jdk8u242-ga.tar.bz2
openjdk8-242-jaxws-aarch64-shenandoah-jdk8u242-b07.tar.bz2
openjdk8-242-jaxws-jdk8u242-ga-aarch32-200120.tar.bz2
openjdk8-242-jaxws-jdk8u242-ga.tar.bz2
openjdk8-242-jdk8u-aarch64-shenandoah-jdk8u242-b07.tar.bz2
openjdk8-242-jdk8u-jdk8u242-ga-aarch32-200120.tar.bz2
openjdk8-242-jdk8u-jdk8u242-ga.tar.bz2
openjdk8-242-jdk-aarch64-shenandoah-jdk8u242-b07.tar.bz2
openjdk8-242-jdk-jdk8u242-ga-aarch32-200120.tar.bz2
openjdk8-242-jdk-jdk8u242-ga.tar.bz2
openjdk8-242-langtools-aarch64-shenandoah-jdk8u242-b07.tar.bz2
openjdk8-242-langtools-jdk8u242-ga-aarch32-200120.tar.bz2
openjdk8-242-langtools-jdk8u242-ga.tar.bz2
openjdk8-242-nashorn-aarch64-shenandoah-jdk8u242-b07.tar.bz2
openjdk8-242-nashorn-jdk8u242-ga-aarch32-200120.tar.bz2
openjdk8-242-nashorn-jdk8u242-ga.tar.bz2
openjdk8-252-corba-aarch64-shenandoah-jdk8u252-b09.tar.bz2
openjdk8-252-corba-jdk8u252-ga-aarch32-20200415.tar.bz2
openjdk8-252-corba-jdk8u252-ga.tar.bz2
openjdk8-252-hotspot-aarch64-shenandoah-jdk8u252-b09.tar.bz2
openjdk8-252-hotspot-jdk8u252-ga-aarch32-20200415.tar.bz2
openjdk8-252-hotspot-jdk8u252-ga.tar.bz2
openjdk8-252-jaxp-aarch64-shenandoah-jdk8u252-b09.tar.bz2
openjdk8-252-jaxp-jdk8u252-ga-aarch32-20200415.tar.bz2
openjdk8-252-jaxp-jdk8u252-ga.tar.bz2
openjdk8-252-jaxws-aarch64-shenandoah-jdk8u252-b09.tar.bz2
openjdk8-252-jaxws-jdk8u252-ga-aarch32-20200415.tar.bz2
openjdk8-252-jaxws-jdk8u252-ga.tar.bz2
openjdk8-252-jdk8u-aarch64-shenandoah-jdk8u252-b09.tar.bz2
openjdk8-252-jdk8u-jdk8u252-ga-aarch32-20200415.tar.bz2
openjdk8-252-jdk8u-jdk8u252-ga.tar.bz2
openjdk8-252-jdk-aarch64-shenandoah-jdk8u252-b09.tar.bz2
openjdk8-252-jdk-jdk8u252-ga-aarch32-20200415.tar.bz2
openjdk8-252-jdk-jdk8u252-ga.tar.bz2
openjdk8-252-langtools-aarch64-shenandoah-jdk8u252-b09.tar.bz2
openjdk8-252-langtools-jdk8u252-ga-aarch32-20200415.tar.bz2
openjdk8-252-langtools-jdk8u252-ga.tar.bz2
openjdk8-252-nashorn-aarch64-shenandoah-jdk8u252-b09.tar.bz2
openjdk8-252-nashorn-jdk8u252-ga-aarch32-20200415.tar.bz2
openjdk8-252-nashorn-jdk8u252-ga.tar.bz2
openjdk8-265-corba-jdk8u265-ga-aarch32-20200729.tar.bz2
openjdk8-265-corba-jdk8u265-ga.tar.bz2
openjdk8-265-hotspot-jdk8u265-ga-aarch32-20200729.tar.bz2
openjdk8-265-hotspot-jdk8u265-ga.tar.bz2
openjdk8-265-jaxp-jdk8u265-ga-aarch32-20200729.tar.bz2
openjdk8-265-jaxp-jdk8u265-ga.tar.bz2
openjdk8-265-jaxws-jdk8u265-ga-aarch32-20200729.tar.bz2
openjdk8-265-jaxws-jdk8u265-ga.tar.bz2
openjdk8-265-jdk8u-jdk8u265-ga-aarch32-20200729.tar.bz2
openjdk8-265-jdk8u-jdk8u265-ga.tar.bz2
openjdk8-265-jdk-jdk8u265-ga-aarch32-20200729.tar.bz2
openjdk8-265-jdk-jdk8u265-ga.tar.bz2
openjdk8-265-langtools-jdk8u265-ga-aarch32-20200729.tar.bz2
openjdk8-265-langtools-jdk8u265-ga.tar.bz2
openjdk8-265-nashorn-jdk8u265-ga-aarch32-20200729.tar.bz2
openjdk8-265-nashorn-jdk8u265-ga.tar.bz2
openjdk8-272-corba-aarch64-shenandoah-jdk8u272-b10.tar.bz2
openjdk8-272-corba-jdk8u272-b09-aarch32-20200929.tar.bz2
openjdk8-272-corba-jdk8u272-ga.tar.bz2
openjdk8-272-hotspot-aarch64-shenandoah-jdk8u272-b10.tar.bz2
openjdk8-272-hotspot-jdk8u272-b09-aarch32-20200929.tar.bz2
openjdk8-272-hotspot-jdk8u272-ga.tar.bz2
openjdk8-272-jaxp-aarch64-shenandoah-jdk8u272-b10.tar.bz2
openjdk8-272-jaxp-jdk8u272-b09-aarch32-20200929.tar.bz2
openjdk8-272-jaxp-jdk8u272-ga.tar.bz2
openjdk8-272-jaxws-aarch64-shenandoah-jdk8u272-b10.tar.bz2
openjdk8-272-jaxws-jdk8u272-b09-aarch32-20200929.tar.bz2
openjdk8-272-jaxws-jdk8u272-ga.tar.bz2
openjdk8-272-jdk8u-aarch64-shenandoah-jdk8u272-b10.tar.bz2
openjdk8-272-jdk8u-jdk8u272-b09-aarch32-20200929.tar.bz2
openjdk8-272-jdk8u-jdk8u272-ga.tar.bz2
openjdk8-272-jdk-aarch64-shenandoah-jdk8u272-b10.tar.bz2
openjdk8-272-jdk-jdk8u272-b09-aarch32-20200929.tar.bz2
openjdk8-272-jdk-jdk8u272-ga.tar.bz2
openjdk8-272-langtools-aarch64-shenandoah-jdk8u272-b10.tar.bz2
openjdk8-272-langtools-jdk8u272-b09-aarch32-20200929.tar.bz2
openjdk8-272-langtools-jdk8u272-ga.tar.bz2
openjdk8-272-nashorn-aarch64-shenandoah-jdk8u272-b10.tar.bz2
openjdk8-272-nashorn-jdk8u272-b09-aarch32-20200929.tar.bz2
openjdk8-272-nashorn-jdk8u272-ga.tar.bz2
openjdk8-292-corba-aarch64-shenandoah-jdk8u292-b10.tar.bz2
openjdk8-292-corba-jdk8u292-ga-aarch32-20210423.tar.bz2
openjdk8-292-corba-jdk8u292-ga.tar.bz2
openjdk8-292-hotspot-aarch64-shenandoah-jdk8u292-b10.tar.bz2
openjdk8-292-hotspot-jdk8u292-ga-aarch32-20210423.tar.bz2
openjdk8-292-hotspot-jdk8u292-ga.tar.bz2
openjdk8-292-jaxp-aarch64-shenandoah-jdk8u292-b10.tar.bz2
openjdk8-292-jaxp-jdk8u292-ga-aarch32-20210423.tar.bz2
openjdk8-292-jaxp-jdk8u292-ga.tar.bz2
openjdk8-292-jaxws-aarch64-shenandoah-jdk8u292-b10.tar.bz2
openjdk8-292-jaxws-jdk8u292-ga-aarch32-20210423.tar.bz2
openjdk8-292-jaxws-jdk8u292-ga.tar.bz2
openjdk8-292-jdk8u-aarch64-shenandoah-jdk8u292-b10.tar.bz2
openjdk8-292-jdk8u-jdk8u292-ga-aarch32-20210423.tar.bz2
openjdk8-292-jdk8u-jdk8u292-ga.tar.bz2
openjdk8-292-jdk-aarch64-shenandoah-jdk8u292-b10.tar.bz2
openjdk8-292-jdk-jdk8u292-ga-aarch32-20210423.tar.bz2
openjdk8-292-jdk-jdk8u292-ga.tar.bz2
openjdk8-292-langtools-aarch64-shenandoah-jdk8u292-b10.tar.bz2
openjdk8-292-langtools-jdk8u292-ga-aarch32-20210423.tar.bz2
openjdk8-292-langtools-jdk8u292-ga.tar.bz2
openjdk8-292-nashorn-aarch64-shenandoah-jdk8u292-b10.tar.bz2
openjdk8-292-nashorn-jdk8u292-ga-aarch32-20210423.tar.bz2
openjdk8-292-nashorn-jdk8u292-ga.tar.bz2
icedtea-2.1.3.tar.gz

Cheers,

Richard

regards;rl

On Mon, 2021-06-14 at 20:20 +0000, Richard Leitner - SKIDATA wrote:

On Thu, Jun 10, 2021 at 10:57:46AM +0200, Alexander Kanavin wrote:

I have the tarball. I think we should toss it somewhere safe and update the
recipe, as it is unlikely the old mercurial repo is coming back.

Suggestions?

Sorry for the late reply, I was on vacation 😉.

Nothing that comes to my mind directly. Do you know of any hosting
possibilites from YP or OE-Core?

@Richard: Sorry for putting you in that conversation without warning...
But maybe you may guide us in a direction where to host/mirror some "legacy"
meta-java source tarballs?

If someone points me at the tarballs I can probably sort something out with
our source mirrors.

Cheers,

Richard

On Thu, Jun 10, 2021 at 10:57:46AM +0200, Alexander Kanavin wrote:

I have the tarball. I think we should toss it somewhere safe and update the
recipe, as it is unlikely the old mercurial repo is coming back.

Suggestions?

Sorry for the late reply, I was on vacation 😉.

Nothing that comes to my mind directly. Do you know of any hosting
possibilites from YP or OE-Core?

@Richard: Sorry for putting you in that conversation without warning...
But maybe you may guide us in a direction where to host/mirror some "legacy"
meta-java source tarballs?

regards;rl

Alex

On Tue, 8 Jun 2021 at 08:10, <George.Mocanu@...> wrote:

Hello,


I am trying to build something that relies on meta-java, but it fails on
do_fetch for the icedtea7 recipe:

--2021-06-07 17:24:33-- http://icedtea.classpath.org/hg/release/icedtea7-forest-2.1/archive/f89009ada191.tar.bz2
Resolving icedtea.classpath.org (icedtea.classpath.org)... 172.104.137.120
Connecting to icedtea.classpath.org (icedtea.classpath.org)|172.104.137.120|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2021-06-07 16:21:05 ERROR 404: Not Found.

ERROR: icedtea7-native-2.1.3-r1.0 do_fetch: Fetcher failure for URL: 'http://icedtea.classpath.org/hg/release/icedtea7-forest-2.1/archive/f89009ada191.tar.bz2;name=openjdk;unpack=false;downloadfilename=openjdk-f89009ada191.tar.bz2'. Unable to fetch URL from any source.


Following this link, seems like the webserver is down. Do you know any
mirror that I can use in the meantime?

Thanks,
George

Hi Yann,

Thanks for the contribution!

On Mon 2021-05-31 @ 04:00:58 PM, yann.dirson@... wrote:

From: Yann Dirson <yann@...>

This is a RK3328 board from Pine64.
Board details at https://wiki.pine64.org/wiki/ROCK64.

Default image is built to boot from SD-card. Building an image for
eMMC requires to set RK_BOOT_DEVICE="mmcblk0".

Signed-off-by: Yann Dirson <yann@...>
---

This is just basic initial support without a kernel BSP. As is the
board boots with a serial console.

Note I had to create the SoC definition for rk3328, and rather than
setting serial at 115200 there just to have the board definition
override it with rockchip-standard 1500000 I've set the latter right
in rk3328.inc.

Sounds good. I prefer the rockchip default of 1,500,000 anyway.

Changes in v2:
- include Ayufan's patch for mmc aliases so presence of eMMC won't
prevent booting from SD

conf/machine/include/rk3328.inc | 25 ++++++++++++++++
conf/machine/rock64.conf | 30 +++++++++++++++++++
...an-dtsi-rk3328-add-mmc0-mmc1-aliases.patch | 27 +++++++++++++++++
recipes-kernel/linux/linux-yocto%.bbappend | 6 ++++
4 files changed, 88 insertions(+)
create mode 100644 conf/machine/include/rk3328.inc
create mode 100644 conf/machine/rock64.conf
create mode 100644 recipes-kernel/linux/files/0001-ayufan-dtsi-rk3328-add-mmc0-mmc1-aliases.patch

diff --git a/conf/machine/include/rk3328.inc b/conf/machine/include/rk3328.inc
new file mode 100644
index 0000000..7d67627
--- /dev/null
+++ b/conf/machine/include/rk3328.inc
@@ -0,0 +1,25 @@
+# Copyright (C) 2020 Garmin Ltd. or its subsidaries

Odd that you'd be assigning the copyright to Garmin ;-)

+# Released under the MIT license (see COPYING.MIT for the terms)
+
+SOC_FAMILY = "rk3328"
+
+DEFAULTTUNE ?= "cortexa53-crypto"
+
+require conf/machine/include/soc-family.inc
+require conf/machine/include/tune-cortexa53.inc
+require conf/machine/include/rockchip-defaults.inc
+
+KBUILD_DEFCONFIG ?= "defconfig"
+KERNEL_CLASSES = "kernel-fitimage"
+KERNEL_IMAGETYPE = "fitImage"
+
+TFA_PLATFORM = "rk3328"
+TFA_BUILD_TARGET = "bl31"
+
+UBOOT_SUFFIX ?= "itb"
+UBOOT_ENTRYPOINT ?= "0x06000000"
+
+SERIAL_CONSOLES = "1500000;ttyS2"
+
+PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot"
+SPL_BINARY ?= "idbloader.img"
diff --git a/conf/machine/rock64.conf b/conf/machine/rock64.conf
new file mode 100644
index 0000000..38bc9fa
--- /dev/null
+++ b/conf/machine/rock64.conf
@@ -0,0 +1,30 @@
+# Copyright (C) 2021 Blade SAS

Can you also specify an OSS-friendly licence too?

+
+#@TYPE: Machine
+#@NAME: Rock64
+#@DESCRIPTION: Rock64 RK3328 board from Pine64
+
+require include/rk3328.inc
+
+MACHINE_FEATURES += "usbhost serial"
+
+UBOOT_MACHINE = "rock64-rk3328_defconfig"
+KERNEL_DEVICETREE = "rockchip/rk3328-rock64.dtb"
+
+# set to mmcblk0 for booting from optional eMMC
+RK_BOOT_DEVICE ?= "mmcblk1"
+
+WKS_FILE ?= "rock-pi-4.wks"

Personally I'd prefer to see a rock64 wic file which includes an rk3328
default, even if it is a copy of the rock-pi-4 layout.

+IMAGE_FSTYPES += "wic wic.bmap"
+
+WKS_FILE_DEPENDS ?= " \
+ mtools-native \
+ dosfstools-native \
+ virtual/bootloader \
+ virtual/kernel \
+ "
+IMAGE_BOOT_FILES ?= "\
+ ${KERNEL_IMAGETYPE} \
+ "
+
+KBUILD_DEFCONFIG = "defconfig"
diff --git a/recipes-kernel/linux/files/0001-ayufan-dtsi-rk3328-add-mmc0-mmc1-aliases.patch b/recipes-kernel/linux/files/0001-ayufan-dtsi-rk3328-add-mmc0-mmc1-aliases.patch
new file mode 100644
index 0000000..1ad3b9e
--- /dev/null
+++ b/recipes-kernel/linux/files/0001-ayufan-dtsi-rk3328-add-mmc0-mmc1-aliases.patch
@@ -0,0 +1,27 @@
+From f10cfe01f753348d346374008b8e8f5f26ed94ab Mon Sep 17 00:00:00 2001
+From: Kamil Trzcinski <ayufan@...>
+Date: Mon, 28 Aug 2017 11:24:37 +0200
+Subject: [PATCH] ayufan: dtsi: rk3328: add mmc0/mmc1 aliases
+Upstream-Status: Pending [https://github.com/ayufan-rock64/linux-mainline-kernel/commit/f10cfe01f753348d346374008b8e8f5f26ed94ab]
+
+Change-Id: I82a5394df8a505f7d1496393621c1198895c88b0
+---
+ arch/arm64/boot/dts/rockchip/rk3328.dtsi | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+index 0afed15bc7ff..800f1c796882 100644
+--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
++++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+@@ -27,6 +27,8 @@
+ i2c1 = &i2c1;
+ i2c2 = &i2c2;
+ i2c3 = &i2c3;
++ mmc0 = &emmc;
++ mmc1 = &sdmmc;
+ ethernet0 = &gmac2io;
+ ethernet1 = &gmac2phy;
+ };
+--
+2.30.2
+
diff --git a/recipes-kernel/linux/linux-yocto%.bbappend b/recipes-kernel/linux/linux-yocto%.bbappend
index 7702e3f..3789c72 100644
--- a/recipes-kernel/linux/linux-yocto%.bbappend
+++ b/recipes-kernel/linux/linux-yocto%.bbappend
@@ -8,3 +8,9 @@ COMPATIBLE_MACHINE_tinker-board-s = "tinker-board-s"
COMPATIBLE_MACHINE_rock-pi-4 = "rock-pi-4"
COMPATIBLE_MACHINE_nanopi-m4 = "nanopi-m4"
COMPATIBLE_MACHINE_nanopi-m4-2gb = "nanopi-m4-2gb"
+COMPATIBLE_MACHINE_rock64 = "rock64"
+
+FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
+
+# indeed applicable to all rk3328 boards

I have a roc-rk3328-cc ("renegade") board I should investigate adding. Then I
can see if this applies there as well.

+SRC_URI_append_rock64 = " file://0001-ayufan-dtsi-rk3328-add-mmc0-mmc1-aliases.patch"
--
2.30.2