Firefly RK3399 support efforts (potential csc board?)

[Igor]

13 hours ago, Igor said:

RK3288 -> rockchip with whatever source, ayugan if there will be not much hassle

RK3399 (RockPRO) and RK3328 (Rock64) ->  rockchip64 (ayufan source)

RK3399 (FriednlyARM) remains RK3399 (fa source) ... we postponed this merge for the future

Working on it. I need help here https://github.com/armbian/build/blob/master/config/sources/rk3399.conf#L95-L106 -> a working boot configuration for Rockpro64. I haven't got to boot the board properly yet.

[Igor]

13 hours ago, botfap said:

Apologies for slightly off topic but what is the most generic Armbian RK3399 build to use as a starting point to bring up an unsupported RK3399 board?

The most generic will (probably) be the rk3399 branch. Currently, it is under RFC.

[tkaiser]

On 8/16/2018 at 7:55 AM, hjc said:

Firefly RK3399 (with official active cooling fan) sbc-bench test results: http://ix.io/1kk9

It shows impressive CPU performance numbers when overclocked to 2.2/1.8 GHz, but that definitely requires a fan.

 

Well, tried the same with your overclocked settings on NanoPC-T4 but this definitely kills the board.

 

I tried it several times without a fan and just the passive heatsink and the board powered down always when running the multi-threaded 7-zip test.

 

Then added a large fan blowing directly over the heatsink and now cpu-miner kills the board:

 

root@nanopct4:/home/tk# cd /tmp/sbc-bench.sh.bpjAvD/
root@nanopct4:/tmp/sbc-bench.sh.bpjAvD# cat results.log 
sbc-bench v0.5.4 FriendlyElec NanoPC-T4 (Sun, 26 Aug 2018 17:00:27 +0000)

Distributor ID:	Debian
Description:	Debian GNU/Linux 9.5 (stretch)
Release:	9.5
Codename:	stretch

Armbian release info:
BOARD=nanopct4
BOARD_NAME="NanoPC T4"
BOARDFAMILY=rk3399
VERSION=5.59
LINUXFAMILY=rk3399
BRANCH=default
ARCH=arm64
IMAGE_TYPE=user-built
BOARD_TYPE=conf
INITRD_ARCH=arm64
KERNEL_IMAGE_TYPE=Image

/usr/bin/gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516

Uptime: 17:00:27 up 27 min,  1 user,  load average: 0.09, 0.28, 0.22

