Date   

Re: [meta-rockchip][PATCH] trusted-firmware-a: replace baudrate with the one specified in machine conf

Quentin Schulz
 

Hi Trevor,

On Mon, Dec 13, 2021 at 05:37:32PM -0500, Trevor Woerner wrote:
On Fri 2021-12-10 @ 11:15:56 AM, Trevor Woerner via lists.yoctoproject.org wrote:
On Fri 2021-12-10 @ 03:50:19 PM, Quentin Schulz wrote:
Hi Trevor,

On Fri, Dec 10, 2021 at 09:43:39AM -0500, Trevor Woerner wrote:
On Thu 2021-11-11 @ 06:00:02 PM, Quentin Schulz wrote:
Not all Rockchip boards have their console running at 1500000 baud in
U-Boot and the kernel. Such is the case for puma-haikou RK3399-based
SoM+Carrierboard.

In order to prepare for the addition of puma-haikou to meta-rockchip,
let's replace the baudrate in TF-A by the one defined in the machine
conf file in the RK_CONSOLE_BAUD variable.

Cc: Quentin Schulz <foss@...>
Signed-off-by: Quentin Schulz <quentin.schulz@...>
---
.../files/serial-console-baudrate.patch | 36 -------------------
.../trusted-firmware-a_%.bbappend | 7 +++-
2 files changed, 6 insertions(+), 37 deletions(-)
delete mode 100644 recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch

diff --git a/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch b/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch
deleted file mode 100644
index 2d6e9bf..0000000
--- a/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch
+++ /dev/null
@@ -1,36 +0,0 @@
-From 840d6b6420e1fd8cdf6e4de7fa58a6f8de151622 Mon Sep 17 00:00:00 2001
-From: Yann Dirson <yann@...>
-Date: Tue, 6 Apr 2021 17:28:45 +0200
-Subject: [PATCH] Set serial console baudrate back to 1500000.
-Upstream-Status: Inappropriate[other]
-
-TF-A runs between two u-boot stages which both uses 1500000 baud, it
-just makes no sense to use the same UART at a different rate.
-
-This effectively reverts part of 0c05748bdebfad9fa43a80962186438bb8fbce62.
-Main reason for that change stated in https://urldefense.proofpoint.com/v2/url?u=https-3A__developer.trustedfirmware.org_T762&d=DwIBaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=TULURVxAXuoOr1qm-lWPJ4RyXC82jen1-RFqhySvz2ZLazQ8DA84GQ7T4MccEcQp&s=7WhFJXuPJAZq8RxczqF3HrMD5JqRZdJ8MyMU9iEnq44&e=
-is ChromeOS compatibility.
-
-Looks like this patch may become unnecessary in the future, when
-u-boot and TF-A get to communicate this value.
-
----
- plat/rockchip/rk3399/rk3399_def.h | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/plat/rockchip/rk3399/rk3399_def.h b/plat/rockchip/rk3399/rk3399_def.h
-index ba83242eb..8d6ecfbe6 100644
---- a/plat/rockchip/rk3399/rk3399_def.h
-+++ b/plat/rockchip/rk3399/rk3399_def.h
-@@ -17,7 +17,7 @@
- /**************************************************************************
- * UART related constants
- **************************************************************************/
--#define RK3399_BAUDRATE 115200
-+#define RK3399_BAUDRATE 1500000
- #define RK3399_UART_CLOCK 24000000
-
- /******************************************************************************
---
-2.30.2
-
diff --git a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
index f7777a7..0d06c44 100644
--- a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
+++ b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
@@ -7,9 +7,14 @@ COMPATIBLE_MACHINE:append:rk3328 = "|rk3328"

FILESEXTRAPATHS:prepend := "${THISDIR}/files:"
SRC_URI += "\
- file://serial-console-baudrate.patch \
file://0001-Fix-build-with-gcc-11.patch \
file://0001-dram-Fix-build-with-gcc-11.patch \
file://0001-plat_macros.S-Use-compatible-.asciz-asm-directive.patch \
file://0001-pmu-Do-not-mark-already-defined-functions-as-weak.patch \
"
+
+fixup_rk3399_baudrate() {
+ sed -i "s/#define RK3399_BAUDRATE 115200/#define RK3399_BAUDRATE ${RK_CONSOLE_BAUD}/" ${S}/plat/rockchip/rk3399/rk3399_def.h
+}
This looks fragile to me, any change in the number of spaces/tabs and this
line will stop working. Thankfully the symbol RK3399_BAUDRATE only appears
once in this file! That will allow us to do something like the following
instead:

sed '/RK3399_BAUDRATE.*/RK3399_BAUDRATE ${RK_CONSOLE_BAUD}/d'
Would
sed -i "s/#define RK3399_BAUDRATE\s\+.*/#define RK3399_BAUDRATE plep/" ${S}/plat/rockchip/rk3399/rk3399_def.h

work for you?
This makes sure that only RK3399_BAUDRATE definition will be changed, no
comment, no RK3399_BAUDRATE_OTHER_VAR or RK3399_BAUDRATE being used in
code/other constant in this file.
Sounds good.
Am I correct in thinking a v2 is coming (or did it get swallowed up by my mail
client)?

Otherwise, I can just fixup your v2 and apply it if you wish?
Yes, sorry just sent it :)

Cheers,
Quentin


[PATCH v2] trusted-firmware-a: replace baudrate with the one specified in machine conf

Quentin Schulz
 

Not all Rockchip boards have their console running at 1500000 baud in
U-Boot and the kernel. Such is the case for puma-haikou RK3399-based
SoM+Carrierboard.

In order to prepare for the addition of puma-haikou to meta-rockchip,
let's replace the baudrate in TF-A by the one defined in the machine
conf file in the RK_CONSOLE_BAUD variable.

Cc: Quentin Schulz <foss+yocto@...>
Signed-off-by: Quentin Schulz <quentin.schulz@...>
---

v2: use a less restrictive regular expression

.../files/serial-console-baudrate.patch | 36 -------------------
.../trusted-firmware-a_%.bbappend | 6 +++-
2 files changed, 5 insertions(+), 37 deletions(-)
delete mode 100644 recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch

diff --git a/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch b/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch
deleted file mode 100644
index 2d6e9bf..0000000
--- a/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch
+++ /dev/null
@@ -1,36 +0,0 @@
-From 840d6b6420e1fd8cdf6e4de7fa58a6f8de151622 Mon Sep 17 00:00:00 2001
-From: Yann Dirson <yann@...>
-Date: Tue, 6 Apr 2021 17:28:45 +0200
-Subject: [PATCH] Set serial console baudrate back to 1500000.
-Upstream-Status: Inappropriate[other]
-
-TF-A runs between two u-boot stages which both uses 1500000 baud, it
-just makes no sense to use the same UART at a different rate.
-
-This effectively reverts part of 0c05748bdebfad9fa43a80962186438bb8fbce62.
-Main reason for that change stated in https://developer.trustedfirmware.org/T762
-is ChromeOS compatibility.
-
-Looks like this patch may become unnecessary in the future, when
-u-boot and TF-A get to communicate this value.
-
----
- plat/rockchip/rk3399/rk3399_def.h | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/plat/rockchip/rk3399/rk3399_def.h b/plat/rockchip/rk3399/rk3399_def.h
-index ba83242eb..8d6ecfbe6 100644
---- a/plat/rockchip/rk3399/rk3399_def.h
-+++ b/plat/rockchip/rk3399/rk3399_def.h
-@@ -17,7 +17,7 @@
- /**************************************************************************
- * UART related constants
- **************************************************************************/
--#define RK3399_BAUDRATE 115200
-+#define RK3399_BAUDRATE 1500000
- #define RK3399_UART_CLOCK 24000000
-
- /******************************************************************************
---
-2.30.2
-
diff --git a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
index 513cea1..07fae1e 100644
--- a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
+++ b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
@@ -7,7 +7,6 @@ COMPATIBLE_MACHINE:append:rk3328 = "|rk3328"

FILESEXTRAPATHS:prepend := "${THISDIR}/files:"
SRC_URI += "\
- file://serial-console-baudrate.patch \
file://0001-dram-Fix-build-with-gcc-11.patch \
file://0001-plat_macros.S-Use-compatible-.asciz-asm-directive.patch \
file://0001-pmu-Do-not-mark-already-defined-functions-as-weak.patch \
@@ -19,3 +18,8 @@ SRC_URI += "\
# this needs fixing until then use gcc
TOOLCHAIN:rk3399 = "gcc"

+fixup_rk3399_baudrate() {
+ sed -i "s/#define RK3399_BAUDRATE\s\+.*/#define RK3399_BAUDRATE ${RK_CONSOLE_BAUD}/" ${S}/plat/rockchip/rk3399/rk3399_def.h
+}
+
+do_patch[postfuncs] += "fixup_rk3399_baudrate"
--
2.33.1


Re: [meta-rockchip][PATCH] kernel: linux-yocto: fix broken Ethernet MAC controller on RK3399 on 5.14 >= version <= 5.14.11

Quentin Schulz
 

Hi Trevor,

Gentle ping :)

Honister 3.4.1 being out it's less of an issue but the question remains
at least for settling on a policy :)

Cheers,
Quentin

On Tue, Nov 16, 2021 at 10:50:13AM -0800, Khem Raj wrote:
On Tue, Nov 16, 2021 at 10:03 AM Quentin Schulz <foss@...> wrote:



On November 16, 2021 6:45:05 PM GMT+01:00, Khem Raj <raj.khem@...> wrote:
On Tue, Nov 16, 2021 at 9:12 AM Quentin Schulz <
quentin.schulz@...> wrote:

On Tue, Nov 16, 2021 at 09:08:41AM -0800, Khem Raj wrote:
On Tue, Nov 16, 2021 at 9:04 AM Quentin Schulz
<quentin.schulz@...> wrote:

On Tue, Nov 16, 2021 at 09:00:42AM -0800, Khem Raj wrote:
On Tue, Nov 16, 2021 at 7:52 AM Quentin Schulz
<quentin.schulz@...> wrote:

From Linux kernel v5.14 to v5.14.11 (both included), the Ethernet
MAC
controller found on RK3399 is not working.

A fix is available in v5.14.12 and later (available also in v5.15)
which is provided here and applied to linux-yocto source tree if
linux-yocto version is of the impacted ones.

The conditional patching is unfortunately required because
Honister 3.4
has linux-yocto v5.14.9 and Honister 3.4.1 will have at least
linux-yocto v5.14.14.
Patching piece below looks quite a bit.
lets just fix v5.14.14 and dont worry about 3.4
v5.14.14 is already fixed. The only release currently is 3.4 and I hit
that issue, hence the patch.
I assume not everybody is updating to 3.4.1 when it's out, I've seen
people running behind dot releases.
What's bothering you?
once dot release is out then thats whats maintained not the original
release since they are incremental.
the anon python to apply a patch. Can you explain why we want to patch
applied this way ?
I could define a python function and use it like this:
SRC_URI:append:rk3399 = "${@rk3399_fix_mac(d)}"

Would that work better for you?

I am not yet convinced why should we have such version specific patch
If you could explain what's *really* bothering you, I could try to find a proper explanation or agree with you but it's a bit too vague to me right now. Anyway, I'll do some guesses in the next paragraphs.

Because Ethernet does not work for all RK3399-based boards in the latest and only release of Honister?
meta-rockchip does not have honister branch for now. So it expects
master to keep working with honister for now. kernel upgrades are
already committed into honister branch on meta-yocto-bsps so fix it
already available in latest honister
branch and will be in imminent point release soon as well.


meta-rockchip is the BSP layer for Rockchip based devices, if not there, where should I put this patch?

Or are we just going to say "Ethernet does not work, we know" to people asking instead of having this patch in? Obviously you could tell them to upgrade their oe-core/poky git repo to rolling honister or 3.4.1 once it's out but having this patch in avoid those questions.
I would say yes, document it as that of a known issue and possible fix
if someone is using exact point release. They might have snapshotted
meta-rockpi too and in that case it will be easy for them to carry a
local patch if needed.
vesion specific patching would also be setting a not so desired
patching practice, so I am trying to avoid it if we can.

I understand we're talking about policy here. I am not fond of this patch either but Ethernet is quite critical on boards which don't have WiFi for example. I don't have anything better to suggest to fix this in the *latest* release.
Update to latest honister branch or wait for 3.4.1, would be my suggestion.


Cheers
Quentin


Cheers,
Quentin


Re: [meta-rockchip][PATCH] trusted-firmware-a: replace baudrate with the one specified in machine conf

Quentin Schulz
 

Hi Trevor,

On Fri, Dec 10, 2021 at 09:43:39AM -0500, Trevor Woerner wrote:
On Thu 2021-11-11 @ 06:00:02 PM, Quentin Schulz wrote:
Not all Rockchip boards have their console running at 1500000 baud in
U-Boot and the kernel. Such is the case for puma-haikou RK3399-based
SoM+Carrierboard.

In order to prepare for the addition of puma-haikou to meta-rockchip,
let's replace the baudrate in TF-A by the one defined in the machine
conf file in the RK_CONSOLE_BAUD variable.

Cc: Quentin Schulz <foss@...>
Signed-off-by: Quentin Schulz <quentin.schulz@...>
---
.../files/serial-console-baudrate.patch | 36 -------------------
.../trusted-firmware-a_%.bbappend | 7 +++-
2 files changed, 6 insertions(+), 37 deletions(-)
delete mode 100644 recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch

diff --git a/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch b/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch
deleted file mode 100644
index 2d6e9bf..0000000
--- a/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch
+++ /dev/null
@@ -1,36 +0,0 @@
-From 840d6b6420e1fd8cdf6e4de7fa58a6f8de151622 Mon Sep 17 00:00:00 2001
-From: Yann Dirson <yann@...>
-Date: Tue, 6 Apr 2021 17:28:45 +0200
-Subject: [PATCH] Set serial console baudrate back to 1500000.
-Upstream-Status: Inappropriate[other]
-
-TF-A runs between two u-boot stages which both uses 1500000 baud, it
-just makes no sense to use the same UART at a different rate.
-
-This effectively reverts part of 0c05748bdebfad9fa43a80962186438bb8fbce62.
-Main reason for that change stated in https://urldefense.proofpoint.com/v2/url?u=https-3A__developer.trustedfirmware.org_T762&d=DwIBaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=TULURVxAXuoOr1qm-lWPJ4RyXC82jen1-RFqhySvz2ZLazQ8DA84GQ7T4MccEcQp&s=7WhFJXuPJAZq8RxczqF3HrMD5JqRZdJ8MyMU9iEnq44&e=
-is ChromeOS compatibility.
-
-Looks like this patch may become unnecessary in the future, when
-u-boot and TF-A get to communicate this value.
-
----
- plat/rockchip/rk3399/rk3399_def.h | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/plat/rockchip/rk3399/rk3399_def.h b/plat/rockchip/rk3399/rk3399_def.h
-index ba83242eb..8d6ecfbe6 100644
---- a/plat/rockchip/rk3399/rk3399_def.h
-+++ b/plat/rockchip/rk3399/rk3399_def.h
-@@ -17,7 +17,7 @@
- /**************************************************************************
- * UART related constants
- **************************************************************************/
--#define RK3399_BAUDRATE 115200
-+#define RK3399_BAUDRATE 1500000
- #define RK3399_UART_CLOCK 24000000
-
- /******************************************************************************
---
-2.30.2
-
diff --git a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
index f7777a7..0d06c44 100644
--- a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
+++ b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
@@ -7,9 +7,14 @@ COMPATIBLE_MACHINE:append:rk3328 = "|rk3328"

FILESEXTRAPATHS:prepend := "${THISDIR}/files:"
SRC_URI += "\
- file://serial-console-baudrate.patch \
file://0001-Fix-build-with-gcc-11.patch \
file://0001-dram-Fix-build-with-gcc-11.patch \
file://0001-plat_macros.S-Use-compatible-.asciz-asm-directive.patch \
file://0001-pmu-Do-not-mark-already-defined-functions-as-weak.patch \
"
+
+fixup_rk3399_baudrate() {
+ sed -i "s/#define RK3399_BAUDRATE 115200/#define RK3399_BAUDRATE ${RK_CONSOLE_BAUD}/" ${S}/plat/rockchip/rk3399/rk3399_def.h
+}
This looks fragile to me, any change in the number of spaces/tabs and this
line will stop working. Thankfully the symbol RK3399_BAUDRATE only appears
once in this file! That will allow us to do something like the following
instead:

sed '/RK3399_BAUDRATE.*/RK3399_BAUDRATE ${RK_CONSOLE_BAUD}/d'
Would
sed -i "s/#define RK3399_BAUDRATE\s\+.*/#define RK3399_BAUDRATE plep/" ${S}/plat/rockchip/rk3399/rk3399_def.h

work for you?
This makes sure that only RK3399_BAUDRATE definition will be changed, no
comment, no RK3399_BAUDRATE_OTHER_VAR or RK3399_BAUDRATE being used in
code/other constant in this file.

Cheers,
Quentin


#dunfell #qt5 #raspberrypi #sdk #linux #dunfell #qt5 #raspberrypi #sdk #linux

arthur.forey@...
 

 
 
 
 
Hello everybody,

I come today to try to solve my problem. I am building a bsp and sdk for a raspberry pi (MACHINE = raspberrypi4-64) in the form of a compute module. I'm trying to compile this app: https://github.com/YvesBas/Tadarida-D/tree/master/sources for the raspberry pi).

I know that in the Libs directory, the libraries are compiled for an x86_64 architecture. This is why I try to integrate them into the sources without this directory. I am also modifying the .pro to match with the correct libs. The integration of these two libs are present in the image of the raspberry pi, but in the sdk I only have the libsndfile1, so the libfftw3.h / .so is missing.

Here are elements for the creation of the bsp and the sdk:
Build Configuration:
BB_VERSION           = "1.46.0"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "universal"
TARGET_SYS           = "aarch64-poky-linux"
MACHINE              = "raspberrypi4-64"
DISTRO               = "poky"
DISTRO_VERSION       = "3.1.12"
TUNE_FEATURES        = "aarch64 cortexa72 crc crypto"
TARGET_FPU           = ""
meta                
meta-poky           
meta-yocto-bsp       = "dunfell:cf5a00721f721d5077c73d1f4e812e5c79833fba"
meta-oe             
meta-python         
meta-networking     
meta-multimedia      = "dunfell:69f94af4d91215e7d4e225bab54bf3bcfee42f1c"
meta-qt5             = "dunfell:b4d24d70aca75791902df5cd59a4f4a54aa4a125"
meta-raspberrypi     = "dunfell:934064a01903b2ba9a82be93b3f0efdb4543a0e8"

