CM3588-NAS: Go fully mainline by adopting the latest mainline changes from kernel 6.11 and U-Boot v2024.10

[ColorfulRhino]

BEFORE UPDATING YOUR CM3588 BOARD

Update procedure after this PR has been merged:

1. On your board, edit the file /boot/armbianEnv.txt: Find the line fdtfile="rockchip/rk3588-nanopc-cm3588-nas.dtb" and replace this line with fdtfile="rockchip/rk3588-friendlyelec-cm3588-nas.dtb", DO NOT REBOOT YET
2. Update your kernel as usual.

You only have to do this once, and only on existing installations. New installations and further update will not need any manual intervention.

Description

Important:

• This PR uses U-Boot v2024.10-rc3 which should release on Monday, August 19th. The tag needs to be available in the source: https://github.com/u-boot/u-boot/tags
• This PR is based on and depends on rockchip-rk3588: Bump edge kernel from 6.10 to 6.11-rc and current from 6.8 to 6.10 #7015 and can only be merged after that PR (NEEDS TO BE REBASED FIRST AFTER RK3588 6.11 HAS BEEN MERGED!)
• This PR should be merged at the same time as vendor kernel PR arm64: dts: rockchip: Adopt mainline naming for Friendlyelec CM3588 NAS linux-rockchip#220

Full mainline support for the CM3588 NAS has been added to kernel 6.11 🎉 Make use of this device tree going forward.

In addition, support for mainline U-Boot is also in the pipeline and is available in v2024.10-rc3. Use this as well.

How Has This Been Tested?

• edge: Successful boot without any obvious errors in dmesg with build command ./compile.sh BOARD=cm3588-nas BRANCH=edge BUILD_DESKTOP=no BUILD_MINIMAL=no EXPERT=yes KERNEL_CONFIGURE=no RELEASE=trixie
• vendor: Successful boot without any obvious errors in dmesg with build command ./compile.sh BOARD=cm3588-nas BRANCH=vendor BUILD_DESKTOP=no BUILD_MINIMAL=no EXPERT=yes KERNEL_CONFIGURE=no RELEASE=trixie

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
• My changes generate no new warnings
• Any dependent changes have been merged and published in downstream modules

[Kwiboo]

@ColorfulRhino looks like my U-Boot rk3xxx-2024.10 branch is a bit out of date, changed the U-Boot defconfig name from friendlyelec-cm3588-nas-rk3588_defconfig to cm3588-nas-rk3588_defconfig just before submitting patches upstream.
That name / build target was just merged into U-Boot master u-boot/u-boot@06dceeb the other day, and will be included in v2024.10-rc3 that is planned to be released on Monday next week.

Will push an updated rk3xxx-2024.10 branch to my U-Boot repo that include the merged defconfig name, sorry if this cause any inconvenience.

[ColorfulRhino]

@ColorfulRhino looks like my U-Boot rk3xxx-2024.10 branch is a bit out of date, changed the U-Boot defconfig name from friendlyelec-cm3588-nas-rk3588_defconfig to cm3588-nas-rk3588_defconfig just before submitting patches upstream. That name / build target was just merged into U-Boot master u-boot/u-boot@06dceeb the other day, and will be included in v2024.10-rc3 that is planned to be released on Monday next week.

Will push an updated rk3xxx-2024.10 branch to my U-Boot repo that include the merged defconfig name, sorry if this cause any inconvenience.

Oh, no worries! Thanks for the heads-up and thanks for your work!

I'll wait for the rc3 and change the defconfig name.

[ColorfulRhino]

This is now rebased on the latest main branch where #7015 has been merged. U-Boot tag v2024.10-rc3 is not out as of now though. v2024.10-rc3 is out now.
Can be reviewed, but only merge after checking that rc3 is available https://github.com/u-boot/u-boot/tags

[ColorfulRhino]

Since the dts name changed: As far as I know the FDT file location is saved in the board's /boot/armbianEnv.txt. Will this be able to be updated on existing installations when the kernel is updated? Or do we need to change the kernel update script for this to work? Or is there another method? Does anybody know? @igorpecovnik

[igorpecovnik]

Will this be able to be updated on existing installations when the kernel is updated?

No.

Or is there another method?

I developed "live patch service", but is not in function.

Two options:

• add command to BSP postinst script so it runs sed when bsp package is updated
• ignore and do nothing as this is not a supported target yet

[ColorfulRhino]

Will this be able to be updated on existing installations when the kernel is updated?

No.

Or is there another method?

I developed "live patch service", but is not in function.

Two options:

• add command to BSP postinst script so it runs sed when bsp package is updated
• ignore and do nothing as this is not a supported target yet

