Thanks for your work on getting this merged @lanefu!

 

Much appreciated.

This image works very well on R5S. Thanks.

Is there any plan to add support to R5C which is very close (Friendly Elec offers the same software for both devices) ? Or must I try to adapt?

R5C boots well on this image, and at first glance, the two points which are not working well are the names of ethernet ports, which can be fixed by an udev rule, and the Leds which remain off. This also can probably be fixed by Udev. How are the Leds handled on R5S ?

 

I just got the R5C last week, and built an image for it locally with a new CSC config file modified from R5S's, which corrected the name of ethernet ports. Also added a DTB overlay tailored from R5S's, the LEDs are also working now (but not WL since mine doesn't have one). So every thing looks good to me.

 

However my problem is that the edge kernel 6.6 is too new for ZFS 2.1 at this moment,  as I intended to use it as a router with ZFS backup function (zfs receive) and its deploy time window is limited. 😅

Edited December 5, 20232 yr by LiX

3 hours ago, LiX said:

However my problem now is that the edge kernel 6.6 is too new for ZFS 2.1

 

There are two paths from here:
- port device tree to LTS 6.1.y kernel (example)

- add more recent ZFS to the stable package base (this might not be the best idea as it affects many existing installations and I saw many corruption related bugs in recent ZFS versions)

21 hours ago, Igor said:

There are two paths from here:
- port device tree to LTS 6.1.y kernel (example)

- add more recent ZFS to the stable package base (this might not be the best idea as it affects many existing installations and I saw many corruption related bugs in recent ZFS versions)

 

Thank your for the guidance! I will try making a current branch build by the 1st approach in these two days. Since ZFS 2.2.2 has 6.6 supported, I have a feeling there's great chance it will appear in debian later this month, that will be my plan B. 😅

Edited December 6, 20232 yr by LiX

Hi all.
Has anyone managed to get the gpio pins working? I'm trying to use gps as timesource for my pi.
I tried connecting the GPS to UART5 (pins 3 and 5) and using pin 12 as a PPS input.
However, I saw that the serial ports are deactivated by default; how can I activate uart5?
then I tried with a serial-usb converter to test the functioning of the pps pin, but without success despite it being correctly configured from gpioinfo. 
 

gpiochip3 - 32 lines: 
        line  21:      unnamed  "pps-gpio0"   input  active-high [used]

any suggestions?

Thanks in advance

9 hours ago, tiziano000 said:

any suggestions?

Devices not installed on the board are generally enabled using device tree overlays.
I don't have your board, but I did this some time ago with an Orange Pi Zero.
Tutorial

 

I used UART1 and PA7

From the tutorial:

Add two lines to /boot/armbianEnv.txt to tell the Orange Pi Zero to use PA7 for PPS and uart1 for GPS NMEA messages

overlays=uart1 pps-gpio

param_pps_pin=PA7

You may not need to edit the file manually, you can add overlays from armbian-config, System, Hardware (you can see which overlays are available for your device).

Overlays may have different names for different boards and families.
If you can't find one for your board, it may be that nobody has created one yet.

Hi,
thanks for reply.
in armbian-config there is no hardware menu, i tried adding uart5 to /boot/armbianEnv.txt but it does not work. Digging in the device tree I found this:

                uart5 {

                        uart5m0-xfer {
                                rockchip,pins = <0x02 0x01 0x03 0xb2 0x02 0x02 0x03 0xb2>;
                                phandle = <0x8f>;
                        };

                        uart5m0-ctsn {
                                rockchip,pins = <0x01 0x1f 0x03 0xb0>;
                                phandle = <0x230>;
                        };

                        uart5m0-rtsn {
                                rockchip,pins = <0x02 0x00 0x03 0xb0>;
                                phandle = <0x231>;
                        };

                        uart5m1-xfer {
                                rockchip,pins = <0x03 0x13 0x04 0xb2 0x03 0x12 0x04 0xb2>;
                                phandle = <0x232>;
                        };
                };

In /dev there are 8 serials configured from ttyS0 to ttyS7, but when I try to read them they return input/output error.

 

9 hours ago, tiziano000 said:

in armbian-config there is no hardware menu

Are you logged in as root?  Your overlay_prefix=rockchip in the built image, so the menu should be visible under System then Hardware and should show all rockchip dtbo's.

This board is a work in progress, so probably there is stuff missing and not working.
Look in /boot/dtb/overlay to find available overlays. 

Drop the overlay_prefix and the .dtbo if you add them manually into armbianEnv.txt
Reboot to activate.

Those beginning with rockchip may work but I suspect that rockchip-RK3568B2 may be different there are no guarantees for a WIP board.
Perhaps the suppliers image has overlays that you could harvest.

Hi,
yes i'm logged in as root, under System menu there is "Dtc View/Edit/Compile device tree WIP".
 

On 12/17/2023 at 10:14 PM, schwar3kat said:

Look in /boot/dtb/overlay to find available overlays. 

In /boot/dtb/rockchip/overlay there are those file:
 

README.rockchip-overlays  rockchip-i2c1.dtbo             rockchip-pwm2.dtbo        rockchip-uart0.dtbo
rockchip-fixup.scr        rockchip-nanopi-r5s-leds.dtbo  rockchip-pwm9.dtbo        rockchip-uart0-rts_cts.dtbo
rockchip-i2c0.dtbo        rockchip-pwm1.dtbo             rockchip-spi-spidev.dtbo  rockchip-uart1.dtbo

decompiling rockchip-uart1.dtbo with dtc -I dtb -O dts rockchip-uart1.dtbo -o rockchip-uart1.dts , return this file:
 

/dts-v1/;

/ {

        fragment@0 {
                target = <0xffffffff>;

                __overlay__ {
                        status = "okay";
                        dma-names = "tx\0rx";
                };
        };

        __fixups__ {
                uart0 = "/fragment@0:target:0";
        };
};

How it's linked to uart1 hardware configuration?
 

 

On 12/17/2023 at 10:14 PM, schwar3kat said:

Perhaps the suppliers image has overlays that you could harvest.

Like this one? https://github.com/friendlyarm/kernel-rockchip/blob/nanopi6-v6.1.y/arch/arm64/boot/dts/rockchip/rk3568-nanopi5-common.dtsi

Thanks
 

Edited December 25, 20232 yr by tiziano000

On 12/5/2023 at 7:05 AM, LiX said:

I just got the R5C last week, and built an image for it locally with a new CSC config file modified from R5S's, which corrected the name of ethernet ports. Also added a DTB overlay tailored from R5S's, the LEDs are also working now (but not WL since mine doesn't have one). So every thing looks good to me.

@LiX, could you make your work available somewhere ? Either the full build or the things you have modified and some short indications to help me build, I am not familiar with armbian yet. I know the R5S version works on the R5C, but with the problems of the leds and the ethernet ports names.

On 1/11/2024 at 8:33 PM, Dysmas said:

@LiX, could you make your work available somewhere ? Either the full build or the things you have modified and some short indications to help me build, I am not familiar with armbian yet. I know the R5S version works on the R5C, but with the problems of the leds and the ethernet ports names.

LiX's Nanopi-R5C CSC stuff is in the Armbian build tree, but no automated community images are being published currently.

Unofficial unsupported R5C builds here:

https://refuge.armsurvivors.icu/lanefu/lanefu_24.2.0-trunk_Nanopi-r5c_bookworm_current_6.6.13/

 

https://refuge.armsurvivors.icu/lanefu/lanefu_24.2.0-trunk_Nanopi-r5c_sid_edge_6.7.1/

I'm happy to see the support for this board is progressing. 🤗

@tiziano000, where did you find an adapter to connect to the GPIO pins?
I have an SPI screen that I can't connect for the time being because of the strange (to me) spacing of the GPIO pins. 🤷‍♂️