search

geerlingguy / sbc-reviews

Jeff Geerling's SBC review data - Raspberry Pi, Radxa, Orange Pi, etc.
MIT License
499 stars 11 forks source link

Orange Pi Compute Module 4 #26

Open geerlingguy opened 1 year ago

geerlingguy commented 1 year ago

DSC04090

Basic information

Linux/system information

# output of `neofetch`
        #####           orangepi@orangepicm4 
       #######          -------------------- 
       ##O#O##          OS: Orange Pi 1.0.0 Bookworm aarch64 
       #######          Host: Rockchip RK3566 Orange Pi CM4 Board 
     ###########        Kernel: 5.10.160-rockchip-rk356x 
    #############       Uptime: 4 mins 
   ###############      Packages: 511 (dpkg) 
   ################     Shell: bash 5.2.15 
  #################     Resolution: 1920x1080 
#####################   Terminal: /dev/pts/0 
#####################   CPU: (4) @ 1.296GHz 
  #################     Memory: 169MiB / 3922MiB 

# output of `uname -a`
Linux orangepicm4 5.10.160-rockchip-rk356x #1.0.0 SMP Mon Aug 28 19:23:33 CST 2023 aarch64 GNU/Linux

Benchmark results

CPU

Power

Disk

Built-in eMMC (SanDisk/Toshiba DV4032 HS200 eMMC 5.1)

Benchmark Result
fio 1M sequential read 153 MB/s
iozone 1M random read 132.24 MB/s
iozone 1M random write 131.52 MB/s
iozone 4K random read 10.52 MB/s
iozone 4K random write 16.06 MB/s

curl https://raw.githubusercontent.com/geerlingguy/pi-cluster/master/benchmarks/disk-benchmark.sh | sudo bash

Run benchmark on any attached storage device (e.g. eMMC, microSD, NVMe, SATA) and add results under an additional heading. Download the script with curl -o disk-benchmark.sh [URL_HERE] and run sudo DEVICE_UNDER_TEST=/dev/sda DEVICE_MOUNT_PATH=/mnt/sda1 ./disk-benchmark.sh (assuming the device is sda).

Also consider running PiBenchmarks.com script.

Network

iperf3 results:

Built-in 1 Gbps Ethernet

Built-in WiFi

GPU

Memory

tinymembench results:

Click to expand memory benchmark result ``` tinymembench v0.4.10 (simple benchmark for memory throughput and latency) ========================================================================== == Memory bandwidth tests == == == == Note 1: 1MB = 1000000 bytes == == Note 2: Results for 'copy' tests show how many bytes can be == == copied per second (adding together read and writen == == bytes would have provided twice higher numbers) == == Note 3: 2-pass copy means that we are using a small temporary buffer == == to first fetch data into it, and only then write it to the == == destination (source -> L1 cache, L1 cache -> destination) == == Note 4: If sample standard deviation exceeds 0.1%, it is shown in == == brackets == ========================================================================== C copy backwards : 1567.6 MB/s C copy backwards (32 byte blocks) : 1560.2 MB/s C copy backwards (64 byte blocks) : 1545.2 MB/s C copy : 2252.8 MB/s C copy prefetched (32 bytes step) : 1552.6 MB/s (0.1%) C copy prefetched (64 bytes step) : 2249.0 MB/s C 2-pass copy : 1347.0 MB/s C 2-pass copy prefetched (32 bytes step) : 1090.0 MB/s C 2-pass copy prefetched (64 bytes step) : 1149.7 MB/s (0.2%) C fill : 4398.3 MB/s (0.2%) C fill (shuffle within 16 byte blocks) : 4395.1 MB/s C fill (shuffle within 32 byte blocks) : 4399.2 MB/s C fill (shuffle within 64 byte blocks) : 4394.9 MB/s NEON 64x2 COPY : 2253.4 MB/s NEON 64x2x4 COPY : 2255.1 MB/s NEON 64x1x4_x2 COPY : 2254.5 MB/s NEON 64x2 COPY prefetch x2 : 2022.0 MB/s NEON 64x2x4 COPY prefetch x1 : 2059.9 MB/s NEON 64x2 COPY prefetch x1 : 2029.3 MB/s (0.1%) NEON 64x2x4 COPY prefetch x1 : 2058.6 MB/s --- standard memcpy : 2252.5 MB/s standard memset : 4397.3 MB/s --- NEON LDP/STP copy : 2255.9 MB/s NEON LDP/STP copy pldl2strm (32 bytes step) : 1495.6 MB/s NEON LDP/STP copy pldl2strm (64 bytes step) : 1988.3 MB/s NEON LDP/STP copy pldl1keep (32 bytes step) : 1755.5 MB/s NEON LDP/STP copy pldl1keep (64 bytes step) : 2287.6 MB/s NEON LD1/ST1 copy : 2254.0 MB/s NEON STP fill : 4398.2 MB/s NEON STNP fill : 3371.9 MB/s (0.5%) ARM LDP/STP copy : 2254.9 MB/s ARM STP fill : 4398.8 MB/s (0.1%) ARM STNP fill : 3373.7 MB/s (0.5%) ========================================================================== == Framebuffer read tests. == == == == Many ARM devices use a part of the system memory as the framebuffer, == == typically mapped as uncached but with write-combining enabled. == == Writes to such framebuffers are quite fast, but reads are much == == slower and very sensitive to the alignment and the selection of == == CPU instructions which are used for accessing memory. == == == == Many x86 systems allocate the framebuffer in the GPU memory, == == accessible for the CPU via a relatively slow PCI-E bus. Moreover, == == PCI-E is asymmetric and handles reads a lot worse than writes. == == == == If uncached framebuffer reads are reasonably fast (at least 100 MB/s == == or preferably >300 MB/s), then using the shadow framebuffer layer == == is not necessary in Xorg DDX drivers, resulting in a nice overall == == performance improvement. For example, the xf86-video-fbturbo DDX == == uses this trick. == ========================================================================== NEON LDP/STP copy (from framebuffer) : 194.7 MB/s (0.4%) NEON LDP/STP 2-pass copy (from framebuffer) : 184.5 MB/s NEON LD1/ST1 copy (from framebuffer) : 51.6 MB/s NEON LD1/ST1 2-pass copy (from framebuffer) : 51.1 MB/s ARM LDP/STP copy (from framebuffer) : 100.6 MB/s ARM LDP/STP 2-pass copy (from framebuffer) : 98.2 MB/s ========================================================================== == Memory latency test == == == == Average time is measured for random memory accesses in the buffers == == of different sizes. The larger is the buffer, the more significant == == are relative contributions of TLB, L1/L2 cache misses and SDRAM == == accesses. For extremely large buffer sizes we are expecting to see == == page table walk with several requests to SDRAM for almost every == == memory access (though 64MiB is not nearly large enough to experience == == this effect to its fullest). == == == == Note 1: All the numbers are representing extra time, which needs to == == be added to L1 cache latency. The cycle timings for L1 cache == == latency can be usually found in the processor documentation. == == Note 2: Dual random read means that we are simultaneously performing == == two independent memory accesses at a time. In the case if == == the memory subsystem can't handle multiple outstanding == == requests, dual random read has the same timings as two == == single reads performed one after another. == ========================================================================== block size : single random read / dual random read 1024 : 0.0 ns / 0.0 ns 2048 : 0.0 ns / 0.0 ns 4096 : 0.0 ns / 0.0 ns 8192 : 0.0 ns / 0.0 ns 16384 : 1.4 ns / 2.6 ns 32768 : 8.5 ns / 13.6 ns 65536 : 19.2 ns / 27.3 ns 131072 : 24.2 ns / 32.1 ns 262144 : 28.8 ns / 34.4 ns 524288 : 36.7 ns / 41.7 ns 1048576 : 108.7 ns / 152.8 ns 2097152 : 148.3 ns / 187.9 ns 4194304 : 168.8 ns / 199.9 ns 8388608 : 191.7 ns / 224.2 ns 16777216 : 205.1 ns / 241.0 ns 33554432 : 214.2 ns / 254.0 ns 67108864 : 219.7 ns / 262.5 ns ```

sbc-bench results

http://ix.io/4KDv

Phoronix Test Suite

Results from pi-general-benchmark.sh:

geerlingguy commented 1 year ago

Supposedly this board is compatible with CM4 IO boards. So far I have tested the PiTray mini and am getting no boot.

Boots just fine on the CM4 IO board, however!

It comes pre-flashed with some sort of Android release, going to see about flashing a different OS on it.

geerlingguy commented 1 year ago

Daaaang, the wiki has about 6 miles of instructions for flashing the eMMC, and all the screenshots are of RockChip's tool in Chinese: http://www.orangepi.org/orangepiwiki/index.php/Orange_Pi_CM4

I'm going to try How to burn a Linux image to eMMC using the dd command...

geerlingguy commented 1 year ago

Interestingly, you can just flash Orange Pi OS (I have 1.0.0 Bookworm) straight to a microSD card and the device will boot off it, even if the device has eMMC. Looks a lot like Armbian.

I wish the 'boot off microSD even though I have eMMC' trick worked on Raspberry Pi CM4 :P

Default user/pass is orangepi.

geerlingguy commented 1 year ago

Running sudo apt update you wind up grabbing sources off http://repo.huaweicloud.com/debian (just an interesting observation...).

geerlingguy commented 1 year ago

I copied the .img file from my Mac over to the microSD card:

scp Orangepicm4_1.0.0_debian_bookworm_server_linux5.10.160.img orangepi@10.0.100.247:~/

Then I erased the eMMC and wrote the image to it:

sudo dd bs=1M if=/dev/zero of=/dev/mmcblk0 count=1000 status=progress
sudo sync
sudo dd bs=1M if=Orangepicm4_1.0.0_debian_bookworm_server_linux5.10.160.img of=/dev/mmcblk0 status=progress
sudo sync

I shut down, pulled the microSD card, and rebooted, and...

TheOnion7 commented 1 year ago

I'm currently doing the exact same process than you . Very happy to see that you worked on that today! I'm a bit disappointed, I thought it would be as easy as a RaspPi... but it's definitely not. I bought the exact same model than you; OrangePI CM4 Control Module with the CM4 board, for a total of 133$ CAD. But as of now, can't boot on anything I flash except the weird Android OS that it's obviously made for a touch screen. I bought that device hoping to install OpenVoiceOS on it since my Raspberry PI 4 was so slow and that new module has very great hardware.... but nothing impressive yet..

Thanks for you work Jeff.

geerlingguy commented 1 year ago

Today when I tried popping the Orange Pi CM4 into my little 3D printed CM4 board carrier tray, I noticed the PCB is way too thick—it's the thickest of all the clones, maybe this is an 8-layer PCB?

UnKnoWn-Consortium commented 12 months ago

@TheOnion7 Given the inferior core mix in the RK3566 (4x Cortex-A55) I dun think it will be faster than a Pi 4B (4x Cortex-A72), not to mention software maturity and optimization of the latter. If performance is your priority you may have better luck with the Orange Pi 5 series. Its RK3588 is an octa-core part (4x Cortex-A76 + 4x Cortex-A55) with a newer P-core architecture plus a 6-TOPS NPU.

TheOnion7 commented 12 months ago

@TheOnion7 Given the inferior core mix in the RK3566 (4x Cortex-A55) I dun think it will be faster than a Pi 4B (4x Cortex-A72), not to mention software maturity and optimization of the latter. If performance is your priority you may have better luck with the Orange Pi 5 series. Its RK3588 is an octa-core part (4x Cortex-A76 + 4x Cortex-A55) with a newer P-core architecture plus a 6-TOPS NPU.

Thank You for your replay and all that information. I would gladly try it, but for now, I'm very disappointed. It's been several days I'm trying to simply boot from an SD Card on any existing possible OS and... no chance yet.

I tried probably anything I could try , I'm about to return it and see for another alternative for me. I have a RaspPi 4B, but it's not enough for what I'm trying to do. I'm currently looking at simple mini Intel PCs. Will see. haha

Thanks for the info

RicardoCst commented 10 months ago

Hi @geerlingguy ,

Can I ask if you have tried the Orange Pi Compute Module 4 in the Radxa Taco?

RicardoCst commented 10 months ago

@geerlingguy

I tested it with the Radxa Taco and it works, no more buying expensive boards from Radxa...

toastmanAu commented 10 months ago

Running sudo apt update you wind up grabbing sources off http://repo.huaweicloud.com/debian (just an interesting observation...).

This is somewhat related to your "looks like Armbian" observation. Their image builder is an Armbian fork complete with the exact same default config file for building images. Apt mirror can be set to "China" for Great Firewall of China friendly apt sources. Armbian uses two Chinese universities for their mirrors and Opi use a Chinese commercial cloud storage service. I use both image builders and if you pass "" to the apt mirror it uses your default sources. My resultant images update from ports.ubuntu.com by default instead of Huawei (Ubuntu images ofc).

AlekseyMamontov commented 9 months ago

Good afternoon, someone managed to assemble a core for this board higher -> 6., because on the manufacturer’s website there is only 5.10 and it’s somehow crooked.

In the main kernel there is not even .dts (of this board) for assembling DT.

AceAsket commented 9 months ago

@geerlingguy

I tested it with the Radxa Taco and it works, no more buying expensive boards from Radxa...

For radxa taco not working nvme

jpiccari commented 9 months ago

Good afternoon, someone managed to assemble a core for this board higher -> 6., because on the manufacturer’s website there is only 5.10 and it’s somehow crooked.

In the main kernel there is not even .dts (of this board) for assembling DT.

I'm kinda working on it as a side project. It is actually very very similar to the Radxa CM3 IO which seems to have great support in current linux kernels. I was able to boot and run for a few seconds with an OS built for the radxa board but the opi cm4 quickly overheats and continuously reboots. I'm working on comparing the .dts on the stock opi cm4 to the .dts for the radxa board. I'll keep you posted but its a nights and weekends (when I feel like it) sort of thing.

AlekseyMamontov commented 9 months ago

I launched it on kernel 6.8, everything works without problems (you can take the device tree from RK3566 OrangePI 3b and remove unnecessary ones), except for SPI3 for some reason PINCTRL does not switch the pins responsible for SPI to alternative functions (probably problems in the rockchip driver, there is chaos in the code )) )

Знімок екрана з 2024-02-05 11-34-48

AlekseyMamontov commented 9 months ago

Знімок екрана з 2024-02-03 16-39-31

jpiccari commented 9 months ago

What is the filename for that DTS? I couldn't find it when browsing the source files :(

AceAsket commented 9 months ago

I launched it on kernel 6.8, everything works without problems (you can take the device tree from RK3566 OrangePI 3b and remove unnecessary ones), except for SPI3 for some reason PINCTRL does not switch the pins responsible for SPI to alternative functions (probably problems in the rockchip driver, there is chaos in the code )) )

Знімок екрана з 2024-02-05 11-34-48

Nmve worked?

AlekseyMamontov commented 9 months ago

What is the filename for that DTS? I couldn't find it when browsing the source files :( https://github.com/orangepi-xunlong/linux-orangepi/blob/orange-pi-6.6-rk35xx/arch/arm64/boot/dts/rockchip/rk3566-orangepi-3b.dts

AlekseyMamontov commented 9 months ago

Taking into account the old device tree https://github.com/orangepi-xunlong/linux-orangepi/blob/orange-pi-5.10-rk35xx/arch/arm64/boot/dts/rockchip/rk3566-orangepi-cm4.dts

AlekseyMamontov commented 9 months ago

I launched it on kernel 6.8, everything works without problems (you can take the device tree from RK3566 OrangePI 3b and remove unnecessary ones), except for SPI3 for some reason PINCTRL does not switch the pins responsible for SPI to alternative functions (probably problems in the rockchip driver, there is chaos in the code )) ) Знімок екрана з 2024-02-05 11-34-48

Nmve worked?

This was not necessary, I did not check.

It’s clear that Rockchip are assholes and it’s probably not worth buying devices based on their chips, they stopped supporting their chips in the Linux kernel a couple of years ago. https://github.com/rockchip-linux/kernel

AlekseyMamontov commented 9 months ago

Everything is built on the basis two files.

include "rk3566.dtsi"

include "rk356x.dtsi"

rk3566-orangepi-cm4.zip

AceAsket commented 9 months ago