In conf/local.conf :
IMAGE_INSTALL_append = " libfftw libfftwl libfftwf fftw-dev libsndfile1"

When I do bitbake meta-toolchain-qt5, I don't have
libfftw3.h / .so .

What can i do ?

Thanks a lot.

Arthur


libsdl2 virtual/nativesdk-libgles2 issue

sateesh m
 

Hi Team,
 
               I am facing a problem libsdl2 while building the core-image-base. Can anybody know this please suggest me. 

NOTE: Resolving any missing task queue dependencies
ERROR: Nothing PROVIDES 'virtual/nativesdk-libgles2' (but virtual:nativesdk:/home/sateesh/sample-kde/openembedded-core/meta/recipes-graphics/libsdl2/libsdl2_2.0.12.bb DEPENDS on or otherwise requires it). Close matches:
  virtual/nativesdk-libgl
  virtual/nativesdk-libsdl
  virtual/nativesdk-libsdl2
NOTE: Runtime target 'nativesdk-qemu' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['nativesdk-qemu', 'nativesdk-libsdl2', 'virtual/nativesdk-libgles2']
NOTE: Runtime target 'nativesdk-packagegroup-sdk-host' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['nativesdk-packagegroup-sdk-host', 'nativesdk-qemu', 'nativesdk-libsdl2', 'virtual/nativesdk-libgles2']
ERROR: Required build target 'core-image-base' has no buildable providers.
Missing or unbuildable dependency chain was: ['core-image-base', 'nativesdk-packagegroup-sdk-host', 'nativesdk-qemu', 'nativesdk-libsdl2', 'virtual/nativesdk-libgles2']
 
--
Regards,
Sateesh


Re: Running unittests built by SDK

Khem Raj
 

On Mon, Dec 13, 2021 at 6:21 PM Rusty Howell <rustyhowell@...> wrote:

We are building our software with a Yocto SDK we created against our imx8m board. We would like to be able to execute unit tests (C++ tests written in Google Test) quickly without having to copy our unittest binaries over to an actual imx board to execute them. For sanity, we are also building our linux distro for MACHINE=qemux86-64 and beaglebone-yocto. So we have SDKs for imx8m, qemux86-64 and beaglebone-yocto.

Is there a MACHINE type that we could build that would be suitable for executing compiled C++ google test binaries directly on Ubuntu 18.04 or 20.04?
I think using qemux86-64 might be your best bet, its fairly automated
with runqemu script
all you would need to do is package up the gtests as ptest package with a runner

Thanks



Running unittests built by SDK

Rusty Howell
 

We are building our software with a Yocto SDK we created against our imx8m board. We would like to be able to execute unit tests (C++ tests written in Google Test) quickly without having to copy our unittest binaries over to an actual imx board to execute them. For sanity, we are also building our linux distro for MACHINE=qemux86-64 and beaglebone-yocto.  So we have SDKs for imx8m, qemux86-64 and beaglebone-yocto. 

Is there a MACHINE type that we could build that would be suitable for executing compiled C++ google test binaries directly on Ubuntu 18.04 or 20.04? 
Thanks


Re: [meta-rockchip][PATCH] trusted-firmware-a: replace baudrate with the one specified in machine conf

Trevor Woerner
 

On Fri 2021-12-10 @ 11:15:56 AM, Trevor Woerner via lists.yoctoproject.org wrote:
On Fri 2021-12-10 @ 03:50:19 PM, Quentin Schulz wrote:
Hi Trevor,

On Fri, Dec 10, 2021 at 09:43:39AM -0500, Trevor Woerner wrote:
On Thu 2021-11-11 @ 06:00:02 PM, Quentin Schulz wrote:
Not all Rockchip boards have their console running at 1500000 baud in
U-Boot and the kernel. Such is the case for puma-haikou RK3399-based
SoM+Carrierboard.

In order to prepare for the addition of puma-haikou to meta-rockchip,
let's replace the baudrate in TF-A by the one defined in the machine
conf file in the RK_CONSOLE_BAUD variable.

Cc: Quentin Schulz <foss@...>
Signed-off-by: Quentin Schulz <quentin.schulz@...>
---
.../files/serial-console-baudrate.patch | 36 -------------------
.../trusted-firmware-a_%.bbappend | 7 +++-
2 files changed, 6 insertions(+), 37 deletions(-)
delete mode 100644 recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch

diff --git a/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch b/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch
deleted file mode 100644
index 2d6e9bf..0000000
--- a/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch
+++ /dev/null
@@ -1,36 +0,0 @@
-From 840d6b6420e1fd8cdf6e4de7fa58a6f8de151622 Mon Sep 17 00:00:00 2001
-From: Yann Dirson <yann@...>
-Date: Tue, 6 Apr 2021 17:28:45 +0200
-Subject: [PATCH] Set serial console baudrate back to 1500000.
-Upstream-Status: Inappropriate[other]
-
-TF-A runs between two u-boot stages which both uses 1500000 baud, it
-just makes no sense to use the same UART at a different rate.
-
-This effectively reverts part of 0c05748bdebfad9fa43a80962186438bb8fbce62.
-Main reason for that change stated in https://urldefense.proofpoint.com/v2/url?u=https-3A__developer.trustedfirmware.org_T762&d=DwIBaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=TULURVxAXuoOr1qm-lWPJ4RyXC82jen1-RFqhySvz2ZLazQ8DA84GQ7T4MccEcQp&s=7WhFJXuPJAZq8RxczqF3HrMD5JqRZdJ8MyMU9iEnq44&e=
-is ChromeOS compatibility.
-
-Looks like this patch may become unnecessary in the future, when
-u-boot and TF-A get to communicate this value.
-
----
- plat/rockchip/rk3399/rk3399_def.h | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/plat/rockchip/rk3399/rk3399_def.h b/plat/rockchip/rk3399/rk3399_def.h
-index ba83242eb..8d6ecfbe6 100644
---- a/plat/rockchip/rk3399/rk3399_def.h
-+++ b/plat/rockchip/rk3399/rk3399_def.h
-@@ -17,7 +17,7 @@
- /**************************************************************************
- * UART related constants
- **************************************************************************/
--#define RK3399_BAUDRATE 115200
-+#define RK3399_BAUDRATE 1500000
- #define RK3399_UART_CLOCK 24000000
-
- /******************************************************************************
---
-2.30.2
-
diff --git a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
index f7777a7..0d06c44 100644
--- a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
+++ b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
@@ -7,9 +7,14 @@ COMPATIBLE_MACHINE:append:rk3328 = "|rk3328"

FILESEXTRAPATHS:prepend := "${THISDIR}/files:"
SRC_URI += "\
- file://serial-console-baudrate.patch \
file://0001-Fix-build-with-gcc-11.patch \
file://0001-dram-Fix-build-with-gcc-11.patch \
file://0001-plat_macros.S-Use-compatible-.asciz-asm-directive.patch \
file://0001-pmu-Do-not-mark-already-defined-functions-as-weak.patch \
"
+
+fixup_rk3399_baudrate() {
+ sed -i "s/#define RK3399_BAUDRATE 115200/#define RK3399_BAUDRATE ${RK_CONSOLE_BAUD}/" ${S}/plat/rockchip/rk3399/rk3399_def.h
+}
This looks fragile to me, any change in the number of spaces/tabs and this
line will stop working. Thankfully the symbol RK3399_BAUDRATE only appears
once in this file! That will allow us to do something like the following
instead:

sed '/RK3399_BAUDRATE.*/RK3399_BAUDRATE ${RK_CONSOLE_BAUD}/d'
Would
sed -i "s/#define RK3399_BAUDRATE\s\+.*/#define RK3399_BAUDRATE plep/" ${S}/plat/rockchip/rk3399/rk3399_def.h

work for you?
This makes sure that only RK3399_BAUDRATE definition will be changed, no
comment, no RK3399_BAUDRATE_OTHER_VAR or RK3399_BAUDRATE being used in
code/other constant in this file.
Sounds good.
Am I correct in thinking a v2 is coming (or did it get swallowed up by my mail
client)?

Otherwise, I can just fixup your v2 and apply it if you wish?



Re: [meta-rockchip][PATCH v2] override syntax fixup

Trevor Woerner
 

On Sat 2021-12-11 @ 08:55:43 AM, Trevor Woerner wrote:
The _virtual notation is not an override. These syntax "fixes" need to be
reverted.

In the case of the kernel override, when it was added, the rock-pi-e needed
the latest kernel (linux-yocto-dev) but now the default linux-yocto kernel
will suffice. So this mistake actually switched the rock-pi-e from
linux-yocto-dev back to linux-yocto inadvertently but at a time when
linux-yocto-dev was no longer required.

In the case of the bootloader overrides, u-boot was always the default, so
these overrides were always redundant.

Therefore, in the end, simply removing these overrides is the best way
forward (considering these aren't doing anything, and the builds are working
fine regardless).

Signed-off-by: Trevor Woerner <twoerner@...>
---
conf/machine/include/rk3288.inc | 1 -
conf/machine/include/rk3328.inc | 2 --
conf/machine/include/rk3399.inc | 2 --
conf/machine/include/rockchip-defaults.inc | 1 -
conf/machine/rock-pi-e.conf | 2 --
5 files changed, 8 deletions(-)
Applied to meta-rockchip, master.


Re: [meta-rockchip][PATCH] kernel: linux-yocto: fix broken Ethernet MAC controller on RK3399 on 5.14 >= version <= 5.14.11

Trevor Woerner
 

Hi Quentin/Khem,

On Mon 2021-12-13 @ 09:35:53 AM, Khem Raj wrote:
On Mon, Dec 13, 2021 at 9:18 AM Quentin Schulz <foss+yocto@...> wrote:

Hi Khem,

On December 13, 2021 4:04:03 PM GMT+01:00, Khem Raj <raj.khem@...> wrote:
On Mon, Dec 13, 2021 at 1:00 AM Quentin Schulz <
quentin.schulz@...> wrote:

Hi Trevor,

Gentle ping :)

Honister 3.4.1 being out it's less of an issue but the question remains
at least for settling on a policy :)
I apologize for not reviewing this patch in a timely manner; I'm sorry for the
frustration it caused.

Would this have been solved by (me) creating a honister branch? I usually
don't create a release branch until openembedded-core moves, but this looks
like it was a case where master and the latest branch diverged?

If so, would that still be useful?

Best regards,
Trevor


M+ & H bugs with Milestone Movements WW50

Stephen Jolley
 

All,

YP M+ or high bugs which moved to a new milestone in WW50 are listed below:

Priority

Bug ID

Short Description

Changer

Owner

Was

Became

Medium+

10693

Add a testcase for multilib eSDK on the autobuilder

randy.macleod@...

Qi.Chen@...

3.5

3.5 M2

 

13908

segfault in mb-wm on qemux86-64 intermittently

randy.macleod@...

ross@...

3.2 M3

3.5 M2

 

14486

qemu rootfs copy is taking too much time

randy.macleod@...

randy.macleod@...

3.4 M4

3.5 M2

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Enhancements/Bugs closed WW50!

Stephen Jolley
 

All,

The below were the owners of enhancements or bugs closed during the last week!

Who

Count

richard.purdie@...

4

jon.mason@...

1

randy.macleod@...

1

Grand Total

6

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Current high bug count owners for Yocto Project 3.5

Stephen Jolley
 

All,

Below is the list as of top 46 bug owners as of the end of WW50 of who have open medium or higher bugs and enhancements against YP 3.5.   There are 94 possible work days left until the final release candidates for YP 3.5 needs to be released.

Who

Count

ross@...

37

michael.opdenacker@...

34

randy.macleod@...

22

david.reyna@...

22

bruce.ashfield@...

16

trevor.gamblin@...

15

timothy.t.orling@...

15

sakib.sajal@...

11

JPEWhacker@...

11

