Search the Community

@moso If you like, you can use my fork https://github.com/markh-de/armbian-rock64 [fork obsoleted, as all relevant changes have been merged into official tree], where I locked the rk3328 kernel upstream repo to an ayufan release tag, instead of a "living" branch. This way, things won't surprisingly break. Currently the used ayufan release provides 4.4.126, which is then patched up to 4.4.133. This image boots and works just fine (for me). @Igor Is locking to a certain upstream kernel source tag maybe generally a good idea for the "default" builds? The armbian kernel patch set depends on a certain kernel version anyway. Yes, you'd miss upstream fixes, but you'd gain stable builds. If builds fail, it's a little hard to go back in time (i.e. the armbian history) if the kernel source link points to a "living" branch (e.g. ayufan). I.e. an older revision of armbian will still fail building. Using tags would eliminate this issue and point to a fixed version supposed to be used with that version of armbian (and the provided set of kernel patches, etc.).

All non-nightly versions are O.K. https://dl.armbian.com/rock64/archive/ 4.4.124 They are also not perfect but they work while nightly are not monitored. They are published automatically if build succeeds.

Hi, I installed an Epson TM-T20 II without problem using the armbian image for z28 tvbox, rockchip rock64 alike board. When I plug it, it creates a /dev/usb/lp0 port that is enough to make the printer work. But I am unable to get the same working on the amlogic images. No port is created when I add the USB printer. Could it be missing UDEV rules? Or usblp driver not being loaded by the kernel? May someone give me a light? Those boxes are optimal for POS installations, and no support for ticket printing is a handicap. BTW, awesome work with all this project, it helped me a lot.

Thanks a bunch for this explanation, Kever. I think it pretty much explains a lot of the annoyances developers ran into. Also thank you for your other explanation and suggestions. Though I'm a bit disappointed about lack of other developer responses. Anyway, to get back on (our) topic. We have the following 'BSP' branches for RK3399 boards right now: RK's own: https://github.com/rockchip-linux/kernel/tree/release-4.4 Firefly's repo for their RK boards: https://gitlab.com/TeeFirefly/linux-kernel/ (If I understood @hjc correctly also based on an older RK 4.4 kernel?) Hardkernel's for their canceled ODROID N1: https://github.com/hardkernel/linux/tree/odroidn1-4.4.y (AFAIK a fork of RK's 4.4 but rebased on 4.4 kernel.org version) ayufan's: https://github.com/ayufan-rock64/linux-kernel/tree/release-4.4 (forked and rebased from RK's 4.4 recently) FriendlyELEC's for NanoPC T4/NaniPi M4: https://github.com/friendlyarm/kernel-rockchip/tree/nanopi4-linux-v4.4.y (older fork from RK's 4.4 with some device specific additions for now) What else? With mainline we have: true mainline Heiko's branch: https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git Heinrich Schuchardt's Firefly RK3399 repo: https://github.com/xypron/kernel-firefly-rk3399 Ayufan said he would be happy to open up his repo for other contributors: http://irc.pine64.uk/?date=2018-06-21 08:03:47 (change the channel to #Rock64 via the menu). TL Lim also added he is for unifying development efforts (stopping developers from wasting their time reinventing the wheel over and over again). Is this addressing your concerns @JMCC? So how to proceed? To me it seems possible to use one single BSP kernel for all three RK 'open source SoCs' but I'm not into any details at all.

