mbox series

[meta-rockchip,master,scarthgap,v3,00/16] various reworks around u-boot and rkbin + fixes for MACHINEOVERRIDES

Message ID 20240531-rk3588-family-v3-0-629586621c5d@cherry.de
Headers show
Series various reworks around u-boot and rkbin + fixes for MACHINEOVERRIDES | expand

Message

Quentin Schulz May 31, 2024, 9:25 a.m. UTC
This does a few reworks of how we handle TF-A and DDR bin blob
dependencies, hopefully in a way that makes it much easier to add
support for new SoCs without having to touch too many files.

While at it, add an SOC_FAMILY entry for rk3588s/rk3588 boards.

Additionally, make rk3308 use the PREFERRED_PROVIDER mechanism to select
rk3308-rkbin instead of rockchip-rkbin.

Finally, fix a few MACHINEOVERRIDES ordering issues.

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
---
Changes in v3:
- rebased on top of master
  - fix merge conflict when moving common code to the .inc file, I
    decided to keep the rk-u-boot-env logic only for upstream u-boot
    recipe and not put it into the .inc as the config fragment is
    probably specific to some version, we could however split it into
    its own separate .inc file so other uy-boot recipes in other layers
    could replicate the rk-u-boot-env logic with their recipe,
- Link to v2: https://lore.kernel.org/r/20240515-rk3588-family-v2-0-f81897a3ac50@cherry.de

Changes in v2:
- nothing in common with v1 except that rk3588s/rk3588 gains an
  SOC_FAMILY variable :)
- Link to v1: https://lore.kernel.org/r/20240514-rk3588-family-v1-1-5366b1534a10@cherry.de

---
Quentin Schulz (16):
      rk3588/rk3588s: add SOC_FAMILY
      rk3066: fix MACHINEOVERRIDES order
      rk3188: fix MACHINEOVERRIDES order
      rk3288: fix MACHINEOVERRIDES order
      add rockchip MACHINEOVERRIDES
      bsp: u-boot: rework BL31 in EXTRA_OEMAKE
      bsp: rkbin: rk3308-rkbin: PROVIDES rockchip-rkbin
      rk3308: move rockchip-rkbin selection to SoC conf file
      bsp: u-boot: explicit dependency on trusted-firware-a
      bsp: u-boot: remove duplicate trusted-firmware-a dependency for SoCs with open DDR init
      bsp: u-boot: split things that can apply to any U-Boot into a .inc file
      machine: rockchip-defaults: conditionally add closed-tpl MACHINEOVERRIDES
      machine: rk3308: mark all machines as to be using the closed TPL
      machine: rk3568: mark all machines as to be using the closed TPL
      machine: rk3588/rk3588s: mark all machines as to be using the closed TPL
      bsp: u-boot-rockchip.inc: rework ROCKCHIP_TPL to use closed-tpl OVERRIDES

 conf/machine/include/px30.inc              |  2 +-
 conf/machine/include/rk3066.inc            |  2 +-
 conf/machine/include/rk3188.inc            |  2 +-
 conf/machine/include/rk3288.inc            |  2 +-
 conf/machine/include/rk3308.inc            |  6 +++++-
 conf/machine/include/rk3328.inc            |  2 +-
 conf/machine/include/rk3399.inc            |  2 +-
 conf/machine/include/rk3568.inc            |  4 +++-
 conf/machine/include/rk3588.inc            |  1 +
 conf/machine/include/rk3588s.inc           |  5 ++++-
 conf/machine/include/rockchip-defaults.inc |  3 ++-
 recipes-bsp/rkbin/rk3308-rkbin_git.bb      |  1 +
 recipes-bsp/u-boot/u-boot-rockchip.inc     | 18 ++++++++++++++++++
 recipes-bsp/u-boot/u-boot_%.bbappend       | 27 ++-------------------------
 14 files changed, 42 insertions(+), 35 deletions(-)
---
base-commit: 3381d6af6eabfb532da16863b785a95abba6b9e8
change-id: 20240514-rk3588-family-6f322d5f1034

Best regards,

Comments

