Search the Community

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.

Updated Armbian on Rock64 today, then lightdm stopped working. After peeling the layers it appears to come down to Xorg giving signal 11 "Segmentation fault" /usr/sbin/lightdm --debug [+0.12s] DEBUG: XServer 0: Launching X Server [+0.12s] DEBUG: Launching process 2575: /usr/bin/X -core :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch [+0.12s] DEBUG: XServer 0: Waiting for ready signal from X server :0 [+0.12s] DEBUG: Acquired bus name org.freedesktop.DisplayManager [+0.13s] DEBUG: Registering seat with bus path /org/freedesktop/DisplayManager/Seat0 [+0.15s] DEBUG: Process 2575 terminated with signal 11 root@rock:~# whoami root cd /usr/lib/xorg file Xorg Xorg: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]=f42da704ae0d3ae4698db2960364a313b08e111f, for GNU/Linux 3.7.0, stripped root@rock:/usr/lib/xorg# Xorg Segmentation fault root@rock:/usr/lib/xorg$ sudo Xorg --configure Segmentation fault uname -a 5.10.63-rockchip64 #21.08.2 SMP PREEMPT Wed Sep 8 10:57:23 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux apt-cache show xserver-xorg | grep Version Version: 1:7.7+22 Version: 1:7.7+19ubuntu14 Is there a way to fix this without downgrading?

Greetings all! A noob here just starting to explore and grasp Linux, ARM, and SBC's. I hope I'm posting in a correct area; don't want to ruffle any feathers. I've worked with IoT for a bit, while we several Rpi's collected dust until I put one to work with Node Red for a smart-home project. That sparked my interest, and I aquired a used Rock64 board relatively cheap to play. In retrospect it may have not been the right choice but I have it now. After trying several "dis-jointed" OS's steered to by the Pine website, and finding them to only work partially, at best, I came across Armbian after much searching. I'm very glad I did. I find the OS I selected to be very adequate for my learning needs with only a few caveats. I've learned to configure some of the system characteristics and am able to follow some tutorials on Debian, Linux, etc. Now I've gotten to a point where I'd like to print out some of the subject matter. However it appears that there doesn't seem to be a print driver for my printer. I just replaced my old HP Deskjet with a Brother HL-L3230CDW network printer. While there are Linux drivers, I could find none for ARM processors. Does anyone have any idea as to a solution. Many thanks for any help.

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!

After shelving my Rock 64 I dusted it off and downloaded the latest desktop image with Ubuntu Focal. The latest OS has video artifacts that the older OS did not. I can only describe the issue as "scan lines," but they are random black bars that appear through out the entire screen (as if WiFi is interrupting the signal only there's no WiFi on the device). I would like to know the best way to bisect the issue as I'm fully capable of cloning the repo, building the image, loading the image and testing it out but if there are pointers to simplify the process I'd love to hear. Hoping to give back since this is a community supported board. Thanks.

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.

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!

Hello, A while back i was using my rock64 as a media player running armbian with some success. Since a hiatus and reinstall of the latest armbian focal mainline release, the i2s output no longer works. I can get output on the 3.5mm jack, but not on the RCAs of the DAC board. I spent some time playing around the fdtget/fdtput with no success as i don't really know what i'm doing in that space. Does anyone know how to enable I2S? Volumio got mentioned allot in my google searches, so i tried that and viola the DAC works again. volumio@volumio:~$ aplay -l **** List of PLAYBACK Hardware Devices **** card 0: HDMI [HDMI], device 0: ff000000.i2s-i2s-hifi i2s-hifi-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: I2S [I2S], device 0: ff010000.i2s-rk3328-hifi rk3328-hifi-0 [] Subdevices: 0/1 Subdevice #0: subdevice #0 card 1: I2S [I2S], device 1: ff010000.i2s-snd-soc-dummy-dai snd-soc-dummy-dai-1 [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: SPDIF [SPDIF], device 0: ff030000.spdif-dit-hifi dit-hifi-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 volumio@volumio:~$ uname -a Linux volumio 4.4.154 #1 SMP Tue Oct 13 11:37:38 CEST 2020 aarch64 GNU/Linux on armbian i get **** List of PLAYBACK Hardware Devices **** card 0: rockchiprk3328 [rockchip,rk3328], device 0: ff000000.i2s-i2s-hifi i2s-hifi-0 [ff000000.i2s-i2s-hifi i2s-hifi-0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: rockchiprk3328 [rockchip,rk3328], device 1: ff010000.i2s-rk3328-hifi ff410000.codec-1 [ff010000.i2s-rk3328-hifi ff410000.codec-1] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: rockchiprk3328 [rockchip,rk3328], device 2: ff030000.spdif-dit-hifi dit-hifi-2 [ff030000.spdif-dit-hifi dit-hifi-2] Subdevices: 1/1 Subdevice #0: subdevice #0 Regards, Dan

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.

Super dumb question, how do I check the current clock speed of the memory? dmesg, /sys, etc? I have a few rock64 (v2) boards. One running Armbian fine, the other and old Ayufan OMV (need to move that to Armbian). I had a board sometimes go unstable (when accessing NTFS filesystem, more details https://forum.pine64.org/showthread.php?tid=13393) so I swapped it out with another board but I keep thinking I could use the board for something and wondering if it was memory clock related. I'd like to check what I have in both systems before trying to change it (and to help keep track later once its changed!) Thanks!

This is when trying to play a Sony demo video that plays OK under Kodi on my Rock 64. Without sudo gives me a green screen, no video whilst using sudo gives me a few green lines then a black screen with no video. dan@rock64:~$ mpv --gpu-context=drm Sony\ Aquarium\ 4K\ Demo.mp4 LIBGL: Initialising gl4es LIBGL: v1.1.5 built on Dec 22 2020 23:27:36 LIBGL: Using GLES 2.0 backend LIBGL: loaded: libGLESv2.so LIBGL: loaded: libEGL.so LIBGL: loaded: libgbm.so LIBGL: loaded: libdrm.so.2 LIBGL: Using GLES 2.0 backend LIBGL: Error while gathering supported extension (eglInitialize: EGL_BAD_ALLOC), default to none LIBGL: Targeting OpenGL 2.1 LIBGL: WARNING, No Limited or Full NPOT support in hardware, Forcing NPOT have no effect! LIBGL: Not trying to batch small subsequent glDrawXXXX LIBGL: try to use VBO LIBGL: Force texture for Attachment color0 on FBO LIBGL: Hack to trigger a SwapBuffers when a Full Framebuffer Blit on default FBO is done LIBGL: glX Will try to recycle EGL Surface LIBGL: Current folder is:/home/dan (+) Video --vid=1 (*) (hevc 3840x2160 59.940fps) (+) Audio --aid=1 --alang=eng (*) (aac 2ch 48000Hz) [vo/gpu] VT_GETMODE failed: Inappropriate ioctl for device [vo/gpu/opengl] Failed to set up VT switcher. Terminal switching will be unavailable. [vo/gpu/opengl] Failed to initialize EGL. [vo/gpu] Failed to setup EGL. Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object file: No such file or directory [vo/vdpau] Error when calling vdp_device_create_x11: 1 [vo/xv] No Xvideo support found. [vaapi] Failed to initialize VAAPI: unknown libva error [vo/x11] Warning: this legacy VO has bad performance. Consider fixing your graphics drivers, or not forcing the x11 VO. mpi: mpp version: 11d98147 author: JMCC Import changes from fork Kwiboo/mpp, branch libreelec-hdr, and version bump mpp_device: mpp_device_init failed to open device /dev/rkvdec, errno 13, error msg: Permission denied mpp_rt: NOT found ion allocator mpp_rt: found drm allocator mpp: deprecated block control, use timeout control instead mpp: deprecated block control, use timeout control instead H265D_PARSER: No start code is found. H265D_PARSER: mpp_hevc_decode_nal_sei error ret = -1006 mpp_device: mpp_device_send_reg ioctl VPU_IOC_SET_REG failed ret -1 errno 9 Bad file descriptor H265HAL: RK_HEVC_DEC: ERROR: mpp_device_send_reg Failed!!! mpp_device: mpp_device_wait_reg ioctl VPU_IOC_GET_REG failed ret -1 errno 9 Bad file descriptor Using hardware decoding (rkmpp). [autoconvert] HW-downloading from drm_prime mpp_device: mpp_device_send_reg ioctl VPU_IOC_SET_REG failed ret -1 errno 9 Bad file descriptor H265HAL: RK_HEVC_DEC: ERROR: mpp_device_send_reg Failed!!! mpp_device: mpp_device_wait_reg ioctl VPU_IOC_GET_REG failed ret -1 errno 9 Bad file descriptor mpp_device: mpp_device_send_reg ioctl VPU_IOC_SET_REG failed ret -1 errno 9 Bad file descriptor H265HAL: RK_HEVC_DEC: ERROR: mpp_device_send_reg Failed!!! mpp_device: mpp_device_wait_reg ioctl VPU_IOC_GET_REG failed ret -1 errno 9 Bad file descriptor mpp_device: mpp_device_send_reg ioctl VPU_IOC_SET_REG failed ret -1 errno 9 Bad file descriptor H265HAL: RK_HEVC_DEC: ERROR: mpp_device_send_reg Failed!!! mpp_device: mpp_device_wait_reg ioctl VPU_IOC_GET_REG failed ret -1 errno 9 Bad file descriptor mpp_device: mpp_device_send_reg ioctl VPU_IOC_SET_REG failed ret -1 errno 9 Bad file descriptor H265HAL: RK_HEVC_DEC: ERROR: mpp_device_send_reg Failed!!! mpp_device: mpp_device_wait_reg ioctl VPU_IOC_GET_REG failed ret -1 errno 9 Bad file descriptor AO: [pulse] 48000Hz stereo 2ch float mpp_device: mpp_device_send_reg ioctl VPU_IOC_SET_REG failed ret -1 errno 9 Bad file descriptor H265HAL: RK_HEVC_DEC: ERROR: mpp_device_send_reg Failed!!! mpp_device: mpp_device_wait_reg ioctl VPU_IOC_GET_REG failed ret -1 errno 9 Bad file descriptor mpp_device: mpp_device_send_reg ioctl VPU_IOC_SET_REG failed ret -1 errno 9 Bad file descriptor H265HAL: RK_HEVC_DEC: ERROR: mpp_device_send_reg Failed!!! mpp_device: mpp_device_wait_reg ioctl VPU_IOC_GET_REG failed ret -1 errno 9 Bad file descriptor mpp_device: mpp_device_send_reg ioctl VPU_IOC_SET_REG failed ret -1 errno 9 Bad file descriptor H265HAL: RK_HEVC_DEC: ERROR: mpp_device_send_reg Failed!!! mpp_device: mpp_device_wait_reg ioctl VPU_IOC_GET_REG failed ret -1 errno 9 Bad file descriptor [ao/pulse] pa_stream_cork() failed: Connection terminated [ao/pulse] pa_stream_flush() failed: Connection terminated VO: [x11] 3840x2160 nv12 mpp_device: mpp_device_deinit invalid negtive file handle, Exiting... (Quit) LIBGL: Shuting down dan@rock64:~$ sudo mpv --gpu-context=drm Sony\ Aquarium\ 4K\ Demo.mp4 [sudo] password for dan: LIBGL: Initialising gl4es LIBGL: v1.1.5 built on Dec 22 2020 23:27:36 LIBGL: Using GLES 2.0 backend LIBGL: loaded: libGLESv2.so LIBGL: loaded: libEGL.so LIBGL: loaded: libgbm.so LIBGL: loaded: libdrm.so.2 LIBGL: Using GLES 2.0 backend LIBGL: GBM Surfaces supported LIBGL: Hardware Full NPOT detected and used LIBGL: Extension GL_EXT_blend_minmax detected and used LIBGL: FBO are in core, and so used LIBGL: PointSprite are in core, and so used LIBGL: CubeMap are in core, and so used LIBGL: BlendColor is in core, and so used LIBGL: Blend Substract is in core, and so used LIBGL: Blend Function and Equation Separation is in core, and so used LIBGL: Texture Mirrored Repeat is in core, and so used LIBGL: Extension GL_OES_mapbuffer detected LIBGL: Extension GL_OES_packed_depth_stencil detected and used LIBGL: Extension GL_OES_depth24 detected and used LIBGL: Extension GL_OES_rgb8_rgba8 detected and used LIBGL: Extension GL_EXT_texture_format_BGRA8888 detected and used LIBGL: Extension GL_OES_depth_texture detected and used LIBGL: Extension GL_EXT_shader_texture_lod detected and used LIBGL: Max vertex attrib: 16 LIBGL: Extension GL_OES_standard_derivatives detected and used LIBGL: Max texture size: 4096 LIBGL: Max Varying Vector: 12 LIBGL: Texture Units: 8/8 (hardware: 8), Max lights: 8, Max planes: 6 LIBGL: Max Color Attachments: 1 / Draw buffers: 1 LIBGL: Hardware vendor is ARM LIBGL: EGLImage from Pixmap supported LIBGL: EGLImage to Texture2D supported LIBGL: EGLImage to RenderBuffer supported LIBGL: Targeting OpenGL 2.1 LIBGL: NPOT texture handled in hardware LIBGL: Not trying to batch small subsequent glDrawXXXX LIBGL: try to use VBO LIBGL: glXMakeCurrent FBO workaround enabled LIBGL: FBO workaround for using binded texture enabled LIBGL: Force texture for Attachment color0 on FBO LIBGL: Hack to trigger a SwapBuffers when a Full Framebuffer Blit on default FBO is done LIBGL: glX Will try to recycle EGL Surface LIBGL: Current folder is:/home/dan (+) Video --vid=1 (*) (hevc 3840x2160 59.940fps) (+) Audio --aid=1 --alang=eng (*) (aac 2ch 48000Hz) [vo/gpu] VT_GETMODE failed: Inappropriate ioctl for device [vo/gpu/opengl] Failed to set up VT switcher. Terminal switching will be unavailable. [vo/gpu/opengl] Could not choose EGLConfig for GLES 3.x! mpi: mpp version: 11d98147 author: JMCC Import changes from fork Kwiboo/mpp, branch libreelec-hdr, and version bump mpp_rt: NOT found ion allocator mpp_rt: found drm allocator mpp: deprecated block control, use timeout control instead mpp: deprecated block control, use timeout control instead H265D_PARSER: No start code is found. H265D_PARSER: mpp_hevc_decode_nal_sei error ret = -1006 Using hardware decoding (rkmpp). AO: [pulse] 48000Hz stereo 2ch float VO: [gpu] 3840x2160 drm_prime[nv12] [vo/gpu] Using HW-overlay mode. No GL filtering is performed on the video! [ao/pulse] pa_stream_cork() failed: Connection terminated [ao/pulse] pa_stream_flush() failed: Connection terminated Exiting... (Quit) LIBGL: Shuting down

Has anyone successfully played a 4K video on a RK3328 (eg a Rock64) using mpv and rkmpp? I've been trying this build of mpv on my 4 GB Rock64 running buster legacy try to get it to play a 4K h264 but I've not had one play properly yet. What is the full mpv command to get fullscreen, 4K h264 playback to work with rkmpp, if possible? I've seen commands such as this suggested but it doesn't work for me: mpv --vo=gpu --gpu-api=opengl --gpu-context=drm --gpu-hwdec-interop=drmprime-drm --hwdec=rkmpp video.mkv I've tried various combos of those options. With all the videos I've tried, I either see the first frame of the video then nothing else (I just have to quit mpv), I just get a black screen or it crashes.

Hi all. Any ideas how to address this problem with apt-get/apt package manager? This system: Welcome to Armbian 21.02.3 Buster with Linux 5.10.35-rockchip64 Hit:1 http://security.debian.org buster/updates InRelease Hit:2 http://httpredir.debian.org/debian buster InRelease Hit:4 http://httpredir.debian.org/debian buster-updates InRelease Hit:5 http://httpredir.debian.org/debian buster-backports InRelease Hit:3 https://armbian.hosthatch.com/apt buster InRelease Error: No information about packages! (Maybe no deb entries?) Reading package lists... Done E: Problem executing scripts APT::Update::Post-Invoke-Success 'test -x /usr/bin/apt-show-versions || exit 0 ; apt-show-versions -i' E: Sub-process returned an error code ============================================ This is my source.list deb http://httpredir.debian.org/debian buster main contrib non-free # deb-src http://httpredir.debian.org/debian buster main contrib non-free deb http://httpredir.debian.org/debian buster-updates main contrib non-free # deb-src http://httpredir.debian.org/debian buster-updates main contrib non-free deb http://httpredir.debian.org/debian buster-backports main contrib non-free # deb-src http://httpredir.debian.org/debian buster-backports main contrib non-free deb http://security.debian.org/ buster/updates main contrib non-free # deb-src http://security.debian.org/ buster/updates main contrib non-free # deb https://download.webmin.com/download/repository buster main # deb-src https://download.webmin.com/download/repository buster main =================================================== This is armbian.list deb http://apt.armbian.com buster main buster-utils buster-desktop Any ideas appreciated. I would like to get a apt-get update and apt-get upgrade working without errors.

Moved out to a separate topic. Rock64 is unsupported, if you do a little search you will know why. In short, because of problems like yours. Do some search in the forums, please.

Hi, I have a Pine Rock64 v2.0 SBC and with the image Buster xfce desktop (I guess this is the right one that mentions here), the board has random freezes and impossible to use. So far the board does work good with Ayufan Debian buster image. Anyone had and idea why? I post here since I need to implement hwaccel so I can use this board as RTSP server using a UVC USB camera (Arducam). Thanks.