Igor

Just use armbian-config for changing kernel which will remove old kernel and prevent troubles on update. Symlink is made on package install ...

Wrote on mobile

I was just giving you an update my friend.  I will get your logs.

Apologies up front - after digging thru the forums, you have a fair investment in your methods and means...  fair enough, and much appreciated.
 
Just ask that you keep an open mind on this item - I've got other things to worry about...
 
current tasks are rk3288 clocks and temps, and an ask to look at rk_cypto performance overall...
 
Keep it simple there... many use cases to consider - one can always find a benchmark to prove a case...
 
I've been there, and this isn't the first ARM platform I've worked with - I've done BSP's for imx6, mvedbu, broadcom, and QCA... not my first rodeo here.
 
Just trying to help.

Yes, that change introduced the problem...  I just pushed a fix:  https://github.com/armbian/build/commit/c1530db4820320a1e837901196d846b0ef71ee4c

Thank you, after configuring it works fine and in stereo! So, I guess the audio codec drivers supplied by FriendlyElec were messed up.
 
The sound quality is OK - good enough for listening on headphones or any non-hifi system. Will see how it works with ZynAddSubFx soon.

Armbian logo should be displayed in uboot by default. At lest on most recent assembly. Image is read from /boot by another patch.

Wrote on mobile

I hope I didn't miss anything.
https://github.com/armbian/build/commit/735a3679e2de12db555e17b0485f99f86a1d106a

Trying to choose between an eMMC module or a USB Flash drive for the boot volume on a Rock64.  I have a few Rock64's that I'm building as various services (Nextcloud, Pi-Hole, VPN, OMV, and/or Netatalk Backup).  None of these devices will need large boot volumes as the data will be in secondary (Hard or SSD) Drives or will require VERY little data storage.
 
On the RPi's that the Rock64's are replacing, I've been using USB Flash drives for booting.  I get the feeling that an eMMC module is a better choice, but do have any real knowledge.  Are the eMMC modules more reliable and less prone to corruption that USB Flash Drives?
 
I do have some 32GB and 64GB eMMC models from Pine64 and am going to try them out shortly.  Any thoughts and advice?
 
Thank you all in advance.  Armbian ROCKS!
 

I had the same message on my Cubietruck. The board was in my desk for two years, it was a HW failure.
Some search on internet suggested a bad soldering under DRAM chip.
So with heating gun I heated up the DRAM chip for approx 5 minutes at 250 Celsius degrees and Cubietruck finally booted from SD Card with Cubietruck Armbian image 5.31.
 

The main repository was updated to 5.60 at this moment. 

Lower your expectations. (modern) kernel for this board is still months away. Provided images are good only for testing, experimenting and development.

https://lists.debian.org/debian-kernel/2017/04/msg00333.html

Hi @Igor
 
wifi works OOB now on my nanopi-duo!
 
I downloaded image recently, after I saw your message about commit -> Armbian_5.59_Nanopiduo_Ubuntu_bionic_next_4.14.70.img
 
First boot with USB cable connected to host laptop, I use nanopi-duo without additional board(s), standalone. 
On host laptop (dmesg -w):
[ 1321.806363] usb 3-1: new high-speed USB device number 4 using xhci_hcd [ 1321.954823] usb 3-1: New USB device found, idVendor=0525, idProduct=a4a7 [ 1321.954828] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 1321.954831] usb 3-1: Product: Gadget Serial v2.4 [ 1321.954834] usb 3-1: Manufacturer: Linux 4.14.70-sunxi with musb-hdrc [ 1321.955533] cdc_acm 3-1:2.0: ttyACM3: USB ACM device On host laptop:
sudo minicom -b 115200 -D /dev/ttyACM3 Welcome to minicom 2.7.1 OPTIONS: I18n  Compiled on Aug 13 2017, 15:25:34. Port /dev/ttyACM3, 16:50:32 Press CTRL-A Z for help on special keys Ubuntu 18.04.1 LTS nanopiduo ttyGS0 nanopiduo login: root Password:  You are required to change your password immediately (root enforced) Changing password for root. (current) UNIX password:  On nanopi-duo:
root@nanopiduo:~# uname -a Linux nanopiduo 4.14.70-sunxi #240 SMP Mon Sep 17 13:32:31 CEST 2018 armv7l armv7l armv7l GNU/Linux  
root@nanopiduo:~# lsmod Module                  Size  Used by lz4hc                  16384  4 lz4hc_compress         24576  1 lz4hc zram                   24576  5 xradio_wlan            94208  1 mac80211              446464  1 xradio_wlan cfg80211              376832  2 mac80211,xradio_wlan sun8i_codec_analog     24576  0 rfkill                 20480  3 cfg80211 snd_soc_core          118784  1 sun8i_codec_analog snd_pcm_dmaengine      16384  1 snd_soc_core snd_pcm                65536  2 snd_pcm_dmaengine,snd_soc_core snd_timer              24576  1 snd_pcm snd                    45056  3 snd_timer,snd_soc_core,snd_pcm soundcore              16384  1 snd sun4i_gpadc_iio        16384  0 uio_pdrv_genirq        16384  0 uio                    16384  1 uio_pdrv_genirq sch_fq_codel           20480  6 usb_f_acm              16384  1 u_serial               20480  3 usb_f_acm g_serial               16384  0 libcomposite           40960  2 g_serial,usb_f_acm ip_tables              20480  0 x_tables               20480  1 ip_tables pwrseq_simple          16384  1  
It's there, xradio_wlan and used! :-)
 