Thanks! This board does not have a BSP yet (neither does rk3588 unless there's something I don't know yet), so I'd rather not make it more complex. This is only a one time change anyway.
In this case, you're probably right, let's ignore this.

I'll update the main post in this PR to make users aware of the change. Edit: done!

[ColorfulRhino]

I have added a temprary help for people with existing installations, a pointer from the old dts to the new one, so they can migrate their /boot/armbianEnv.txt. This is just a temporary workaround though, will be finally removed in 6.12. This will make migration smoother since it gives people one kernel version to migrate, which should be enough.

[igorpecovnik]

I have added a temprary help

Updated on download pages https://www.armbian.com/nanopc-cm3588-nas/

[rpardini]

Hey @ColorfulRhino -- what's your opinion on the quality of the mainline DT? I mean, yours had very nice details like gpio line names, exposed pwm8 for buzzer, working USB & OTG, etc.

Ref the migration, I think that the board file rename is more impacting than the DT change: the bsp-cli pkg name will change, and existing users won't upgrade to the new pkg name. I personally wouldn't change the board file name right now.

[ColorfulRhino]

Updated on download pages https://www.armbian.com/nanopc-cm3588-nas/

Thanks! When someone downloads a fresh image, they will not be impacted by this though, since the fresh image (once this is merged and a new image is on the website).

what's your opinion on the quality of the mainline DT? I mean, yours had very nice details like gpio line names, exposed pwm8 for buzzer, working USB & OTG, etc.

It's good enough and has most things. USB seems to work and your buzzer is also exposed as far as I can see. I don't see any reason not to use it.

Ref the migration, I think that the board file rename is more impacting than the DT change: the bsp-cli pkg name will change, and existing users won't upgrade to the new pkg name. I personally wouldn't change the board file name right now.

Does this mean that with the name change, people won't get the updated kernel? What is shipped with the bsp-cli package?
As far as I understood, when the old dts is missing in the kernel, it won't boot at all after the new kernel update.
The best time for a name change was yesterday and the best time now is today imo. In the future it likely would be more painful 😄 Like @igorpecovnik said, this is in theory not a supported board.

[rpardini]

Does this mean that with the name change, people won't get the updated kernel? What is shipped with the bsp-cli package?

No -- with a board name change, the kernel pkg would still be the same.

The bsp-cli contains... stuff I wish it didn't... and essentially family_tweaks_bsp highlander-function and post_family_tweaks_bsp hooks stuff -- that is both $BRANCH and $BOARD specific, so changing BOARD changes the bsp-cli package name -- users will need to apt install the new bsp-cli to keep getting updates to it.

As far as I understood, when the old dts is missing in the kernel, it won't boot at all after the new kernel update.

Yeah but I see you have an #include based placeholder -- so that should be fine for now.

The best time for a name change was yesterday and the best time now is today imo. In the future it likely would be more painful 😄 Like @igorpecovnik said, this is in theory not a supported board.

Indeed. Feel free, I just wanted to point out Armbian's limitations ref package renames. Similar conundrum's happen if we try to change LINUXFAMILY -- that would impact kernel/headers/dtb pkg names and is the reason we have rk35xx and rockchip-rk3588 etc

[rpardini]

Cherry picked, built, tested.
Everything works as expected.
Some quality-of-life improvements needed:

• mainline u-boot (24.10-rc3) is defaulting to booting from sd/emmc first than nvme (needs a patch, I think)
  • this is really in comparison to the vendor u-boot; the previous mainline u-boot (from t6) didn't boot from nvme at all
• pwm-beeper on pwm8 needs CONFIG_INPUT_PWM_BEEPER in kernel config
• compared to @ColorfulRhino 's DT, this one loses the cooling map / trip for the pwm-fan -- not a problem

I'll try to send fixes for those, but really in the meantime this is IMHO good to merge.

[rpardini]

During testing I've found out that booting the vendor kernel using mainline u-boot doesn't work well. I guess the vendor kernel expects u-boot to do magic that mainline doesn't -- there's no nvme and no network.
I've brought back the vendor u-boot for vendor branch and it works again.

So I'd make mainline u-boot conditional for now.

I was driven to try vendor kernel due to some pcie crazy (nvme2 is detected sometimes, sometimes not).

[igorpecovnik]

What this needs to completion?

[rpardini]

we'll need to rebase around 6.11-rc5 that has a large DT Makefile change that affects our "overlay support" patch. That is not specific to this family, I think every family that has overlays will be affected.

Otherwise this is working fine -- can't both enum-pci-in-uboot-and-use-nvme-from-kernel but if booting from eMMC all is fine, at least, that I can detect.

@ColorfulRhino do you remember if the vendor u-boot scanned pci / enabled booting from NVMe? Because if it did, then this bump to mainline would break it; otherwise this is good to merge.