New legacy bootscript for rockchip-rk3588 so vendor/patched overlays work

[efectn]

Description

It wasn't possible to use overlays out-of-the-box because of they didn't have same prefix as Armbian's overlay prefix. Now they have valid names and it's possible to use them without extra effort.

How Has This Been Tested?

• Checked overlays on OPi5

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• Any dependent changes have been merged and published in downstream modules

[rpardini]

Hmm. You're renaming the overlays coming from vendor kernel tree?
What if they add an overlay? Eternal maintenance here?
Isn't it easier to change the overlay prefix to the one used by vendor, then change the OPi overlays to match?

[efectn]

Hmm. You're renaming the overlays coming from vendor kernel tree? What if they add an overlay? Eternal maintenance here? Isn't it easier to change the overlay prefix to the one used by vendor, then change the OPi overlays to match?

Yeah it's exactly easier than maintaining renaming patch. I thought changing the prefix from https://github.com/armbian/build/blob/master/config/sources/families/rockchip-rk3588.conf#L7 but i didn't do it because of it may be breaking change? If it's not, i can do it

[igorpecovnik]

but i didn't do it because of it may be breaking change?

If both legacy vendors uses the same overlay naming, then moving inside legacy might be a best way?
https://github.com/armbian/build/blob/master/config/sources/families/rockchip-rk3588.conf#L11

[efectn]

but i didn't do it because of it may be breaking change?

If both legacy vendors uses the same overlay naming, then moving inside legacy might be a best way? https://github.com/armbian/build/blob/master/config/sources/families/rockchip-rk3588.conf#L11

Doesn't old overlay prefix remain in armbianEnv.txt after we change it? It may be problem for someone who defreezed kernel updates and use some overlays. But i can change default prefix if you're still OK

[igorpecovnik]

Doesn't old overlay prefix remain in armbianEnv.txt after we change it?

I think this is set at build time and doesn't change. But can be wrong.

But i can change default prefix if you're still OK

Change it and use unchanged overlays as @rpardini suggested.

[rpardini]

It would be a "fixing change" ;-) (do it only for legacy)

[efectn]

It would be a "fixing change" ;-) (do it only for legacy)

Some overlays don't start with valid prefix (eg. rock-5b-hdmi1-8k). should i rename them still?

[igorpecovnik]

Some overlays don't start with valid prefix (eg. rock-5b-hdmi1-8k). should i rename them still?

You mean some overlays don't work with any prefix?

[efectn]

Some overlays don't start with valid prefix (eg. rock-5b-hdmi1-8k). should i rename them still?

You mean some overlays don't work with any prefix?

Yes, they don't start with rk3588. You can check new patch file in my last commit

[rpardini]

Damn. Turns out managing 2x boards on a vendor kernel based on only 1 of them is hard. Who knew? 🤣

@efectn take a look at config/bootscripts/boot-rockchip64-vendor.cmd which tries both with/without prefix and folder; maybe that can make it easier? I think patching to rename Radxa's is out of the question, it's way too much future work... question is how to name the OPi5 overlays so they work "too".

[efectn]

Damn. Turns out managing 2x boards on a vendor kernel based on only 1 of them is hard. Who knew? rofl

@efectn take a look at config/bootscripts/boot-rockchip64-vendor.cmd which tries both with/without prefix and folder; maybe that can make it easier? I think patching to rename Radxa's is out of the question, it's way too much future work... question is how to name the OPi5 overlays so they work "too".

I think OPi overlays should be compatible with overlay prefix since we're adding them and there are no maintenance problem.

Maybe we should add new if condition to boot-rockchip64-vendor.cmd that looks for overlays without prefix in overlays/ dir

[rpardini]

new if condition to boot-rockchip64-vendor.cmd

We're free to twist that vendor bootscript any way. It's only used by odroidm1, which does not have any overlays right now (it's separate-kernel is now pure mainline, sans-overlays, just waiting for rockchip64 to be de-shitted enough to be moved over).

[efectn]

new if condition to boot-rockchip64-vendor.cmd

We're free to twist that vendor bootscript any way. It's only used by odroidm1, which does not have any overlays right now (it's separate-kernel is now pure mainline, sans-overlays, just waiting for rockchip64 to be de-shitted enough to be moved over).

Looks like i mentioned false bootscript. All rockchip64, rk3588 family boards use boot-rockchip64.cmd. Is it good idea to make changes there? I think this is the easiest and most right way.

[rpardini]

Looks like i mentioned false bootscript. All rockchip64, rk3588 family boards use boot-rockchip64.cmd. Is it good idea to make changes there? I think this is the easiest and most right way.

Nah, don't touch boot-rockchip64.cmd -- that's the non-vendor version.
Instead, look at the odroidm1 board / family and see how I change the bootscript there, BOOTSCRIPT= ? memory fails me) and do the same/similar/whatever for the legacy branch of rk3588.

[efectn]

Looks like i mentioned false bootscript. All rockchip64, rk3588 family boards use boot-rockchip64.cmd. Is it good idea to make changes there? I think this is the easiest and most right way.

Nah, don't touch boot-rockchip64.cmd -- that's the non-vendor version. Instead, look at the odroidm1 board / family and see how I change the bootscript there, BOOTSCRIPT= ? memory fails me) and do the same/similar/whatever for the legacy branch of rk3588.

I saw some differences. For example vendor uses ramdisk_addr_r instead of load_addr var. Should i create new script?

[rpardini]

I saw some differences. For example vendor uses ramdisk_addr_r instead of load_addr var. Should i create new script?

As you wish. The ramdisk_addr_r uses values from u-boot, usually specified by vendor, instead of a fixed addr.

[efectn]

@rpardini @igorpecovnik can you review latest commit? I added elif condition for non-prefixed overlays. For example we're now able to use rk3588-pwm14-m1 overlay that's not compatible with Armbian's default prefix overlay.

[rpardini]

Seems isolated enough to only that vendor kernel, let's merge and see what happens...