richard.purdie@...

8

kai.kang@...

7

mhalstead@...

7

bluelightning@...

6

saul.wold@...

6

kiran.surendran@...

5

hongxu.jia@...

4

chee.yang.lee@...

4

Qi.Chen@...

3

pgowda.cve@...

3

jon.mason@...

3

mshah@...

2

alexandre.belloni@...

2

alejandro@...

2

yf3yu@...

1

shachar@...

1

angolini@...

1

Martin.Jansa@...

1

nicolas.dechesne@...

1

open.source@...

1

jay.shen.teoh@...

1

raj.khem@...

1

elberger@...

1

limon.anibal@...

1

john.kaldas.enpj@...

1

pokylinux@...

1

kexin.hao@...

1

steve@...

1

thomas.perrot@...

1

aehs29@...

1

mark.hatle@...

1

matthewzmd@...

1

TicoTimo@...

1

yi.zhao@...

1

akuster808@...

1

mingli.yu@...

1

mostthingsweb@...

1

Grand Total

268

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Yocto Project Newcomer & Unassigned Bugs - Help Needed

Stephen Jolley
 

All,

 

The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on the triage page under the appropriate heading:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs  Also please review: https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and how to create a bugzilla account at: https://bugzilla.yoctoproject.org/createaccount.cgi

The idea is these bugs should be straight forward for a person to help work on who doesn't have deep experience with the project.  If anyone can help, please take ownership of the bug and send patches!  If anyone needs help/advice there are people on irc who can likely do so, or some of the more experienced contributors will likely be happy to help too.

 

Also, the triage team meets weekly and does its best to handle the bugs reported into the Bugzilla. The number of people attending that meeting has fallen, as have the number of people available to help fix bugs. One of the things we hear users report is they don't know how to help. We (the triage team) are therefore going to start reporting out the currently 399 unassigned or newcomer bugs.

 

We're hoping people may be able to spare some time now and again to help out with these.  Bugs are split into two types, "true bugs" where things don't work as they should and "enhancements" which are features we'd want to add to the system.  There are also roughly four different "priority" classes right now, “3.4”, “3.5, "3.99" and "Future", the more pressing/urgent issues being in "3.4" and then “3.5”.

 

Please review this link and if a bug is something you would be able to help with either take ownership of the bug, or send me (sjolley.yp.pm@...) an e-mail with the bug number you would like and I will assign it to you (please make sure you have a Bugzilla account).  The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer_Bugs

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Re: [meta-rockchip][PATCH] kernel: linux-yocto: fix broken Ethernet MAC controller on RK3399 on 5.14 >= version <= 5.14.11

Khem Raj
 

On Mon, Dec 13, 2021 at 9:18 AM Quentin Schulz <foss+yocto@...> wrote:

Hi Khem,

On December 13, 2021 4:04:03 PM GMT+01:00, Khem Raj <raj.khem@...> wrote:
On Mon, Dec 13, 2021 at 1:00 AM Quentin Schulz <
quentin.schulz@...> wrote:

Hi Trevor,

Gentle ping :)

Honister 3.4.1 being out it's less of an issue but the question remains
at least for settling on a policy :)

Do we still need this patch ? I think now that dot release is out it’s less
of a problem. Version specific patching will set a different preset for the
layer to carry unexcercised patches
We need this patch for honister 3.4 but what I meant is that even though it's not needed for honister >= 3.4.1, I'm still interested in what the policy should be. Especially what we should have done between 3.4 and 3.4.1, before the latter was released.

I understand the precedent it creates but also, it's a bit sad for a "BSP" layer to have some support broken between Yocto releases.
I agree with you that broken is not good as it was for sometime, but
now with the latest supported release in 3.4 series ( which is 3.4.1)
things should be good.


Cheers,
Quentin



Cheers,
Quentin

On Tue, Nov 16, 2021 at 10:50:13AM -0800, Khem Raj wrote:
On Tue, Nov 16, 2021 at 10:03 AM Quentin Schulz <foss@...> wrote:



On November 16, 2021 6:45:05 PM GMT+01:00, Khem Raj <
raj.khem@...> wrote:
On Tue, Nov 16, 2021 at 9:12 AM Quentin Schulz <
quentin.schulz@...> wrote:

On Tue, Nov 16, 2021 at 09:08:41AM -0800, Khem Raj wrote:
On Tue, Nov 16, 2021 at 9:04 AM Quentin Schulz
<quentin.schulz@...> wrote:

On Tue, Nov 16, 2021 at 09:00:42AM -0800, Khem Raj wrote:
On Tue, Nov 16, 2021 at 7:52 AM Quentin Schulz
<quentin.schulz@...> wrote:

From Linux kernel v5.14 to v5.14.11 (both included), the
Ethernet
MAC
controller found on RK3399 is not working.

A fix is available in v5.14.12 and later (available also in
v5.15)
which is provided here and applied to linux-yocto source
tree if
linux-yocto version is of the impacted ones.

The conditional patching is unfortunately required because
Honister 3.4
has linux-yocto v5.14.9 and Honister 3.4.1 will have at
least
linux-yocto v5.14.14.
Patching piece below looks quite a bit.
lets just fix v5.14.14 and dont worry about 3.4
v5.14.14 is already fixed. The only release currently is 3.4
and I hit
that issue, hence the patch.
I assume not everybody is updating to 3.4.1 when it's out, I've
seen
people running behind dot releases.
What's bothering you?
once dot release is out then thats whats maintained not the
original
release since they are incremental.
the anon python to apply a patch. Can you explain why we want to
patch
applied this way ?
I could define a python function and use it like this:
SRC_URI:append:rk3399 = "${@rk3399_fix_mac(d)}"

Would that work better for you?

I am not yet convinced why should we have such version specific patch
If you could explain what's *really* bothering you, I could try to
find a proper explanation or agree with you but it's a bit too vague to me
right now. Anyway, I'll do some guesses in the next paragraphs.

Because Ethernet does not work for all RK3399-based boards in the
latest and only release of Honister?

meta-rockchip does not have honister branch for now. So it expects
master to keep working with honister for now. kernel upgrades are
already committed into honister branch on meta-yocto-bsps so fix it
already available in latest honister
branch and will be in imminent point release soon as well.


