add support for the fine3399 with the Linux 6.1 about build

[rpardini]

• In kernel versions below 6.1, the initialization of GPIOs was accomplished using the functions of_get_gpio_flags and of_get_named_gpio_flags(), which are part of the gpiolib and Device Tree (DT) support. These functions allowed for the initialization of the st77xx series SPI small screens and displaying content on them. However, in the 6.3 kernel, these functions have been removed. Currently, I have not found a replacement method in higher versions......😓😓

If this is the case, adding a 6.1 would be a bandaid. Focus on mainline (6.11-rcX), make it work there, then backport to 6.6.y.

[Lemon1151]

Currently, I have submitted support for the fine3399 board in the main Armbian source code for Linux kernel versions 6.6 and 6.9.

[ColorfulRhino]

Since it's part of rockchip64, you can't. The goal is to support the most recent LTS and stable versions if at all possible.

Does the board come with such a st77xx screen or is it some kind of official addon (like the pcie hat for the Raspberry Pi)?
There is probably a good reason that support was removed 😅

[Lemon1151]

Since it's part of rockchip64, you can't. The goal is to support the most recent LTS and stable versions if at all possible.

Does the board come with such a st77xx screen or is it some kind of official addon (like the pcie hat for the Raspberry Pi)? There is probably a good reason that support was removed 😅

The board has an 8-pin SPI connector that can be used to connect small screens such as ST7735 and ST7789. In kernel versions below 6.1, the initialization of GPIOs was done using the functions of_get_gpio_flags and of_get_named_gpio_flags(), which are part of the gpiolib and Device Tree (DT) support. However, in the 6.3 kernel, these functions have been removed.

[igorpecovnik]

Since it's part of rockchip64, you can't.