I launched it on kernel 6.8, everything works without problems (you can take the device tree from RK3566 OrangePI 3b and remove unnecessary ones), except for SPI3 for some reason PINCTRL does not switch the pins responsible for SPI to alternative functions (probably problems in the rockchip driver, there is chaos in the code )) ) Знімок екрана з 2024-02-05 11-34-48

Nmve worked?

This was not necessary, I did not check.

It’s clear that Rockchip are assholes and it’s probably not worth buying devices based on their chips, they stopped supporting their chips in the Linux kernel a couple of years ago. https://github.com/rockchip-linux/kernel

I tested nvme on 5.10 and it works on the native board for cm4 from orange pi, but not on taco

AlekseyMamontov commented 9 months ago

I launched it on kernel 6.8, everything works without problems (you can take the device tree from RK3566 OrangePI 3b and remove unnecessary ones), except for SPI3 for some reason PINCTRL does not switch the pins responsible for SPI to alternative functions (probably problems in the rockchip driver, there is chaos in the code )) ) Знімок екрана з 2024-02-05 11-34-48

Nmve worked?

This was not necessary, I did not check. It’s clear that Rockchip are assholes and it’s probably not worth buying devices based on their chips, they stopped supporting their chips in the Linux kernel a couple of years ago. https://github.com/rockchip-linux/kernel

I tested nvme on 5.10 and it works on the native board for cm4 from orange pi, but not on taco

Check if this is enabled in the device tree for your device and .config file Also note that on Github the rockchip branch is different from the main one... In general, advice to everyone who wants to buy motherboards with a rockchip chip - don’t do it, unless of course you want to waste a lot of time looking for bugs, etc.

AlekseyMamontov commented 9 months ago

http://www.orangepi.org/orangepiwiki/index.php/Orange_Pi_CM4#Linux_SDK.E2.80.94.E2.80.94orangepi-build_instructions

**The branch mentioned here is not the same thing as the branch of the orangepi-build source code, please do not confuse it. This branch is mainly used to distinguish different kernel source code versions.

Currently, the Linux5.10 bsp kernel provided by RK is defined as the legacy branch. If the mainline kernel is supported in the future, a current branch will be added.**

It looks like Rockchip has leaked its RK3566 chips to board makers on the cheap. They leaked these boards to users)) As a result, you bought new boards with a chip that has been discontinued and is supported by user enthusiasm. The technical description of the chip is minimally available.

Rockchip_RK3566_Datasheet_V1.1.pdf

jpiccari commented 9 months ago

Everything is built on the basis two files.

include "rk3566.dtsi" #include "rk356x.dtsi" rk3566-orangepi-cm4.zip

I tried it out and it works but drops a lot of support for things like eMMC, SD cards, wifi/bt, etc. I also started working on a dts that works with mainline linux and it works pretty good based on my testing. I've never written dts before so I'm sure there are basic mistakes being made but most things I need are working. The major exception is onboard wifi/bt. The sdio initialize for the wifi chip fails most of the time and randomly works other times. Even when initialization works the drives/firmware don't load properly. I think there is some kind of clock issue going on but I'm not really sure. rk3566-orangepi-cm4.dts.txt

AlekseyMamontov commented 9 months ago

.config.zip Don’t forget to compile and edit DT without a configured .config - meaningless work. Because in the tree you can specify any devices, but if there are no drivers in the assembled kernel. None of this makes sense.))

AlekseyMamontov commented 9 months ago

wireless_wlan: wireless-wlan { compatible = "wlan-platdata"; rockchip,grf = <&grf>; wifi_chip_type = "ap6256"; WIFI,host_wake_irq = <&gpio0 RK_PD6 GPIO_ACTIVE_HIGH>; status = "okay"; };

wireless_bluetooth: wireless-bluetooth {
    compatible = "bluetooth-platdata";
    clocks = <&rk809 1>;
    clock-names = "ext_clock";
    uart_rts_gpios = <&gpio2 RK_PB5 GPIO_ACTIVE_LOW>;
    pinctrl-names = "default", "rts_gpio";
    pinctrl-0 = <&uart1m0_rtsn>;
    pinctrl-1 = <&uart1_gpios>;
    BT,reset_gpio    = <&gpio2 RK_PB7 GPIO_ACTIVE_HIGH>;
    BT,wake_gpio     = <&gpio2 RK_PC1 GPIO_ACTIVE_HIGH>;
    BT,wake_host_irq = <&gpio2 RK_PC0 GPIO_ACTIVE_HIGH>;
    status = "okay";
};
jpiccari commented 8 months ago