Trevor Woerner June 5, 2024, 5:23 p.m. UTC | #1
On Fri 2024-05-31 @ 11:25:07 AM, Quentin Schulz via lists.yoctoproject.org wrote:
> This does a few reworks of how we handle TF-A and DDR bin blob
> dependencies, hopefully in a way that makes it much easier to add
> support for new SoCs without having to touch too many files.
> 
> While at it, add an SOC_FAMILY entry for rk3588s/rk3588 boards.
> 
> Additionally, make rk3308 use the PREFERRED_PROVIDER mechanism to select
> rk3308-rkbin instead of rockchip-rkbin.
> 
> Finally, fix a few MACHINEOVERRIDES ordering issues.

Here are the new MACHINEOVERRIDES (with these patches applied) for all the
MACHINEs we support (with rk-u-boot-env enabled):

	MACHINEOVERRIDES="armv7ve:rockchip:rk3288:firefly-rk3288:rk-u-boot-env"
	MACHINEOVERRIDES="armv7a:rockchip:rk3066:marsboard-rk3066"
	MACHINEOVERRIDES="armv7a:rockchip:rk3188:radxarock"
	MACHINEOVERRIDES="armv7ve:rockchip:rk3288:rock2-square"
	MACHINEOVERRIDES="armv7ve:rockchip:rk3288:tinker-board:rk-u-boot-env"
	MACHINEOVERRIDES="armv7ve:rockchip:rk3288:tinker-board-s:rk-u-boot-env"
	MACHINEOVERRIDES="armv7ve:rockchip:rk3288:vyasa-rk3288:rk-u-boot-env"
	MACHINEOVERRIDES="aarch64:cortexa72-cortexa53:rockchip:rk3399:nanopi-m4:nanopi-m4:rk-u-boot-env"
	MACHINEOVERRIDES="aarch64:cortexa72-cortexa53:rockchip:rk3399:nanopi-m4:nanopi-m4-2gb:rk-u-boot-env"
	MACHINEOVERRIDES="aarch64:cortexa72-cortexa53:rockchip:rk3399:nanopi-m4b:rk-u-boot-env"
	MACHINEOVERRIDES="aarch64:rockchip:rk3328:nanopi-r2s:rk-u-boot-env"
	MACHINEOVERRIDES="aarch64:cortexa72-cortexa53:rockchip:rk3399:nanopi-r4s:rk-u-boot-env"
	MACHINEOVERRIDES="aarch64:cortexa76-cortexa55:rockchip:closed-tpl:rk3588s:rk3588:orangepi-5-plus:rk-u-boot-env"
	MACHINEOVERRIDES="aarch64:rockchip:closed-tpl:rk3308:roc-rk3308-cc:rk-u-boot-env"
	MACHINEOVERRIDES="aarch64:rockchip:rk3328:roc-rk3328-cc:rk-u-boot-env"
	MACHINEOVERRIDES="aarch64:rockchip:closed-tpl:rk3568:rock-3a:rk-u-boot-env"
	MACHINEOVERRIDES="aarch64:cortexa72-cortexa53:rockchip:rk3399:rock-pi-4:rock-4c-plus:rk-u-boot-env"
	MACHINEOVERRIDES="aarch64:cortexa76-cortexa55:rockchip:closed-tpl:rk3588s:rock-5a:rk-u-boot-env"
	MACHINEOVERRIDES="aarch64:cortexa76-cortexa55:rockchip:closed-tpl:rk3588s:rk3588:rock-5b:rk-u-boot-env"
	MACHINEOVERRIDES="aarch64:cortexa72-cortexa53:rockchip:rk3399:rock-pi-4:rock-pi-4a:rk-u-boot-env"
	MACHINEOVERRIDES="aarch64:cortexa72-cortexa53:rockchip:rk3399:rock-pi-4:rock-pi-4b:rk-u-boot-env"
	MACHINEOVERRIDES="aarch64:cortexa72-cortexa53:rockchip:rk3399:rock-pi-4:rock-pi-4c:rk-u-boot-env"
	MACHINEOVERRIDES="aarch64:rockchip:rk3328:rock-pi-e:rk-u-boot-env"
	MACHINEOVERRIDES="aarch64:rockchip:closed-tpl:rk3308:rock-pi-s:rk-u-boot-env"
	MACHINEOVERRIDES="aarch64:rockchip:rk3328:rock64:rk-u-boot-env"

