Search the Community
Showing results for 'rock64'.
-
Ram configuration, something else. They aren't the same board, and the Rockchip designs, using such complex PMIC's, don't usually just come on with each others' images. (MiQi and Tinker won't boot each other's images, I don't believe Renegade and Rock64 will either). I need to sit down and make a wip/csc for this board. Confirmed, renegade elite has LPDDR4, Firefly has DDR3.
-
Has anyone figured out what is preventing APCUPSD to work here? I am having the same issue on Odroid C2 using the latest Ubuntu 18.04 image. Everything works fine on Rock64.
-
Problem with patch level solved.. armbian has 4.4.174 kernel now and preempt-rt kernel updated to 4.4.174 patch... But preempt-rt patch fail to applied to armbian rock64 kernel 4.4.174 because armbian kernel is not stock kernel but already patched kernel.. preempt-rt patch is for stock kernels only.. Is there any solution for that ? Can rockpro64 run with stock kernel ?
-
Thanks, I'm already doing a test with my M4 with Armbian Bionic. It seems to be set to 250. I'll do some tests with different settings. I didn't know about this, it indeed seems very important. That's another thing I have to add to "reasons why benchmarks can be misleading". Spoiler I received the OPi3 today, that's another vat of issue's it seems. unable to keep it cool with heatsink+fan and underclocks at 60°C to seemingly 1.5Ghz. It seems to underperform to the Rock64, OdroidC2. But that's another topic for another day.
-
Blender results BMW render @ 1080p Odroid N2 @ 1.9Ghz-1.8Ghz Bionic 50m28s NanoPC T3+ @ 8x1.4Ghz Armbian Bionic 1h10m25s The NanoPi M4 @ 1.5Ghz-2Ghz Armbian Bionic 1h13m28s 1.4Ghz-1.8Ghz FriendlyElec Bionic 1h28m13s RockPi 4B @ 1.4Ghz-1.8Ghz Bionic 1h17m22s Odroid C2 @ 1.75Ghz 1104Mhz ram Bionic 2h10m21s 1.5Ghz 912Mhz ram Bionic 2h35m10s Rock64 @ 1.5Ghz Bionic 2h55m56s The difference is huge. The N2 is in a league of it's own here. You can only compare 64-bit with 64-bit OS's with Blender. And Stretch performs a bit worse than Bionic. 7zip is an ok test for cpu only. Blender is good to see the performance for most daily use(cpu+ram).
-
I'd like to think that pine64 would send you the current and popular selling rev 2 which I've had for 9 months as well as rev 3 when it comes out as you as well as every other dev on Armbian is helping make the rock64 more reliable and useful
-
Thanks for your hard work. Just started using Armbian on my Rock64 rev 2. Pleased with performance and resource usage. I did notice that it updated from 5.73 to 5.75 during an upgrade but when I login, it still shows 5.73.... I read that Rock64 rev 3 with POE will be released in the coming months.
-
I was familiar with the vpu2 hw regs that needed to be set from creating an experimental mpeg-2 hwaccel for the rk vcodec kernel driver some time ago. After collaboration with @jernej to create a v4l2 request api hwaccel and getting it working with the Allwinner cedrus driver I learned enough v4l2 to get the rockchip vpu MPEG-2 decoder to work on my Rock64. Ezecquiel Garcia was then very helpful and got my initial work (decoder boilerplate was copied from encoder and chromium os) ready for upstream and submitted the MPEG-2 decoder for rk3399 on top of his decoder boilerplate work. RK3288 and RK3328 was left out as they requires clk and drm changes to work properly, patches are being prepared to be submitted. The rockchip-vpu-regtool was created to help set correct hw regs for both vpu1 and vpu2, mpeg2.txt was created based on mpp hal code, some imx-vpu-hantro code along with some docs was also useful to get more insights into the rockchip vpu.
-
Thread to keep track of the RK3328. Boards supported with this kernel: Pine64 Rock64 (multiple hardware revs, will need board identification in case of problems) Rev1 and Rev2 Rev3 Libre Computer Renegade/Firefly ROC-RK3328-CC (same board) Current events: Rock64 Rev 3 appears to need some u-boot tweaks. time to re-assess mainline support Boards have USB3, ethernet, HDMI all working. needed: Renegade at least capped to 1.3 GHz somehow No 4K Renegade sound not set up yet, should be easy enough
-
For mpeg-2 on rk3288/rk3328 there are some other patches needed, see my rockchip-5.x-vpu branch for working rk3288/rk3328 mpeg-2 decoding on v5.0-rc6. clk, drm and dts patches will be sent upstream any day now. Also check out https://github.com/mpv-player/mpv/pull/6461 and the linked ffmpeg hwaccel if you want to use mpv or kodi-gbm for testing, I recently pushed dynamic selection of media/video device to hwaccel so should work without forcing decoder to /dev/video0. I pushed two libreelec test images to http://kwiboo.libreelec.tv/test/ for tinker board and rock64 if you want to test mpeg-2 decoder, it includes patches from my rockchip-5.x-rebase and rockchip-5.x-vpu linux branch.
-
Hi, got a H96 Max+ with 4GB and 64GB eMMC today (https://www.banggood.com/H96-Max-Plus-RK3328-4GB-RAM-64GB-ROM-Android-8_1-USB3_0-5G-WIFI-TV-Box-Support-HD-Netflix-4K-Youtube-p-1335810.html?ID=533601). It's booting Android 8.1 with a kernel 4.4.120, build date 2018-12-18. I opened it using a GB-5A opening tool. Attached are some pictures. 1. PCB is labelled as "RK3328_8D4_V1.1" with date "20180703" 2 .Wifi/BT chip seems to be: HS2734A V15628 98MA 3. eMMC seems to be Samsung: SEC525 B031 (unreadable due to QA marks) I flashed Armbian_5.68_Rk3328-tv_Ubuntu_bionic_default_4.4.154_20190110.img from your mega account to an microSD card. Tried all rk3328 FDTs in extlinux.conf # Result: LABEL=ROOTFS does not exists + drop to busybox rk3328-box-trn9.dtb rk3328-box-z28.dtb rk3328-box.dtb rk3328-evb-100m.dtb rk3328-evb.dtb rk3328-mx10.dtb rk3328-roc-cc.dtb rk3328-rock64-android.dtb rk3328-rock64.dtb rk3328-rockbox.dtb # Result: black screen/crash? rk3328-box-liantong.dtb rk3328-evb-android.dtb rk3328-t9-android.dtb Thanks Roland
-
I'm going to hazard a guess that https://forum.armbian.com/forum/34-hardware-hacks/ Might have the information you're looking for, there are 3 different "general-purpose" gpio libraries there, if the rock64 isn't in any of them, the documentation is relatively clear on how to add them.
-
So, I never resolved the problems with the Pine64-CPP library but I found an alternate. First, I used bash scripts to make sure the Rock64 was working, and I had the right pin addresses. https://github.com/Leapo/Rock64-BashGPIO I used the table table from this website to correctly identify the gpio indices. https://github.com/Leapo/Rock64-R64.GPIO...GPIO-Modes I used the items from the column labeled GPIO# (ROCK) Lastly, I used the GPIO Class from the following. https://github.com/halherta/RaspberryPi-GPIOClass-v2 Even though it is was created for the Raspberry Pi, I found that it correctly manipulated the files in /sys/class/gpio on my Rock64. Note: I have only tested the GPIO read function, since that is what I'm trying to do for my project.
-
Hello, I'm new to Armbian which i just installed on a Rock64 board (Armbian_5.65_Rock64_Ubuntu_bionic_default_4.4.162.7z). I have to say that my first impressions are that Armbian is a nice Os and that this is the one that causes me the less troubles on the Rock64 to install and to start. My goal is the write/port an application in C++ preferably by using Qt. Here, it is the problem. I tried to install it using command: sudo apt-get install qtcreator sudo apt-get install qt4-designer "Qt 4 Designer" seems installed correctly and seems working properly. Qt Creator was not installed completely, the IDE is installed but there is no kits installed (nor Qt4.8, nor Qt5.x). I was not surprised because during the execution of "sudo apt-get install qtcreator", some errors happened; below the text of the error: Setting up nodm (0.13-1.3) ... Job for nodm.service failed because the control process exited with error code. See "systemctl status nodm.service" and "journalctl -xe" for details. invoke-rc.d: initscript nodm, action "start" failed. ● nodm.service - Display manager for automatic session logins Loaded: loaded (/lib/systemd/system/nodm.service; static; vendor preset: enabled) Active: activating (auto-restart) (Result: exit-code) since Thu 2018-12-27 16:51:04 CET; 26ms ago Docs: man:nodm(8) Process: 18678 ExecStartPre=/bin/sh -c [ "$(cat /etc/X11/default-display-manager 2>/dev/null)" = "/usr/sbin/nodm" ] (code=exited, status=1/FAILURE) dpkg: error processing package nodm (--configure): installed nodm package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: nodm E: Sub-process /usr/bin/dpkg returned an error code (1) I also see such error implying "nodm.service" (?) during the install of other packages. Someone can help? Regards Pascal
-
Maximum Geek Edit: The Rock64 Revision 3 is the latest version of the company’s mini PC with a Rockchip RK3328 processor. https://liliputing.com/2019/02/pine64s-single-board-computers-are-getting-2019-upgrades-prices-still-start-at-25.html
-
I didn't notice that one. I knew there was an Rock64, but I didn't check it. There was even more stuff I didn't talk about. A tablet kind of thing, and another board with A64. I ordered the OPi3 on Friday cause I couldn't handle not being able to order the Pine H64 yet. But I still want the H64 so much. That form factor could replace many of my older/ancient devices. I'll have to see when I'll get it if it's all I imagine it to be. Could be my C2 still gives it a beating. I need passively cooled, light but fast.... The C2 still does this great at 1.75Ghz maxed without a fan. You've got to use the right tool for the job, so I've invented many jobs for my tools. In this video my RPi2b is used to record the sound, the Odroid C2 to check filmed images. And I had an RPi3b+ for gaming on the train. All a job well done. Of course 1 sbc could have done it all Cheers
-
Don't forget Rock64 Rev 3. I'll take one of those and an Pine H64 B, please.
-
3 MB/s was fine for what I was expecting over my 802.11n network, but now I've upgraded to 802.11ac and it hasn't increased speeds. I've seen a few users on here get 40+ MBps over wifi, so I know that higher performance is indeed possible. I think you're right with the local loopback though, seeing as it's only a gigabit connection on the Rock64
-
I have made progress by applying the attached patch and rebuilding linux-headers-rk3399.deb I then installed the deb manually with `sudo dpkg -i ./linux-headers-rk3399_5.74_arm64.deb` then `sudo apt-get install -f` However now I'm getting a different error when compiling test kernel module attached above "/bin/sh: 1: ./scripts/recordmcount: not found": I have found some references to needing to "make scripts" in the headers directory, however I've been unable to find a way to do that successfully. Any hints would be appreciated. Update: when running `sudo make scripts` in /usr/src/linux-headers-4.4.172-rk3399 I get the following error This appears to be a similar issue to here: https://forum.armbian.com/topic/7253-rock64-cannot-install-wireguard-module-on-ubuntu-1804/ I will try the suggested fix once I have had some sleep. fix-linux-headers-rk3399-pkg.patch
-
For completeness, the issue is only present in friendlyarm 4.4 repo: https://github.com/friendlyarm/kernel-rockchip/blob/nanopi4-linux-v4.4.y/scripts/package/builddeb#L325 Which is the source for the default kernel for 'rk3399' family boards such as nanopc-t4 (https://github.com/armbian/build/blob/master/config/sources/rk3399.conf). It looks like the fix has already been applied to both the 4.4 and mainline ayufan-rock64 repositories (which are the source for 'rockchip64' boards): https://github.com/ayufan-rock64/linux-kernel/blob/release-4.4/scripts/package/builddeb#L325 https://github.com/ayufan-rock64/linux-mainline-kernel/blob/master/scripts/package/builddeb#L158 (not sure whether Armbian is sourcing the release-4.4 branch though).
-
I can decode HTSP from tvheadend with vlc on a pi zero at 1280x1024 but need something more powerfull for 1920x1080. (PI3B+ do the job so I think a PI3A+ would do). Can you give me some advice for small device that can do it ? Do you think a Rock64 could transcode DVD mpeg2 to h264 on the fly ?
-
My memory test numbers TV box MX10 in the line will indicate what dtb and what is the result core 4.4 mx10 328 a5x 576 a5x-1300 597 a5x-1500 621 kernel 5.0 there's one working dtb MX10 - 336. TV box MVR9 (adjusted for the size of the RAM test output is reduced to 500 units) 4.4 a5x 531 a5x-1300 559 a5x-1500 566 trn9 604 trn9-1500 619 5.0 here is here sign in, mx-10 278 rock64 280 It is unclear what the test was measured at 5.0 MVR9 Otherwise, it becomes clear why subjectively after the transition to a new DTB on MX10 was a feeling of similar work with MVR9 , memory speed is almost equal.
-
A new version of the DEV 5.74 image using the 4.4.172 kernel (this kernel is used in General Armbian builds for Rock64 as the default). I pay attention, in this version in settings of DTS the maximum frequency of the processor 1500 is included. Therefore, when working under load, the processor heats up quickly and requires very good cooling (I recommend a fan). Here is the temperature log with MVR9 (desktop resolution 1080) when running a full-screen text video (media script with acceleration is not set). When the temperature reached 80 g , the video and sound began to slow down. Notice how quickly the temperature has reached a critical value. The heatsink on the CPU was not hot and in case I made a big hole above the radiator and on the sides for the free passage of natural air. By the way, this indirectly shows how passive cooling does not cope with the work in the case.
-
Rock64 is the server, and my apologies - I edited that post right as you were replying. Pinging in a loop from the Rock64 back to the Rock64 across different ports got a result - I haven't been able to get it to work from that IP to my desktop on the same network though. Not sure if it matters but I'm running off of an SD card and not eMMC or anything. No additional software that I would be able to name either than Plex and Samba. From what I remember the speeds were that slow prior to setting up Plex. Armbianmonitor link is http://ix.io/1zC9
-
So the Rock64 is the server? As for SSH, it takes very little bandwidth. Do you have any special software installed that might be interfering? Also please post the armbianmonitor -u link, that might be helpful.