I downloaded the nightly build Igor made on 06/22 and can not get desktop to work. Did like Viy said: 1) Burn to uSD 2) Boot uSD 3) armbian-config to install to eMMC 4) reboot (booting from eMMC) 5) armbian-config to enable desktop 6) Nothing I tried both lightDM and nodm. Neither worked. LightDM causes screen to go to black with no return. nodm causes screen to flash a few times and return to command prompt. I tried on a 1920X1080 FHD HDMI display. I tried on a 1600X1200 HDMI -> VGA display same results: not working. I know the display works. I can use a Rock64, OrangePi Plus 2E, Raspberry Pi, all can use display via HDMI cable. If I run startx at command line I get: MESA-LOADER: failed to load device (see full log below) X.Org X Server 1.19.2 Release Date: 2017-03-02 X Protocol Version 11, Revision 0 Build Operating System: Linux 4.9.0-4-arm64 aarch64 Debian Current Operating System: Linux nanopik1plus 4.17.2-sunxi64 #21 SMP Thu Jun 21 14:39:44 UTC 2018 aarch64 Kernel command line: root=UUID=467fb03c-c302-4b62-8891-84ef761afc8f rootwait rootfstype=ext4 console=tty1 console=ttyS0,115200 panic=10 consoleblank=0 loglevel=1 ubootpart= usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u cgroup_enable=memory swapaccount=1 Build Date: 16 October 2017 08:11:43AM xorg-server 2:1.19.2-1+deb9u2 (https://www.debian.org/support) Current version of pixman: 0.34.0 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/home/nmi/.local/share/xorg/Xorg.0.log", Time: Thu Jun 21 18:27:23 2018 (==) Using config directory: "/etc/X11/xorg.conf.d" (==) Using system config directory "/usr/share/X11/xorg.conf.d" MESA-LOADER: failed to retrieve device information gbm: failed to open any driver (search paths /usr/lib/aarch64-linux-gnu/dri:${ORIGIN}/dri:/usr/lib/dri) gbm: Last dlopen error: /usr/lib/dri/sun4i-drm_dri.so: cannot open shared object file: No such file or directory failed to load driver: sun4i-drm EGL_MESA_drm_image required. (EE) Fatal server error: (EE) AddScreen/ScreenInit failed for driver 0 (EE) (EE) Please consult the The X.Org Foundation support at http://wiki.x.org for help. (EE) Please also check the log file at "/home/nmi/.local/share/xorg/Xorg.0.log" for additional information. (EE) (EE) Server terminated with error (1). Closing log file. xinit: giving up xinit: unable to connect to X server: Connection refused xinit: server error

Has anyone here tested the Rock64 successfully with an u-boot version which is not the one from ayufan? I did not have much luck with the rk3328 default config and mainline u-boot when I tried it a while back. The same is true when I tried to use the board config from ayufan with mainline u-boot. The version by ayufan is working in principle but also is rather dated as far as I know and therefore does not support some newer features. Anyone knows if the version from ayufan will be bumped or has a working config for a more recent u-boot version?