For uniformity, would it be nicer to have all MACHINEs include the SoC
OVERRIDE?

Other than that this patch set looks great!

I'm not overly fond of the name "u-boot-rockchip.inc" since it sounds like
it's an inc file for building the rockchip vendor fork of u-boot, but I can't
really think of anything that is obviously nicer.
Quentin Schulz June 6, 2024, 8:17 a.m. UTC | #2
Hi Trevor,

On 6/5/24 7:23 PM, Trevor Woerner wrote:
> On Fri 2024-05-31 @ 11:25:07 AM, Quentin Schulz via lists.yoctoproject.org wrote:
>> This does a few reworks of how we handle TF-A and DDR bin blob
>> dependencies, hopefully in a way that makes it much easier to add
>> support for new SoCs without having to touch too many files.
>>
>> While at it, add an SOC_FAMILY entry for rk3588s/rk3588 boards.
>>
>> Additionally, make rk3308 use the PREFERRED_PROVIDER mechanism to select
>> rk3308-rkbin instead of rockchip-rkbin.
>>
>> Finally, fix a few MACHINEOVERRIDES ordering issues.
> 
> Here are the new MACHINEOVERRIDES (with these patches applied) for all the
> MACHINEs we support (with rk-u-boot-env enabled):
> 
> 	MACHINEOVERRIDES="armv7ve:rockchip:rk3288:firefly-rk3288:rk-u-boot-env"
> 	MACHINEOVERRIDES="armv7a:rockchip:rk3066:marsboard-rk3066"
> 	MACHINEOVERRIDES="armv7a:rockchip:rk3188:radxarock"
> 	MACHINEOVERRIDES="armv7ve:rockchip:rk3288:rock2-square"
> 	MACHINEOVERRIDES="armv7ve:rockchip:rk3288:tinker-board:rk-u-boot-env"
> 	MACHINEOVERRIDES="armv7ve:rockchip:rk3288:tinker-board-s:rk-u-boot-env"
> 	MACHINEOVERRIDES="armv7ve:rockchip:rk3288:vyasa-rk3288:rk-u-boot-env"
> 	MACHINEOVERRIDES="aarch64:cortexa72-cortexa53:rockchip:rk3399:nanopi-m4:nanopi-m4:rk-u-boot-env"
> 	MACHINEOVERRIDES="aarch64:cortexa72-cortexa53:rockchip:rk3399:nanopi-m4:nanopi-m4-2gb:rk-u-boot-env"
> 	MACHINEOVERRIDES="aarch64:cortexa72-cortexa53:rockchip:rk3399:nanopi-m4b:rk-u-boot-env"
> 	MACHINEOVERRIDES="aarch64:rockchip:rk3328:nanopi-r2s:rk-u-boot-env"
> 	MACHINEOVERRIDES="aarch64:cortexa72-cortexa53:rockchip:rk3399:nanopi-r4s:rk-u-boot-env"
> 	MACHINEOVERRIDES="aarch64:cortexa76-cortexa55:rockchip:closed-tpl:rk3588s:rk3588:orangepi-5-plus:rk-u-boot-env"
> 	MACHINEOVERRIDES="aarch64:rockchip:closed-tpl:rk3308:roc-rk3308-cc:rk-u-boot-env"
> 	MACHINEOVERRIDES="aarch64:rockchip:rk3328:roc-rk3328-cc:rk-u-boot-env"
> 	MACHINEOVERRIDES="aarch64:rockchip:closed-tpl:rk3568:rock-3a:rk-u-boot-env"
> 	MACHINEOVERRIDES="aarch64:cortexa72-cortexa53:rockchip:rk3399:rock-pi-4:rock-4c-plus:rk-u-boot-env"
> 	MACHINEOVERRIDES="aarch64:cortexa76-cortexa55:rockchip:closed-tpl:rk3588s:rock-5a:rk-u-boot-env"
> 	MACHINEOVERRIDES="aarch64:cortexa76-cortexa55:rockchip:closed-tpl:rk3588s:rk3588:rock-5b:rk-u-boot-env"
> 	MACHINEOVERRIDES="aarch64:cortexa72-cortexa53:rockchip:rk3399:rock-pi-4:rock-pi-4a:rk-u-boot-env"
> 	MACHINEOVERRIDES="aarch64:cortexa72-cortexa53:rockchip:rk3399:rock-pi-4:rock-pi-4b:rk-u-boot-env"
> 	MACHINEOVERRIDES="aarch64:cortexa72-cortexa53:rockchip:rk3399:rock-pi-4:rock-pi-4c:rk-u-boot-env"
> 	MACHINEOVERRIDES="aarch64:rockchip:rk3328:rock-pi-e:rk-u-boot-env"
> 	MACHINEOVERRIDES="aarch64:rockchip:closed-tpl:rk3308:rock-pi-s:rk-u-boot-env"
> 	MACHINEOVERRIDES="aarch64:rockchip:rk3328:rock64:rk-u-boot-env"
> 
> For uniformity, would it be nicer to have all MACHINEs include the SoC
> OVERRIDE?
> 

