Its already several days of testing ROCK64 and I'm still getting so much disappointing. I've installed Android 7.1 - could not get neither bluetooth, nor wifi USB dongles working. Installed Linux UBUNTU, managed to get bluetooth and one of the Wifi dongles working, but perfomance of whole system is on level of pentium 1 1980year of manufactury - even can not play youtube video at 1080P smooth.
What is your experience with this SBC? What is the best distributive/OS to run on this board kindly presented through pine installer?
P.S. I bought this board in maximum options (4GB RAM) to build CarPC, however my feelings at the moment - I wasted another 100USD
I've got TP-Link TL-WN823N usb wifi dongle based on RTL8192EU chip and it does not work in Linux loaded to ROCK64 eMMC
Does anyone know how to get this usb dongle working?
I just upgraded from 0.6.15 to 0.6.22 of xenial minimal install. Now i can't ssh to it. When I edit the sources file and ran a apt-get update and apt-get upgrade it said 2 had been held back, which were the new pre-release sources. So I ran an apt-get install instead which seemed to work, but when i did a restart, i can't access it but can ping the IP. Can anyone give some help...
I also have found it impossible with my near limited linux experience to set a static ip address using standard tips from ubuntu forums. Not sure where i'm going wrong...
EDIT
Sorry, my bad, it had changed IP address on me. Now working fine. Not sure why the sudo apt-get upgrade didn't work though.
I had my Rock64 working with the Stretch Mate image. Also the latest Android was booting fine.
Now I tried flashing Uboot to the SPI which seemed to work, cause the white LED was blinking.
Unfortunately now nothing is booting anymore. I tried to use the Uboot erase SPI image but it did nothing.
Is there an alternative way to erase the SPI ?
Could it be that the Uboot image eis faulty ?? How to recover my Rock64 now ??
So bear with me here got to get the fix. I don't like re-inventing the wheel but was unable to find a driver that was built for the RTL8812AU adaper in the store, I bought one, mainly for 5GHz band as well as 2.4 it does not work out of the box on the artful build (ayufan's) since he is one of the main kernel grinders, I looked there first... did not see anything, for the RTL8812AU. I was plenty of questions, but no working solutions... so.. did some digging, most driver code is a base, as drivers are added, and just functions are added or adapted, rarely is a whole driver written if a similar one exists.
So, I gave it a try..., ran into error(s), most were warnings, those are not uncommon, I like to get rid of them,but mostly at this level they are informative, rather than deadly... I like no warnings, but with any portable code shared among several builds, and probably at this age several compile versions, you will see them... So, most of the warning were simply generated from older 'C' coding..., the main thing to me in maintaining code is some notion to 'overcode' if it works on similar or elsewhere, it is probably not a complicated fix.
That was the case on this... it terminated with an error:
include/linux/sched.h:1198:42: warning: type qualifiers ignored on function return type [-Wignored-qualifiers]
const struct sched_group_energy * const(*sched_domain_energy_f)(int cpu);
^
/root/rtl8812AU/core/rtw_br_ext.c: In function 'nat25_db_handle':
/root/rtl8812AU/core/rtw_br_ext.c:1444:28: error: implicit declaration of function 'csum_ipv6_magic' [-Werror=implicit-function-declaration]
hdr->icmp6_cksum = csum_ipv6_magic(&iph->saddr, &iph->daddr,
^
cc1: some warnings being treated as errors scripts/Makefile.build:258: recipe for target '/root/rtl8812AU/core/rtw_br_ext.o' failed
The fatal error in the compile was this (if you are a coder)...:
/root/rtl8812AU/core/rtw_br_ext.c:1444:28: error: implicit declaration of function 'csum_ipv6_magic' [-Werror=implicit-function-declaration] hdr->icmp6_cksum = csum_ipv6_magic(&iph->saddr, &iph->daddr,
^
Did some digging in header files...experience has taught me more often than not with 'development' be developed on these days, someone probably improved the code in some other place..., here is the fix:
in core/rtw_br_ext.c I added the following after digging...
(Actually I didn't put in the spaces and comments, I did here so others could see the surrounding code, but the fix was not at line 1444, it was the inclusion of a now independent header file that apparently did not exist on the building machine of the original code or it was in an included header file)
Earlier, I questioned about manifest defines, in actuality, the is a linux fix, but it is at the Linux level, not the actual low level code writing, and it works. So if someone want to include it in a distributed, please help yourself, you can add other defines if necessary, I suppose you could tighten it up more, but the above put in the manifest define for the header, without changing the code generously, and this was for the 'artful' load, not previous loads... so since these are somewhat experimental boards, either way it was a good excercise, and it works on the rock64 under artful where it previously was unavailable with the build.
I saved the broken make (make.out), and I saved the one that worked..(make.good)
Following the instructions on the above URL do not work did not work out of the box, as my CROSS_COMPILE was set to aarch64, ayufan's is arm64 so, I made it simple, rather than digging reconfiguring, etc, etc by doing the simplest change at the shell:
export ARCH=arm64<enter>
That said - I don't care what your CROSS_COMPILE ARCH is, override it. (I am lazy... guess I should fix my cross compiler)..
using the gcc-5 that it prompted me to use, was easy as well (geeze been away from this along time, I am not on board with Tim Cook, everybodyisn't a coder, in fact most get too intimidated by very verbose error messages... too many coders create too many of everything..., about 4-5 different 'current' version of gcc these days. 8 years ago we were only using a couple).... I pulled gcc-5.
I compile with the following added on and go watch tv while it compiles..
make all (all is mostly) 2>&1 | tee <make.out>
With the correction,
make CC=/usr/bin/gcc-5 2>&1 | tee make.good
ended with:
include/linux/sched.h:1198:42: warning: type qualifiers ignored on function return type [-Wignored-qualifiers] const struct sched_group_energy * const(*sched_domain_energy_f)(int cpu); ^ LD [M] /root/rtl8812AU/8812au.ko make[1]: Leaving directory '/usr/src/linux-headers-4.4.77-rockchip-ayufan-136'
The kernel module!!!!!
Followed by a:
make CC=/usr/bin/gcc-5 install <- this installs the kernel module...
So, I never hand setup a wireless on linux, that is another story, however I had to configure wpa_supplicant, I won't go into that here, but there is always a first time.
here is the end result (I am logged in on the wireless, it is connected... we will see how good the code is..., wearing it in now):
root@rock64:~/rtl8812AU# lsusb
Bus 005 Device 003: ID 05e3:0617 Genesys Logic, Inc.
Bus 005 Device 002: ID 05e3:0617 Genesys Logic, Inc.
Bus 005 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 004 Device 004: ID 0bda:8812 Realtek Semiconductor Corp. RTL8812AU 802.11a/b/g/n/ac WLAN Adapter
Bus 004 Device 003: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 004 Device 002: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
root@rock64:~/rtl8812AU#
Does anyone have any idea how exactly to go about this procedure? I mean, I managed to build kernel 4.15.5 from the vanilla sources, and I'm aware of what I'd do next on an x86-64 machine (make a .deb package, install it)...but, and this is the part that throws me for a loop, I'd normally just run update grub and reboot. I've looked in the /boot partition, and I'm feeling the process might be a little more complex here...I see a label for kernel-4.4 in extlinux.conf, but nothing immediately in the way of tools for adding to this file a new image...
Is it all right to plug the Rock64 to a 5V/2.4A USB super charge socket? I should've gone with the prong version but I ordered the barrel to USB cable instead. The Rock64 boots up fine and I did some playing around (ran two x265, 1080p videos through Kodi on Android).
From what I've read on this forum, some have even gone as far as turn the board up on a 1 amp with success, so 2.4A seems good enough, right? What about this "super charge" thing? I know that's meant for phone charging, so I'm concerned if this could damage the board over time.
)