* [meta-rockchip PATCH v2 1/2] bsp: rkbin: rkbin-ddr: use version and file variables for path matching
2024-11-28 15:58 [meta-rockchip PATCH v2 0/2] bsp: rkbin: bump to latest commit in master Quentin Schulz
@ 2024-11-28 15:58 ` Quentin Schulz
2024-12-16 3:53 ` [yocto-patches] " Trevor Woerner
2024-11-28 15:58 ` [meta-rockchip PATCH v2 2/2] bsp: rkbin: bump to latest commit in master branch Quentin Schulz
` (2 subsequent siblings)
3 siblings, 1 reply; 12+ messages in thread
From: Quentin Schulz @ 2024-11-28 15:58 UTC (permalink / raw)
To: yocto-patches; +Cc: Quentin Schulz
From: Quentin Schulz <quentin.schulz@cherry.de>
By using variables to give the path where to find the file to install,
it is easier for users to have a different SRCREV for their own machine.
Additionally, because glob patterns are now not used by default, it is
guaranteed only to match a single file.
The glob pattern for rk3308 has been hardcoded with the only file that
matches in the rkbin git repository at the currently used commit.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
---
README | 15 +++++++++++++++
recipes-bsp/rkbin/rockchip-rkbin-ddr_git.bb | 20 ++++++++++++++++----
2 files changed, 31 insertions(+), 4 deletions(-)
diff --git a/README b/README
index 85ab2ec560ff27c0197965f6a6cd26d404723694..6bceba0c9cf09cc0fc881c855fabeeb68aeb55fb 100644
--- a/README
+++ b/README
@@ -55,6 +55,21 @@ Status of supported boards:
Notes:
-----
+ Custom DDR rkbin version:
+ If you wish to use a different version of DDR binary provided by
+ rockchip-rkbin-ddr recipe than the one in this layer, you can create a
+ .bbappend in your own layer, and accordingly set SRCREV (possibly
+ LIC_FILES_CHKSUM too) and the version for path matching stored in
+ DDRBIN_VERS variable. Do so in your .bbappend with:
+
+ DDRBIN_VERS:my-machine = "v2.07"
+
+ If somehow the filename differs from the one provided in this layer, you
+ can override it from your bbappend with the DDRBIN_FILE variable:
+
+ DDRBIN_VERS:my-machine = "v2.07"
+ DDRBIN_FILE:my-machine = "rk3308_ddr_451MHz_uart4_m0_${DDRBIN_VERS}.bin"
+
rk3308 rkbin:
The latest ddr initializer for the rk3308 platform does not output
diagnostic messages to uart0. This causes a bunch of gibberish to
diff --git a/recipes-bsp/rkbin/rockchip-rkbin-ddr_git.bb b/recipes-bsp/rkbin/rockchip-rkbin-ddr_git.bb
index 0ff71320de8cfeee259a820a07375f490d1086d6..a5cba9a61f3226def00bd8ab0a777d79ac5de3a1 100644
--- a/recipes-bsp/rkbin/rockchip-rkbin-ddr_git.bb
+++ b/recipes-bsp/rkbin/rockchip-rkbin-ddr_git.bb
@@ -2,22 +2,34 @@ DESCRIPTION = "Rockchip Firmware for DDR init (TPL in U-Boot terms)"
require rockchip-rkbin.inc
+DDRBIN_VERS:rk3308 ?= "v2.07"
+DDRBIN_FILE:rk3308 ?= "rk3308_ddr_589MHz_uart4_m0_${DDRBIN_VERS}.bin"
+
do_deploy:rk3308() {
# Prebuilt U-Boot TPL (DDR init)
- install -m 644 ${S}/bin/rk33/rk3308_ddr_589MHz_uart?_m0_v*.bin ${DEPLOYDIR}/ddr-rk3308.bin
+ install -m 644 ${S}/bin/rk33/${DDRBIN_FILE} ${DEPLOYDIR}/ddr-rk3308.bin
}
+DDRBIN_VERS:rk3566 ?= "v1.21"
+DDRBIN_FILE:rk3566 ?= "rk3566_ddr_1056MHz_${DDRBIN_VERS}.bin"
+
do_deploy:rk3566() {
# Prebuilt U-Boot TPL (DDR init)
- install -m 644 ${S}/bin/rk35/rk3566_ddr_1056MHz_v1.21.bin ${DEPLOYDIR}/ddr-rk3566.bin
+ install -m 644 ${S}/bin/rk35/${DDRBIN_FILE} ${DEPLOYDIR}/ddr-rk3566.bin
}
+DDRBIN_VERS:rk3568 ?= "v1.21"
+DDRBIN_FILE:rk3568 ?= "rk3568_ddr_1560MHz_${DDRBIN_VERS}.bin"
+
do_deploy:rk3568() {
# Prebuilt U-Boot TPL (DDR init)
- install -m 644 ${S}/bin/rk35/rk3568_ddr_1560MHz_v1.21.bin ${DEPLOYDIR}/ddr-rk3568.bin
+ install -m 644 ${S}/bin/rk35/${DDRBIN_FILE} ${DEPLOYDIR}/ddr-rk3568.bin
}
+DDRBIN_VERS:rk3588s ?= "v1.16"
+DDRBIN_FILE:rk3588s ?= "rk3588_ddr_lp4_2112MHz_lp5_2400MHz_${DDRBIN_VERS}.bin"
+
do_deploy:rk3588s() {
# Prebuilt U-Boot TPL (DDR init)
- install -m 644 ${S}/bin/rk35/rk3588_ddr_lp4_2112MHz_lp5_2400MHz_v1.16.bin ${DEPLOYDIR}/ddr-rk3588.bin
+ install -m 644 ${S}/bin/rk35/${DDRBIN_FILE} ${DEPLOYDIR}/ddr-rk3588.bin
}
--
2.47.0
^ permalink raw reply related [flat|nested] 12+ messages in thread* Re: [yocto-patches] [meta-rockchip PATCH v2 1/2] bsp: rkbin: rkbin-ddr: use version and file variables for path matching
2024-11-28 15:58 ` [meta-rockchip PATCH v2 1/2] bsp: rkbin: rkbin-ddr: use version and file variables for path matching Quentin Schulz
@ 2024-12-16 3:53 ` Trevor Woerner
0 siblings, 0 replies; 12+ messages in thread
From: Trevor Woerner @ 2024-12-16 3:53 UTC (permalink / raw)
To: yocto-patches; +Cc: Quentin Schulz
On Thu 2024-11-28 @ 04:58:49 PM, Quentin Schulz via lists.yoctoproject.org wrote:
> From: Quentin Schulz <quentin.schulz@cherry.de>
>
> By using variables to give the path where to find the file to install,
> it is easier for users to have a different SRCREV for their own machine.
>
> Additionally, because glob patterns are now not used by default, it is
> guaranteed only to match a single file.
>
> The glob pattern for rk3308 has been hardcoded with the only file that
> matches in the rkbin git repository at the currently used commit.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
> ---
> README | 15 +++++++++++++++
> recipes-bsp/rkbin/rockchip-rkbin-ddr_git.bb | 20 ++++++++++++++++----
> 2 files changed, 31 insertions(+), 4 deletions(-)
Applied to meta-rockchip, master and styhead branches. Thanks!
^ permalink raw reply [flat|nested] 12+ messages in thread
* [meta-rockchip PATCH v2 2/2] bsp: rkbin: bump to latest commit in master branch
2024-11-28 15:58 [meta-rockchip PATCH v2 0/2] bsp: rkbin: bump to latest commit in master Quentin Schulz
2024-11-28 15:58 ` [meta-rockchip PATCH v2 1/2] bsp: rkbin: rkbin-ddr: use version and file variables for path matching Quentin Schulz
@ 2024-11-28 15:58 ` Quentin Schulz
2024-12-16 3:54 ` [yocto-patches] " Trevor Woerner
2024-12-05 17:09 ` [yocto-patches] [meta-rockchip PATCH v2 0/2] bsp: rkbin: bump to latest commit in master Trevor Woerner
2024-12-12 20:11 ` Trevor Woerner
3 siblings, 1 reply; 12+ messages in thread
From: Quentin Schulz @ 2024-11-28 15:58 UTC (permalink / raw)
To: yocto-patches; +Cc: Quentin Schulz
From: Quentin Schulz <quentin.schulz@cherry.de>
This seems to be fixing random RCU stalls, system hangs or resets while
running upstream Linux kernel on RK3588 boards.
License-Update: Fixing typos c.f. 385bf9f1700c ("license: typo fix")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
---
recipes-bsp/rkbin/rockchip-rkbin-ddr_git.bb | 8 ++++----
recipes-bsp/rkbin/rockchip-rkbin.inc | 4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/recipes-bsp/rkbin/rockchip-rkbin-ddr_git.bb b/recipes-bsp/rkbin/rockchip-rkbin-ddr_git.bb
index a5cba9a61f3226def00bd8ab0a777d79ac5de3a1..3227a53db22ba5906355e6925399aafe08813c9f 100644
--- a/recipes-bsp/rkbin/rockchip-rkbin-ddr_git.bb
+++ b/recipes-bsp/rkbin/rockchip-rkbin-ddr_git.bb
@@ -2,7 +2,7 @@ DESCRIPTION = "Rockchip Firmware for DDR init (TPL in U-Boot terms)"
require rockchip-rkbin.inc
-DDRBIN_VERS:rk3308 ?= "v2.07"
+DDRBIN_VERS:rk3308 ?= "v2.10"
DDRBIN_FILE:rk3308 ?= "rk3308_ddr_589MHz_uart4_m0_${DDRBIN_VERS}.bin"
do_deploy:rk3308() {
@@ -10,7 +10,7 @@ do_deploy:rk3308() {
install -m 644 ${S}/bin/rk33/${DDRBIN_FILE} ${DEPLOYDIR}/ddr-rk3308.bin
}
-DDRBIN_VERS:rk3566 ?= "v1.21"
+DDRBIN_VERS:rk3566 ?= "v1.23"
DDRBIN_FILE:rk3566 ?= "rk3566_ddr_1056MHz_${DDRBIN_VERS}.bin"
do_deploy:rk3566() {
@@ -18,7 +18,7 @@ do_deploy:rk3566() {
install -m 644 ${S}/bin/rk35/${DDRBIN_FILE} ${DEPLOYDIR}/ddr-rk3566.bin
}
-DDRBIN_VERS:rk3568 ?= "v1.21"
+DDRBIN_VERS:rk3568 ?= "v1.23"
DDRBIN_FILE:rk3568 ?= "rk3568_ddr_1560MHz_${DDRBIN_VERS}.bin"
do_deploy:rk3568() {
@@ -26,7 +26,7 @@ do_deploy:rk3568() {
install -m 644 ${S}/bin/rk35/${DDRBIN_FILE} ${DEPLOYDIR}/ddr-rk3568.bin
}
-DDRBIN_VERS:rk3588s ?= "v1.16"
+DDRBIN_VERS:rk3588s ?= "v1.18"
DDRBIN_FILE:rk3588s ?= "rk3588_ddr_lp4_2112MHz_lp5_2400MHz_${DDRBIN_VERS}.bin"
do_deploy:rk3588s() {
diff --git a/recipes-bsp/rkbin/rockchip-rkbin.inc b/recipes-bsp/rkbin/rockchip-rkbin.inc
index d70a5551c8171188af93dddf4b3b1dc960f27a83..9264db9048e31b7dae650bdc8e31009f7f4cf404 100644
--- a/recipes-bsp/rkbin/rockchip-rkbin.inc
+++ b/recipes-bsp/rkbin/rockchip-rkbin.inc
@@ -1,7 +1,7 @@
SRC_URI = "git://github.com/rockchip-linux/rkbin;protocol=https;branch=master"
-SRCREV = "a2a0b89b6c8c612dca5ed9ed8a68db8a07f68bc0"
+SRCREV = "7c35e21a8529b3758d1f051d1a5dc62aae934b2b"
LICENSE = "Proprietary"
-LIC_FILES_CHKSUM = "file://LICENSE;md5=15faa4a01e7eb0f5d33f9f2bcc7bff62"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=11e3673115959bf596feaaa6ea7ce9a5"
inherit bin_package deploy
--
2.47.0
^ permalink raw reply related [flat|nested] 12+ messages in thread* Re: [yocto-patches] [meta-rockchip PATCH v2 2/2] bsp: rkbin: bump to latest commit in master branch
2024-11-28 15:58 ` [meta-rockchip PATCH v2 2/2] bsp: rkbin: bump to latest commit in master branch Quentin Schulz
@ 2024-12-16 3:54 ` Trevor Woerner
0 siblings, 0 replies; 12+ messages in thread
From: Trevor Woerner @ 2024-12-16 3:54 UTC (permalink / raw)
To: yocto-patches; +Cc: Quentin Schulz
On Thu 2024-11-28 @ 04:58:50 PM, Quentin Schulz via lists.yoctoproject.org wrote:
> From: Quentin Schulz <quentin.schulz@cherry.de>
>
> This seems to be fixing random RCU stalls, system hangs or resets while
> running upstream Linux kernel on RK3588 boards.
>
> License-Update: Fixing typos c.f. 385bf9f1700c ("license: typo fix")
>
> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
> ---
> recipes-bsp/rkbin/rockchip-rkbin-ddr_git.bb | 8 ++++----
> recipes-bsp/rkbin/rockchip-rkbin.inc | 4 ++--
> 2 files changed, 6 insertions(+), 6 deletions(-)
Applied to meta-rockchip, master and styhead branches. Thanks!
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [yocto-patches] [meta-rockchip PATCH v2 0/2] bsp: rkbin: bump to latest commit in master
2024-11-28 15:58 [meta-rockchip PATCH v2 0/2] bsp: rkbin: bump to latest commit in master Quentin Schulz
2024-11-28 15:58 ` [meta-rockchip PATCH v2 1/2] bsp: rkbin: rkbin-ddr: use version and file variables for path matching Quentin Schulz
2024-11-28 15:58 ` [meta-rockchip PATCH v2 2/2] bsp: rkbin: bump to latest commit in master branch Quentin Schulz
@ 2024-12-05 17:09 ` Trevor Woerner
2024-12-05 17:21 ` Quentin Schulz
2024-12-12 20:11 ` Trevor Woerner
3 siblings, 1 reply; 12+ messages in thread
From: Trevor Woerner @ 2024-12-05 17:09 UTC (permalink / raw)
To: yocto-patches; +Cc: Quentin Schulz
On Thu 2024-11-28 @ 04:58:48 PM, Quentin Schulz via lists.yoctoproject.org wrote:
> We've been hit by random RCU stalls, system hangs or resets on some (not
> all) of our RK3588-based products running some old BL31/DDR init
> binaries.
>
> Upgrading to latest commit in master branch seems to mitigate those
> issues, so let's do that.
>
> Only build tested.
If I wanted to test on boards without having to yank the SDcard and re-image,
I would only need to update the idbloader.img in /dev/disk/by-partlabel/ ?
> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
> ---
> Changes in v2:
> - use version and filename variables instead of using glob pattern for
> path matching the DDR init binaries,
> - Link to v1: https://lore.kernel.org/r/20241127-rkbin-bump-v1-0-b90b6c04a88f@cherry.de
>
> ---
> Quentin Schulz (2):
> bsp: rkbin: rkbin-ddr: use version and file variables for path matching
> bsp: rkbin: bump to latest commit in master branch
>
> README | 15 +++++++++++++++
> recipes-bsp/rkbin/rockchip-rkbin-ddr_git.bb | 20 ++++++++++++++++----
> recipes-bsp/rkbin/rockchip-rkbin.inc | 4 ++--
> 3 files changed, 33 insertions(+), 6 deletions(-)
> ---
> base-commit: 3a8be31581651ced6c27f5bad1333064e513a8f0
> change-id: 20241127-rkbin-bump-4cdfb23aa49f
>
> Best regards,
> --
> Quentin Schulz <quentin.schulz@cherry.de>
>
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#857): https://lists.yoctoproject.org/g/yocto-patches/message/857
> Mute This Topic: https://lists.yoctoproject.org/mt/109823578/900817
> Group Owner: yocto-patches+owner@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/yocto-patches/leave/13168745/900817/63955952/xyzzy [twoerner@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [yocto-patches] [meta-rockchip PATCH v2 0/2] bsp: rkbin: bump to latest commit in master
2024-12-05 17:09 ` [yocto-patches] [meta-rockchip PATCH v2 0/2] bsp: rkbin: bump to latest commit in master Trevor Woerner
@ 2024-12-05 17:21 ` Quentin Schulz
0 siblings, 0 replies; 12+ messages in thread
From: Quentin Schulz @ 2024-12-05 17:21 UTC (permalink / raw)
To: Trevor Woerner, yocto-patches
Hi Trevor,
On 12/5/24 6:09 PM, Trevor Woerner wrote:
> On Thu 2024-11-28 @ 04:58:48 PM, Quentin Schulz via lists.yoctoproject.org wrote:
>> We've been hit by random RCU stalls, system hangs or resets on some (not
>> all) of our RK3588-based products running some old BL31/DDR init
>> binaries.
>>
>> Upgrading to latest commit in master branch seems to mitigate those
>> issues, so let's do that.
>>
>> Only build tested.
>
> If I wanted to test on boards without having to yank the SDcard and re-image,
> I would only need to update the idbloader.img in /dev/disk/by-partlabel/ ?
>
As far as I remember, idbloader.img only includes the DDR bin (DRAM
init), u-boot.itb contains the BL31 (TF-A/ATF) and BL32 (OP-TEE OS) as
well as U-Boot proper and scripts if you have some.
So depending on what you want to test, you may need to update both.
Cheers,
Quentin
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [yocto-patches] [meta-rockchip PATCH v2 0/2] bsp: rkbin: bump to latest commit in master
2024-11-28 15:58 [meta-rockchip PATCH v2 0/2] bsp: rkbin: bump to latest commit in master Quentin Schulz
` (2 preceding siblings ...)
2024-12-05 17:09 ` [yocto-patches] [meta-rockchip PATCH v2 0/2] bsp: rkbin: bump to latest commit in master Trevor Woerner
@ 2024-12-12 20:11 ` Trevor Woerner
2024-12-13 10:10 ` Quentin Schulz
3 siblings, 1 reply; 12+ messages in thread
From: Trevor Woerner @ 2024-12-12 20:11 UTC (permalink / raw)
To: yocto-patches; +Cc: Quentin Schulz
On Thu 2024-11-28 @ 04:58:48 PM, Quentin Schulz via lists.yoctoproject.org wrote:
> We've been hit by random RCU stalls, system hangs or resets on some (not
> all) of our RK3588-based products running some old BL31/DDR init
> binaries.
>
> Upgrading to latest commit in master branch seems to mitigate those
> issues, so let's do that.
>
> Only build tested.
I have finally gotten around to testing before and after images of your
patchset. This was complicated by the fact that the u-boot and kernel for the
radxa-zero-3 stopped working recently, so I needed updates for that in order
to test everything.
I was able to confirm all of the changes work on hardware except for the
rk3308.
in order to test i have a
^^^^^^^^^^^^^^^^ ^^^^^^^^
rk3308 rock-pi-s
rk3566 radxa-zero-3e
rk3568 rock-3a
rk3588s rock-5a
rk3588 rock-5b
In all cases but the rk3308 I have nice before and after captures, clearly
showing the old version numbers then the new version numbers.
In the case of the rk3308 this patch set is moving from v2.07 to v2.10, but
here's what the before looks like on the rock-pi-s:
DDR Version V1.26
REGFB: 0x00000032, 0x00000032
In
589MHz
DDR3
Col=10 Bank=8 Row=14 Size=256MB
msch:1
Returning to boot ROM...
U-Boot SPL 2024.04 (Apr 03 2024 - 02:37:23 +0000)
Trying to boot from MMC2
U-Boot 2024.04 (Apr 03 2024 - 02:37:23 +0000)
Model: Radxa ROCK Pi S
DRAM: 256 MiB (effective 254 MiB)
Core: 281 devices, 21 uclasses, devicetree: separate
MMC: mmc@ff480000: 1, mmc@ff490000: 0, mmc@ff4a0000: 2
Loading Environment from MMC... OK
and the after:
DDR Version V1.26
REGFB: 0x00000032, 0x00000033
In
589MHz
DDR3
Col=10 Bank=8 Row=14 Size=256MB
msch:1
Returning to boot ROM...
U-Boot SPL 2024.10-dirty (Oct 07 2024 - 14:54:35 +0000)
Trying to boot from MMC2
## Checking hash(es) for config config-1 ... OK
## Checking hash(es) for Image atf-1 ... sha256+ OK
## Checking hash(es) for Image u-boot ... sha256+ OK
## Checking hash(es) for Image fdt-1 ... sha256+ OK
## Checking hash(es) for Image atf-2 ... sha256+ OK
U-Boot 2024.10-dirty (Oct 07 2024 - 14:54:35 +0000)
Model: Radxa ROCK Pi S
DRAM: 256 MiB (effective 254 MiB)
Core: 293 devices, 30 uclasses, devicetree: separate
MMC: mmc@ff480000: 1, mmc@ff490000: 0, mmc@ff4a0000: 2
Loading Environment from MMC... Reading from MMC(1)... OK
So I'm not sure what's going on here. But I'm happy with the patchset
otherwise.
> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
> ---
> Changes in v2:
> - use version and filename variables instead of using glob pattern for
> path matching the DDR init binaries,
> - Link to v1: https://lore.kernel.org/r/20241127-rkbin-bump-v1-0-b90b6c04a88f@cherry.de
>
> ---
> Quentin Schulz (2):
> bsp: rkbin: rkbin-ddr: use version and file variables for path matching
> bsp: rkbin: bump to latest commit in master branch
>
> README | 15 +++++++++++++++
> recipes-bsp/rkbin/rockchip-rkbin-ddr_git.bb | 20 ++++++++++++++++----
> recipes-bsp/rkbin/rockchip-rkbin.inc | 4 ++--
> 3 files changed, 33 insertions(+), 6 deletions(-)
> ---
> base-commit: 3a8be31581651ced6c27f5bad1333064e513a8f0
> change-id: 20241127-rkbin-bump-4cdfb23aa49f
>
> Best regards,
> --
> Quentin Schulz <quentin.schulz@cherry.de>
>
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#857): https://lists.yoctoproject.org/g/yocto-patches/message/857
> Mute This Topic: https://lists.yoctoproject.org/mt/109823578/900817
> Group Owner: yocto-patches+owner@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/yocto-patches/leave/13168745/900817/63955952/xyzzy [twoerner@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [yocto-patches] [meta-rockchip PATCH v2 0/2] bsp: rkbin: bump to latest commit in master
2024-12-12 20:11 ` Trevor Woerner
@ 2024-12-13 10:10 ` Quentin Schulz
2024-12-13 13:25 ` Trevor Woerner
0 siblings, 1 reply; 12+ messages in thread
From: Quentin Schulz @ 2024-12-13 10:10 UTC (permalink / raw)
To: yocto-patches
Hi Trevor,
On 12/12/24 9:11 PM, Trevor Woerner via lists.yoctoproject.org wrote:
> On Thu 2024-11-28 @ 04:58:48 PM, Quentin Schulz via lists.yoctoproject.org wrote:
>> We've been hit by random RCU stalls, system hangs or resets on some (not
>> all) of our RK3588-based products running some old BL31/DDR init
>> binaries.
>>
>> Upgrading to latest commit in master branch seems to mitigate those
>> issues, so let's do that.
>>
>> Only build tested.
>
> I have finally gotten around to testing before and after images of your
> patchset. This was complicated by the fact that the u-boot and kernel for the
> radxa-zero-3 stopped working recently, so I needed updates for that in order
> to test everything.
>
> I was able to confirm all of the changes work on hardware except for the
> rk3308.
>
> in order to test i have a
> ^^^^^^^^^^^^^^^^ ^^^^^^^^
> rk3308 rock-pi-s
> rk3566 radxa-zero-3e
> rk3568 rock-3a
> rk3588s rock-5a
> rk3588 rock-5b
>
> In all cases but the rk3308 I have nice before and after captures, clearly
> showing the old version numbers then the new version numbers.
>
> In the case of the rk3308 this patch set is moving from v2.07 to v2.10, but
> here's what the before looks like on the rock-pi-s:
>
>
> DDR Version V1.26
> REGFB: 0x00000032, 0x00000032
> In
> 589MHz
> DDR3
> Col=10 Bank=8 Row=14 Size=256MB
> msch:1
> Returning to boot ROM...
>
> U-Boot SPL 2024.04 (Apr 03 2024 - 02:37:23 +0000)
> Trying to boot from MMC2
>
>
> U-Boot 2024.04 (Apr 03 2024 - 02:37:23 +0000)
>
> Model: Radxa ROCK Pi S
> DRAM: 256 MiB (effective 254 MiB)
> Core: 281 devices, 21 uclasses, devicetree: separate
> MMC: mmc@ff480000: 1, mmc@ff490000: 0, mmc@ff4a0000: 2
> Loading Environment from MMC... OK
>
> and the after:
>
>
> DDR Version V1.26
> REGFB: 0x00000032, 0x00000033
> In
> 589MHz
> DDR3
> Col=10 Bank=8 Row=14 Size=256MB
> msch:1
> Returning to boot ROM...
>
> U-Boot SPL 2024.10-dirty (Oct 07 2024 - 14:54:35 +0000)
> Trying to boot from MMC2
> ## Checking hash(es) for config config-1 ... OK
> ## Checking hash(es) for Image atf-1 ... sha256+ OK
> ## Checking hash(es) for Image u-boot ... sha256+ OK
> ## Checking hash(es) for Image fdt-1 ... sha256+ OK
> ## Checking hash(es) for Image atf-2 ... sha256+ OK
>
>
> U-Boot 2024.10-dirty (Oct 07 2024 - 14:54:35 +0000)
>
> Model: Radxa ROCK Pi S
> DRAM: 256 MiB (effective 254 MiB)
> Core: 293 devices, 30 uclasses, devicetree: separate
> MMC: mmc@ff480000: 1, mmc@ff490000: 0, mmc@ff4a0000: 2
> Loading Environment from MMC... Reading from MMC(1)... OK
>
> So I'm not sure what's going on here. But I'm happy with the patchset
> otherwise.
>
What's going on is that we have an rkbin recipe specifically for the
rk3308 which is selected by default :)
I have not updated it as it was specifically done because the UART
console/mux for one of your devices didn't exist in newer versions of
rkbin, so I assume this is still the case?
If you were to set RKBIN_RK3308_LATEST to 1, this should work (albeit
nothing on the UART anymore).
Does reality match my expectations?
Cheers,
Quentin
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [yocto-patches] [meta-rockchip PATCH v2 0/2] bsp: rkbin: bump to latest commit in master
2024-12-13 10:10 ` Quentin Schulz
@ 2024-12-13 13:25 ` Trevor Woerner
2024-12-13 13:46 ` Quentin Schulz
0 siblings, 1 reply; 12+ messages in thread
From: Trevor Woerner @ 2024-12-13 13:25 UTC (permalink / raw)
To: yocto-patches
On Fri 2024-12-13 @ 11:10:31 AM, Quentin Schulz via lists.yoctoproject.org wrote:
> Hi Trevor,
>
> On 12/12/24 9:11 PM, Trevor Woerner via lists.yoctoproject.org wrote:
> > On Thu 2024-11-28 @ 04:58:48 PM, Quentin Schulz via lists.yoctoproject.org wrote:
> > > We've been hit by random RCU stalls, system hangs or resets on some (not
> > > all) of our RK3588-based products running some old BL31/DDR init
> > > binaries.
> > >
> > > Upgrading to latest commit in master branch seems to mitigate those
> > > issues, so let's do that.
> > >
> > > Only build tested.
> >
> > I have finally gotten around to testing before and after images of your
> > patchset. This was complicated by the fact that the u-boot and kernel for the
> > radxa-zero-3 stopped working recently, so I needed updates for that in order
> > to test everything.
> >
> > I was able to confirm all of the changes work on hardware except for the
> > rk3308.
> >
> > in order to test i have a
> > ^^^^^^^^^^^^^^^^ ^^^^^^^^
> > rk3308 rock-pi-s
> > rk3566 radxa-zero-3e
> > rk3568 rock-3a
> > rk3588s rock-5a
> > rk3588 rock-5b
> >
> > In all cases but the rk3308 I have nice before and after captures, clearly
> > showing the old version numbers then the new version numbers.
> >
> > In the case of the rk3308 this patch set is moving from v2.07 to v2.10, but
> > here's what the before looks like on the rock-pi-s:
> >
> >
> > DDR Version V1.26
> > REGFB: 0x00000032, 0x00000032
> > In
> > 589MHz
> > DDR3
> > Col=10 Bank=8 Row=14 Size=256MB
> > msch:1
> > Returning to boot ROM...
> >
> > U-Boot SPL 2024.04 (Apr 03 2024 - 02:37:23 +0000)
> > Trying to boot from MMC2
> >
> >
> > U-Boot 2024.04 (Apr 03 2024 - 02:37:23 +0000)
> >
> > Model: Radxa ROCK Pi S
> > DRAM: 256 MiB (effective 254 MiB)
> > Core: 281 devices, 21 uclasses, devicetree: separate
> > MMC: mmc@ff480000: 1, mmc@ff490000: 0, mmc@ff4a0000: 2
> > Loading Environment from MMC... OK
> >
> > and the after:
> >
> >
> > DDR Version V1.26
> > REGFB: 0x00000032, 0x00000033
> > In
> > 589MHz
> > DDR3
> > Col=10 Bank=8 Row=14 Size=256MB
> > msch:1
> > Returning to boot ROM...
> >
> > U-Boot SPL 2024.10-dirty (Oct 07 2024 - 14:54:35 +0000)
> > Trying to boot from MMC2
> > ## Checking hash(es) for config config-1 ... OK
> > ## Checking hash(es) for Image atf-1 ... sha256+ OK
> > ## Checking hash(es) for Image u-boot ... sha256+ OK
> > ## Checking hash(es) for Image fdt-1 ... sha256+ OK
> > ## Checking hash(es) for Image atf-2 ... sha256+ OK
> >
> >
> > U-Boot 2024.10-dirty (Oct 07 2024 - 14:54:35 +0000)
> >
> > Model: Radxa ROCK Pi S
> > DRAM: 256 MiB (effective 254 MiB)
> > Core: 293 devices, 30 uclasses, devicetree: separate
> > MMC: mmc@ff480000: 1, mmc@ff490000: 0, mmc@ff4a0000: 2
> > Loading Environment from MMC... Reading from MMC(1)... OK
> >
> > So I'm not sure what's going on here. But I'm happy with the patchset
> > otherwise.
> >
>
> What's going on is that we have an rkbin recipe specifically for the rk3308
> which is selected by default :)
>
> I have not updated it as it was specifically done because the UART
> console/mux for one of your devices didn't exist in newer versions of rkbin,
> so I assume this is still the case?
>
> If you were to set RKBIN_RK3308_LATEST to 1, this should work (albeit
> nothing on the UART anymore).
>
> Does reality match my expectations?
Enabling RKBIN_RK3308_LATEST causes the build to fail. But it's not failing
because of your recent patches, something prior already broke it.
> Cheers,
> Quentin
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#893): https://lists.yoctoproject.org/g/yocto-patches/message/893
> Mute This Topic: https://lists.yoctoproject.org/mt/109823578/900817
> Group Owner: yocto-patches+owner@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/yocto-patches/leave/13168745/900817/63955952/xyzzy [twoerner@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [yocto-patches] [meta-rockchip PATCH v2 0/2] bsp: rkbin: bump to latest commit in master
2024-12-13 13:25 ` Trevor Woerner
@ 2024-12-13 13:46 ` Quentin Schulz
2024-12-13 15:17 ` Trevor Woerner
0 siblings, 1 reply; 12+ messages in thread
From: Quentin Schulz @ 2024-12-13 13:46 UTC (permalink / raw)
To: yocto-patches
On 12/13/24 2:25 PM, Trevor Woerner via lists.yoctoproject.org wrote:
> On Fri 2024-12-13 @ 11:10:31 AM, Quentin Schulz via lists.yoctoproject.org wrote:
>> Hi Trevor,
>>
>> On 12/12/24 9:11 PM, Trevor Woerner via lists.yoctoproject.org wrote:
>>> On Thu 2024-11-28 @ 04:58:48 PM, Quentin Schulz via lists.yoctoproject.org wrote:
>>>> We've been hit by random RCU stalls, system hangs or resets on some (not
>>>> all) of our RK3588-based products running some old BL31/DDR init
>>>> binaries.
>>>>
>>>> Upgrading to latest commit in master branch seems to mitigate those
>>>> issues, so let's do that.
>>>>
>>>> Only build tested.
>>>
>>> I have finally gotten around to testing before and after images of your
>>> patchset. This was complicated by the fact that the u-boot and kernel for the
>>> radxa-zero-3 stopped working recently, so I needed updates for that in order
>>> to test everything.
>>>
>>> I was able to confirm all of the changes work on hardware except for the
>>> rk3308.
>>>
>>> in order to test i have a
>>> ^^^^^^^^^^^^^^^^ ^^^^^^^^
>>> rk3308 rock-pi-s
>>> rk3566 radxa-zero-3e
>>> rk3568 rock-3a
>>> rk3588s rock-5a
>>> rk3588 rock-5b
>>>
>>> In all cases but the rk3308 I have nice before and after captures, clearly
>>> showing the old version numbers then the new version numbers.
>>>
>>> In the case of the rk3308 this patch set is moving from v2.07 to v2.10, but
>>> here's what the before looks like on the rock-pi-s:
>>>
>>>
>>> DDR Version V1.26
>>> REGFB: 0x00000032, 0x00000032
>>> In
>>> 589MHz
>>> DDR3
>>> Col=10 Bank=8 Row=14 Size=256MB
>>> msch:1
>>> Returning to boot ROM...
>>>
>>> U-Boot SPL 2024.04 (Apr 03 2024 - 02:37:23 +0000)
>>> Trying to boot from MMC2
>>>
>>>
>>> U-Boot 2024.04 (Apr 03 2024 - 02:37:23 +0000)
>>>
>>> Model: Radxa ROCK Pi S
>>> DRAM: 256 MiB (effective 254 MiB)
>>> Core: 281 devices, 21 uclasses, devicetree: separate
>>> MMC: mmc@ff480000: 1, mmc@ff490000: 0, mmc@ff4a0000: 2
>>> Loading Environment from MMC... OK
>>>
>>> and the after:
>>>
>>>
>>> DDR Version V1.26
>>> REGFB: 0x00000032, 0x00000033
>>> In
>>> 589MHz
>>> DDR3
>>> Col=10 Bank=8 Row=14 Size=256MB
>>> msch:1
>>> Returning to boot ROM...
>>>
>>> U-Boot SPL 2024.10-dirty (Oct 07 2024 - 14:54:35 +0000)
>>> Trying to boot from MMC2
>>> ## Checking hash(es) for config config-1 ... OK
>>> ## Checking hash(es) for Image atf-1 ... sha256+ OK
>>> ## Checking hash(es) for Image u-boot ... sha256+ OK
>>> ## Checking hash(es) for Image fdt-1 ... sha256+ OK
>>> ## Checking hash(es) for Image atf-2 ... sha256+ OK
>>>
>>>
>>> U-Boot 2024.10-dirty (Oct 07 2024 - 14:54:35 +0000)
>>>
>>> Model: Radxa ROCK Pi S
>>> DRAM: 256 MiB (effective 254 MiB)
>>> Core: 293 devices, 30 uclasses, devicetree: separate
>>> MMC: mmc@ff480000: 1, mmc@ff490000: 0, mmc@ff4a0000: 2
>>> Loading Environment from MMC... Reading from MMC(1)... OK
>>>
>>> So I'm not sure what's going on here. But I'm happy with the patchset
>>> otherwise.
>>>
>>
>> What's going on is that we have an rkbin recipe specifically for the rk3308
>> which is selected by default :)
>>
>> I have not updated it as it was specifically done because the UART
>> console/mux for one of your devices didn't exist in newer versions of rkbin,
>> so I assume this is still the case?
>>
>> If you were to set RKBIN_RK3308_LATEST to 1, this should work (albeit
>> nothing on the UART anymore).
>>
>> Does reality match my expectations?
>
> Enabling RKBIN_RK3308_LATEST causes the build to fail. But it's not failing
> because of your recent patches, something prior already broke it.
>
Probably the switch to separate recipes for ddrbin, op-tee and tf-a.
Do you have the logs somewhere I could have a look at?
Cheers,
Quentin
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [yocto-patches] [meta-rockchip PATCH v2 0/2] bsp: rkbin: bump to latest commit in master
2024-12-13 13:46 ` Quentin Schulz
@ 2024-12-13 15:17 ` Trevor Woerner
0 siblings, 0 replies; 12+ messages in thread
From: Trevor Woerner @ 2024-12-13 15:17 UTC (permalink / raw)
To: yocto-patches
On Fri 2024-12-13 @ 02:46:15 PM, Quentin Schulz via lists.yoctoproject.org wrote:
> On 12/13/24 2:25 PM, Trevor Woerner via lists.yoctoproject.org wrote:
> > On Fri 2024-12-13 @ 11:10:31 AM, Quentin Schulz via lists.yoctoproject.org wrote:
> > > Hi Trevor,
> > >
> > > On 12/12/24 9:11 PM, Trevor Woerner via lists.yoctoproject.org wrote:
> > > > On Thu 2024-11-28 @ 04:58:48 PM, Quentin Schulz via lists.yoctoproject.org wrote:
> > > > > We've been hit by random RCU stalls, system hangs or resets on some (not
> > > > > all) of our RK3588-based products running some old BL31/DDR init
> > > > > binaries.
> > > > >
> > > > > Upgrading to latest commit in master branch seems to mitigate those
> > > > > issues, so let's do that.
> > > > >
> > > > > Only build tested.
> > > >
> > > > I have finally gotten around to testing before and after images of your
> > > > patchset. This was complicated by the fact that the u-boot and kernel for the
> > > > radxa-zero-3 stopped working recently, so I needed updates for that in order
> > > > to test everything.
> > > >
> > > > I was able to confirm all of the changes work on hardware except for the
> > > > rk3308.
> > > >
> > > > in order to test i have a
> > > > ^^^^^^^^^^^^^^^^ ^^^^^^^^
> > > > rk3308 rock-pi-s
> > > > rk3566 radxa-zero-3e
> > > > rk3568 rock-3a
> > > > rk3588s rock-5a
> > > > rk3588 rock-5b
> > > >
> > > > In all cases but the rk3308 I have nice before and after captures, clearly
> > > > showing the old version numbers then the new version numbers.
> > > >
> > > > In the case of the rk3308 this patch set is moving from v2.07 to v2.10, but
> > > > here's what the before looks like on the rock-pi-s:
> > > >
> > > >
> > > > DDR Version V1.26
> > > > REGFB: 0x00000032, 0x00000032
> > > > In
> > > > 589MHz
> > > > DDR3
> > > > Col=10 Bank=8 Row=14 Size=256MB
> > > > msch:1
> > > > Returning to boot ROM...
> > > >
> > > > U-Boot SPL 2024.04 (Apr 03 2024 - 02:37:23 +0000)
> > > > Trying to boot from MMC2
> > > >
> > > >
> > > > U-Boot 2024.04 (Apr 03 2024 - 02:37:23 +0000)
> > > >
> > > > Model: Radxa ROCK Pi S
> > > > DRAM: 256 MiB (effective 254 MiB)
> > > > Core: 281 devices, 21 uclasses, devicetree: separate
> > > > MMC: mmc@ff480000: 1, mmc@ff490000: 0, mmc@ff4a0000: 2
> > > > Loading Environment from MMC... OK
> > > >
> > > > and the after:
> > > >
> > > >
> > > > DDR Version V1.26
> > > > REGFB: 0x00000032, 0x00000033
> > > > In
> > > > 589MHz
> > > > DDR3
> > > > Col=10 Bank=8 Row=14 Size=256MB
> > > > msch:1
> > > > Returning to boot ROM...
> > > >
> > > > U-Boot SPL 2024.10-dirty (Oct 07 2024 - 14:54:35 +0000)
> > > > Trying to boot from MMC2
> > > > ## Checking hash(es) for config config-1 ... OK
> > > > ## Checking hash(es) for Image atf-1 ... sha256+ OK
> > > > ## Checking hash(es) for Image u-boot ... sha256+ OK
> > > > ## Checking hash(es) for Image fdt-1 ... sha256+ OK
> > > > ## Checking hash(es) for Image atf-2 ... sha256+ OK
> > > >
> > > >
> > > > U-Boot 2024.10-dirty (Oct 07 2024 - 14:54:35 +0000)
> > > >
> > > > Model: Radxa ROCK Pi S
> > > > DRAM: 256 MiB (effective 254 MiB)
> > > > Core: 293 devices, 30 uclasses, devicetree: separate
> > > > MMC: mmc@ff480000: 1, mmc@ff490000: 0, mmc@ff4a0000: 2
> > > > Loading Environment from MMC... Reading from MMC(1)... OK
> > > >
> > > > So I'm not sure what's going on here. But I'm happy with the patchset
> > > > otherwise.
> > > >
> > >
> > > What's going on is that we have an rkbin recipe specifically for the rk3308
> > > which is selected by default :)
> > >
> > > I have not updated it as it was specifically done because the UART
> > > console/mux for one of your devices didn't exist in newer versions of rkbin,
> > > so I assume this is still the case?
> > >
> > > If you were to set RKBIN_RK3308_LATEST to 1, this should work (albeit
> > > nothing on the UART anymore).
> > >
> > > Does reality match my expectations?
> >
> > Enabling RKBIN_RK3308_LATEST causes the build to fail. But it's not failing
> > because of your recent patches, something prior already broke it.
> >
>
> Probably the switch to separate recipes for ddrbin, op-tee and tf-a.
>
> Do you have the logs somewhere I could have a look at?
I think I have a fix, I just need a bit more testing.
I'll resend my recent patches with this one added (and add the [meta-rockchip]
label as I should have for v1 ;-) )
> Cheers,
> Quentin
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#896): https://lists.yoctoproject.org/g/yocto-patches/message/896
> Mute This Topic: https://lists.yoctoproject.org/mt/109823578/900817
> Group Owner: yocto-patches+owner@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/yocto-patches/leave/13168745/900817/63955952/xyzzy [twoerner@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>
^ permalink raw reply [flat|nested] 12+ messages in thread