meta-rockchip is the BSP layer for Rockchip based devices, if not
there, where should I put this patch?

Or are we just going to say "Ethernet does not work, we know" to
people asking instead of having this patch in? Obviously you could tell
them to upgrade their oe-core/poky git repo to rolling honister or 3.4.1
once it's out but having this patch in avoid those questions.
I would say yes, document it as that of a known issue and possible fix
if someone is using exact point release. They might have snapshotted
meta-rockpi too and in that case it will be easy for them to carry a
local patch if needed.
vesion specific patching would also be setting a not so desired
patching practice, so I am trying to avoid it if we can.

I understand we're talking about policy here. I am not fond of this
patch either but Ethernet is quite critical on boards which don't have WiFi
for example. I don't have anything better to suggest to fix this in the
*latest* release.

Update to latest honister branch or wait for 3.4.1, would be my
suggestion.


Cheers
Quentin


Cheers,
Quentin


Re: help with ERROR: Nothing RPROVIDES <recipe> error

Quentin Schulz
 

Hi José,

On December 13, 2021 12:26:29 PM GMT+01:00, "Cardenas Jose Antonio (JCARDENA)" <joseantonio.cardenas@...> wrote:
Hi all.

I have added a recipe to BBMASK to skip the processing of this recipe for now, but when I try to compile the image i get ERROR: Nothing RPROVIDES <recipe> error. It's like I should say to yocto to reparse all recipes but I don't find the way to do it without remove the build directory and build again.
The issue is that you masked a recipe whose packages are required by other recipes packages. Find where the RDEPENDS is set for this recipe package and remove the package which depends on that recipe package from your image (usually, don't include it), or break the dependency chain there by removing the RDEPENDS.

Hope this helps,
Cheers,
Quentin

Regards.
José


Re: Is it possible to run a read-only fs without IMAGE_FEATURE = "read-only-rootfs"

Quentin Schulz
 

Hi Léon,

On December 13, 2021 3:40:05 PM GMT+01:00, "Beek, Léon van de" <l.v.d.beek@...> wrote:
Dear all,

Currently I have created an image which upon boot mounts my rootfs as readonly in an overlay with my data partition. I set out to change the FS type of my rootfs to something that is actuall read-only like squashfs, however I am getting a kernel panic whenever I boot saying:

"Not syncing: vfs: Unable to mount root fs on unknown-blick(179,2)"

The steps I took to convert to a read-only rootfs:

* Change -fstype in .wks file to squashfs
* Changed IMAGE_FSTYPE= "squashfs wic.bz2", in local.conf, however I do not believe this is necessary actually
Did you check that your kernel actually supports squashfs as rootfs? There is a Kconfig option for it IIRC.

Are there steps I am missing? I believe that IMAGE_FEATURE = "read-only-rootfs" should not be necessary as I am mounting the rootfs in an overlay before starting /sbin/init , but I might be wrong.
Since it's an image feature, it's not going to impact anything outside of the image recipe but I don't know exactly what this is doing from memory.

Cheers,
Quentin

Kind regards,

Léon van de Beek


Re: [meta-rockchip][PATCH] kernel: linux-yocto: fix broken Ethernet MAC controller on RK3399 on 5.14 >= version <= 5.14.11

Quentin Schulz
 

Hi Khem,

On December 13, 2021 4:04:03 PM GMT+01:00, Khem Raj <raj.khem@...> wrote:
On Mon, Dec 13, 2021 at 1:00 AM Quentin Schulz <
quentin.schulz@...> wrote:

Hi Trevor,

Gentle ping :)

Honister 3.4.1 being out it's less of an issue but the question remains
at least for settling on a policy :)

Do we still need this patch ? I think now that dot release is out it’s less
of a problem. Version specific patching will set a different preset for the
layer to carry unexcercised patches
We need this patch for honister 3.4 but what I meant is that even though it's not needed for honister >= 3.4.1, I'm still interested in what the policy should be. Especially what we should have done between 3.4 and 3.4.1, before the latter was released.

I understand the precedent it creates but also, it's a bit sad for a "BSP" layer to have some support broken between Yocto releases.

Cheers,
Quentin



Cheers,
Quentin

On Tue, Nov 16, 2021 at 10:50:13AM -0800, Khem Raj wrote:
On Tue, Nov 16, 2021 at 10:03 AM Quentin Schulz <foss@...> wrote:



On November 16, 2021 6:45:05 PM GMT+01:00, Khem Raj <
raj.khem@...> wrote:
On Tue, Nov 16, 2021 at 9:12 AM Quentin Schulz <
quentin.schulz@...> wrote:

On Tue, Nov 16, 2021 at 09:08:41AM -0800, Khem Raj wrote:
On Tue, Nov 16, 2021 at 9:04 AM Quentin Schulz
<quentin.schulz@...> wrote:

On Tue, Nov 16, 2021 at 09:00:42AM -0800, Khem Raj wrote:
On Tue, Nov 16, 2021 at 7:52 AM Quentin Schulz
<quentin.schulz@...> wrote:

From Linux kernel v5.14 to v5.14.11 (both included), the
Ethernet
MAC
controller found on RK3399 is not working.

A fix is available in v5.14.12 and later (available also in
v5.15)
which is provided here and applied to linux-yocto source
tree if
linux-yocto version is of the impacted ones.

The conditional patching is unfortunately required because
Honister 3.4
has linux-yocto v5.14.9 and Honister 3.4.1 will have at
least
linux-yocto v5.14.14.
Patching piece below looks quite a bit.
lets just fix v5.14.14 and dont worry about 3.4
v5.14.14 is already fixed. The only release currently is 3.4
and I hit
that issue, hence the patch.
I assume not everybody is updating to 3.4.1 when it's out, I've
seen
people running behind dot releases.
What's bothering you?
once dot release is out then thats whats maintained not the
original
release since they are incremental.
the anon python to apply a patch. Can you explain why we want to
patch
applied this way ?
I could define a python function and use it like this:
SRC_URI:append:rk3399 = "${@rk3399_fix_mac(d)}"

Would that work better for you?

I am not yet convinced why should we have such version specific patch
If you could explain what's *really* bothering you, I could try to
find a proper explanation or agree with you but it's a bit too vague to me
right now. Anyway, I'll do some guesses in the next paragraphs.