I'm not sure to follow here, the SoC name is in the override?

rk3288
rk3066
rk3188
rk3288
rk3288
rk3288
rk3288
rk3399
rk3399
rk3399
rk3328
rk3399
rk3588
rk3308
rk3328
rk3568
rk3399
rk3588s
rk3588
rk3399
rk3399
rk3399
rk3328
rk3308
rk3328

for all the above?

Aaaaaah... or you meant renaming the machines so that they have their 
SoC name in the filename? e.g. rock-pi-4a to rk3399-rock-pi-4a? I found 
it annoying when reworking to look into each machine conf to figure out 
which SoC they were based on, so I understand the pain :) If you want to 
go this route, I would suggest to prefix it with <SoC>- as is customary 
in the Linux kernel for Device Trees for example.

> Other than that this patch set looks great!
> 
> I'm not overly fond of the name "u-boot-rockchip.inc" since it sounds like
> it's an inc file for building the rockchip vendor fork of u-boot, but I can't
> really think of anything that is obviously nicer.

Could suggest u-boot-rkxxxx.inc instead? There are only a few SoCs that 
do not follow RKXXXX naming scheme (the PX family and RV families right now)

We could also add some comment at the top of this file explaining what 
this is supposed to be used for?

Let me know how you want to proceed with this,
Cheers,
Quentin
Trevor Woerner June 6, 2024, 11:49 a.m. UTC | #3
On Thu 2024-06-06 @ 10:17:17 AM, Quentin Schulz wrote:
> Hi Trevor,
> 
> On 6/5/24 7:23 PM, Trevor Woerner wrote:
> > On Fri 2024-05-31 @ 11:25:07 AM, Quentin Schulz via lists.yoctoproject.org wrote:
> > > This does a few reworks of how we handle TF-A and DDR bin blob
> > > dependencies, hopefully in a way that makes it much easier to add
> > > support for new SoCs without having to touch too many files.
> > > 
> > > While at it, add an SOC_FAMILY entry for rk3588s/rk3588 boards.
> > > 
> > > Additionally, make rk3308 use the PREFERRED_PROVIDER mechanism to select
> > > rk3308-rkbin instead of rockchip-rkbin.
> > > 
> > > Finally, fix a few MACHINEOVERRIDES ordering issues.
> > 
> > Here are the new MACHINEOVERRIDES (with these patches applied) for all the
> > MACHINEs we support (with rk-u-boot-env enabled):
> > 
> > 	MACHINEOVERRIDES="armv7ve:rockchip:rk3288:firefly-rk3288:rk-u-boot-env"
> > 	MACHINEOVERRIDES="armv7a:rockchip:rk3066:marsboard-rk3066"
> > 	MACHINEOVERRIDES="armv7a:rockchip:rk3188:radxarock"
> > 	MACHINEOVERRIDES="armv7ve:rockchip:rk3288:rock2-square"
> > 	MACHINEOVERRIDES="armv7ve:rockchip:rk3288:tinker-board:rk-u-boot-env"
> > 	MACHINEOVERRIDES="armv7ve:rockchip:rk3288:tinker-board-s:rk-u-boot-env"
> > 	MACHINEOVERRIDES="armv7ve:rockchip:rk3288:vyasa-rk3288:rk-u-boot-env"
> > 	MACHINEOVERRIDES="aarch64:cortexa72-cortexa53:rockchip:rk3399:nanopi-m4:nanopi-m4:rk-u-boot-env"
> > 	MACHINEOVERRIDES="aarch64:cortexa72-cortexa53:rockchip:rk3399:nanopi-m4:nanopi-m4-2gb:rk-u-boot-env"
> > 	MACHINEOVERRIDES="aarch64:cortexa72-cortexa53:rockchip:rk3399:nanopi-m4b:rk-u-boot-env"
> > 	MACHINEOVERRIDES="aarch64:rockchip:rk3328:nanopi-r2s:rk-u-boot-env"
> > 	MACHINEOVERRIDES="aarch64:cortexa72-cortexa53:rockchip:rk3399:nanopi-r4s:rk-u-boot-env"
> > 	MACHINEOVERRIDES="aarch64:cortexa76-cortexa55:rockchip:closed-tpl:rk3588s:rk3588:orangepi-5-plus:rk-u-boot-env"
> > 	MACHINEOVERRIDES="aarch64:rockchip:closed-tpl:rk3308:roc-rk3308-cc:rk-u-boot-env"
> > 	MACHINEOVERRIDES="aarch64:rockchip:rk3328:roc-rk3328-cc:rk-u-boot-env"
> > 	MACHINEOVERRIDES="aarch64:rockchip:closed-tpl:rk3568:rock-3a:rk-u-boot-env"
> > 	MACHINEOVERRIDES="aarch64:cortexa72-cortexa53:rockchip:rk3399:rock-pi-4:rock-4c-plus:rk-u-boot-env"
> > 	MACHINEOVERRIDES="aarch64:cortexa76-cortexa55:rockchip:closed-tpl:rk3588s:rock-5a:rk-u-boot-env"
> > 	MACHINEOVERRIDES="aarch64:cortexa76-cortexa55:rockchip:closed-tpl:rk3588s:rk3588:rock-5b:rk-u-boot-env"
> > 	MACHINEOVERRIDES="aarch64:cortexa72-cortexa53:rockchip:rk3399:rock-pi-4:rock-pi-4a:rk-u-boot-env"
> > 	MACHINEOVERRIDES="aarch64:cortexa72-cortexa53:rockchip:rk3399:rock-pi-4:rock-pi-4b:rk-u-boot-env"
> > 	MACHINEOVERRIDES="aarch64:cortexa72-cortexa53:rockchip:rk3399:rock-pi-4:rock-pi-4c:rk-u-boot-env"
> > 	MACHINEOVERRIDES="aarch64:rockchip:rk3328:rock-pi-e:rk-u-boot-env"
> > 	MACHINEOVERRIDES="aarch64:rockchip:closed-tpl:rk3308:rock-pi-s:rk-u-boot-env"
> > 	MACHINEOVERRIDES="aarch64:rockchip:rk3328:rock64:rk-u-boot-env"
> > 
> > For uniformity, would it be nicer to have all MACHINEs include the SoC
> > OVERRIDE?
> > 
> 
> I'm not sure to follow here