Maybe this is nothing but I noticed on the orangepi provided image the mmc2/sdio (used by wifi/bt module) frequency does not match the requested frequency.

orangepi@orange:~$ sudo cat /sys/kernel/debug/mmc2/ios
clock:          150000000 Hz
actual clock:   148500000 Hz
vdd:            21 (3.3 ~ 3.4 V)
bus mode:       2 (push-pull)
chip select:    0 (don't care)
power mode:     2 (on)
bus width:      2 (4 bits)
timing spec:    6 (sd uhs SDR104)
signal voltage: 1 (1.80 V)
driver type:    0 (driver type B)

Notice the 1.5Mhz difference in actual and advertised clock frequencies. This seemed a bit sus so I tried lowering the max clock frequency in my modified dt against mainline linux and it now gets detected super reliably. However, I noticed now the actual clock frequency is down to about 50Mhz.

root@OpenWrt:/# cat /sys/kernel/debug/mmc2/ios
clock:          145000000 Hz
actual clock:   50000000 Hz
vdd:            21 (3.3 ~ 3.4 V)
bus mode:       2 (push-pull)
chip select:    0 (don't care)
power mode:     2 (on)
bus width:      2 (4 bits)
timing spec:    6 (sd uhs SDR104)
signal voltage: 1 (1.80 V)
driver type:    0 (driver type B)

Still can't get wifi/bt to work though. I have the drivers (I think) compiled and I've tried symlinking the firmware to the right location but it just fails to load and returns this no matter what I do. Maybe I'm using the wrong drivers or set the wrong device compatibility? Hard to say but on the orangepi image it is using some android driver which I find a little strange and it advertises as bcm43456 so it seems like that isn't exactly the issue. Maybe next I'll try copying over the firmware from the orangepi image but I'd really like to be able to find a source for it.

root@OpenWrt:/# dmesg | grep -iE 'mmc2|sdio|brcm'
[    0.832791] mmc_host mmc2: card is non-removable.
[    0.847037] mmc_host mmc2: Bus speed (slot 0) = 375000Hz (slot req 400000Hz, actual 375000HZ div = 0)
[    0.975579] mmc_host mmc2: Bus speed (slot 0) = 50000000Hz (slot req 145000000Hz, actual 50000000HZ div = 0)
[    0.995438] mmc2: new ultra high speed SDR104 SDIO card at address 0001
[   12.641734] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43456-sdio for chip BCM4345/9
[   13.924217] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (1000000): clkctl 0x50
[   14.934260] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (1000000): clkctl 0x50
AlekseyMamontov commented 8 months ago

Maybe this is nothing but I noticed on the orangepi provided image the mmc2/sdio (used by wifi/bt module) frequency does not match the requested frequency.


You have chosen the path of experimentation))

If you assemble on the board itself

In principle the steps are simple .

  1. Place the .config file in the folder with the kernel sources
  2. Run make menuconfig. Connect additional drivers that you need.
  3. Then in the folder arch/arm64/boot/dts edit the device tree file of your board.
  4. run build make -J4
  5. Then definitely make modules_install (when building the kernel for the first time or when making changes to the kernel itself)
  6. Then make install Check the /boot folder
  7. Do not forget that you have a U-boot bootloader. And copy the image of the new kernel Image to the /boot folder from the arch/arm64/boot/ folder B check the .dtb file in the /boot folder corresponds to what was collected in the arch/arm64/boot/dts folder then. Reboot))

And now you can experiment with assembling the device tree.

In general, you can change parameters, add and remove devices from the device tree. And then by running just make -j4 you can rebuild it (with the kernel assembled, only updated files are rebuilt, that is, the device tree file). And then from the /arch/arm64/boot/dts/ folder you can copy it to the /boot folder and reboot and watch your experiments))

And if you change something in the drivers (in the sources), then you update the Image file in the boot folder

jpiccari commented 8 months ago