Ok, although I did see strange results earlier today, I now can say that the patch works, tested about 10 times from scratch so I can login, update/upgrade/install some stuff I see error messages in the boot : ** File not found /boot/dtb/rockchip/overlay/-fixup.scr ** and Starting kernel ... ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) Loading, please wait... starting version 229 and [ OK ] Started User Manager for UID 0. [FAILED] Failed to start Network Manager Wait Online. See 'systemctl status NetworkManager-wait-online.service' for details. [ OK ] Reached target Network is Online. Is that "normal" ? But reboot does not always work, hangs on one sbc, succeeds on another sbc, both show like : Starting kernel ... ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) Loading, please wait... starting version 229 [ 2.080920] Internal error: Oops: 96000004 [#1] SMP [ 2.081455] Modules linked in: [ 2.081810] CPU: 3 PID: 212 Comm: udevadm Not tainted 4.4.124-rk3328 #24 [ 2.082522] Hardware name: Pine64 Rock64 (DT) [ 2.082989] task: ffffffc037833600 task.stack: ffffffc027510000 [ 2.083627] PC is at __rmqueue.isra.7+0x84/0x3f4 [ 2.084120] LR is at get_page_from_freelist+0x20c/0x774 [ 2.084674] pc : [<ffffff800819550c>] lr : [<ffffff8008195a88>] pstate: 20000 1c5 [ 2.085447] sp : ffffffc027513a30 [ 2.085802] x29: ffffffc027513a30 x28: 0000000000000001 [ 2.086391] x27: 0000000000000010 x26: ffffffc03ff95d98 [ 2.086978] x25: 0000004036e79000 x24: ffffffc03ff95d88 [ 2.087565] x23: 0000000000000001 x22: 0000000000000001 [ 2.088153] x21: 0000000000000000 x20: ffffff800928a380 [ 2.0 etc etc

https://github.com/ayufan-rock64/linux-build/blob/master/recipes/flash-spi.md Untested.

Hello, I need some help to find an U-Boot image to flash on rock64 so that armbian boots directly from USB3. Where can I find it. If your answer is to build my own U-Boot image, please give me step by step instructions. Thanks a lot

Linux-sunxi.org is the community around SunXi (the naming scheme of Allwinner). Rockchip contributes a lot for their 'open source SoCs' (e.g. RK3288, RK3328, RK3399). http://opensource.rock-chips.com/wiki_Main_Page Mediatek 'starts' to do it similar for the MT7623 (but there's only one board, and currently not supported by armbian) see here: IMO if USB2 together with GbE is fast enough (max ~40MB/s due to USB2), I would still go for a H3 device. They're cheap, they're mature and the support is quite good. If you want a bit more power and a all-in-one solution the HC1/HC2 from Hardkernel are IMO worth a look. Their use the 'case' as a large heatsink, sticked everything together saves you the money for casing and tinkering. https://www.hardkernel.com/main/products/prdt_info.php?g_code=G151505170472 The SoC is a bit outdated, but I still prefer it as NAS/Server. The hardware avoids major problems (no connector problems, powering seems to be sane, and ~50$ for a board with case, able to saturate GbE together mature software saves you headache). I didn't check who did the mainlining for the SoC/Board (Armbian uses Hardkernels sources, so at least they must care about supporting their own hardware on recent kernels). You may have a look into this topics: It IMO depends on your preferences. E.g. the BPi R2, I spend a bunch of time with, is a 'pure' mainline Board/SoC, from kernel side (u-boot, well that's a different story), where Mediatek did the whole mainlining on their own. The 'NAS' part of the board seems to work without major issues, whereas the networking part is just not mature enough for a 'sane' setup yet (and it seems that the boardmaker isn't much interested in solving those issues). Depending on your first post. IMO those boards come to my mind (others might have other opinions): A NanoPi LTS board (pro: likely that they're there as long as the SoC is available, FriendlyArm sells mostly sane looking heatsinks to their boards cons: limited to USB2 speed, powering might be an issue when microUSB powered) Rock64 (pro: USB3/GbE with proper barrelplug powering, relatively cheap starts at ~25$ plus shipping, as @tkaiser suggests multiple times, their 10$ SATA/USB cable is worth the money, con: SATA over USB3 connector - connector can be an issue) HC1/HC2 (pro: proper heatsink, SATA over 'onboard' USB - no connector issues.. con: bit outdated SoC) Newer rk3399 boards might be interesting too, but software situation is IMO not mature enough at the moment. Marvell SoCs might be worth a look at (e.g. the relatively cheap espressoBin with native SATA) but I've no experience with those boards and don't follow the related content close enough to make a proper statement.

I know that you have a lot of to do, because there is a lot of new single boards... For considerate for the future support.: Nano pi k1 plus with H5 allwinner cpu. And also renegade single board from libre computers based on Rockchip RK 3328 the same as rock64. Both cpu's are supported in other boards so it will be easer.

Further, I can fix the errors above with 'ifconfig eth1 down' - I'm not sure why that interface is even there, it seems to be an IPV6 version of the eth0 interface. Anyway, with that noise out of the way, here's what I see when I try to use both USB3 ethernet interfaces: un 16 20:04:04 localhost kernel: [ 273.782909] NETDEV WATCHDOG: enx00e04c68d929 (r8152): transmit queue 0 timed out Jun 16 20:04:04 localhost kernel: [ 273.783169] ------------[ cut here ]------------ Jun 16 20:04:04 localhost kernel: [ 273.783183] WARNING: at net/sched/sch_generic.c:306 Jun 16 20:04:04 localhost kernel: [ 273.783191] Modules linked in: tun r8152 poly_hash_ce ip_tables x_tables Jun 16 20:04:04 localhost kernel: [ 273.783223] Jun 16 20:04:04 localhost kernel: [ 273.783247] CPU: 2 PID: 2927 Comm: unattended-upgr Not tainted 4.4.124-rk3328 #24 Jun 16 20:04:04 localhost kernel: [ 273.783257] Hardware name: Pine64 Rock64 (DT) Jun 16 20:04:04 localhost kernel: [ 273.783271] task: ffffffc0e46b4380 task.stack: ffffffc0e4500000 Jun 16 20:04:04 localhost kernel: [ 273.783304] PC is at dev_watchdog+0x1e4/0x234 Jun 16 20:04:04 localhost kernel: [ 273.783315] LR is at dev_watchdog+0x1e4/0x234 With an intervening stack dump, and ending in: Jun 16 20:04:06 localhost kernel: [ 275.908967] usb 5-1.2: reset SuperSpeed USB device number 4 using xhci-hcd At which point one of the USB 3 ethernet adapters dies.

I got the Rock64 specifically for router-like functionality. In addition to the native ethernet port, I've added two USB3 RTL8153 Gigabit adapters: http://www.realtek.com.tw/products/productsView.aspx?Langid=1&PFid=56&Level=5&Conn=4&ProdID=326 I've tried multiple 0.5.x and 0.6.x Ayufan images, and also Stretch armbian here (which also uses the Ayufan kernel). I've tried both the 4.4 kernel all these distros come with, and up to 4.17 as well. In all cases I see terrible and unreliable USB3/USB2 and ethernet performance. In the Armbian Sketch image I see 'eth1' go up and down contstantly: Jun 17 09:48:44 localhost avahi-daemon[712]: Joining mDNS multicast group on interface eth1.IPv6 with address fe80::e824:33dd:2309:841c. Jun 17 09:48:44 localhost avahi-daemon[712]: New relevant interface eth1.IPv6 for mDNS. Jun 17 09:48:44 localhost avahi-daemon[712]: Registering new address record for fe80::e824:33dd:2309:841c on eth1.*. Jun 17 09:48:45 localhost kernel: [ 249.804881] Rockchip integrated EPHY stmmac-1:00: rockchip_integrated_phy_fixup_100M: reset phy Jun 17 09:48:47 localhost kernel: [ 251.863022] rk_gmac-dwmac ff550000.ethernet eth1: Link is Down Jun 17 09:48:48 localhost kernel: [ 252.865169] rk_gmac-dwmac ff550000.ethernet eth1: Link is Up - 100Mbps/Half - flow con8:48 localhost NetworkManager[708]: <info> [1529228928.6344] deort 67 interval 5 Jun 17 09:48:56 localhost systemd[1]: Starte00: rockchip_integrated_phy_fixup_100M: reset phy Jun 17 09:49:04 localhost kernel: [ 268.951741] rk_gmac-dwmac ff550000.ethernet eth1: Link is Down Jun 17 09:49:05 localhost kernel: [ 269.953899] rk_gmac-dwmac ff550000.ethernet eth1: Link is Up - 100Mbps/Half - flow control off Jun 17 09:49:05 localhost NetworkManager[708]: <info> [1529228945.7255] device (eth1): link connected Jun 17 09:49:07 localhost dhclient[3157]: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 21 Jun 17 09:49:19 localhost kernel: [ 283.986689] Rockchip integrated EPHY stmmac-1:00: rockchip_integrated_phy_fixup_100M: reset phy Jun 17 09:49:21 localhost kernel: [ 286.046267] rk_gmac-dwmac ff550000.ethernet eth1: Link is Down Jun 17 09:49:22 localhost kernel: [ 287.048219] rk_gmac-dwmac ff550000.ethernet eth1: Link is Up - 100Mbps/Half - flow control off Jun 17 09:49:22 localhost NetworkManager[708]: <info> [1529228962.8166] device (eth1): link connected Jun 17 09:49:27 localhost NetworkManager[708]: <warn> [1529228967.8545] dhcp4 (eth1): request timed out Jun 17 09:49:27 localhost NetworkManager[708]: <info> [1529228967.8553] dhcp4 (eth1): state changed unknown -> timeout Jun 17 09:49:27 localhost NetworkManager[708]: <info> [1529228967.8724] dhcp4 (eth1): canceled DHCP transaction, DHCP client pid 3157 Jun 17 09:49:27 localhost NetworkManager[708]: <info> [1529228967.8728] dhcp4 (eth1): state changed timeout -> done Jun 17 09:49:27 localhost NetworkManager[708]: <info> [1529228967.8792] device (eth1): state change: ip-config -> failed (reason 'ip-config-unavailable') [70 120 5] Jun 17 09:49:27 localhost NetworkManager[708]: <warn> [1529228967.8834] device (eth1): Activation: failed for connection 'Wired connection 2' Jun 17 09:49:27 localhost NetworkManager[708]: <info> [1529228967.8915] device (eth1): state change: failed -> disconnected (reason 'none') [120 30 0] Jun 17 09:49:27 localhost avahi-daemon[712]: Withdrawing address record for fe80::e824:33dd:2309:841c on eth1. Jun 17 09:49:27 localhost avahi-daemon[712]: Leaving mDNS multicast group on interface eth1.IPv6 with address fe80::e824:33dd:2309:841c. Jun 17 09:49:27 localhost avahi-daemon[712]: Interface eth1.IPv6 no longer relevant for mDNS. Jun 17 09:49:27 localhost NetworkManager[708]: <info> [1529228967.9290] policy: auto-activating connection 'Wired connection 2' Jun 17 09:49:27 localhost NetworkManager[708]: <info> [1529228967.9487] device (eth1): Activation: starting connection 'Wired connection 2' (2f03db29-a92b-3782-86d7-64b613f8e9d0) Jun 17 09:49:27 localhost NetworkManager[708]: <info> [1529228967.9530] device (eth1): state change: disconnected -> prepare (reason 'none') [30 40 0] Jun 17 09:49:27 localhost NetworkManager[708]: <info> [1529228967.9630] device (eth1): state change: prepare -> config (reason 'none') [40 50 0] Jun 17 09:49:27 localhost NetworkManager[708]: <info> [1529228967.9829] device (eth1): state change: config -> ip-config (reason 'none') [50 70 0] Jun 17 09:49:28 localhost NetworkManager[708]: <info> [1529228967.9949] dhcp4 (eth1): activation: beginning transaction (timeout in 45 seconds) Jun 17 09:49:28 localhost NetworkManager[708]: <info> [1529228968.0254] dhcp4 (eth1): dhclient started with pid 3425 Jun 17 09:49:28 localhost dhclient[3425]: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 7 I've read now multiple reports of these issues. See: * https://github.com/ayufan-rock64/linux-build/issues/112#issuecomment-397817650 * https://forum.pine64.org/showthread.php?tid=5557 What I can't find is how to resolve this? It seems Rock64 don't actually support this board properly, and just rely on Ayufan.

Hey fellow tinkerers, I'm pretty happy with my Rock64 boards so far, however, when I recently upgraded the kernel on the oldest one and rebooted, I couldn't ssh back in. So I hooked it up to a monitor and was blown away from all the error-like text that kept flowing on my screen. Since I have if this is logged anywhere (I looked but couldn't find anything after mounting the sdcard in my laptop), I had to film it. See attached video. It basically consists of lots of errors formatted like this: [<ffffffxxxxxxxxxx>] and a lot of errors looking like this: dma-pl330 ff1f0000.dmac: pl330_update:1783 Unexpected! Is there any way to salvage this? Eg, tinker with some boot file? Or should I just be done with it and reinstall the entire system? Is it board-related aka is my board done and needs to be replaced? System info: Rock64 with 4GB RAM, running Armbian Ubuntu 16.04. Has been working solid before the kernel upgrade and reboot. VID_20180617_094424_1_1.mp4

Please test the following. It works on my Renegade, not sure about a Rock64: 1. In the SD card, find the 6th line in /boot/boot.cmd. Change it from: setenv load_addr "0x44000000" to: setenv load_addr "0x39000000" 2. Recompile the script with: mkimage -C none -A arm -T script -d boot.cmd boot.scr 3. Try to boot.

So only 1 step to go then ? 1 : repair the boot script and get it into all Rock64 Armbian images Who can do that ?

Ok, next steps ? 1 : repair the boot script and get it into the Rock64 Armbian images 2: Why does it get stuck after it boots ? I will try it on the other image too.

Just thinking out loud : Could it be memory timing as mentioned earlier in this thread by boobypi https://forum.armbian.com/topic/5771-rock64-nightly-image/?tab=comments#comment-45615 ? Perhaps the Rock64 1GB have/need different timing than 2/4 GB ? My memory chip has the marking PB047-125PT Looks like this is the manufacturer www.spectek.com chip code PB047 = 8GBit = SS256M32V01MD1LPF LPDDR3 somewhere else on that site, I found that code -125 stands for PC3-12800/DDR3 1600 11-11-11 What chips are on the 2G/4G ?

Well we ( 1GB Rock64 owners ) only have problems with the Armbian images for Rock64, and not with the Pine64/Rock64 Bionic image, so despite how much we love Armbian, I can't imagine that the problem is not in the Armbian image. I see that it starts U-Boot 2018.01-rc2-armbian (May 14 2018 - 20:13:51 +0200), so that is Armbian right ? My guess is that the during boot, memory locations between 1GB and 2GB are used that are not there ? No idea where how to check / solve, as I am no expert in that, but I can make some time for that, as I am willing to learn, so anyone have a clue where to start ?

Good to know. I'm coming at Armbian from the perspective that I'd rather be using straight Debian, but the Arm machines have some peculiar hardware which require specialized knowledge, kernels, drivers, etc. I want it to be as much like normal Debian as possible, not keep stumbling over hidden "helpful" features. For that matter I'd probably be running OpenBSD but by last account they're woefully far behind and don't even have HDMI working yet, you can't install without a serial console. As far as I'm concerned everything not an Arm machine is a dinosaur. I still have a couple 10+ year old i386/amd laptops but most of my efforts go into setting up my Arm machines (and using them). I'd like to get back to the Gphoto program I'm working on and some SDR stuff, not keep messing with operating systems. But until Arms are as mainstream as i386 only Armbian, Raspbian, etc. can deal with them. With a relatively stock Pi all I have to do is set /etc/hostname so it's unique. It boots up, DHCP works because it needs NTP. I can get on the internet from it, also I can boot one headless and connect to that hostname from another machine. I grudgingly gave up static IPs once I realized that hostnames from DHCP get fed to DNS in my Android phone hotspot/AP. That's not quite right in my Rock64 yet. On a Pi, even under Stapleberg's amd64 Buster it seems to not matter that much whether I use my interfaces file or not. Sometimes I forget to make one or copy one in, it still works.

You need to adjust DT on your NanoPC since the device claims to be only capable of PCIe Gen1. Please see also https://patchwork.kernel.org/patch/9345861/ @FrankM: Would be interesting to test on your RockPro64 with link speed set to 1 and see whether now a x4 link will be established: https://github.com/ayufan-rock64/linux-kernel/blob/65dce4f6760180105cda50d6f8d603e25eaf26fc/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts#L260

Ok, it works rock64@rockpro64:~$ lspci 00:00.0 PCI bridge: Rockchip Inc. RK3399 PCI Express Root Port Device 0100 01:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM961/PM961 rock64@rockpro64:~$ sudo lspci -vvv [sudo] password for rock64: 00:00.0 PCI bridge: Rockchip Inc. RK3399 PCI Express Root Port Device 0100 (prog-if 00 [Normal decode]) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort+ <TAbort+ <MAbort+ >SERR+ <PERR+ INTx- Latency: 0 Interrupt: pin A routed to IRQ 238 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: 00000000-00000fff Memory behind bridge: fa000000-fa0fffff Prefetchable memory behind bridge: 00000000-000fffff Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR- BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: [80] Power Management version 3 Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA PME(D0+,D1+,D2-,D3hot+,D3cold-) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME+ Capabilities: [90] MSI: Enable+ Count=1/1 Maskable+ 64bit+ Address: 00000000fee30040 Data: 0000 Masking: 00000000 Pending: 00000000 Capabilities: [b0] MSI-X: Enable- Count=1 Masked- Vector table: BAR=0 offset=00000000 PBA: BAR=0 offset=00000008 Capabilities: [c0] Express (v2) Root Port (Slot+), MSI 00 DevCap: MaxPayload 256 bytes, PhantFunc 0 ExtTag- RBE+ DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+ RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- LnkCap: Port #0, Speed 5GT/s, Width x4, ASPM L1, Exit Latency L0s <256ns, L1 <8us ClockPM- Surprise- LLActRep- BwNot+ ASPMOptComp+ LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- CommClk- ExtSynch- ClockPM- AutWidDis- BWInt+ AutBWInt+ LnkSta: Speed 5GT/s, Width x2, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt- SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise- Slot #0, PowerLimit 0.000W; Interlock- NoCompl- SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg- Control: AttnInd Off, PwrInd Off, Power+ Interlock- SltSta: Status: AttnBtn- PowerFlt- MRL+ CmdCplt- PresDet- Interlock- Changed: MRL- PresDet- LinkState- RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna+ CRSVisible- RootCap: CRSVisible- RootSta: PME ReqID 0000, PMEStatus- PMEPending- DevCap2: Completion Timeout: Range B, TimeoutDis+, LTR+, OBFF Via message ARIFwd+ DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled ARIFwd- LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis- Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance De-emphasis: -6dB LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1- EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest- Capabilities: [100 v2] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn- Capabilities: [274 v1] Transaction Processing Hints Interrupt vector mode supported Device specific mode supported Steering table in TPH capability structure Kernel driver in use: pcieport 01:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM961/PM961 (prog-if 02 [NVM Express]) Subsystem: Samsung Electronics Co Ltd NVMe SSD Controller SM961/PM961 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 237 Region 0: Memory at fa000000 (64-bit, non-prefetchable) [size=16K] Capabilities: [40] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Capabilities: [50] MSI: Enable- Count=1/32 Maskable- 64bit+ Address: 0000000000000000 Data: 0000 Capabilities: [70] Express (v2) Endpoint, MSI 00 DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset+ SlotPowerLimit 0.000W DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ FLReset- MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend- LnkCap: Port #0, Speed 8GT/s, Width x4, ASPM L1, Exit Latency L0s unlimited, L1 <64us ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp+ LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- CommClk- ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt- LnkSta: Speed 5GT/s, Width x2, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- DevCap2: Completion Timeout: Range ABCD, TimeoutDis+, LTR+, OBFF Not Supported DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis- Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance De-emphasis: -6dB LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1- EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest- Capabilities: [b0] MSI-X: Enable+ Count=8 Masked- Vector table: BAR=0 offset=00003000 PBA: BAR=0 offset=00002000 Capabilities: [100 v2] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn- Capabilities: [148 v1] Device Serial Number 00-00-00-00-00-00-00-00 Capabilities: [158 v1] Power Budgeting <?> Capabilities: [168 v1] #19 Capabilities: [188 v1] Latency Tolerance Reporting Max snoop latency: 0ns Max no snoop latency: 0ns Capabilities: [190 v1] L1 PM Substates L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+ PortCommonModeRestoreTime=10us PortTPowerOnTime=10us L1SubCtl1: PCI-PM_L1.2- PCI-PM_L1.1- ASPM_L1.2- ASPM_L1.1- T_CommonMode=0us LTR1.2_Threshold=0ns L1SubCtl2: T_PwrOn=10us Kernel driver in use: nvme rock64@rockpro64:/mnt$ sudo dd if=/dev/zero of=sd.img bs=1M count=4096 conv=fdatasync 4096+0 records in 4096+0 records out 4294967296 bytes (4.3 GB, 4.0 GiB) copied, 12.6595 s, 339 MB/s Atm only x2 Used Kernel rock64@rockpro64:~$ uname -a Linux rockpro64 4.4.126-rockchip-ayufan-257 #1 SMP Sun Jun 10 18:30:43 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux

Minor tweak. I don't have gethostname() (Actually I think that's a C function, not an executable.) Anyway my Rock64 didn't show up my wifi network by name. In /etc/dhcp/dhclient.conf I changed: #send host-name = gethostname(); send host-name = $HOSTNAME; Now it works. And $HOSTNAME is just whatever's in /etc/hostname so you may need to change it if you've got 2 or more machines of the same kind. I mostly lug around a cell phone and I can ftp or ssh to rock64 from anywhere in the house.

I'd love to stay with the Tinker given the hardware. Unfortunately they were needed on a time-dependent project that I've joined and my patience doesn't get included in their budget The project itself is for a number of small community groups in Ecuador, and there wasn't much of a budget to begin with. The software had already been created by a group of UK students and was working fine, at the basic level with Raspberry Pi's but there weren't any Pi's available to the community groups here and Tinker Boards had already been supplied. An electronics shop in the closest city had a number of unbranded Chinese boards where I couldn't even read the CPU model or find a similar picture on the internet to identify them. The software communicates directly with the framebuffer, the only alternative was for a browser to be used but X and a browser sucks resources out of the boards and it would have been a fair amount of reprogramming. I've actually got a ROCK64 board with me too, and Armbian/Debian work fabulously on it, no flaws at all that I have found. I'm quite sure it's down to Asus' poor support of this board, and Tinker OS just being thrown together with a handful of their own drivers. I've tried starting with Tinker OS and stripping it down to just the bare essentials and stuff just breaks too easily.

I'm not sure about the current state. But images from maybe 1-2 weeks ago did not work for me as well as images from several months ago. So up to now there was no version which worked. I'm maybe going to test the images from time to time but my focus will be more on some custom debian builds or other operating systems. Edit: Since the problem occurs before the kernel boots it is likely u-boot related. So you could ask on the u-boot mailing list or irc or maybe on the official pine64/rock64 forum. I guess the version is still the one from ayufan so you could maybe also ask him. From what I understand the pine64 armbian image works on the rock64 1gb version. If you could figure out the differences maybe you could find a hint on why the official rock64 version fails.