Sorry, what I mean is the "cortexa72-cortexa53" parts, which I guess is the
CPU? I don't know that I've seen those overrides being used often, but I would
rather either see all of them have this override, or none of them, as part of
any MACHINEOVERRIDE cleaning patches.
Quentin Schulz June 6, 2024, 1:02 p.m. UTC | #4
Hi Trevor,

On 6/6/24 1:49 PM, Trevor Woerner wrote:
> On Thu 2024-06-06 @ 10:17:17 AM, Quentin Schulz wrote:
>> Hi Trevor,
>>
>> On 6/5/24 7:23 PM, Trevor Woerner wrote:
>>> On Fri 2024-05-31 @ 11:25:07 AM, Quentin Schulz via lists.yoctoproject.org wrote:
>>>> This does a few reworks of how we handle TF-A and DDR bin blob
>>>> dependencies, hopefully in a way that makes it much easier to add
>>>> support for new SoCs without having to touch too many files.
>>>>
>>>> While at it, add an SOC_FAMILY entry for rk3588s/rk3588 boards.
>>>>
>>>> Additionally, make rk3308 use the PREFERRED_PROVIDER mechanism to select
>>>> rk3308-rkbin instead of rockchip-rkbin.
>>>>
>>>> Finally, fix a few MACHINEOVERRIDES ordering issues.
>>>
>>> Here are the new MACHINEOVERRIDES (with these patches applied) for all the
>>> MACHINEs we support (with rk-u-boot-env enabled):
>>>
>>> 	MACHINEOVERRIDES="armv7ve:rockchip:rk3288:firefly-rk3288:rk-u-boot-env"
>>> 	MACHINEOVERRIDES="armv7a:rockchip:rk3066:marsboard-rk3066"
>>> 	MACHINEOVERRIDES="armv7a:rockchip:rk3188:radxarock"
>>> 	MACHINEOVERRIDES="armv7ve:rockchip:rk3288:rock2-square"
>>> 	MACHINEOVERRIDES="armv7ve:rockchip:rk3288:tinker-board:rk-u-boot-env"
>>> 	MACHINEOVERRIDES="armv7ve:rockchip:rk3288:tinker-board-s:rk-u-boot-env"
>>> 	MACHINEOVERRIDES="armv7ve:rockchip:rk3288:vyasa-rk3288:rk-u-boot-env"
>>> 	MACHINEOVERRIDES="aarch64:cortexa72-cortexa53:rockchip:rk3399:nanopi-m4:nanopi-m4:rk-u-boot-env"
>>> 	MACHINEOVERRIDES="aarch64:cortexa72-cortexa53:rockchip:rk3399:nanopi-m4:nanopi-m4-2gb:rk-u-boot-env"
>>> 	MACHINEOVERRIDES="aarch64:cortexa72-cortexa53:rockchip:rk3399:nanopi-m4b:rk-u-boot-env"
>>> 	MACHINEOVERRIDES="aarch64:rockchip:rk3328:nanopi-r2s:rk-u-boot-env"
>>> 	MACHINEOVERRIDES="aarch64:cortexa72-cortexa53:rockchip:rk3399:nanopi-r4s:rk-u-boot-env"
>>> 	MACHINEOVERRIDES="aarch64:cortexa76-cortexa55:rockchip:closed-tpl:rk3588s:rk3588:orangepi-5-plus:rk-u-boot-env"
>>> 	MACHINEOVERRIDES="aarch64:rockchip:closed-tpl:rk3308:roc-rk3308-cc:rk-u-boot-env"
>>> 	MACHINEOVERRIDES="aarch64:rockchip:rk3328:roc-rk3328-cc:rk-u-boot-env"
>>> 	MACHINEOVERRIDES="aarch64:rockchip:closed-tpl:rk3568:rock-3a:rk-u-boot-env"
>>> 	MACHINEOVERRIDES="aarch64:cortexa72-cortexa53:rockchip:rk3399:rock-pi-4:rock-4c-plus:rk-u-boot-env"
>>> 	MACHINEOVERRIDES="aarch64:cortexa76-cortexa55:rockchip:closed-tpl:rk3588s:rock-5a:rk-u-boot-env"
>>> 	MACHINEOVERRIDES="aarch64:cortexa76-cortexa55:rockchip:closed-tpl:rk3588s:rk3588:rock-5b:rk-u-boot-env"
>>> 	MACHINEOVERRIDES="aarch64:cortexa72-cortexa53:rockchip:rk3399:rock-pi-4:rock-pi-4a:rk-u-boot-env"
>>> 	MACHINEOVERRIDES="aarch64:cortexa72-cortexa53:rockchip:rk3399:rock-pi-4:rock-pi-4b:rk-u-boot-env"
>>> 	MACHINEOVERRIDES="aarch64:cortexa72-cortexa53:rockchip:rk3399:rock-pi-4:rock-pi-4c:rk-u-boot-env"
>>> 	MACHINEOVERRIDES="aarch64:rockchip:rk3328:rock-pi-e:rk-u-boot-env"
>>> 	MACHINEOVERRIDES="aarch64:rockchip:closed-tpl:rk3308:rock-pi-s:rk-u-boot-env"
>>> 	MACHINEOVERRIDES="aarch64:rockchip:rk3328:rock64:rk-u-boot-env"
>>>
>>> For uniformity, would it be nicer to have all MACHINEs include the SoC
>>> OVERRIDE?
>>>
>>
>> I'm not sure to follow here
> 
> Sorry, what I mean is the "cortexa72-cortexa53" parts, which I guess is the
> CPU? I don't know that I've seen those overrides being used often, but I would
> rather either see all of them have this override, or none of them, as part of
> any MACHINEOVERRIDE cleaning patches.