3399 family does not have stock Rockchip "vendor" branch. If we are talking about vendor kernel, then it would be possible (but it is some work which we can't do) to add / merge
https://github.com/armbian/build/blob/main/config/sources/families/rockchip-rk3588.conf#L31-L40
into common rockchip64
https://github.com/armbian/build/blob/main/config/sources/families/include/rockchip64_common.inc#L27
or keep it on this level
https://github.com/armbian/build/blob/main/config/sources/families/rockchip64.conf

just an idea ...

[Lemon1151]

Since it's part of rockchip64, you can't.

3399 family does not have stock Rockchip "vendor" branch. If we are talking about vendor kernel, then it would be possible (but it is some work which we can't do) to add / merge https://github.com/armbian/build/blob/main/config/sources/families/rockchip-rk3588.conf#L31-L40 into common rockchip64 https://github.com/armbian/build/blob/main/config/sources/families/include/rockchip64_common.inc#L27 or keep it on this level https://github.com/armbian/build/blob/main/config/sources/families/rockchip64.conf

just an idea ...

My idea is to introduce a new "legacy" option (tentatively named as "legacy") in the KERNEL_TARGET section of the fine3399.csc file. Additionally, I plan to make the following changes:

Modify config/sources/families/rockchip64.conf:

I will add a new case in this configuration file to handle the "legacy" branch. This will include setting specific variables for the kernel version, Linux family, and the configuration file name tailored for the "legacy" branch.

    legacy)  
        declare -g KERNEL_MAJOR_MINOR="6.1"  
        declare -g LINUXFAMILY=rockchip64  
        declare -g LINUXCONFIG='linux-rockchip64-'$BRANCH  
        ;;   
esac

Add a New Kernel Configuration File:

In the config/kernel/ directory, I will create a new configuration file named linux-rockchip64-legacy.config. This file will contain the specific kernel configuration settings required for the "legacy" branch.

Prepare a Folder for DTS and Patches:

Under the patch/kernel/archive/ directory, I will create a new folder named rockchip64-6.1. This folder will be used to store the Device Tree Source (DTS) files and any necessary patches specific to the Fine3399 board, targeted for the Linux 6.1 kernel, under the "legacy" configuration.
In summary, these changes will enable support for a "legacy" kernel configuration targeting the Rockchip RK3399Pro SoC (used in the Fine3399 board), using Linux kernel version 6.1, with a dedicated kernel configuration file and a structured approach for managing device-specific DTS and patches.
Is this okay?

[igorpecovnik]

Is this okay?

Well, this would create some troubles as we had "legacy" target before and there are boards out there running that kernel (v4.4.y). If we push mainline based kernel over those, it won't be good. Remember, all those targets are being pushed to package repository. Name has to be different.

I don't understand the actual aim here - do you want to have:

• mainline based kernel 6.1 (cleaner but less functional)
• Rockchip kernel 6.1 (which supports hardware best)

In case you plan to use this 6.1 kernel https://github.com/armbian/linux-rockchip then it name has to be "vendor" instead of "legacy".

[Lemon1151]

• Rockchip kernel 6.1 (which supports hardware best)

https://github.com/armbian/linux-rockchip

What I desire is to have a 6.1 kernel based on the mainline, which is also the most optimized for my specific board (meaning I need to apply patches for the kernel drivers specific to my board), and be able to follow the updates for minor versions of the kernel as the mainline progresses. So, should I submit the relevant DTS (Device Tree Source) files and patches for my board to https://github.com/armbian/linux-rockchip?

[igorpecovnik]

I desire is to have a 6.1 kernel based on the mainline

Why then you don't go and start with 6.6. mainline based? It should be less work to fix what is missing then introducing 6.1 mainline based. Which we used to have, but dropped due to upgrade to 6.6.

the most optimized for my specific board

We never used 6.1 Rockchip with 3399 SoC (only older) but this is supposed to be best featured kernel for this SoC, maintained by Rockchip.

So, should I submit the relevant DTS (Device Tree Source) files and patches for my board to

I can't tell you what is the best for your case, I know too little. I am just telling you what are options.

[Lemon1151]

I desire is to have a 6.1 kernel based on the mainline

Why then you don't go and start with 6.6. mainline based? It should be less work to fix what is missing then introducing 6.1 mainline based. Which we used to have, but dropped due to upgrade to 6.6.

the most optimized for my specific board

We never used 6.1 Rockchip with 3399 SoC (only older) but this is supposed to be best featured kernel for this SoC, maintained by Rockchip.

So, should I submit the relevant DTS (Device Tree Source) files and patches for my board to

I can't tell you what is the best for your case, I know too little. I am just telling you what are options.

Thank you! If I really want to use the 6.1 kernel, but the Armbian mainline has moved on from supporting it, how can I proceed?"

[igorpecovnik]

If I really want to use the 6.1 kernel

I am suggesting you to think about and look into 6.6.y I don't understand why would 6.1 be so special that you need it and you can't backport functionality from 6.6.y (in case it only exists there). In both cases its some work and we have less then zero budget to help you in this.

[Lemon1151]

I am suggesting you to think about and look into 6.6.y I don't understand why would 6.1 be so special that you need it and you can't backport functionality from 6.6.y (in case it only exists there). In both cases its some work and we have less then zero budget to help you in this.

• • • In kernel versions below 6.1, the initialization of GPIOs was accomplished using the functions of_get_gpio_flags and of_get_named_gpio_flags(), which are part of the gpiolib and Device Tree (DT) support. These functions allowed for the initialization of the st77xx series SPI small screens and displaying content on them. However, in the 6.3 kernel, these functions have been removed. Currently, I have not found a replacement method in higher versions......😓😓

[igorpecovnik]

Oh, that is unfortunate and doesn't seems like a trivial problem :(

See this:
https://github.com/armbian/build/blob/main/config/sources/families/rk35xx.conf

linux-image-legacy-rk33xx would at least not make any conflicts. And leave / add / try also vendor 6.1.y kernel for this SoC. If not for you, someone else might find that useful / interesting.

Also if this is only for you, you might keep this at your fork and update it with our changes. When you got it working, sent a PR and if nobody opposes, we can merge it.

[Lemon1151]

Oh, that is unfortunate and doesn't seems like a trivial problem :(

See this:

https://github.com/armbian/build/blob/main/config/sources/families/rk35xx.conf

linux-image-legacy-rk33xx would at least not make any conflicts. And leave / add / try also vendor 6.1.y kernel for this SoC. If not for you, someone else might find that useful / interesting.

Also if this is only for you, you might keep this at your fork and update it with our changes. When you got it working, sent a PR and if nobody opposes, we can merge it.

Okay, thanks!

[ColorfulRhino]

Thank you! If I really want to use the 6.1 kernel, but the Armbian mainline has moved on from supporting it, how can I proceed?"

I basically see these two options:

• You try to actually solve the underlying issue and figure out a way to control the SPIs with GPIO functions that are available in latest Linux 6.10. Figure out why the functions you mentioned were cut and what the expected replacement is.
• You hack 6.1 into rockchip64 on your own Armbian fork and use this to build an image for your board.

Going back to older kernels is, in my opinion and as far as I understand the goals of the Armbian project, counterproductive since 95% of stuff is (better) supported in the latest kernels. Adding an additional kernel will also increase maintenance burden overall.

[Lemon1151]

Thank you! If I really want to use the 6.1 kernel, but the Armbian mainline has moved on from supporting it, how can I proceed?"

I basically see these two options:

• You try to actually solve the underlying issue and figure out a way to control the SPIs with GPIO functions that are available in latest Linux 6.10. Figure out why the functions you mentioned were cut and what the expected replacement is.
• You hack 6.1 into rockchip64 on your own Armbian fork and use this to build an image for your board.

Going back to older kernels is, in my opinion and as far as I understand the goals of the Armbian project, counterproductive since 95% of stuff is (better) supported in the latest kernels. Adding an additional kernel will also increase maintenance burden overall.

This is the removal notice for version 6.3: gpiolib: of: remove of_get_gpio_flags and of_get_named_gpio_flags()
There are no more users of these APIs in the mainline kernel, remove
them. This leaves of_get_named_gpio() as the only legacy OF-specific
API.However, using the of_get_named_gpio() function alone is not sufficient to initialize the st77xx small screen display that is connected via SPI.

[ColorfulRhino]

There are no more users of these APIs in the mainline kernel, remove them.

Have a look at how other screens or other boards do it :)
If it's specific to this screen, the easiest solution may be to get a different screen that is comfirmed to work on the latest Linux mainline kernel.

I'm sure you can figure out a way to make it work on Linux 6.10 👍

[Lemon1151]

There are no more users of these APIs in the mainline kernel, remove them.

Have a look at how other screens or other boards do it :)

If it's specific to this screen, the easiest solution may be to get a different screen that is comfirmed to work on the latest Linux mainline kernel.

I'm sure you can figure out a way to make it work on Linux 6.10 👍

At present, this board can only be compatible with and use the small screens of the st77xx series. The AvaotaA1 AI development board of Wei Dongshan also uses the small screens of the st77xx series, but only firmware with kernel 6.1 and below can be used normally on this board.