Search the Community
Showing results for 'rock64'.
-
Hi @Thewonderer, I have dev samples of a few boards, it's one of the ways we work with vendors that show interest. My other Rock64 is a pre-V1, so I wanted to make sure I had something representative moving forward. I've had some personal projects going, and @martinayotte moved so much around on these boards I decided to stay out of the way. Taking a look at the u-boot configs and device trees tonight to see if I can find a difference, the Renegade image got to the point of loading kernel (obviously didn't get past that with the differences in DTS's) on the Rock64 3.0 while the Rock64 V1/2 image would not, telling me there's no hardware issue. @martinayotte did you try to boot Renegade with newer u-boot? I can't remember if you have one or not.
-
How's the Rev 3 of the ROCK64 going? How did you manage to get it as the website doesn't seem to show whether its rev2 or 3 that you get.... Realise there are more powerful boards out there but don't need some power hungry board for my needs, though the Odroid N2 looks tempting and low power too.
-
So if I understand correctly, the next kernel release for rock64 will be 5.0xxx! That's great. I see that Ayufan on github is still working on 4.4 . Personally I'd be happy with just a stable build.... Thanks for all the hard work. Would like to think that there is still plenty interest in the the 3328....
-
Just after you have choosen rock64 board from the dialog, next dialog should show "default" or "dev" branch ...
-
I must sound annoying, that is because I don’t have much experience. When I run the ./compile.sh EXPERT=YES it still grabs the 4.4, if I look at non supported tree the ROCK64 is not there.
-
there is no 4.20.y for Rock64, or I don't see it. i get impression that there is not much interest for the rockchip 3288. Should I just give up on trying to update ?
-
Hello. I am wanting to upgrade my Armbian ubuntu on the Rock64 to a newer kernel. I have set up a Virtual machine with ubuntu 18.04 x86 on my mac, and it is working fine I have been following the directions on the https://docs.armbian.com/Developer-Guide_Build-Preparation/ when run the build it is pulling in the old 4.4.x kernel, i want to upgrade to the 4.14 kernel (the reason why I picked 4.14 it has better performance.) how can I upgrade the kernel to a later version ?
-
rsync between two external hdds caused rootfs vanished
dkking replied to Jerry Jyrer's topic in Rockchip
is it the same issue faced by users of rock64? ayufan Rock64 and rock64 Armbian -
newer kernel version could be compiles with the armbian-build-system. https://docs.armbian.com/Developer-Guide_Build-Preparation/ do you use armabian on your Rock64?
-
On March 6th a big update to the rock64 DTS happened on the default kernel upstream. It included hooking to the SoC codec, so we should have that feature available soon, I haven't personally tested it yet.
-
JMCC: You'd asked for a follow-up, I have been using a 4GB Rock64 as a primary desktop machine for about six weeks now using Armbian + your script. Thank you very much for the script, being able to use sites like YouTube etc with streaming video and have it work (in full screen) is very nice. Chromium is horribly unstable for me, I find that it works well for the first while, but eventually locks up the box almost completely. I ran vmstat on a console to try and figure out what the issue is, I think it is because I have a microSD card for storage and that is basically not a long-term solution, I need an eMMC. I was never able to get to get the Rock64 to talk properly to my 27" screen, I always experienced severe tearing and flickering -- I believe I will have fewer problems with a newer screen, so that is another solution I want to try, in the meantime I use a small screen with low resolution -- I will provide more feedback when I have a better storage device and screen, in the meantime I get by and the script helps a lot with getting this SBC to where I need it to be.
-
So, let me ask some questions to make sure I have the full picture, and unpack some of this: Have you tried booting the device with only 1 device plugged into the Rock64, in the usb2 port that is giving you trouble? Is the USB3 drive you are using self-powered or powering from the USB port itself, and what are it's power requirements? Some background: One of the USB 2 ports on these boards is a USB OTG with the device tree specifying it as a host. That used to be problematic before the "host" mode was explicitly stated. That said, I don't think that's the issue here, although I'll double check a new image if I get time. The other issue is basic single board computer reality, which is always a tough pill to swallow: The entire board only has available the amount of power a single USB 3.0 port is allowed to consume according to specification. I wish USB had some kind of split specification compliance so that you could show that your device is USB3 communication compliant but not USB 3.0 power compliant. It sounds like the USB power is falling below 4.75 volts and some of your devices are disconnecting due to under powering. If the drive has no provisions for power other than the USB port, then a powered hub or powering the board via GPIO (only for the experienced) is recommended. Even if the drive seems to work without other things plugged in, you will face data corruption if you're underpowering it.
-
I tried for the third time to get an answer from archlinux's kevin on the usb3 patch for renegade on archlinuxARM on another account (scetchy, I know). Apparently I'm added to the sh*tlist for "blatantly" ignoring his Oh, so important rules that he had to ban me from contributing to the project instead of acting like a normal adult. I sent 2 emails - ignored - and looked over the contributor guidelines again. I formatted my patch as seen in other merged PRs and the onl response I got was " Skirting bans from your blatant, irreverent disregard for posted rules and requirements and then continuing that tradition has now ensured your permanent placement on the sh*tlist " I'm so done with this guy. He thinks he's a god. Just look at the way he talks, jesus christ. Seems like he's allergic to equal support for rk3328 boards. Rock64 has exclusive rights to usb3... At least this way I finally got an answer instead of the usual ignore.
-
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, 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 -
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?)