Ahah, this isn't something to fix in meta-rockchip (or as a temporary 
work-around if you prefer, or for non-master branches) but rather in 
openembedded-core :)

c.f. 
https://git.openembedded.org/openembedded-core/tree/meta/conf/machine/include/arm/armv8-2a/tune-cortexa76-cortexa55.inc#n7 
for RK3588(s).

I assume we need to add the same to other Arm conf include files?

For the Aarch32 ones, the Cortex-A17 and Cortex-A9 already have this but 
not setting cortex-a17/a9 in it but rather armv7ve/armv7a.

For Aarch64 ones, all that use a big.LITTLE architecture have it set, 
but not the other, maybe something we could add then?

Cheers,
Quentin
Trevor Woerner June 6, 2024, 5:23 p.m. UTC | #5
On Thu 2024-06-06 @ 03:02:42 PM, Quentin Schulz wrote:
> Hi Trevor,
> 
> On 6/6/24 1:49 PM, Trevor Woerner wrote:
> > On Thu 2024-06-06 @ 10:17:17 AM, Quentin Schulz wrote:
> > > Hi Trevor,
> > > 
> > > On 6/5/24 7:23 PM, Trevor Woerner wrote:
> > > > On Fri 2024-05-31 @ 11:25:07 AM, Quentin Schulz via lists.yoctoproject.org wrote:
> > > > > This does a few reworks of how we handle TF-A and DDR bin blob
> > > > > dependencies, hopefully in a way that makes it much easier to add
> > > > > support for new SoCs without having to touch too many files.
> > > > > 
> > > > > While at it, add an SOC_FAMILY entry for rk3588s/rk3588 boards.
> > > > > 
> > > > > Additionally, make rk3308 use the PREFERRED_PROVIDER mechanism to select
> > > > > rk3308-rkbin instead of rockchip-rkbin.
> > > > > 
> > > > > Finally, fix a few MACHINEOVERRIDES ordering issues.
> > > > 
> > > > Here are the new MACHINEOVERRIDES (with these patches applied) for all the
> > > > MACHINEs we support (with rk-u-boot-env enabled):
> > > > 
> > > > 	MACHINEOVERRIDES="armv7ve:rockchip:rk3288:firefly-rk3288:rk-u-boot-env"
> > > > 	MACHINEOVERRIDES="armv7a:rockchip:rk3066:marsboard-rk3066"
> > > > 	MACHINEOVERRIDES="armv7a:rockchip:rk3188:radxarock"
> > > > 	MACHINEOVERRIDES="armv7ve:rockchip:rk3288:rock2-square"
> > > > 	MACHINEOVERRIDES="armv7ve:rockchip:rk3288:tinker-board:rk-u-boot-env"
> > > > 	MACHINEOVERRIDES="armv7ve:rockchip:rk3288:tinker-board-s:rk-u-boot-env"
> > > > 	MACHINEOVERRIDES="armv7ve:rockchip:rk3288:vyasa-rk3288:rk-u-boot-env"
> > > > 	MACHINEOVERRIDES="aarch64:cortexa72-cortexa53:rockchip:rk3399:nanopi-m4:nanopi-m4:rk-u-boot-env"
> > > > 	MACHINEOVERRIDES="aarch64:cortexa72-cortexa53:rockchip:rk3399:nanopi-m4:nanopi-m4-2gb:rk-u-boot-env"
> > > > 	MACHINEOVERRIDES="aarch64:cortexa72-cortexa53:rockchip:rk3399:nanopi-m4b:rk-u-boot-env"
> > > > 	MACHINEOVERRIDES="aarch64:rockchip:rk3328:nanopi-r2s:rk-u-boot-env"
> > > > 	MACHINEOVERRIDES="aarch64:cortexa72-cortexa53:rockchip:rk3399:nanopi-r4s:rk-u-boot-env"
> > > > 	MACHINEOVERRIDES="aarch64:cortexa76-cortexa55:rockchip:closed-tpl:rk3588s:rk3588:orangepi-5-plus:rk-u-boot-env"
> > > > 	MACHINEOVERRIDES="aarch64:rockchip:closed-tpl:rk3308:roc-rk3308-cc:rk-u-boot-env"
> > > > 	MACHINEOVERRIDES="aarch64:rockchip:rk3328:roc-rk3328-cc:rk-u-boot-env"
> > > > 	MACHINEOVERRIDES="aarch64:rockchip:closed-tpl:rk3568:rock-3a:rk-u-boot-env"
> > > > 	MACHINEOVERRIDES="aarch64:cortexa72-cortexa53:rockchip:rk3399:rock-pi-4:rock-4c-plus:rk-u-boot-env"
> > > > 	MACHINEOVERRIDES="aarch64:cortexa76-cortexa55:rockchip:closed-tpl:rk3588s:rock-5a:rk-u-boot-env"
> > > > 	MACHINEOVERRIDES="aarch64:cortexa76-cortexa55:rockchip:closed-tpl:rk3588s:rk3588:rock-5b:rk-u-boot-env"
> > > > 	MACHINEOVERRIDES="aarch64:cortexa72-cortexa53:rockchip:rk3399:rock-pi-4:rock-pi-4a:rk-u-boot-env"
> > > > 	MACHINEOVERRIDES="aarch64:cortexa72-cortexa53:rockchip:rk3399:rock-pi-4:rock-pi-4b:rk-u-boot-env"
> > > > 	MACHINEOVERRIDES="aarch64:cortexa72-cortexa53:rockchip:rk3399:rock-pi-4:rock-pi-4c:rk-u-boot-env"
> > > > 	MACHINEOVERRIDES="aarch64:rockchip:rk3328:rock-pi-e:rk-u-boot-env"
> > > > 	MACHINEOVERRIDES="aarch64:rockchip:closed-tpl:rk3308:rock-pi-s:rk-u-boot-env"
> > > > 	MACHINEOVERRIDES="aarch64:rockchip:rk3328:rock64:rk-u-boot-env"
> > > > 
> > > > For uniformity, would it be nicer to have all MACHINEs include the SoC
> > > > OVERRIDE?
> > > > 
> > > 
> > > I'm not sure to follow here
> > 
> > Sorry, what I mean is the "cortexa72-cortexa53" parts, which I guess is the
> > CPU? I don't know that I've seen those overrides being used often, but I would
> > rather either see all of them have this override, or none of them, as part of
> > any MACHINEOVERRIDE cleaning patches.
> 
> Ahah, this isn't something to fix in meta-rockchip (or as a temporary
> work-around if you prefer, or for non-master branches) but rather in
> openembedded-core :)
> 
> c.f. https://git.openembedded.org/openembedded-core/tree/meta/conf/machine/include/arm/armv8-2a/tune-cortexa76-cortexa55.inc#n7
> for RK3588(s).

Ah okay. Well in that case let's just leave it as-is. Like I said, I don't
know that I've seen much of anything use those overrides, and it's not
something we're using. I was just going for uniformity for what I thought was
our cleanup.

Applied to meta-rockchip, master and scrathgap branches. Thanks!