Because Ethernet does not work for all RK3399-based boards in the
latest and only release of Honister?

meta-rockchip does not have honister branch for now. So it expects
master to keep working with honister for now. kernel upgrades are
already committed into honister branch on meta-yocto-bsps so fix it
already available in latest honister
branch and will be in imminent point release soon as well.


meta-rockchip is the BSP layer for Rockchip based devices, if not
there, where should I put this patch?

Or are we just going to say "Ethernet does not work, we know" to
people asking instead of having this patch in? Obviously you could tell
them to upgrade their oe-core/poky git repo to rolling honister or 3.4.1
once it's out but having this patch in avoid those questions.
I would say yes, document it as that of a known issue and possible fix
if someone is using exact point release. They might have snapshotted
meta-rockpi too and in that case it will be easy for them to carry a
local patch if needed.
vesion specific patching would also be setting a not so desired
patching practice, so I am trying to avoid it if we can.

I understand we're talking about policy here. I am not fond of this
patch either but Ethernet is quite critical on boards which don't have WiFi
for example. I don't have anything better to suggest to fix this in the
*latest* release.

Update to latest honister branch or wait for 3.4.1, would be my
suggestion.


Cheers
Quentin


Cheers,
Quentin


Re: [meta-rockchip][PATCH] kernel: linux-yocto: fix broken Ethernet MAC controller on RK3399 on 5.14 >= version <= 5.14.11

Khem Raj
 



On Mon, Dec 13, 2021 at 1:00 AM Quentin Schulz <quentin.schulz@...> wrote:
Hi Trevor,

Gentle ping :)

Honister 3.4.1 being out it's less of an issue but the question remains
at least for settling on a policy :)

Do we still need this patch ? I think now that dot release is out it’s less of a problem. Version specific patching will set a different preset for the layer to carry unexcercised patches



Cheers,
Quentin

On Tue, Nov 16, 2021 at 10:50:13AM -0800, Khem Raj wrote:
> On Tue, Nov 16, 2021 at 10:03 AM Quentin Schulz <foss@...> wrote:
> >
> >
> >
> > On November 16, 2021 6:45:05 PM GMT+01:00, Khem Raj <raj.khem@...> wrote:
> > >On Tue, Nov 16, 2021 at 9:12 AM Quentin Schulz <
> > >quentin.schulz@...> wrote:
> > >
> > >> On Tue, Nov 16, 2021 at 09:08:41AM -0800, Khem Raj wrote:
> > >> > On Tue, Nov 16, 2021 at 9:04 AM Quentin Schulz
> > >> > <quentin.schulz@...> wrote:
> > >> > >
> > >> > > On Tue, Nov 16, 2021 at 09:00:42AM -0800, Khem Raj wrote:
> > >> > > > On Tue, Nov 16, 2021 at 7:52 AM Quentin Schulz
> > >> > > > <quentin.schulz@...> wrote:
> > >> > > > >
> > >> > > > > From Linux kernel v5.14 to v5.14.11 (both included), the Ethernet
> > >> MAC
> > >> > > > > controller found on RK3399 is not working.
> > >> > > > >
> > >> > > > > A fix is available in v5.14.12 and later (available also in v5.15)
> > >> > > > > which is provided here and applied to linux-yocto source tree if
> > >> > > > > linux-yocto version is of the impacted ones.
> > >> > > > >
> > >> > > > > The conditional patching is unfortunately required because
> > >> Honister 3.4
> > >> > > > > has linux-yocto v5.14.9 and Honister 3.4.1 will have at least
> > >> > > > > linux-yocto v5.14.14.
> > >> > > >
> > >> > > > Patching piece below looks quite a bit.
> > >> > > > lets just fix v5.14.14 and dont worry about 3.4
> > >> > > >
> > >> > >
> > >> > > v5.14.14 is already fixed. The only release currently is 3.4 and I hit
> > >> > > that issue, hence the patch.
> > >> > > I assume not everybody is updating to 3.4.1 when it's out, I've seen
> > >> > > people running behind dot releases.
> > >> > > What's bothering you?
> > >> >
> > >> > once dot release is out then thats whats maintained not the original
> > >> > release since they are incremental.
> > >> > the anon python to apply a patch. Can you explain why we want to patch
> > >> > applied this way ?
> > >> >
> > >>
> > >> I could define a python function and use it like this:
> > >> SRC_URI:append:rk3399 = "${@rk3399_fix_mac(d)}"
> > >>
> > >> Would that work better for you?
> > >
> > >
> > >I am not yet convinced why should we have such version specific patch
> > >
> >
> > If you could explain what's *really* bothering you, I could try to find a proper explanation or agree with you but it's a bit too vague to me right now. Anyway, I'll do some guesses in the next paragraphs.
> >
> > Because Ethernet does not work for all RK3399-based boards in the latest and only release of Honister?
>
> meta-rockchip does not have honister branch for now. So it expects
> master to keep working with honister for now. kernel upgrades are
> already committed into honister branch on meta-yocto-bsps so fix it
> already available in latest honister
> branch and will be in imminent point release soon as well.
>
> >
> > meta-rockchip is the BSP layer for Rockchip based devices, if not there, where should I put this patch?
> >
> > Or are we just going to say "Ethernet does not work, we know" to people asking instead of having this patch in? Obviously you could tell them to upgrade their oe-core/poky git repo to rolling honister or 3.4.1 once it's out but having this patch in avoid those questions.
> >
>
> I would say yes, document it as that of a known issue and possible fix
> if someone is using exact point release. They might have snapshotted
> meta-rockpi too and in that case it will be easy for them to carry a
> local patch if needed.
> vesion specific patching would also be setting a not so desired
> patching practice, so I am trying to avoid it if we can.
>
> > I understand we're talking about policy here. I am not fond of this patch either but Ethernet is quite critical on boards which don't have WiFi for example. I don't have anything better to suggest to fix this in the *latest* release.
>
> Update to latest honister branch or wait for 3.4.1, would be my suggestion.
>
> >
> > Cheers
> > Quentin
> > >>
> > >>
> > >> Cheers,
> > >> Quentin
> > >>

2241 - 2260 of 57774