Jump to content

Search the Community

Showing results for tags 'rock64'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Community
    • Announcements
    • Feature Requests
  • Using Armbian
    • Beginners
    • Software, Applications, Userspace
    • Advanced users - Development
  • Upcoming Hardware
    • News
    • RISC-V
  • Maintained Hardware
    • Board does not start
    • Amlogic meson
    • Allwinner sunxi
    • Marvell mvebu
    • Rockchip
    • Other families
  • Community maintained / Unmaintained
    • TV boxes
    • Off-topic
    • Amlogic meson
    • Allwinner sunxi
    • Marvell mvebu
    • Rockchip
    • Other families


  • Official giveaways
  • Community giveaways

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start






Website URL







  1. Hi I had bought a NanoPi R4S with the goal of installing IPfire. Unfortunately that was too complicated for me https://wiki.ipfire.org/hardware/arm/friendlyelec/nanopi-r4s I had now installed Armbian and NextCloud and I am very satisfied. In about 10 hours I had "my own cloud". Therefore a very warm and big thank you to the Armbian developers. Only thanks to the Armbian, I can look over the Raspberry horizon. I wish you a very pleasant week Best regards
  2. Hi, I've booted the board from SD card with the latest image and I'm trying to configure the board to boot from MTD and use USB drive as a system drive. When running armbian-config (or armbian-install, or nand-sata-install), it fails with error "SPI u-boot image not found!". It looks like the bootloader package is missing the /usr/lib/linux-u-boot-current-rock64_23.02.2_arm64/rkspi_loader.img. Can I find it anywhere? Dmitry
  3. I have owned numerous Raspberry Pi boards over the years, and I have always have ran Kodi on one of them. For years I have been wanting to upgrade my RPi 3 as it cannot play any of my H.265/HEVC videos. With all the shortages, and how old the Raspberry Pi 4 is getting, I made a rather spontaneous purchase for this Orange Pi 4 LTS board. Getting it all setup is easy enough, but of course, the video (even with H.264!) nearly maxes all 6 cores and the video is chunky as it's just doing everything without any video acceleration. Even navigating the menu seems slow and delayed. I have been scouring these forums and other sources for about 12 hours now, and I am still unsure which route to go. Just as a test, I ran Kodi as root and it was much smoother in the menu system and seemed to do H.264 (in software of course, so it was working really hard). But broke Pulseaudio, as Pulse is hardcoded to not accept connections from root when it's not setup as a system-wide service. Anyway, that's not an option. Kodi doesn't need to, and shouldn't run as root. I was very excited, then extremely let down when I found this post: A custom image with custom repositories? Plus, I don't want X11 or Wayland plus a window manager, I don't need it! Either way, it *seems* to be tied to a completely different chipset. I've been up all night working on this, and I am starting to go delirious, so any help would be appreciated.
  4. 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.
  5. I get Kernel Panics when i do a reboot of the device with the reboot command. I don't get any Panics, when doing a normal boot of the System by powering it. The Panics don't occur on Manjaro. Updating the kernel to 6.1, did nothing for me and the Panic messages are always different and occur at different points of the Boot process. The System runs stable for days, when it boots. I don't have any clues what is going on hear, but i it seems that the device and sdcards aren't broken.
  6. 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):
  7. 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 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 # netmask # gateway # dns-nameservers 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.
  8. The initial installation went fine from the flashed image on SD card, and still works fine. However, after using armbian-config to attempt to transfer the OS and bootloader to the eMMC card, nothing actually changes. It says it formats the card and then goes through the process of transferring the files, or at least it looks like it does. But when I reboot it it's still running on the SD card and no files appear to have been transferred to the eMMC. fstab lists the UUID of the SD card and not the eMMC at all; this is also true of the bootenv section of armbian-config. One thing I did notice is that there are some new directories under /mnt : '/mnt/nand-sata-install.Jkf7AG' and '/mnt/nand-sata-install.xo9PVr'. Both of these contain 'bootfs' and 'rootfs' directories, but these are all empty. Also, 'lsblk' shows some sort of boot partitions on the eMMC: mmcblk1 179:32 0 29.1G 0 disk └─mmcblk1p1 179:33 0 28.8G 0 part mmcblk1boot0 179:64 0 4M 1 disk mmcblk1boot1 179:96 0 4M 1 disk Previously, I used this board with ayufan, booting directly from the eMMC card. Before flashing the SD card I erased the boot files from the eMMC card, and as I said the initial installation seemed to go just fine
  9. 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.... )
  10. 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.
  11. 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.
  12. 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
  13. 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?
  14. 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
  15. 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
  16. 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
  17. 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.
  18. (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?
  19. 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
  20. 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!
  21. 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?
  22. 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.
  23. 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
  24. 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.
  25. 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?
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines