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.
Are the two LEDs (white and red) that are connected to the RK805-1 out1 and out2 pins (which seem to be general purpose IO pins according to the data sheet) controllable from user space somehow? I have noticed that at least the u-boot-spi flash tool can blink the red LED and also at least one of the available images I tried turned off the red LED after successful boot. The image I am currently running leaves both LEDs turned on all the time.
I seem to be missing the rtc-ds1307 module (I'm on Debian Stretch Mate Community). Is there a way to get this module without downloading and recompiling a new kernel?
Well, there's this thread by the moderator called Luke instructing how to boot Linux and "some" Android images from a USB device. The link to it is this: https://forum.pine64.org/showthread.php?tid=5610
I followed the instructions. I downloaded and burned ayufan's u-boot-flash-spi.img.xz image to my SD, waited for the Rock64 to start blinking, and then turned off to take the SD out. I then tried Pine64's own Android image AND Ayufan's TV version but none will boot off an externally powered HDD OR USB flash drive. The screen on my monitor doesn't even turn black or anything (no signal).
According to Luke's guide, I have to go to this link here: https://github.com/ayufan-rock64/ to check which images can be booted from SPI but I do not understand these hub pages at all. I've no idea where to even find a list of Android images that mention SPI.
I found this hub page titled "u-boot Android" or something but I have no clue what this page is even about: https://github.com/rock64-android/u-boot . I'm not Linux savvy to understand at all.
BTW, running Android through SD runs perfectly fine. But as we all know, SDs wear out -- especially for what I'll want to use the Rock64 for.
)