mbox series

[meta-rockchip,v2,0/2] bsp: rkbin: bump to latest commit in master

Message ID 20241128-rkbin-bump-v2-0-a194385aad7a@cherry.de
Headers show
Series bsp: rkbin: bump to latest commit in master | expand

Message

Quentin Schulz Nov. 28, 2024, 3:58 p.m. UTC
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.

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,

Comments

Trevor Woerner Dec. 5, 2024, 5:09 p.m. UTC | #1
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]
> -=-=-=-=-=-=-=-=-=-=-=-
> 
>
Quentin Schulz Dec. 5, 2024, 5:21 p.m. UTC | #2
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
Trevor Woerner Dec. 12, 2024, 8:11 p.m. UTC | #3
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]
> -=-=-=-=-=-=-=-=-=-=-=-
> 
>
Quentin Schulz Dec. 13, 2024, 10:10 a.m. UTC | #4
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
Trevor Woerner Dec. 13, 2024, 1:25 p.m. UTC | #5
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]
> -=-=-=-=-=-=-=-=-=-=-=-
> 
>
Quentin Schulz Dec. 13, 2024, 1:46 p.m. UTC | #6
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
Trevor Woerner Dec. 13, 2024, 3:17 p.m. UTC | #7
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]
> -=-=-=-=-=-=-=-=-=-=-=-
> 
>