Thanks for the tip but I already know how to compile the kernel of device. :) My goal is slightly different, I don't care to rely on questionable vendor-provided binaries for my bootloader, kernel, and userland. Instead my focus is on replace all code on the board with patches from the official sources. I have that 90% working at this point. I have some more testing to do (specifically nvme ssds and see if I can't get wifi working) but hope to get patches into the official versions of u-boot and linux kernel so that we can have support for all OSes without needing to rely on OrangePi to provide distros.

I'll send an update once I get there.

AlekseyMamontov commented 8 months ago

Wifi

wireless_wlan: wireless-wlan { compatible = "wlan-platdata"; rockchip,grf = <&grf>; wifi_chip_type = "ap6256"; WIFI,host_wake_irq = <&gpio0 RK_PD6 GPIO_ACTIVE_HIGH>; status = "okay"; };

Sfinx commented 7 months ago

Anybody seeing this too ?

http://www.orangepi.org/orangepibbsen/forum.php?mod=viewthread&tid=147478

Looks like h/w issue that just ignored by orange

jpiccari commented 7 months ago

Anybody seeing this too ?

http://www.orangepi.org/orangepibbsen/forum.php?mod=viewthread&tid=147478

Looks like h/w issue that just ignored by orange

I see something similar. When uart console is connected and power is cycled by usb-c port, the device does not boot and the power light stays sort of half lit. Not sure if related but felt reminiscent. Good luck.

JL2010 commented 6 months ago

@jpiccari, not sure if this helps your efforts, but I did find this device tree rk3566-orangepi-cm4.dts: https://github.com/orangepi-xunlong/linux-orangepi/blame/orange-pi-5.10-rk35xx/arch/arm64/boot/dts/rockchip/rk3566-orangepi-cm4.dts

Probably better to start with that rather than trying to modify the orangepi-3b one? which was mentioned here

It's in Orange Pi's orange-pi-5.10-rk35xx branch for kernel 5.10 only, don't know why it's not available in any other 5.x or 6.x branch - although if I'm following things correctly, probably because of some specific vendor support from Rockchip that's only available in a forked 5.10 kernel source? I'm slowly trying to unravel the world of building (and not just using) embedded linux, so please bear with me as I stumble across the terminology.

I'm going to take that device tree and see if I can figure out how to build Armbian for the OPi CM4, I think this commit could serve as a guide: https://github.com/armbian/build/commit/05a72b8954e932089d4867b55da0d353dc4ba1ac

AlekseyMamontov commented 6 months ago

Rockchip, Nvidia (Jetson Nano) are assholes, they release a product, and then a year later they refuse to support their products with old kernels maximum 5.10 no higher...

In short, you shouldn't buy their products... unless you want to spend a lot of time looking for problems...

jpiccari commented 6 months ago

I’ve seen all the branches. I have everything working correctly (or as correctly as possible) except WiFi/bluetooth and with a dts that could be integrated into the Linux kernel (unlike the hacky ones that have been shared that rely on non-standard vendor drivers). I’ve tested it with the latest kernel releases and it seems mostly stable (although with some odd sdio clock issue).

you will never get WiFi to work without correct drivers and firmware which I’ve not been able to find (even when copying firmware from the orange pi images). The dts in their repo is obfuscating some driver magic and it is not obvious or time efficient for me to jump into what a correct dts should look like.

if you want I can see if I can get the dts upstreamed into mainline Linux as-is and maybe get some help refining a couple things. But overall it seems more valuable to just go buy a rpi cm4 😬 digikey has them at MSRP last I checked.

AlekseyMamontov commented 6 months ago

Until your board appears in this list https://github.com/torvalds/linux/tree/master/arch/arm64/boot/dts/rockchip it's not worth buying

the Armbian team seems to be trying hard and writing in their newsletters Most popular Rokchip SoC is getting vendor kernel upgrade to 6.1.y with a focus on delivering a fully functional desktop experience.

padiazg commented 1 month ago

I'm starting to play with two of these boards to update some of the kubernetes clusters I run for fun/learning/testing. They are cluster hats with several Banana pi M2 Zeros as nodes, the cheapest and most updated hardware I can use with this setup, and that can run k3s. So far so good