Igor Posted August 26, 2018 Posted August 26, 2018 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 Posted August 26, 2018 Posted August 26, 2018 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 Posted August 26, 2018 Posted August 26, 2018 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 Posted August 27, 2018 Author Posted August 27, 2018 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 Posted August 27, 2018 Posted August 27, 2018 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 Posted August 27, 2018 Posted August 27, 2018 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 Posted August 27, 2018 Posted August 27, 2018 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 Posted August 27, 2018 Posted August 27, 2018 23 minutes ago, tkaiser said: IMO we should enable 2.0/1.5GHz https://github.com/armbian/build/commit/c73748bc366e39053691668a9284e03949cb5b3b
tkaiser Posted August 27, 2018 Posted August 27, 2018 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 Posted August 27, 2018 Posted August 27, 2018 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 Posted August 27, 2018 Author Posted August 27, 2018 @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. 1
mmarks Posted August 28, 2018 Posted August 28, 2018 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 Posted August 28, 2018 Posted August 28, 2018 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 Posted September 3, 2018 Posted September 3, 2018 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 Posted September 4, 2018 Posted September 4, 2018 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 Posted September 4, 2018 Posted September 4, 2018 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 Posted September 4, 2018 Author Posted September 4, 2018 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 Posted September 4, 2018 Posted September 4, 2018 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/ 3
hjc Posted September 4, 2018 Author Posted September 4, 2018 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 Posted October 1, 2018 Author Posted October 1, 2018 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 Posted October 2, 2018 Posted October 2, 2018 "Don't have this board. Untested. https://dl.armbian.com/firefly-rk3399/" Are they images for EMMC or only micro-sd cards?
constantius Posted October 29, 2018 Posted October 29, 2018 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 Posted October 29, 2018 Posted October 29, 2018 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 Posted October 30, 2018 Posted October 30, 2018 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 Posted October 31, 2018 Posted October 31, 2018 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 Posted December 9, 2018 Posted December 9, 2018 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 Posted December 9, 2018 Posted December 9, 2018 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 Posted December 18, 2018 Posted December 18, 2018 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 Posted January 15, 2019 Posted January 15, 2019 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 Posted March 13, 2019 Posted March 13, 2019 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?
![m][sko](https://forum.armbian.com/uploads/n2a/n2a-180904eb9612afa23a4c3358385bd86f384613e3.avatars_letters_gd.png){kind=avatar}
Recommended Posts