Search the Community

A lot. Just out of my head what I'm willing to part with. What I can miss. KM6 TVbox, OrangePi3, RPiZeroW, Tinker Board, Rock64, Atomic Pi. Only for a good price the Khadas VIM2 and Jetson Nano. RPi2B very maybe. I love that one too much, so only +50 euro for that one. I'll have to take a lok at what else I've got.

https://imola.armbian.com/archive/rock64/ ???

For anyone reading this in the future, https://imola.armbian.com/dl/archive/rock64/ is the url. Everything up to and including the version I had was also added to https://armbian.hosthatch.com/archive/rock64/archive/. But the new place even has Armbian_21.08.1_Rock64_bullseye_current_5.10.60 !!! Truly we are living in the blessedest of times!

This message is on-topic, but for an unknown reason, it is not possible for me to create a message in Help wanted. So I post here. I have used Armbian for two years, I think, on several devices, and I have given some money to support it. Thanks for the job. I recently upgraded to the last version with Debian 11. Everything fine but one point which is probably not a bug, that's why I don't post in "bugs". I use Unbound which is the heart of my soft. And I use a python script which is loaded by Unbound. Until now, there was no problem. With the last version, I ran in several read problems. The first reason I found is apparmor, which prevented the script to open a module in /usr/local/lib. I removed apparmor and this solved this problem and another one. But when the scripts must open (read) /home/rock64/unbound.conf, I get a permission denied, even if the file and the directory has 777 permission. I made a lot of tests. I can read the file if copied on some directories, and not in others. I don't understand the logic. I suppose there is another program like apparmor, but I cannot find it. What can prevent Unbound from reading a 777 file ? Thanks if you have an idea.

First, thanks for the tips. It's good to have someone to boune ideas off of. The extcon is the physical port (re: "external connection"), in this case a Typc-C connector on our board. It notifies the phy core that then initiates the callback to the workqueue in the dwc3-rockchip driver. At least that's my understanding. You have to reference the extcon in the usbdrd3 proprerty, which is the rockchip dwc3 driver (the dwc3-simple driver doesn't directly reference an extcon), so it can attach the extcon to the phy. But apparently you also need to attach it to the tcphy0 property, or so it seems based on some other DTS examples. It's very confusing. The extcon driver in this case is fusb302. There is one of those under drivers/usb/typec/tcpm that comes from Google. But that doesn't seem to work no matter what I do with its dts config. So I forward ported the fusb302 driver from the BSP, which comes from rockchip. With some added debug I can see connection events and the callback to the workqueue function. Turns out my version of that patch came later and does not have the call to dwc3_phy_setup() - which is why my port compiled without the core.c/h patch. Of course, that may also be the reason it doesn't work. I ported it from a 4.4 kernel. The ayufan-rock64 kernel is not something I can drop on this device. We're bumped to 5.15.14 (upstream release + custom patches, most if not all are from the net) at the moment and it's tied to the specific u-boot we have. It also probably wouldn't support our display, though I have a serial console so maybe that doesn't matter. My changes are simple, really. They consist of choosing a fusb302 driver: Google's (CONFIG_TYPEC_FUSB302, plus some other typec drivers which I think are required) or Rockchips (CONFIG_FUSB_30X, which is part of my port and is standalone) a dwc3-* driver: dwc3-of-simple (aka CONFIG_USB_DWC3_OF_SIMPLE) or dwc3-rockchip (CONFIG_USB_DWC3_ROCKCHIP, which I've added to the Kconfig). We run as an embedded board so nearly everything is statically compiled, but I make the fusb driver a module and manually load it after boot. This way if any of the drivers lock up it won't happen until the fusb is loaded and I plug something in (or left something plugged in from the last test). Then the DTS is updated to match those selections. There are a few places that this matters. Note that what follows is what I have, but it obviously isn't working. When using the stock drivers (Google fusb302, dwc3-of-simple), it looks like this: &i2c4 { status = "okay"; fusb0: fusb30x@22 { // Google fusb compatible = "fcs,fusb302"; fcs,int_n = <&gpio1 2 GPIO_ACTIVE_HIGH>; interrupt-parent = <&gpio1>; interrupts = <RK_PA2 IRQ_TYPE_LEVEL_LOW>; pinctrl-names = "default"; pinctrl-0 = <&fusb0_int>; vbus-supply = <&vcc5v0_typec0>; status = "okay"; connector { compatible = "usb-c-connector"; data-role = "dual"; label = "USB-C"; op-sink-microwatt = <1000000>; power-role = "dual"; sink-pdos = <PDO_FIXED(5000, 2500, PDO_FIXED_USB_COMM)>; source-pdos = <PDO_FIXED(5000, 1400, PDO_FIXED_USB_COMM)>; try-power-role = "sink"; ports { #address-cells = <1>; #size-cells = <0>; port@0 { reg = <0>; usbc_hs: endpoint { remote-endpoint = <&u2phy0_typec_hs>; }; }; port@1 { reg = <1>; usbc_ss: endpoint { remote-endpoint = <&tcphy0_typec_ss>; }; }; }; }; }; }; &u2phy0 { status = "okay"; extcon = <&fusb0>; // otg-vbus-gpios = <&gpio1 3 GPIO_ACTIVE_HIGH>; u2phy0_otg: otg-port { // phy-supply = <&vcc5v0_typec0>; status = "okay"; }; u2phy0_host: host-port { phy-supply = <&vcc5v0_typec0>; status = "okay"; }; port { u2phy0_typec_hs: endpoint { remote-endpoint = <&usbc_hs>; }; }; }; &usbdrd3_0 { status = "okay"; }; &usbdrd_dwc3_0 { status = "okay"; dr_mode = "peripheral"; }; &tcphy0 { status = "okay"; extcon = <&fusb0>; }; &tcphy0_usb3 { status = "okay"; extcon = <&fusb0>; port { tcphy0_typec_ss: endpoint { remote-endpoint = <&usbc_ss>; }; }; }; When using the Rockchip fusb302 and dwc3 driver it looks like this: &i2c4 { status = "okay"; fusb0: fusb30x@22 { compatible = "fairchild,fusb302"; vbus-5v-gpios = <&gpio0 6 GPIO_ACTIVE_HIGH>; int-n-gpios = <&gpio1 2 GPIO_ACTIVE_HIGH>; fusb302,role = "ROLE_MODE_DRP"; fusb302,try_role = "ROLE_MODE_DRP"; reg = <0x22>; pinctrl-names = "default"; pinctrl-0 = <&fusb0_int>; status = "okay"; }; }; &u2phy0 { status = "okay"; otg-vbus-gpios = <&gpio1 3 GPIO_ACTIVE_HIGH>; u2phy0_otg: otg-port { status = "okay"; }; u2phy0_host: host-port { phy-supply = <&vcc5v0_typec0>; status = "disabled"; }; }; &usbdrd3_0 { status = "okay"; extcon = <&fusb0>; }; &usbdrd_dwc3_0 { status = "okay"; extcon = <&fusb0>; dr_mode = "otg"; /* USB 3.0 */ maximum-speed = "super-speed"; phys = <&tcphy0_usb3>; phy-names = "usb3-phy"; }; &tcphy0 { status = "okay"; extcon = <&fusb0>; resets = <&cru SRST_UPHY0>, <&cru SRST_UPHY0_PIPE_L00>, <&cru SRST_P_UPHY0_TCPHY>, <&cru SRST_A_USB3_OTG0>; reset-names = "uphy", "uphy-pipe", "uphy-tcphy", "usb3-otg"; }; &tcphy0_usb3 { status = "okay"; }; I'll try adding that dwc3_phy_setup() call just for grins to see what happens. But I'm not sure it matters if I try to boot in peripheral mode to start with. I think it only matters if I'm trying to use OTG. I'm trying to use peripheral mode only right now just to get device mode working in any way possible (but preferrably at least at HS).

Thanks for sharing the link, that was an interesting read. Seeing the patches jogged my memory a bit. The 'dwc3_rockchip_otg_extcon_evt_work' function is what handles the actual mode switching. Its execution is scheduled using a work queue via the dwc3_rockchip_*_notifier functions which are based on some extcon notifier. I have almost no understanding of what extcon is nor how the notifiers work and how they are ultimately connected to the physical switch. It is possible the physical switch manipulates a basic resistance circuit to force the CC pin resistance to the required amount to force UFP/DFP modes. Once the resistance is forced the dwc3 controller generates IRQs that inform the driver via notifiers? I am guessing here, but it makes sense because the OTG port is wired to a type-A connector which means the physical switch could control the CC pin resistances without interfering since CC pin can't be wired to a type-A connector. You are right about the dwc3 controller needing to be reset at the same time, the patch thread discusses this requirement. In fact, I think it was this very requirement that led to them stripping the 'static' keyword from the 'dwc3_phy_setup' function in dwc3/core.c so it could be called from their new dwc3/dwc3-rockchip.c driver. It was this change in particular that caused the immediate NAK for upstream. I presume that if your port attempts lack the required logic to reset the dwc3 controller managed in core.c that is likely why the work queue item is hanging or locking up the system? What kernel version and from what source did you port the driver? If it isn't from the 'legacy' branch repo used by Armbian it might be worth trying again with the following version which I can confirm has functioning mode switch logic: https://github.com/ayufan-rock64/linux-kernel tag:4.4.202-1237-rockchip-ayufan Are you possibly running into issues getting back to USB2 HS peripheral mode because you still have ported code compiled in? I ask because I took Terry's DTS patch from above and integrated it into the Armbian build for a linux-5.10.y 'current' branch kernel (specifically 5.10.92-rockchip64) and have the peripheral mode operational as long as 'dr_mode = "peripheral"' is set in the built DTB as shown in the patch. I have tested it with mass storage, hid and ncm gadgets, all working as expected.

hello were you able to solve it somehow? I have the same problems on the desktop , with buster and a rock64 , i have black horizontal lightning bolts every x seconds

No, they are here: https://imola.armbian.com/dl/rock64/archive/ All changes regarding new support rules are WIP since we lack people, time and better organisation. There are mistakes here and there. Also we haven't been able to speak with all people that want to help. And after they join, we need to work overtime on overtime to support them. Even we try to keep this project under control its still huge. And expensive - end users wishes and demands (which creates stress and just more damages with negative effect on help) never stops If you can't find image you need - build one. https://docs.armbian.com/Developer-Guide_Build-Preparation/ @kehrnal Maintainer is not a technical demanding role:

One thing I found particularly concerning is that https://armbian.hosthatch.com/archive/rock64/archive/ goes up to `Armbian_21.02.3_Rock64_buster_current_5.10.21.i..> 09-Mar-2021 11:32` while I previously, on `26-Aug-2021` downloaded `Armbian_21.08.1_Rock64_buster_current_5.10.60.img.xz` Are the newer images gone?

looking at https://github.com/150balbes/build/blob/station-x2/config/sources/families/rockchip64.conf if [[ $BOARD == station-p2 || $BOARD == station-m2 ]]; then BOOTSOURCE='https://github.com/150balbes/u-boot-rk' BOOTBRANCH='branch:rk356x' BOOTPATCHDIR="u-boot-station-p2" KERNELSOURCE='https://github.com/150balbes/rockchip-kernel' KERNELBRANCH='branch:rk35xx' KERNELPATCHDIR='station-p2-'$BRANCH LINUXCONFIG='linux-station-p2-'$BRANCH LINUXFAMILY=station-p2 else KERNELSOURCE='https://github.com/ayufan-rock64/linux-kernel' KERNELBRANCH='tag:4.4.202-1237-rockchip-ayufan' KERNELPATCHDIR='rockchip64-'$BRANCH fi can anyone tell me where this "station-m2" board name comes from? looking at this file https://github.com/150balbes/build/blob/station-x2/config/boards/station-m2.wip # Rockchip RK3566 BOARD_NAME="Station M2" BOARDFAMILY="rockchip64" BOOTCONFIG="firefly-rk3568_defconfig" KERNEL_TARGET="legacy,current,edge" FULL_DESKTOP="yes" BOOT_LOGO="desktop" BOOT_FDT_FILE="rockchip/rk3566-firefly-roc-pc.dtb" SRC_EXTLINUX="yes" SRC_CMDLINE="console=uart8250,mmio32,0xfe660000 console=tty0" ASOUND_STATE="asound.state.station-m2" IMAGE_PARTITION_TABLE="gpt" the string "station-m2" only appears in the filename "station-m2.wip". Is it the filename itself that gets converted into $BOARD or does it get populated some other way?

The other point is, if you look at the original Armbian code at https://github.com/armbian/build/blob/master/config/sources/families/rockchip64.conf source "${BASH_SOURCE%/*}/include/rockchip64_common.inc" case $BRANCH in legacy) KERNELSOURCE='https://github.com/ayufan-rock64/linux-kernel' KERNELBRANCH='tag:4.4.202-1237-rockchip-ayufan' KERNELDIR='linux-rockchip64' KERNELPATCHDIR='rockchip64-'$BRANCH ;; esac prepare_boot_configuration that in itself depends on the ayufan-rock64 repo. So if it doesn't actually work on a specific board then what are 150balbes or myself supposed to do about it? Who's to say that the ayufan-rock64 repo is any more legitimate than 150balbes? This is, I think, entirely the fault of Rockchip for not providing upto date working code for the RK3566, and by working I mean with an HDMI port that actually works.

So where I started with all this. I originally took 150balbes binary image for the Station M2 and discovered that by making some pretty minor config changes I could get it to boot on my quartz64. Now I have found 150balbes source code, and I can compile it from source ( it's here https://github.com/150balbes/build/tree/station-x2 ). I think that I found his "secret sauce". I think that maybe it's here https://github.com/150balbes/build/blob/station-x2/config/sources/families/rockchip64.conf what it contains is this source "${BASH_SOURCE%/*}/include/rockchip64_common.inc" case $BRANCH in legacy) KERNELDIR='linux-rockchip64' if [[ $BOARD == station-p2 || $BOARD == station-m2 ]]; then BOOTSOURCE='https://github.com/150balbes/u-boot-rk' BOOTBRANCH='branch:rk356x' BOOTPATCHDIR="u-boot-station-p2" KERNELSOURCE='https://github.com/150balbes/rockchip-kernel' KERNELBRANCH='branch:rk35xx' KERNELPATCHDIR='station-p2-'$BRANCH LINUXCONFIG='linux-station-p2-'$BRANCH LINUXFAMILY=station-p2 else KERNELSOURCE='https://github.com/ayufan-rock64/linux-kernel' KERNELBRANCH='tag:4.4.202-1237-rockchip-ayufan' KERNELPATCHDIR='rockchip64-'$BRANCH fi ;; esac prepare_boot_configuration So, for a station-m2 there is a dependancy on his own u-boot-rk and rockchip-kernel repos. Can that ever be merged back into something hosted by Armbian ? And what if I further modify it to support the quartz64 ? Then it's a mod of a mod so even harder to merge back in. Presumably what I should do is fork his repos into my own repo and then do an if $BOARD == quartz64-a then blah blah my repo ? Sorry; I'm new to git. This seems like a mess, maybe it's just me. What's the "right" way to do this?

Hi! I'm having trouble with hdmi display and armbian focal on rock64. All works with simple office hdmi displays but fails with an open frame display connected using hdmi->dvi cable. Even the boot messages do not display and the display goes into power saving mode. Here are some of the outputs: rock64@rock64:~$ cat /sys/class/drm/card0/card0-HDMI-A-1/status connected rock64@rock64:~$ cat /sys/class/drm/card0-HDMI-A-1/status connected rock64@rock64:~$ dmesg | grep hdmi [ 4.484419] dwhdmi-rockchip ff3c0000.hdmi: Detected HDMI TX controller v2.11a with HDCP (inno_dw_hdmi_phy2) [ 4.485826] dwhdmi-rockchip ff3c0000.hdmi: registered DesignWare HDMI I2C bus driver [ 4.487156] rockchip-drm display-subsystem: bound ff3c0000.hdmi (ops dw_hdmi_rockchip_ops [rockchipdrm]) [ 10.354029] rc rc1: dw_hdmi as /devices/platform/ff3c0000.hdmi/rc/rc1 [ 10.354226] input: dw_hdmi as /devices/platform/ff3c0000.hdmi/rc/rc1/input5 [ 10.973383] hdmi-audio-codec hdmi-audio-codec.4.auto: ASoC: error at snd_soc_component_of_xlate_dai_id on hdmi-audio-codec.4.auto: -22 rock64@rock64:~$ lsmod | grep hdmi snd_soc_hdmi_codec 20480 1 dw_hdmi_cec 16384 0 dw_hdmi_i2s_audio 16384 0 snd_soc_core 237568 7 snd_soc_spdif_tx,snd_soc_hdmi_codec,snd_soc_rockchip_spdif,snd_soc_audio_graph_card,snd_soc_rk3328,snd_soc_simple_card_utils,snd_soc_rockchip_i2s snd_pcm 118784 3 snd_soc_hdmi_codec,snd_soc_core,snd_pcm_dmaengine snd 90112 4 snd_soc_hdmi_codec,snd_timer,snd_soc_core,snd_pcm dw_hdmi 53248 2 dw_hdmi_i2s_audio,rockchipdrm drm_kms_helper 245760 4 dw_mipi_dsi,rockchipdrm,dw_hdmi,analogix_dp cec 73728 3 drm_kms_helper,dw_hdmi_cec,dw_hdmi drm 573440 8 gpu_sched,drm_kms_helper,dw_mipi_dsi,lima,rockchipdrm,dw_hdmi,analogix_dp

I'm afraid I'm coming to this rather late, but I have had a Rock64 for about 2.5 years running Stretch and I want to upgrade. After seeing that this board is listed as CSC, I found this thread and was wondering what exactly CSC means? When did the board become CSC? Is there a particular build I should stick to for upgrade (such as just doing a modest upgrade to Buster)? As I write this, I'm wondering if the reason that I haven't been able to update some software recently via CL is because it is listed as CSC? This is the first time I've had hardware become unsupported, so I'm not certain what to do. Thanks kindly.

Hello everyone, First of all, thank you all for making ARM accessible! I have a RockPro64 that only boot legacy kernels... I couldn't find anything specific about it online. Is this something to do with the SPI chip? Do I have to update it with the procedure listed here? https://github.com/ayufan-rock64/linux-build/blob/master/recipes/flash-spi.md Any tip would be really welcome, I tried most of the ROCKPRO64 images and nothing... only kernel 4.x boot, SD or emmc, no difference. Bellow is one of the error messages I get... the screen flashes different colors and the system halts. Different images, different behaviors... usually it just flash colors. (Warning... Bad CRC) is this CRC about the SPI firmware? It's not the emmc or SD. I tried different ones and it just doesn't work for mainline kernels. No HDMI output and I won't see an new IP on my network. I tried it without the HDMI cable too.. nothing. Thank you for any assistance!

Hi, Does repo https://github.com/jernejsk/FFmpeg compiles against kernel 5.14.13 (5.14.13-rockchip64)? I am testing unstable Armbian for Rock64 (Armbian 21.11.0-trunk.38 Hirsute) and gives me: Configured with: Thanks in advance.

No, I don't own a Rock64. I only tried HW encoding on the Tinker Board (RK3288), and quality was quite acceptable.

Did you ever try H.264 hardware encoding on the Rock64? What was your experience with the quality? On my Raspberry Pi 4 I did hardware encode my webcam stream for a while, but the quality was so much worse at similar bitrate than libx264, that I ended up using software encoding after all.

So the issue might be in the kernel after all which is good. I found this by playing with armbian-config utility to change the kernel and u-boot versions. 4.4.x is ok but 5.10, 5.13, and 5.14 exhibit the behavior. I'm not sure why my older tests did not exhibit the HDMI artifacts. I've been trying to compile old versions for rock64 using armbian build but it seems that is quite challenging because gcc-linaro is not found because the old torrent file is not longer available (branch v20.08) and in a different branch (v20.05) u-boot fails to compile because of an error (/usr/include/libfdt_env.h:71:30: error: conflicting types for ‘fdt64_t’). I think it's time to ask in the peer to peer section

More news, this is not u-boot issue. I git cloned current armbian build from github.com and compiled kernel+bootloader. This resulted in `output/debs/linux-u-boot-current-rock64_21.11.0-trunk_arm64.deb` I inspected this file and can see there is no `preinst` or `postinst` files so manual update of the bootloader is necessary (without doing more search). Looking at the `/usr/lib/u-boot/platform_install.sh` script and the files in the *.deb I can see the relevant dd commands that are needed to update the bootloader. With `Armbian_5.91_Rock64_Debian_buster_default_4.4.184_desktop.img` as the image written to SD card, I wrote the newly compiled bootloader and I restarted the rock64. It did not display any HDMI/video artifacts. To further exclude u-boot being problematic, I wrote `Armbian_21.08.1_Rock64_bullseye_current_5.10.60.img` to SD card then extracted the bootloaded from Armbian 5.91 and wrote it to SD card. This did not fix the HDMI artifacts. Now time to investigate which package is causing the issue This will probably take a long time.

I found the rock64 archive at https://mirror.12z.eu/pub/linux/armbian/dl/rock64/archive/ So before I start bisecting I will be loading several versions to see if it's a kernel issue or userspace issue. (Taking a kernel from one release to another) Will post updates on what I find!

I know this is a old thread, take a look at this https://www.instructables.com/Get-HDMI-Output-From-Your-Rock64-Using-Armbian/ Look at notes starting with step 6.

It was fixed for a day or two but it broke again. This means quick fix doesn't work well, while serious and expensive time slot to tear down this complicated mechanism can't be allocated just like that. If you want that things works smoothly, you should not leave also costs of maintenance on our shoulders. We already blow too much on R&D and are crying for help, repository management tool authors as well, ... Even this is unrelated to the problem from the topic - your hardware (Rock64 due to quality issues) and software (Armbian Bionic is old LTS) and the way it was build (user-built / support is only for digitally signed releases) is not eligible for support we / armbian maintainers pay for you. We can't cover. No ETA. It is urgent matter and will be fixed accordingly. With another quick fix, I am on vacations.

Hello, I am still facing the E: The repository 'http://apt.armbian.com bionic Release, is no longer signed. error message when attempting a apt update So far, I have tried: 1. Waiting 2. Re-adding the repository key as suggested by user "favorit800" in this thread. 3. Setting the repository as "trusted" as suggested by "Jerry Jyrer" in this thread. None of the above have worked, I am running: ~$ cat /etc/armbian-release # PLEASE DO NOT EDIT THIS FILE BOARD=rock64 BOARD_NAME="Rock 64" BOARDFAMILY=rockchip64 BUILD_REPOSITORY_URL=https://github.com/armbian/build BUILD_REPOSITORY_COMMIT=baaefaf69-dirty DISTRIBUTION_CODENAME=bionic DISTRIBUTION_STATUS=csc VERSION=21.05.4 LINUXFAMILY=rockchip64 ARCH=arm64 IMAGE_TYPE=user-built BOARD_TYPE=csc INITRD_ARCH=arm64 KERNEL_IMAGE_TYPE=Image BRANCH=current ~$ uname -a Linux rock64 5.10.43-rockchip64 #21.05.4 SMP PREEMPT Wed Jun 16 08:02:12 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux Any ETA regarding the repository signing ? Regards!

Hey everyone...I've tried searching the problem I'm having and have tried different things...all so far to no avail. I'm relatively new to learning about pihole and decided to go out and buy the kit from ameriDroid (maybe should have built my own but decided to go this route to try and save myself some time). I received the kit today and started following the install instructions (I am attempting to install via SSH thru Putty). Once I reached the install command, I get an error stating: "Error: Unable to update package cache. Please try "apt-get update". I've tried the apt update/upgrade and I'm still getting the same error. The output from the apt-get update command is the following: root@rock64:/home/pihole# sudo apt update Hit:2 http://ports.ubuntu.com focal InRelease Hit:3 http://ports.ubuntu.com focal-security InRelease Ign:1 https://armbian.tnahosting.net/apt focal InRelease Hit:4 http://ports.ubuntu.com focal-updates InRelease Hit:6 http://ports.ubuntu.com focal-backports InRelease Err:5 https://armbian.tnahosting.net/apt focal Release Certificate verification failed: The certificate is NOT trusted. The certificate issuer is unknown. Could not handshake: Error in the certificate verification. [IP: 130.185.239.75 443] Reading package lists... Done W: http://apt.armbian.com/dists/focal/InRelease: No system certificates available. Try installing ca-certificates. W: http://apt.armbian.com/dists/focal/Release: No system certificates available. Try installing ca-certificates. E: The repository 'http://apt.armbian.com focal Release' does not have a Release file. N: Updating from such a repository can't be done securely, and is therefore disabled by default. N: See apt-secure(8) manpage for repository creation and user configuration details. I've tried running sudo apt-get install ca-certificates but they already appear to be installed. Any help will be greatly appreciated.