Search the Community
Showing results for 'rock64'.
-
I like the armbian-system-packages armbian header information. Will modify my rock64 to output the additional information. Thanks for the tip!
-
I have a similar issue. My Rock64 doesn't seem to higher than 1296000Hz when 100% stressed using "stress -c 8 -t 60s &". roy@rock64:~$ stress -c 8 -t 60s & [1] 23003 stress: info: [23003] dispatching hogs: 8 cpu, 0 io, 0 vm, 0 hdd roy@rock64:~$ cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_max_freq 1512000 roy@rock64:~$ cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_min_freq 408000 roy@rock64:~$ cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_cur_freq 1296000 stress: info: [23003] successful run completed in 60s [1]+ Done stress -c 8 -t 60s
-
Just saw these recent changes to the mainline Kernel on Ayufun's git repository. Maybe this will help... Will these come across to the Armbian build? https://github.com/ayufan-rock64/linux-mainline-kernel https://github.com/ayufan-rock64/linux-mainline-kernel/commit/41eeb7cd789ea7cac0cbf4b35b53055f354da757 https://github.com/ayufan-rock64/linux-mainline-kernel/commit/41eeb7cd789ea7cac0cbf4b35b53055f354da757
-
I want to make an Armbian image with BTRFS rootfs. I did, it works. My problem is the default setup only assign 58M to the partition for /boot, leave only 18M of free space. I want to make it 150M. I had some bad experience related to such issue before - when I did an "apt upgrade" that involves building of new initrd.img file, the /boot partition is too small to allow the upgrade. So, I want to fix this issue before I build other stuffs on it. I have browse the docs.armbian.com and read couple of README under the build/ folder but find no hints. Thanks in advance for your help P.S. I think my question should be a general one, not build environment or SBC dependent. But for just in case I use the mini.iso image here (i.e. Ubuntu Bionic 18.04 x64) to build a KVM vm as build environment. I pick the followings when being prompted (1) Full OS image, (2) Not change kernel conf, (3) rock64 board, (4) stretch, (5) image with console interface -
Hi TonyMac32, hope this info helps uname -a Linux rock64 4.4.174-rockchip64 #6 SMP Sun Feb 10 10:43:16 CET 2019 aarch64 aarch64 aarch64 GNU/Linux dmesg ip link show dev eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 1000 link/ether 8a:aa:04:a1:19:ec brd ff:ff:ff:ff:ff:ff ifconfig eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.1.8 netmask 255.255.255.0 broadcast 192.168.1.255 inet6 fe80::8023:c6f6:b8cd:f435 prefixlen 64 scopeid 0x20<link> ether 8a:aa:04:a1:19:ec txqueuelen 1000 (Ethernet) RX packets 25652717 bytes 25286449632 (25.2 GB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 21508044 bytes 10823532692 (10.8 GB) TX errors 135 dropped 0 overruns 135 carrier 0 collisions 0 device interrupt 40
-
Hi, my rock64 (rev2) with the latest build of Armbian randomly looses its network connection. I couldn't use the armbianmonitor -u as it had no network connection, but when i use ifconfig, I can see it's still got it's settings and is the NIC lights are on. ifconfig showed 6 TX errors. My NIC is set to DHCP with static reserved IP address to an ASUS router. I leave it on 24/7 and check it once a while as it pretty much is used as a NAS with a single USB 3 drive. This morning I connected up via HDMI and a USB keyboard and logged in successfully. I don't have much Linux experience so wasn't sure how to capture the logs to SD card so i could copy them up here later. The NIC dropouts occur about once a week at random days and times. I have tried use ifup and ifdown to try and re-enable the NIC, but when I did this I got a stack dump and I couldn't enter any further commands into Ubuntu. Next time the NIC fails, what command(s) should I use? I've had this issue before on the later ayufun arm64 ubuntu builds too. I see the kernel has been updated to v5 over at ayufun's github, maybe there are some code changes that might help. I did read that dropping the MTU down from 1500 to 1492 might help, but don't really want to make random changes. Any suggestions much appreciated.
-
Hi, I'm using ARMBIAN 5.73 stable Ubuntu 18.04.2 LTS 4.4.174-rockchip64. It seems max clock for all cores is 1.51 GHz, however the output of cpufreq-info shows that 1.51 GHz is hardly used, despite CPU load at 100% (Plex media server transcoding), it sits for most of the time at 1.392 GHz. Am I missing something? I tried also changing governor to "Performance", but this didn't help. uname -a Linux rock64 4.4.174-rockchip64 #6 SMP Sun Feb 10 10:43:16 CET 2019 aarch64 aarch64 aarch64 GNU/Linux cat /sys/devices/system/cpu/cpu{0,1,2,3}/cpufreq/scaling_available_frequencies 408000 600000 816000 1008000 1200000 1296000 1392000 1512000 408000 600000 816000 1008000 1200000 1296000 1392000 1512000 408000 600000 816000 1008000 1200000 1296000 1392000 1512000 408000 600000 816000 1008000 1200000 1296000 1392000 1512000 cpufreq-info output: CPU has heatsink and fan, temperature stays below 55 degrees C with 100% constant load. Many thanks for your help. Regards. Christian
-
Right, I'm getting a statement that the gpios on the rk805 don't exist from the driver, see debugging is in order there if I have time. The Rock64 patches look the same, I'll test that when I can. For the drive level, I'm hoping to capture the waveforms with my oscilloscope to demonstrate the differences beyond theory and some rectified boot failures, then I'll set them up as overrides in the individual dts's as Robin rightly pointed out on a similar topic that the increased drive level will cause increased EMI from the board, some users won't be fan.
-
@jpegxguy the LED patch applied but didn't work on 4.20, have you tested it against the 5.0? Just so I'm not losing my mind. Hang on, https://github.com/ayufan-rock64/linux-mainline-kernel/commit/da36a16b40628f7cc3ef1b662748cac93e3ff4ce hmm, already in there on our sources...
-
My Rock64 is using this build since 6 weeks : Linux rock64 4.20.0-rockchip64 #5.72 SMP Thu Jan 17 16:15:05 EST 2019 aarch64 GNU/Linux EDIT : Now building Ayufan 4.20.13 ... will see ! EDIT2 : My Rock64 is now updated with 4.20.13 without any issues ...
-
@jpegxguy For the mainline ethernet tx/rx delays, were those just copied from the Rock64 or were they empirically determined? They're caused by trace impedance/etc, so they're tied to the specific hardware. I'll dig up the thread/tool Ayufan and Tkaiser were using and see what I get, there might be some more to gain there, since obviously the default ones are fairly bad. @Igor Any argument against moving Ayufan's RK3328 mainline to "next" and putting true mainline at "dev"? I think it's to the point that 5.1/5.2 are nearly to RK3288 levels of support in mainline. [edit] Fixed the lower USB port on Renegade.
-
No ethernet on mainline kernel - Libre Computer ROC-RK3328-CC
TonyMac32 replied to jpegxguy's topic in Libre Renegade
No harm, and yes, I'll tag you in the rk3328 thread since this also impacts the Rock64 v1/v2/v3 -
The newest revision does not boot from current SD images. I'm working to debug why. If anyone else has a board and can test it out, let me know. The eMMC will boot, no problem, so it's just the SD itself. Model: Pine64 Rock64 DRAM: 1022 MiB MMC: rksdmmc@ff520000: 0, rksdmmc@ff500000: 1 SF: Detected w25q128bv with page size 256 Bytes, erase size 4 KiB, total 16 MiB *** Warning - bad CRC, using default environment In: serial@ff130000 Out: serial@ff130000 Err: serial@ff130000 Model: Pine64 Rock64 misc_init_r cpuid=55524b50303930343200000000051f1a serial=f55c6806c317581 Net: eth0: ethernet@ff540000 Hit any key to stop autoboot: 0 Card did not respond to voltage select! mmc_init: -95, time 9 switch to partitions #0, OK mmc1 is current device ** No partition table - mmc 1 ** starting USB... USB0: USB EHCI 1.00 USB1: USB OHCI 1.0 USB2: Core Release: 3.10a USB3: Register 2000140 NbrPorts 2 Starting the controller USB XHCI 1.10 scanning bus 0 for devices... 1 USB Device(s) found scanning bus 1 for devices... 2 USB Device(s) found scanning bus 2 for devices... 2 USB Device(s) found scanning bus 3 for devices... 2 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Device 0: unknown device ethernet@ff540000 Waiting for PHY auto negotiation to complete......... TIMEOUT Ideally getting old an new to boot would be ideal, @Igor this might mean a fragmentation for this board though, like having a V2 and older and a V3 and newer build if we can't make them all play nice with one bootloader.
-
No ethernet on mainline kernel - Libre Computer ROC-RK3328-CC
suberimakuri replied to jpegxguy's topic in Libre Renegade
Interesting to hear! (Sorry to side track post). My previous building effort with armbian was smooth but turned out to be invalid because the specific rock64 was verifying on turned out to have a hardware issue. 1/6, unlucky. Look forward to your results, happy to test (new topic?) -
If you're using ayufan's mainline: https://github.com/ayufan-rock64/linux-mainline-kernel/blob/master/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dts can check to see how correct that is.
-
That image runs like poo. It's Debian Jessie and hasn't been updated in ages. The cpu handless very badly. When in use it underclocks to 1.5Ghz cause it's above 60°C. Even with a heatsink + fan I can't keep it under 60°C. It performs a lot worse than the Rock64 or Odroid C2 @ 1.5Ghz. This is not what I call an acceptable image. Ubuntu the same. It's like they try to make a game out of it to keep using the same old images for all new models. I'm not sure I've tried that one. I'll try it again. I do not need ethernet if I can get some wifi to work.
-
Awsome! Thats really what im after. Replace my current ITX amd setup for opi3. SInce this is only a storage server, i don't really care for other than networking and usb3. Idea is to build as cheap storage server as possible using existing itx case (having a small opi sized board gives me room for more drives) capable of gigabit network transfers (so usb2 is out of the question). OPI3 and Rock64 currently seem like the cheapest option. Rock64 being better supported and 5$ cheaper, but slower CPU and less usb3 ports
-
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.
