Jump to content

Search the Community

Showing results for tags 'rock64'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Community
    • Announcements
    • Feature Requests
  • Using Armbian
    • Beginners
    • Software, Applications, Userspace
    • Advanced users - Development
  • Upcoming Hardware (WIP)
    • News
    • Odroid M1
    • ROCK 5B
  • Maintained Hardware
    • Board does not start
    • Amlogic meson
    • Allwinner sunxi
    • Marvell mvebu
    • Rockchip
    • Other families
  • Unmaintained (CSC/EOL/TVB) / Other
    • TV boxes
    • Off-topic
    • Amlogic meson
    • Allwinner sunxi
    • Marvell mvebu
    • Rockchip
    • Other families

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Matrix


Mastodon


IRC


Website URL


XMPP/Jabber


Skype


Github


Discord


Location


Interests

  1. Hello community, I have just been successful building my own image of Ubuntu focal + preempt_rt (kernel 5.15.76-rt53) for my Rock64 board for the first time (a bit of additional background at the end of my post). Exciting! I had a few hiccups along the way, and I need to figure out a few more things. So far I'm happy and impressed with the project. However, given I want to share my work (and the resulting image(s)) I would like to ask for some pointers on what is the best way to go in regards of forking armbian/build and the changes I found myself doing. I have added my kernel compilation flags to config/kernel/linux-rockchip64-current.config but I feel like maybe I should create a new file, something like 'linux-rockchip64-current-rt.config' but I do not know if the compile.sh will find it (or how to make it find it) if I do so. What would be the best way to go about it? I added the PREEMPT_RT patches to patch/kernel/rockchip64-current , but again, there should probably be a folder for RT maybe? (I wonder how to make compile.sh find it). I created userpatches/lib.config with the content 'KERNELBRANCH='tag:v5.15.76'' to use the latest PREEMPT_RT compatible kernel, ideally this could be scripted to use the latest closest to 'current', which also would avoid needing to modify the patch/kernel/BOARD_NAME folder. I also needed to remove the box64 package cause it would stop building my image (GPG key outdated?) is this package necessary for a minimal installation? I don't think I found I needed it so far. I left a comment about it in this github issue: https://github.com/armbian/build/issues/3968#issuecomment-1310390875 I needed to add a couple of additional cmdline flags, I edited by hand (after booting the board) the resulting /boot/armbianEnv.txt with 'extraargs=nohz_full=3 isolcpus=3' and that worked, but I'd like to create the image with that already done. What would be the best place to do that? userpatches/customize-image.sh ? If I place anything in userpatches/customize-image.sh am I able to run the build just from there? Thank you very much for any pointers you can give me about best practices to go about it, anything I did wrong, or templates to follow. My first goal is to provide a reproducible build of ubuntu focal + preempt_rt for the rock64 board (which I'm very close!), but I'd be happy to extend the work to be able to apply the PREEMPT_RT patches to any board saving people a bit of the guess work I needed to do (at least for as long the patches are not part of the kernel by default!). Additional background: I need to use Ubuntu as my plan is to use ROS 2 on it, and the officially supported distro is Ubuntu (and focal happens to be the most useful for my use-case). I am aiming, in conjunction with some members of the ROS real-time working group, to ease the entry barrier of learning to make real-time apps for robotics. I am using a Rock64 board because it's similar to a Raspberry Pi 4, as I am unable to source a Raspi4 and I believe it is the same for everyone. Bonus: a quick test (running 10min) of cyclictest with stress on the system provided the following plot on latency (74us max, 15us min, about 20ish us average):
  2. I have a Rock64, purchased in 2019, that has been running happily for 4 years. I was recently experimenting with hooking it up to a relay board and now I am unable to connect to the internet. I am unsure whether something is fried on the board itself or if this is a software problem I can fix, and unsure how to figure that out. Details I have learned more about relay boards now, so I'll do a few things differently and more carefully next attempt, but I had the 5v pin powering the relay board and the 3v pin, GPIO3_A4, and GPIO3_A5 connected to the control side to control two of the board's relays. When connected the Rock's power leds were still on, but either the OS or the internet was down, not sure which. When I then disconnected the relay board, everything worked as normal for a few iterations, but then it remained down even with the relay board disconnected. At this point I logged in over a serial console and found the OS working just fine, but no sign of the ethernet port. This is the current state and I'd like to figure out if it's a fixable one! I have ordered a wifi dongle, but I'd also like to get back ethernet if possible. I believe the only thing I've done intentionally that may have changed the state of the filesystem was that I ran `dpkg-reconfigure network-manager`. Not sure if that changed anything. The orange light on the ethernet port is lit constantly when the board is on. The green light is always off (now). `lspci` produces no output. `ip a` lists only the `lo` interface: 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever `/etc/network/interfaces`: #source /etc/network/interfaces.d/* # Network is managed by Network manager auto eth0 iface eth0 inet dhcp # address 192.168.70.70 # netmask 255.255.255.0 # gateway 192.168.1.1 # dns-nameservers 8.8.8.8 8.8.4.4 USB, emmc, and sd still work Boot output The only thing I note here is the line `Net: No ethernet found.` and, at the bottom, several `EXT4-fs error`s. The first makes sense, that's what I'm seeing after bootup. Not sure what to do about the second, if anything.
  3. If I understand the custom-image script is run as a chroot after the image is built. So didn't see anything specifically in the docs but can I ONLY run (from compile script) the custom image script on an already already built image (in /output/images)? Along the same lines can I chroot at any time to the image via the compile script? I should mention that I am using the docker container build for arm on my amd machine. (i.e. ./compile.sh docker.... )
  4. I wanted to build the cli version but didn't see an obvious way to do that with conf variables and the docs don't illuminate that choice. so I tried BUILD_MINIMAL=no BUILD_DESKTOP=no and that seems to do force the cli version. Just suggesting that this might be easier to grok if the variable was say BUILD_TYPE=(desktop|cli|minimal|custom) with maybe default cli where custom might be a rootfs that is custom (like one I put together) and thus doesn't need to be reconstructed from the custom-image script. Maybe setting custom then RELEASE could hold the path to the tarball? If that seems better maybe I can try making a pr? BTW this is not necessarily a beginner topic but didn't see a category for just generic building discussion.
  5. I installed tvheadend on Armbian 22.08 Jammy and Bullseye using the 5.15 kernel. Tvheadend runs fine for a while and then freezes and disconnects filling the log file with the following message: rock64 kernel : au0828: recv_control_msg() Failed receiving control message, error -71. At first I thought it was a problem with Jammy, but I still had the same problem on Bullseye. So I switched to the legacy kernel 4.4.213-rockchip64 and I do not have the problem. I am using a Rock64 Ver. 2 with usb dvb tuner for tvheadend and it is stable running Bullseye with kernel 4.4.213. I am not sure what changed between these kernel versions, but it seems to cause this problem.
  6. Hello, i am pretty new to arm embedded. I have a Rock64 V3.0 2019-0626 So I downloaded Armbian 22.08 Jammy XFCE from https://www.armbian.com/rock64/ and copied it on a 265GB SanDisk Extreme microsd XC 1 V30 A2 using Balena Etcher. Boot process did work, but startxfc4 did not work. The system just went on a blackscreen, but i could still switch to another terminal with alt+f1 ... Best regards, Bo
  7. after several minutes, a 3 line error message is output on 2 old original rock64's. network works, I can log in from my local net, and dmesg says: [ 35.867400] Unbalanced IRQ 47 wake disable [ 35.867422] WARNING: CPU: 0 PID: 1580 at kernel/irq/manage.c:900 irq_set_irq_wake+0x108/0x148 [ 35.867447] Modules linked in: rfkill joydev snd_soc_spdif_tx gpio_ir_recv rc_core lz4hc cdc_acm lz4 hantro_vpu(C) rockchip_vdec(C) rockchip_iep snd_soc_simple_card v4l2_h264 snd_soc_rockchip_i2s rockchip_rga videobuf2_dma_contig snd_soc_rockchip_pcm snd_soc_hdmi_codec snd_soc_rk3328 snd_soc_simple_card_utils v4l2_mem2mem snd_soc_rockchip_spdif videobuf2_dma_sg videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 snd_soc_core videobuf2_common videodev snd_pcm_dmaengine mc snd_pcm snd_timer snd soundcore cpufreq_dt zram binfmt_misc sch_fq_codel ramoops reed_solomon pstore_blk pstore_zone ip_tables x_tables autofs4 hid_logitech_hidpp hid_logitech_dj realtek dwmac_rk stmmac_platform stmmac lima dw_hdmi_cec pcs_xpcs gpu_sched dw_hdmi_i2s_audio gpio_syscon [ 35.867680] CPU: 0 PID: 1580 Comm: NetworkManager Tainted: G C 5.15.74-rockchip64 #22.08.6 [ 35.867693] Hardware name: Pine64 Rock64 (DT) [ 35.867699] pstate: 800000c5 (Nzcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 35.867709] pc : irq_set_irq_wake+0x108/0x148 [ 35.867724] lr : irq_set_irq_wake+0x108/0x148 [ 35.867734] sp : ffff80000a7e3b30 [ 35.867739] x29: ffff80000a7e3b30 x28: ffff00000184d880 x27: 0000000000000000 [ 35.867757] x26: 0000000000000000 x25: 0000000000000000 x24: 0000ffffe172c0f8 [ 35.867774] x23: 000000000000002f x22: 0000000000000000 x21: 00000000ffffffea [ 35.867790] x20: ffff80000954c7c8 x19: ffff000000711200 x18: 0000000000000001 [ 35.867806] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000280 [ 35.867822] x14: ffff80000a7e3840 x13: 00000000ffffffea x12: ffff800009b1fd10 [ 35.867838] x11: 0000000000000003 x10: ffff800009b07cd0 x9 : ffff800009b07d28 [ 35.867855] x8 : 0000000000017fe8 x7 : c0000000ffffefff x6 : 0000000000000001 [ 35.867870] x5 : ffff8000f501a000 x4 : 0000000000000000 x3 : 0000000000000002 [ 35.867886] x2 : 0000000000000001 x1 : 8cf7ed973ed99a00 x0 : 0000000000000000 [ 35.867903] Call trace: [ 35.867908] irq_set_irq_wake+0x108/0x148 [ 35.867920] stmmac_set_wol+0x74/0x128 [stmmac] [ 35.867985] dev_ethtool+0x1400/0x20b0 [ 35.867998] dev_ioctl+0x1fc/0x3f8 [ 35.868008] sock_do_ioctl+0xb4/0xf8 [ 35.868018] sock_ioctl+0x2d4/0x3b8 [ 35.868027] __arm64_sys_ioctl+0xa8/0xe8 [ 35.868038] invoke_syscall+0x44/0x108 [ 35.868050] el0_svc_common.constprop.3+0x94/0xf8 [ 35.868061] do_el0_svc+0x24/0x88 [ 35.868071] el0_svc+0x20/0x50 [ 35.868080] el0t_64_sync_handler+0x90/0xb8 [ 35.868089] el0t_64_sync+0x180/0x184 [ 35.868099] ---[ end trace b82369d81dab89d6 ]--- [ 147.094526] hdmi-audio-codec hdmi-audio-codec.4.auto: Only one simultaneous stream supported! [ 147.095731] hdmi-audio-codec hdmi-audio-codec.4.auto: ASoC: error at snd_soc_dai_startup on i2s-hifi: -22 [ 147.096881] ff000000.i2s-i2s-hifi: soc_pcm_open() failed (-22) [ 147.250755] overlayfs: "xino" feature enabled using 2 upper inode bits. ================== on both machines. These have a primary assignment of running octoprint as part of my printer farm and hdmi video is required. Any clues as to what will restore their video?
  8. How is the 1-wire bus enabled on a Rock64 with Armbian 20.08.17 Bionic? I have enabled the w1-gpio through armbian-config. The /sys/bus/w1/devices/ folder is empty after sudo modprobe w1-gpio and sudo modprobe w1-therm. Below is what is in the armbianEnv.txt file in the /boot directory. verbosity=1 bootlogo=false overlay_prefix=rockchip rootdev=UUID=cbeeff94-c38d-4a79-b10a-3854a2470be4 rootfstype=ext4 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u overlays=i2c7 spi-spidev w1-gpio In the /boot/dtb/rockchip/overlay/ directory there is a file rockchip-w1-gpio.dtbo. I have connected the VCC pin of the DS18B20 to 3v3 physical pin 1, ground of the DS18B20 to physical pin 9, data of the DS18B20 to physical 7. The DS18B20 address and w1_bus_master1 do not appear in the /sys/bus/w1/devices/ folder. What more is required to see the DS18B20 and take readings? I have already connected an 18x2 LCD to i2c and am writing information to the LCD using python. Thank you for the help. Perry
  9. Hello everyone, i was thinking about running a jellyfin server on the Rock64, is there any chance for hardware encoding? Thank you in advance Regards
  10. On Armbian Buster, rockchip (rock64), kernel 5.16.69. This was also happening on the latest backported version of 5.10, I think 5.10.72? I tried upgrading to fix it to no avail. I have a couple 8TB HDDs that I use as backups. All I did was reformat one of them as btrfs and start copying the data back over from the other (still EXT4). I tried rsync and simple cp. Without fail, a few minutes into the operation, the copy operation will hang indefinitely, and all open terminals receive these kernel messages: Message from syslogd@localhost at Oct 1 16:59:57 ... kernel:[ 339.539365] Internal error: Oops: 96000004 [#1] PREEMPT SMP Message from syslogd@localhost at Oct 1 16:59:57 ... kernel:[ 339.560387] Code: cb0100a3 cb0d015c 7100019f 9b167c00 (9adb2400) After that, every subsequent copy operation from the EXT4 drive to this new btrfs partition will hang until I reboot the rock64. However, the drive otherwise continues to work fine. fsck and btrfs scrub find no problems. The super weird thing is I can still write files, and copy a small shell script from the home folder, all just fine--but copying from the other 8TB drive will immediately hang. I have had zero issues with either drive until trying btrfs now. I'm able to rsync between them just fine when they're both EXT4. journalctl.txt specific-error.txt
  11. A month or two back, when I installed Armbian, I had to revert to an older kernel, 5.10.63-rockchip64, which has known vulnerabilities. I needed to be able to boot off of a USB 3 HDD, so I had to revert it and hold updates for the kernel/kernel headers. These are the commands I used to revert to the older kernel: sudo apt install linux-dtb-current-rockchip64=21.08.2 linux-image-current-rockchip64=21.08.2 sudo apt-mark hold linux-dtb-current-rockchip64 linux-image-current-rockchip64 Fast forward to today, where the issue with USB 3 has been apparently resolved in the latest kernel, I tried to unhold the kernel/kernel header updates, that seemed to work. But after running an update, nothing. It's still showing 5.10.63-rockchip64 when it should be 5.15.63rockchip64. I tried to run firmware updates and everything, still not updating the kernel. It still also says Armbian 22.05.3 Jammy. In Armbian Config, the latest kernel I can choose from seems to be one with borked USB3 support, linux-image-current-rockchip64=22.05.3 5.15.48-rockchip64. If I select this kernel, my OS will be bricked since I would not be able to boot off of the USB HDD. linux-image-current-rockchip64=22.08.1 5.15.63-rockchip64 should technically exist as it is the current Armbian release for this board, but it is nowhere to be found in Armbian Config and even after doing an unhold, the system will not update to the latest borked kernel either.
  12. (Note: this is crossposted from an ATS issue, since I think it might be quicker to get answers here. Will post on one thread when I get answers that work in the other) Have installed ats on my Rock64, running Armbian 22.05 Jammy with kernel version 5.10.63, and am having trouble getting the fan to spin. The fan I'm using is the one that comes with this case, and it spins when I connect it to a battery. One possible issue is that I had to manually add an entry for PWM_CTL: running sudo find /sys -name pwm\*, I get: /sys/kernel/tracing/events/pwm /sys/kernel/tracing/events/pwm/pwm_apply /sys/kernel/tracing/events/pwm/pwm_get /sys/kernel/debug/tracing/events/pwm /sys/kernel/debug/tracing/events/pwm/pwm_apply /sys/kernel/debug/tracing/events/pwm/pwm_get /sys/kernel/debug/pwm /sys/class/pwm /sys/bus/platform/drivers/pwm-clock /sys/bus/platform/drivers/pwm-regulator /sys/firmware/devicetree/base/pinctrl/pwm1 /sys/firmware/devicetree/base/pinctrl/pwm1/pwm1-pin /sys/firmware/devicetree/base/pinctrl/pwmir /sys/firmware/devicetree/base/pinctrl/pwmir/pwmir-pin /sys/firmware/devicetree/base/pinctrl/pwm2 /sys/firmware/devicetree/base/pinctrl/pwm2/pwm2-pin /sys/firmware/devicetree/base/pinctrl/pwm0 /sys/firmware/devicetree/base/pinctrl/pwm0/pwm0-pin /sys/firmware/devicetree/base/__symbols__/pwm0_pin /sys/firmware/devicetree/base/__symbols__/pwm3 /sys/firmware/devicetree/base/__symbols__/pwm1 /sys/firmware/devicetree/base/__symbols__/pwm1_pin /sys/firmware/devicetree/base/__symbols__/pwmir_pin /sys/firmware/devicetree/base/__symbols__/pwm2_pin /sys/firmware/devicetree/base/__symbols__/pwm2 /sys/firmware/devicetree/base/__symbols__/pwm0 /sys/firmware/devicetree/base/pwm@ff1b0030 /sys/firmware/devicetree/base/pwm@ff1b0020 /sys/firmware/devicetree/base/pwm@ff1b0010 /sys/firmware/devicetree/base/pwm@ff1b0000 My guess was that I should use /sys/firmware/devicetree/base/pinctrl/pwm1. Putting that in my ats config, when I run ats -t, I get: info:'SYSTEM' Table info: 'BOARD' Table info: 'NAME' = ROCK64 info: 'CPU' = RK3328 info: 'THERMAL0_CTL' = /sys/class/thermal/thermal_zone0/temp info: 'THERMAL1_CTL' = ERROR info: 'PWM_CTL' = /sys/firmware/devicetree/base/pinctrl/pwm1 info: 'MAX_CONTINUOUS_THERMAL_TEMP' = 45 info: 'MIN_CONTINUOUS_THERMAL_TEMP' = 20 info: 'MAX_PWM' = 255 info: 'MIN_PWM' = 40 info: 'ALWAYS_ON' = false info: 'PROFILE_NAME' = profile0 info: 'PROFILE' = 0 info:'Pratio' timers info: 'Pratio[ -20 - 20 [' = 0 info: 'Pratio[ 20 ]' = 40 ... info: 'Pratio[ 45 ]' = 255 info: 'Pratio[ 45 - 70 [' = 255 (the temperature range is low so that the fan would definitely run if it was working) When I run this command, the fan doesn't spin. For what it's worth, here's the rest of the output of ats -t: Stopping for[ seconds ]............... 3 CPU Temperature[ max 70 °C ].......... 0 GPU Temperature[ max 70 °C ].......... 0 Fan PWM Duty Cycle value[ 0 - 255 ]... 190 -------------------- Running for[ seconds ]................ 10 CPU Temperature[ max 70 °C ].......... 39 GPU Temperature[ max 70 °C ].......... 0 Fan PWM Duty Cycle value[ 0 - 255 ]... 0 -------------------- Any idea what might be wrong?
  13. Running latest Jammy image and trying to attach USB to SATA 3 SSD. I tried two different USB 3 to SATA adapters and they both show up in lsusb: Bus 005 Device 002: ID 2109:0711 VIA Labs, Inc. VL711 SATA 6Gb/s bridge sudo fdisk -l doesn't show drive, but I can plug into my desktop and it mounts disk. Could be related to https://github.com/MichaIng/DietPi/issues/5378
  14. That's all, really. I appreciate the amount and quality of work that the leaders here generously share with the community. I donated an amount that would buy 6 bottles of my preferred local brew, hoping that the project's accountants will allow at least that tiny drop in the total donation pool to be used to celebrate a little. It's well-earned!
  15. I just cannot access spi on my Rock64. I read a couple posts of it but none works out for me I'm running Armbian 22.05.3 Focal with Linux 5.15.52-rockchip64 on it. Tried enabling spi-jedec-nor and spi-spidev overlay, but with none of them I get output when executing ls /dev/spi*. Is it maybe a hardware issue, reading this post suggests that to me: https://forum.pine64.org/showthread.php?tid=5473&pid=34616#pid34616 But I cannot make much sense out of it. Can anyone help me get spi working?
  16. Today I flashed the latest version CLI Jammy img instead of my old OS.First system boot,I can get the IP from my router DHCP and I can ping the Board's IP,but SSH connection refused.Now the Latest System won't start SSH service in first boot?I haven't a monitor,so I cant check the system booted or not.
  17. Hi, Sorry wasn't sure where to put this. Looking for a lightweight desktop linux for a ANBERNIC RG351MP https://anbernic.com/collections/handheld-game-console/products/anbernic-new-rg351mp-retro-games-built?variant=40994614542500 Rockchip RK3326 & Mali-G31 GPU Tried the generic ARM64 version but no boot. Do any of the other supported boards have the same CPU & GPU combo? Thanks
  18. Since Linux 5.15, the USB3 port on ROCK64 does not work anymore with Armbian. The following kernel errors are shown: usb 5-1: USB disconnect, device number 2 [...] usb usb5-port1: Cannot enable. Maybe the USB cable is bad? This has been reported by multiple users with multiple drives and cables, also disabling UAS does not help. lsusb shows the drive/device, but lsblk does not. I know the ROCK64 is not currently supported by Armbian/has no maintainer, so I'm not expecting anything, just posting this as information and probably someone with more insights into the rockchip64 kernel build has an idea or workaround.
  19. 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.
  20. 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?
  21. 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
  22. Hi, I need some guide and steps required (and if possible) to enable hardware acceleration using FFmpeg. Is the only thing I need since the idea is to use this SBC as Surveillance platform (for example, with Motion+Motioneye or Shinobi). Currencly without hardware accel, using 3 rtsp cams uses each 100% of a core (which translate to 300%). I've searching a lot, but I saw hwaccel with others apps, but not in particular with ffmpeg. I already managed to compile it with --enable-rkmpp (h264_rkmpp hevc_rkmpp vp8_rkmpp vp9_rkmpp) and available hwaccels: vdpau cuda vaapi drm opencl. Any help will be much appreciated. Currently fresh installed OS: Armbian Focal Thanks in advance.
  23. Hi, I'd like to control ws2812 led's via gpio spi. I'm using this octoprint build by ldiaz: I checked /boot/armbianEnv.txt and there's overlay_prefix=rock64 and after enabling spi via armbian-config also overlays=spi-spidev. Then I rebooted but ls /dev/spi* shows nothing. Can anyone help?
  24. Hi, I wanted to try this build so I cant test HW (using the legacy kernel). But, is impossible to make Rock64 boot correctly, having random kernel crashes, It does boot with the 5.10.x kernel version and work just fine, but I need the Legacy one so I can test HW. I can only attach a photo since there is nothing I can do since the OS is halt. Any ideas? Thanks.
  25. I have Rock64 board with latest Armbian Focal flashed on it. I want to use it with this HDMI display by Waveshare: https://www.waveshare.com/wiki/7inch_HDMI_LCD_(H)_(with_case) Now, when I connect it to Rock64 it runs as 1080p downscaled by HDMI controller on display, resulted image is garbage, even though it is present. As was discussed here: https://forum.armbian.com/topic/10071-tinker-board-hdmi-resolutions-do-not-all-work/ current kernel/u-boot doesn't have required video mode to run this display properly. I tried to set required mode with xrandr but with no success. Can anyone help me to figure out how to patch kernel/u-boot to get this thing work properly? And what exactly is setting video mode kernel or u-boot? I've found where video modes are set in u-boot source, but I suspect that adding required video mode there won't be enough, am I right?
×
×
  • Create New...