root@nanopiduo:~# nmcli r WIFI-HW  WIFI     WWAN-HW  WWAN     enabled  enabled  enabled  enabled  Onboard wifi hardware is operating.
 
root@nanopiduo:~# nmcli dev DEVICE  TYPE      STATE         CONNECTION  wlan0   wifi      disconnected  --          eth0    ethernet  unavailable   --          lo      loopback  unmanaged     -- root@nanopiduo:~# nmcli device wifi list IN-USE  SSID         MODE   CHAN  RATE        SIGNAL  BARS  SECURITY                  UPC Wi-Free  Infra  9     130 Mbit/s  27      *     WPA1 WPA2 802.1X          UPC Wi-Free  Infra  1     130 Mbit/s  9       *     WPA2 802.1X   

Fixed with this commit for NEXT, stable builds. DEV (4.18.y) has other problems and there is no rush to fix it there,
https://github.com/armbian/build/commit/acf84bac596c6110d87f7e92389ecd05fb42ce64
 
Images at the download section were also fixed.

Thank you Igor. I tested it out on a spare SD card and I can confirm that Plex works on the Debian version.
 
I can also confirm that upgrading udev to version 237 (backports) replicates the 'link_config' errors displayed above but does not affect the functioning of Plex...

HW configuration in the modern kernel is done differently.
 
Menu driven:
https://docs.armbian.com/User-Guide_Armbian-Config/
Manual:
https://docs.armbian.com/User-Guide_Allwinner_overlays/

Don't have this board. Untested.
https://dl.armbian.com/firefly-rk3399/

thank you very much, it's already working.

We usually work with/have two kernels. Stock legacy, currently mostly 4.4.y.  and mainline, usually latest LTS or stable, 4.14.y/4.18.y at the time. Legacy is labeled "default", while modern "next" ... or "dev" when attached to the master kernel branch.

Repositories per kernel family are defined here: https://github.com/armbian/build/tree/master/config/sources ... for this particular board family we use the repository from Ayufan which seems to be in the best shape. Another alternative would be kernel.org + a bunch of patches. 
 
 

4.18.y and 4.17.y are pretty much the same. Both are development.

Problem solved. I downloaded the latest version of Armbian. In this version, the system transfer from sd to emmc worked as expected.

Ok,
Im on EST I will do so this evening and let you know the outcome.

Thanks Igor -- for the benefit of anyone finding this thread in the future:
 
I checked voltage on the PSU and all seemed fine. However, I got a replacement PSU "just in case" (a 5V 3A UK plug wall wart off ebay, instead of the EU plug one that came with the OPi; just had to solder a 4/1.7mm barrel connector onto the cable) and miraculously with the new PSU the board now comes up fine!
 
Lesson learned: PSU quality is make or break with these boards, even when using a decent barrel connector. And the symptoms of dodgy power supply can be pretty random.
 
Thanks again
 

Manual for start perhaps?
 
https://docs.armbian.com/User-Guide_Getting-Started/#how-to-connect-to-wireless

Dunno, but we fix it https://github.com/armbian/build/commit/46340a242fd196597a3c862e9b075a94d4290381