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

On Mon, Jun 14, 2021 at 07:58:19AM -0400, Robert P. J. Day wrote:

starting to think about a new laptop that will, among other things,
do lots of OE/YP builds, and i'll start with this as the basis for a
few questions about hard drives:

https://www.dell.com/en-ca/shop/gaming-laptops/g15-ryzen-edition-gaming-laptop/spd/g-series-15-5515-laptop/ng155515_sb_ps25e

while an SSD would be delightful, i'm concerned about how doing
frequent 40-50G builds would wear out an SSD. so i was considering
looking for something with a fast regular HD for the actual build
directories, but room to put in an M.2 NVMe that would hold fairly
static content, like the OS itself, all the layers, a local source
mirror and so on.

am i overthinking this? anyone have a laptop setup that is smokin'
fast (yeah, 8 core AMD ryzen :-),

When using a laptop with only 16 GB RAM to build with 8 or 16 threads,
on what drive will the heavily used large swap partition be?

gcc loves to use > 2 GB RAM for non-trivial C++ code,
with 16 threads I'd recommend 64 GB RAM.

and a dual drive layout that seems
to work well with lots and lots of OE builds?

Ask for the specs of the SSD and do the math.

E.g. 150 TBW / 50 GB/build = 3000 builds

If you are building from scratch so often that the resulting number
is a worry, I'd rather buy 128 GB RAM and use a tmpfs instead of
creating a spinning rust bottleneck.

rday

cu
Adrian

- Ryzen based for core count
- No dedicated GPU as more wattage available for CPU + less heat for cpu
boosting
- Dual NVMe slots, or at least on-board emmc + NVMe slot, hold tmp in
NVMe, replace if it dies. Probably not going to be an issue, I have a
1TB NVMe drive which I've been doing multiple daily builds on for 2
years which is still at 99% health.

For a decent manufacturer? Dell aren't recommended at the moment as the
QA due to pandemic conditions is lacking and machines are arriving
broken. HP do some decent Ryzen based laptops, as do Lenovo. For a wild
card you can also check out System76 but they're just OEM rebrands.

Good luck, it's a minefield out there.

Regards,
Jack

--
Jack Mitchell, Consultant
https://www.tuxable.co.uk

starting to think about a new laptop that will, among other things,
do lots of OE/YP builds, and i'll start with this as the basis for a
few questions about hard drives:

https://www.dell.com/en-ca/shop/gaming-laptops/g15-ryzen-edition-gaming-laptop/spd/g-series-15-5515-laptop/ng155515_sb_ps25e

while an SSD would be delightful, i'm concerned about how doing
frequent 40-50G builds would wear out an SSD. so i was considering
looking for something with a fast regular HD for the actual build
directories, but room to put in an M.2 NVMe that would hold fairly
static content, like the OS itself, all the layers, a local source
mirror and so on.

am i overthinking this? anyone have a laptop setup that is smokin'
fast (yeah, 8 core AMD ryzen :-), and a dual drive layout that seems
to work well with lots and lots of OE builds?

rday

Yes, look at the PACKAGECONFIGs and setting QEMU_TARGETS.

Does it mean that with the local.conf line:

# enable,disable,depends,rdepends
#
PACKAGECONFIG[qemu] = "--with-qemu,--without-qemu,qemu,"

The QEMU is completely removed (this is all that needs to be done, or...)?

Thank you,
Zee
_______

On Mon, Jun 14, 2021 at 12:14 PM Ross Burton <ross@...> wrote:

Yes, look at the PACKAGECONFIGs and setting QEMU_TARGETS.

Ross

On Mon, 14 Jun 2021 at 09:04, Aashik Aswin <thisisaash9698@...> wrote:

Thanks for the clarification, yes I am installing QEMU in my image. Is there some way that we can disable the additional architectures and streamline the size ?

Thanks

On Fri, Jun 11, 2021 at 8:48 PM Ross Burton <ross@...> wrote:

Are you installing qemu into your image though?

Qemu did get larger as it is built with more architectures enabled,
but unless you're installing it in your image it won't make a
difference.

Ross

On Fri, 11 Jun 2021 at 11:40, Aashik Aswin <thisisaash9698@...> wrote:

Hi Experts,

I am upgrading my Linux from Yocto Thud to Zeus (5.4 Kernel) . After building I could see a significant increase in the size of the image.
On checking with buildhistory enabled, I could see that qemu has nearly doubled in size.

Thud (4.19) - 223084 KiB qemu
Zeus (5.4) - 474757 KiB qemu

Is this size increase expected or are there some additional configs that might have been added as a part of the upgrade ?

Appreciate your help.

TIA,
Aashik

Yes, look at the PACKAGECONFIGs and setting QEMU_TARGETS.

Ross

Hello,

you can use wildebeest's mirror:

ICEDTEA_HG_URL = "http://icedtea.wildebeest.org/hg/release/${ICEDTEA_PREFIX}"

Marvin