Linux 4.4.152-rk3399 (nanopct4) 	08/26/2018 	_aarch64_	(6 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           2.99    0.01    0.51    0.09    0.00   96.40

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
mmcblk1           0.15         4.42         0.00       7340          0
mmcblk1rpmb       0.00         0.01         0.00         24          0
mmcblk1boot1      0.08         0.33         0.00        540          0
mmcblk1boot0      0.08         0.33         0.00        540          0
mmcblk0           1.99       102.00        72.31     169413     120114
zram0             0.36         0.44         0.99        736       1640
zram1             0.18         0.70         0.00       1168          4
zram2             0.18         0.70         0.00       1168          4
zram3             0.18         0.70         0.00       1168          4
zram4             0.18         0.70         0.00       1168          4

              total        used        free      shared  buff/cache   available
Mem:           3.7G         72M        3.2G         13M        449M        3.6G
Swap:          1.0G          0B        1.0G

Filename				Type		Size	Used	Priority
/dev/zram1                             	partition	262140	0	5
/dev/zram2                             	partition	262140	0	5
/dev/zram3                             	partition	262140	0	5
/dev/zram4                             	partition	262140	0	5

##########################################################################

Checking cpufreq OPP for cpu0-cpu3:

Cpufreq OPP: 1800    Measured: 1788.107/1788.741/1787.948
Cpufreq OPP: 1512    Measured: 1499.856/1499.995/1500.292
Cpufreq OPP: 1416    Measured: 1402.779/1403.328/1403.831
Cpufreq OPP: 1200    Measured: 1188.661/1187.664/1188.169
Cpufreq OPP: 1008    Measured: 995.824/995.800/996.016
Cpufreq OPP:  816    Measured: 803.730/804.091/803.730
Cpufreq OPP:  600    Measured: 588.137/587.386/587.830
Cpufreq OPP:  408    Measured: 395.342/395.967/395.809

Checking cpufreq OPP for cpu4-cpu5:

Cpufreq OPP: 2208    Measured: 2200.013/2200.253/2200.277
Cpufreq OPP: 1992    Measured: 1983.248/1983.930/1984.126
Cpufreq OPP: 1800    Measured: 1792.873/1792.495/1792.475
Cpufreq OPP: 1608    Measured: 1600.285/1600.166/1599.472
Cpufreq OPP: 1416    Measured: 1408.240/1408.363/1408.256
Cpufreq OPP: 1200    Measured: 1153.708/1187.759/1187.978
Cpufreq OPP: 1008    Measured: 999.497/1000.198/1000.186
Cpufreq OPP:  816    Measured: 808.052/808.141/808.131
Cpufreq OPP:  600    Measured: 590.930/591.280/591.280
Cpufreq OPP:  408    Measured: 399.518/399.698/399.929

root@nanopct4:/tmp/sbc-bench.sh.bpjAvD# tail -f monitor.log 
System health while running tinymembench:

Time       big.LITTLE   load %cpu %sys %usr %nice %io %irq   Temp
17:00:41: 2208/1800MHz  0.23   3%   0%   3%   0%   0%   0%  36.2°C
17:01:41: 2208/1800MHz  0.72  16%   0%  16%   0%   0%   0%  33.9°C
17:02:41: 2208/1800MHz  0.90  16%   0%  16%   0%   0%   0%  33.9°C
17:03:41: 2208/1800MHz  0.96  16%   0%  16%   0%   0%   0%  32.2°C
17:04:41: 2208/1800MHz  0.99  16%   0%  16%   0%   0%   0%  31.1°C
17:05:41: 2208/1800MHz  1.00  16%   0%  16%   0%   0%   0%  30.6°C
17:06:41: 2208/1800MHz  1.00  16%   0%  16%   0%   0%   0%  30.6°C
17:07:41: 2208/1800MHz  1.00  16%   0%  16%   0%   0%   0%  30.6°C
17:08:41: 2208/1800MHz  1.00  16%   0%  16%   0%   0%   0%  31.1°C
17:09:41: 2208/1800MHz  1.00  16%   0%  16%   0%   0%   0%  30.6°C
17:10:41: 2208/1800MHz  1.00  16%   0%  16%   0%   0%   0%  30.6°C
17:11:41: 2208/1800MHz  1.00  16%   0%  16%   0%   0%   0%  30.6°C
17:12:42: 2208/1800MHz  1.06  16%   0%  16%   0%   0%   0%  30.6°C
17:13:42: 2208/1800MHz  1.02  16%   0%  16%   0%   0%   0%  30.6°C
17:14:42: 2208/1800MHz  1.00  16%   0%  16%   0%   0%   0%  30.6°C
17:15:42: 2208/1800MHz  1.00  16%   0%  16%   0%   0%   0%  30.6°C
17:16:42: 2208/1800MHz  1.00  16%   0%  16%   0%   0%   0%  31.1°C
17:17:42: 2208/1800MHz  1.00  16%   0%  16%   0%   0%   0%  30.6°C
17:18:42: 2208/1800MHz  1.00  16%   0%  16%   0%   0%   0%  30.6°C
17:19:42: 2208/1800MHz  1.00  16%   0%  16%   0%   0%   0%  30.6°C
17:20:42: 2208/1800MHz  1.00  16%   0%  16%   0%   0%   0%  40.0°C
17:21:42: 2208/1800MHz  1.00  16%   0%  16%   0%   0%   0%  42.2°C
17:22:43: 2208/1800MHz  1.00  16%   0%  16%   0%   0%   0%  38.8°C
17:23:43: 2208/1800MHz  1.00  16%   0%  16%   0%   0%   0%  36.2°C
17:24:43: 2208/1800MHz  1.00  16%   0%  16%   0%   0%   0%  35.6°C
17:25:43: 2208/1800MHz  1.05  16%   0%  16%   0%   0%   0%  34.4°C
17:26:43: 2208/1800MHz  1.02  16%   0%  16%   0%   0%   0%  34.4°C
17:27:43: 2208/1800MHz  1.00  16%   0%  16%   0%   0%   0%  34.4°C
17:28:43: 2208/1800MHz  1.00  16%   0%  16%   0%   0%   0%  34.4°C
17:29:43: 2208/1800MHz  1.00  16%   0%  16%   0%   0%   0%  35.0°C
17:30:43: 2208/1800MHz  1.00  16%   0%  16%   0%   0%   0%  35.0°C
17:31:43: 2208/1800MHz  1.00  16%   0%  16%   0%   0%   0%  34.4°C
17:32:43: 2208/1800MHz  1.00  16%   0%  16%   0%   0%   0%  35.0°C
17:33:44: 2208/1800MHz  1.00  16%   0%  16%   0%   0%   0%  35.0°C

System health while running OpenSSL benchmark:

Time       big.LITTLE   load %cpu %sys %usr %nice %io %irq   Temp
17:34:38: 2208/1800MHz  1.00  10%   0%  10%   0%   0%   0%  36.2°C
17:34:48: 2208/1800MHz  1.00  16%   0%  16%   0%   0%   0%  32.8°C
17:34:58: 2208/1800MHz  1.00  16%   0%  16%   0%   0%   0%  38.1°C
17:35:08: 2208/1800MHz  1.00  16%   0%  16%   0%   0%   0%  39.4°C
17:35:18: 2208/1800MHz  1.00  16%   0%  16%   0%   0%   0%  34.4°C
17:35:28: 2208/1800MHz  1.00  16%   0%  16%   0%   0%   0%  33.9°C
17:35:38: 2208/1800MHz  1.00  16%   0%  16%   0%   0%   0%  40.6°C
17:35:48: 2208/1800MHz  1.00  16%   0%  16%   0%   0%   0%  41.1°C
17:35:58: 2208/1800MHz  1.00  16%   0%  16%   0%   0%   0%  35.0°C
17:36:09: 2208/1800MHz  1.00  16%   0%  16%   0%   0%   0%  38.8°C
17:36:19: 2208/1800MHz  1.00  16%   0%  16%   0%   0%   0%  41.1°C

System health while running 7-zip single core benchmark:

Time       big.LITTLE   load %cpu %sys %usr %nice %io %irq   Temp
17:36:26: 2208/1800MHz  1.00  11%   0%  10%   0%   0%   0%  40.6°C
17:36:56: 2208/1800MHz  1.81  16%   0%  16%   0%   0%   0%  33.3°C
17:37:26: 2208/1800MHz  3.06  16%   0%  16%   0%   0%   0%  32.2°C
17:37:56: 2208/1800MHz  3.24  16%   0%  16%   0%   0%   0%  31.7°C
17:38:26: 2208/1800MHz  4.04  16%   0%  16%   0%   0%   0%  31.7°C
17:38:57: 2208/1800MHz  4.29  16%   0%  16%   0%   0%   0%  31.1°C
17:39:27: 2208/1800MHz  4.14  16%   0%  16%   0%   0%   0%  31.1°C
17:39:57: 2208/1800MHz  4.24  16%   0%  16%   0%   0%   0%  30.0°C
17:40:27: 2208/1800MHz  4.57  16%   0%  16%   0%   0%   0%  31.1°C
17:40:57: 2208/1800MHz  5.15  16%   0%  16%   0%   0%   0%  31.1°C
17:41:27: 2208/1800MHz  4.31  16%   0%  16%   0%   0%   0%  30.6°C
17:41:57: 2208/1800MHz  4.17  16%   0%  16%   0%   0%   0%  31.1°C
17:42:27: 2208/1800MHz  3.89  16%   0%  16%   0%   0%   0%  31.1°C
17:42:57: 2208/1800MHz  3.94  16%   0%  16%   0%   0%   0%  30.6°C
17:43:28: 2208/1800MHz  3.93  16%   0%  16%   0%   0%   0%  31.1°C
17:43:58: 2208/1800MHz  4.69  16%   0%  16%   0%   0%   0%  30.6°C
17:44:28: 2208/1800MHz  4.57  16%   0%  16%   0%   0%   0%  31.1°C
17:44:58: 2208/1800MHz  4.80  16%   0%  16%   0%   0%   0%  31.1°C
17:45:28: 2208/1800MHz  5.02  16%   0%  16%   0%   0%   0%  37.5°C
17:45:58: 2208/1800MHz  4.90  16%   0%  16%   0%   0%   0%  37.5°C
17:46:28: 2208/1800MHz  5.23  16%   0%  16%   0%   0%   0%  39.4°C
17:46:58: 2208/1800MHz  4.89  16%   0%  16%   0%   0%   0%  38.1°C
17:47:28: 2208/1800MHz  4.85  16%   0%  16%   0%   0%   0%  38.1°C
17:47:58: 2208/1800MHz  5.08  16%   0%  16%   0%   0%   0%  40.0°C
17:48:29: 2208/1800MHz  4.89  16%   0%  16%   0%   0%   0%  38.8°C
17:48:59: 2208/1800MHz  4.35  16%   0%  16%   0%   0%   0%  38.8°C
17:49:29: 2208/1800MHz  4.61  16%   0%  16%   0%   0%   0%  38.1°C
17:49:59: 2208/1800MHz  4.18  16%   0%  16%   0%   0%   0%  38.1°C
17:50:29: 2208/1800MHz  4.63  16%   0%  16%   0%   0%   0%  40.0°C

System health while running 7-zip multi core benchmark:

Time       big.LITTLE   load %cpu %sys %usr %nice %io %irq   Temp
17:50:38: 2208/1800MHz  4.84  12%   0%  11%   0%   0%   0%  41.1°C
17:51:09: 2208/1800MHz  4.90  79%   1%  78%   0%   0%   0%  51.7°C
17:51:39: 2208/1800MHz  5.25  86%   1%  85%   0%   0%   0%  52.8°C
17:52:09: 2208/1800MHz  5.52  82%   1%  81%   0%   0%   0%  55.0°C
17:52:40: 2208/1800MHz  5.15  80%   1%  79%   0%   0%   0%  56.7°C
17:53:10: 2208/1800MHz  5.49  89%   1%  87%   0%   0%   0%  60.6°C
17:53:40: 2208/1800MHz  5.05  77%   1%  76%   0%   0%   0%  58.9°C
17:54:10: 2208/1800MHz  5.50  89%   1%  87%   0%   0%   0%  56.7°C

System health while running cpuminer:

Time       big.LITTLE   load %cpu %sys %usr %nice %io %irq   Temp
17:54:27: 2208/1800MHz  5.53  15%   0%  15%   0%   0%   0%  55.6°C
Write failed: Broken pipe

 

[hjc]

3 hours ago, tkaiser said:

Then added a large fan blowing directly over the heatsink and now cpu-miner kills the board

Does the whole board powered down immediately, or it ran into kernel panic or benchmark process crash?

 

I haven't analyzed the schematics of both boards, but I guess there are two possibilities:

1. different voltage requirements in different batches of RK3399 causes the issue.

There are already different opp tables in the kernel, for different RK3399 batches: rk3399-opp.dtsi rk3399-op1-opp.dtsi, The latter is for Chromebooks, which uses lower voltage and are more efficient.

Insufficient voltage are basically causing the same issues like those in x86 overclocking, resulting in kernel panic & process crash.

2. On NanoPC T4, overclocking makes it exceed the max allowed current of the board, which triggers some sort of protection, and the board powered down immediately.

 

IMO the 2.2/1.8GHz overclocking could be an option, but should never enabled by default. Though we could try a clock slightly higher than official configuration (e.g. 2.2/1.5 or even 2.0/1.5), have it stress tested on multiple batches of the board, and make it the default value.

[TonyMac32]

55 minutes ago, hjc said:

IMO the 2.2/1.8GHz overclocking could be an option, but should never enabled by default.

This is the method used on RK3288.

[Igor]

3 hours ago, hjc said:

IMO the 2.2/1.8GHz overclocking could be an option, but should never enabled by default.

Currently, OC is enabled but limited with cpufreq-tools ... but at the boot time, it can jump high and die. Let's see. 3399 boards will remain labelled "testing" for a while.

[tkaiser]

4 hours ago, hjc said:

On NanoPC T4, overclocking makes it exceed the max allowed current of the board, which triggers some sort of protection, and the board powered down immediately.

 

That's what I observed, the lights simply went out.

 

52 minutes ago, Igor said:

OC is enabled but limited with cpufreq-tools

 

Nope since cpufrequtils can't deal with big.LITTLE. The little cores will always be overclocked unless we set maximum cpufreq to 1.4GHz or less. IMO we should enable 2.0/1.5GHz (tested successfully on ODROID-N1), test this on a bunch of boards and encourage users to join the testing and leave everything above to the overclocker camp.

[Igor]

23 minutes ago, tkaiser said:

IMO we should enable 2.0/1.5GHz

https://github.com/armbian/build/commit/c73748bc366e39053691668a9284e03949cb5b3b

[tkaiser]

32 minutes ago, Igor said:

https://github.com/armbian/build/commit/c73748bc366e39053691668a9284e03949cb5b3b

 

Thank you! This seems right

Time       big.LITTLE   load %cpu %sys %usr %nice %io %irq   Temp
06:52:52: 1992/1512MHz  0.23   5%   2%   2%   0%   0%   0%  29.4°C

 

[tkaiser]

On 8/16/2018 at 7:55 AM, hjc said:

Firefly RK3399 (with official active cooling fan) sbc-bench test results: http://ix.io/1kk9

 

I added now results with 2.0/1.5 GHz cpufreq OPP for NanoPC-T4: https://github.com/ThomasKaiser/sbc-bench/blob/master/Results.md

 

Several things to mention:

• Memory performance for whatever reasons is way higher with mainline kernel compared to RK's 4.4. This directly affects 7-zip scores (same with a lot of real-world workloads). I get 5540 7-zip MIPS with old 1.8/1.4GHz settings compared to 6250 7-zip MIPS with more recent kernel
• Your tinymembench numbers for overclocked Firefly are somewhat identical to those from the other boards (I would've assumed they would be significantly higher)
• RockPro64 tinymembench numbers are lower with mainline kernel compared to NanoPC-T4 (I suspect it's really kernel here that matters since same DRAM initialization BLOBs are used when switching between kernels)
• RockPro64 7-zip scores with RK's 4.4 kernel are much better compared to NanoPC-T4 running at same clockspeed: 6140 vs. 5530 is massive. And an incentive to compare ayufan's kernel config with the one we use for NanoPC-T4 now

Numbers with 1.8/1.4GHz (Firefly using 2.2/1.8), all the time using tinymembench built the same way (GCC 6.3) and Debian Stretch arm64 7zr binary:

Board        kernel   memcpy  memset  7-zip
NanoPC-T4     4.17     4100    9000    6250
NanoPC-T4      4.4     2840    4890    5530

RockPro64     4.18     3650    8450    6300
RockPro64      4.4     2800    4850    6140

Firefly (OC)  4.18     4150    8280    7900
Firefly (OC)   4.4     2900    4880    7420

OC = overclocked

 

 

[hjc]

@tkaiser I've managed to boot 4.18 kernel on Firefly RK3399 (those problems on 4.17 seems gone), and ran sbc-bench after editing the dts in the same way (set trip point to 85℃, OC to 2.2/1.8GHz), results are here: http://ix.io/1lmN.

[mmarks]

On 8/27/2018 at 11:07 AM, hjc said:

@tkaiser I've managed to boot 4.18 kernel on Firefly RK3399 (those problems on 4.17 seems gone), and ran sbc-bench after editing the dts in the same way (set trip point to 85℃, OC to 2.2/1.8GHz), results are here: http://ix.io/1lmN.

 

Just a follow up to my problems with the nvme ssd. I found that the NVME SSD I was using - an ADATA 512GB SX6000 2280 PCIe SSD which was supposeldy PCIE 1.2 compatible just wanst recognized. I switched to the Samsung 256GB NVME SSD and it was recognized and works. So not all NVME SSDs work.

 

Now I'd like to know how to fix the MAC address, which changes on every boot. 

[Igor]

1 hour ago, mmarks said:

Now I'd like to know how to fix the MAC address, which changes on every boot. 

IIRC this was fixed in the recent build.

[emk2203]

On 6/13/2018 at 1:02 PM, codnoscope said:

Have you tried the offical aluminium case for your firefly? There is a internal aluminium "piller" the push against the CPU so the entire case acts as a large heat sink.

https://shop.t-firefly.com/goods.php?id=62

For people reading this: Before you get your hopes up, the aluminum case is out of stock, and the Firefly sales rep told me in the chat that there probably won't be a second series. Demand was too low and price too high.

[codnoscope]

18 hours ago, emk2203 said:

For people reading this: Before you get your hopes up, the aluminum case is out of stock, and the Firefly sales rep told me in the chat that there probably won't be a second series. Demand was too low and price too high.

It seems I’ve got one of the last case . Bit of dent, but cost me almost nothing. CPU temperature holding at 45C w/ room temperature of 20C when doing light browsing. 

 

BTW, can we enable the WIP image build on dl.armbian.com? Thanks. 

[emk2203]

On 8/27/2018 at 6:07 PM, hjc said:

@tkaiser I've managed to boot 4.18 kernel on Firefly RK3399 (those problems on 4.17 seems gone), and ran sbc-bench after editing the dts in the same way (set trip point to 85℃, OC to 2.2/1.8GHz), results are here: http://ix.io/1lmN.

Any chance for you to share your kernel? My first attempt to compile a 4.19rc1 was unsuccessful. Or, let's say the compile went through, but I am still not sure what to put where afterwards. I would like to try with something known to work.

[hjc]

3 minutes ago, emk2203 said:

Any chance for you to share your kernel? My first attempt to compile a 4.19rc1 was unsuccessful. Or, let's say the compile went through, but I am still not sure what to put where afterwards. I would like to try with something known to work.

There's already one usable mainline kernel in armbian official beta repo (use armbian-config to switch to nightly, reboot, then switch to dev kernel, reboot again), though USB 3.0 and PCIe/NVMe are not enabled.

[Igor]

59 minutes ago, codnoscope said:

BTW, can we enable the WIP image build on dl.armbian.com? Thanks. 

Don't have this board. Untested.

https://dl.armbian.com/firefly-rk3399/

[hjc]

4 hours ago, Igor said:

Don't have this board. Untested.

https://dl.armbian.com/firefly-rk3399/

There's one issue in the Ubuntu (4.4 kernel) image: FriendlyARM kernel defines the CONFIG_MACH_NANOPI4, and only compile the NanoPi dtbs when it's set. So the dtb of Firefly RK3399 is missing in the linux-dtb-rk3399 package. Firefly-RK3399 might be moved into rockchip64 board family, or to use a patch to configure that. Anyway I'll test both kernel when I'm free.

 

[hjc]

It seems that @ayufan's rebase work is done recently (in the github repo it's now 187 commits ahead of official rockchip kernel). Maybe it's suitable now to test and evaluate the kernel and decide to merge rk3399 and rockchip64 family or not?

[constantius]

"Don't have this board. Untested.

https://dl.armbian.com/firefly-rk3399/"

 

Are they images for EMMC or only micro-sd cards?

[constantius]

I downloaded armbian 5.65 bionic default desktop kernel 4.4.162 image and burned it on sd-micro-card. I was looking for instruction how to boot from sd card on firefly www.pages. And also on firefly forum. There is no information how to boot from sdcard. During the boot i pressed pwr button and also combination of reset and recovery button but device not boot. Do you have any knowledge how boot system from micro-sd card?

 

PS I have downloaded firefly image for booting from sd card . it works. Your image armbian 5.65 bionic does not boot at all. To boot from sd card you need press PWR Key button only.  Did you checked your image that is bootable?

[Igor]

6 hours ago, constantius said:

Did you checked your image that is bootable?

Why? I got confirmation on Twitter: 

 

That's fine for "No official support" images. 

[codnoscope]

On 10/30/2018 at 12:38 AM, constantius said:

 you checked your image that is bootable?

On Firefly-rk3399, if the internal emmc contains firefly's linux image, the board will only boot from SD card if the SD card contains android or "linux with android style /boot". 

 

Therefore, to force the board to boot from Armbian SD (contains normal linux /boot) you should wipe your internal emmc by running: sudo blkdiscard /dev/mmcblk1 as pointed out by hjc months ago.

 

if you want to install Armbian to emmc, you could run armbian-config (untested) 

[constantius]

I have done it. System works. I tested it. Thank you very much for your reply Condoscope. I can confirm that Armbian 5.65 Bionic Desktop work on EMMC Firefly-rk3399.

Best regards

[denni_isl]

Did try armbian for firefly rk3399 and it did work quite well, actually much better than the firefly ubuntu 16.04.   Then I did install the system on the emmc with armbian-config and was very fast.    Somehow I managed to corrupt the emmc later on and now I can only use one SD image from firefly on the board ( mentioned here  http://bbs.t-firefly.com/forum.php?mod=viewthread&tid=1921&extra=page%3D1&page=2  

 

Now I am wiping the emmc wit blkdiscard /dev/mmcblk1 hoping to be able to flash with upgrade_tool.     Is it possible to install armbian for firefly on the official firefly SD image and then from there to the emmc drive.   Did try it before with armbian-config but it did not offer to flash boot from emmc sd and usb.   

 

 

[denni_isl]

After blkdiscard /dev/mmcblk1 and new  Etcher flashing on a SD card with the Armbian_5.66.181015_firefly_rk3399.img and rebooting.   It did boot at last and armbian-config - system - emmc flash.   So the debian is running from the emmc drive now.   Think it is becaus of blkdiscard command that did clean the drive correctly.   

[pfry]

Finally fired up my NanoPC-T4. Reading this thread, I figured it had thermal limits in either the power components or the RK3399, so I stuck heat sinks on some of the power components (the Silergy 837/838 and the main 3.3V regulator, and the RK808) and an old Thermalright HR-05 (single heat pipe with a fin stack about the size of the board) on the RK3399. The power components seem to run OK, but it's fairly easy to push the RK3399 +45..50C ("openssl speed -multi 6") in an 18C room (no air flow) (the CPU thermal sensor seems fairly accurate). So the RK3399's over-temp signal (NanoPC-T4 schematic, sheet 13) is likely the source of the shutdown issue when overclocking. A couple things:

- 6W TDP? At 2.0/1.5, I'd guess higher - maybe 10W. Higher than an N3150 Atom (not comparing anything other than TDP).

- Is there a way to clock the thing up without compiling a new kernel?

- Probably the wrong thread, but has anyone set up to boot from an NVME SSD? I firgure I'll try it, as soon as I wrangle a USB cable (to cheesily update the U-Boot "parameter.txt" on the eMMC, something I could probably do from the console or via dd, but hey).

- Gluing tiny pieces of aluminum to tiny chips is a pain. And the giant fin stack somewhat defeats the purpose of the tiny board, assuming one cares more about board size than the burning weenie-roasting SOC. Me, I'd prefer Mini-ITX.

- Photo of the silly thing (warning: 2MB JPG): http://www.tailbone.net/p1000322.jpg

 

[TenseGazebo]

On 9/4/2018 at 4:35 AM, hjc said:

There's already one usable mainline kernel in armbian official beta repo (use armbian-config to switch to nightly, reboot, then switch to dev kernel, reboot again), though USB 3.0 and PCIe/NVMe are not enabled.

What would it take to enable PCIe on the mainline kernel? Is this a matter of changing/enabling some config settings or something a lot more involved?

 

I have a Firefly RK3399 board that I'd like use with a Quectel EC25 LTE modem mini-PCIe module. As far as I could gather,  mainline kernel already supports the modem via the QMI WWAN driver, but when I try the prebuilt mainline kernel from this thread, I can't even see the modem in lsusb output. The modem shows up in lsusb on 4.4 kernel just fine (although apparently one needs to build the QMI module separately to make it usable).

 

Disclaimer: I am very much a noob when it comes to Linux, but generally comfortable compiling things and editing code, fiddling with configs, etc.

[TimSmall]

On 1/15/2019 at 6:11 AM, sanekgusev said:

I have a Firefly RK3399 board that I'd like use with a Quectel EC25 LTE modem mini-PCIe module.

 

Because the EC25 is a USB modem in a mini-PCIe formfactor, this should be completely independent of the PCIe support in the kernel (unless you have a card which also implements a PCIe to USB bridge, but I've not seen one of those).  How are you attaching it physically to the RK3399?  Did you try other USB devices, or maybe a USB to mini-PCIe carrier board?