RK3399 Orange Pi

[ning]

https://item.taobao.com/item.htm?spm=a1z10.5-c.w4002-9552179460.19.51b420baqekCuz&id=564484944766

 

699RMB  for pre-order.

[pbies]

I have it in my hand. I can give you feedback about this board.

 

Due to eMMC it is nearly not accessible from outside. Android already installed in eMMC is useless. Keyboard and mouse gives nothing with this board.

 

Need to make some acrobatics to work this board out. First install a normal Linux system.

 

By USB-C cable connected to my PC I can't do anything with this board, because it receives not enough power.

Dedicated PSU gives possibility to boot to Android, but no other sensible port to program the eMMC.

[pbies]

Well, after two weeks fight with Orange Pi RK3399 I am trying to return it to seller on AliExpress. I flashed Linux images to the board few times, but the board does not boot. Many users on manufacturer's forum are complaining that they can't do anything with the board. The only system which is working in Android, which is useless in many cases.

 

Maybe this board is powerful, but the software and support given are ridiculous. Board has few months and there should be stable Linux provided, not only Android (even without Google Play shop).

 

If you want to lose money - buying this board is the right direction.

[pbies]

AT LAST!

 

I've started the RK3399 with Ubuntu Server 16.04.3 LTS, kernel 4.4.103.
Exactly flashed under Linux the provided Ubuntu image from Mega hosting.
You need the Linux4.4...tar.gz file to flash the image.
The mk-image.sh script is making recursive rootfs.img inside system.img - so it won't work! You can check that by 7-zip on Windows.
Image compiled like it is said in manual won't work as rootfs is in this image recursively.
Via Windows AndroidTool you can flash only Android image, other images, whatever they are, won't be taken.
/proc/cpuinfo sees only 6 CPUs (0-5). Serial number for CPU is only zeros.
You can flash the image only on Linux, using USB 2.0 port - not 3.0!
Linux flash_tool.sh is in .tar.gz - you need to uncompress the whole file (binaries which are needed are elsewhere in that archive).
Reboot from logged in root to login prompt takes 16 seconds.
Login "root", password "orangepi" - I suspect root can't login first time.
Other user - login "orangepi", password "orangepi", then "su", there is no "sudo".
There are NO: ifconfig, ping, trace*, mc, pv, links, arp, rarp.
There are: ifup, ifdown, ifquery, wpa_passphrase, wpa_supplicant.
There is no network configuration - any! Only some files that are nearly empty - not configured. "ifquery" gives only "lo" and "eth0".

 

Now I need to configure Ethernet and/or Wi-Fi on that board - all help appreciated!
If you need to know anything - just ask!
 

[pbies]

Steps:
 - Download:
    "OrangePi-RK3399_Linux4.4_V1.0_2018_0110.tar.gz"
    "OrangePi-rk3399_Ubuntu16.04-Server_20171227.img"
 - Start Linux on PC
 - Unpack .tar.gz via "tar xvf OrangePi-RK3399_Linux4.4_V1.0_2018_0110.tar.gz" - it will create a subfolder "rk-linux", no need to create any folders
 - In folder "rk-linux" create folder "out"
 - Put in "out" folder the Ubuntu .img file and rename it to "system.img"
 - Short connect the two pins and connect board via USB-C to USB 2.0 in your PC - you may need to repeat this step if the following step gives error
 - Run "./build/flash_tool.sh -c rk3399 -p system -i out/system.img" from "rk-linux" folder
Done!
 

[tkaiser]

1 hour ago, pbies said:

OrangePi-RK3399_Linux4.4_V1.0_2018_0110.tar.gz

 

I downloaded the tarball and extracted the relevant stuff: http://kaiser-edv.de/tmp/jk4NM5/rk3399-orangepi.dts.tgz

 

Back in March Xunlong said they have no RK3399 dev samples to send out. No idea whether this has changed. But whoever is interested in getting Armbian on this board needs at least the contained 3 files:

-rw-r--r--@ 1 tk  staff   5777 19 Dez  2017 rk3399-orangepi.dts
-rw-r--r--@ 1 tk  staff  19811  2 Nov  2017 rk3399-sdram-lpddr3-4GB-1600.dtsi
-rw-r--r--@ 1 tk  staff  53378  2 Nov  2017 rk3399.dtsi

 

[pbies]

2 hours ago, tkaiser said:

whoever is interested in getting Armbian on this board needs at least the contained 3 files

 

 

Are these files the same as in manufacturers files (all OSes), or they are especially written for Armbian?

[pbies]

In 7-zip benchmark Orange Pi RK3399 gives about 5330 MIPS total, when Raspberry Pi 3 B+ gives 2833 MIPS.

 

Surely these are not very accurate benchmarks as there throttling occurs.

[pbies]

Orange Pi RK3399 eMMC read speed is:

14,6GiB 0:01:13 [ 202MiB/s] [===...===>] 100%

It varies from 170 MB/s to over 216 MB/s.

 

Command used:

pv /dev/mmcblk1 > /dev/null

Write speed in filesystem is about 48 MB/s.

[pbies]

Benchmarks 2018-08-18:

 

$ stress-ng --cpu 1 --cpu-method matrixprod --metrics-brief -t 60
stress-ng: info:  [1932] dispatching hogs: 1 cpu
stress-ng: info:  [1932] cache allocate: using built-in defaults as unable to determine cache details
stress-ng: info:  [1932] cache allocate: default cache size: 2048K
stress-ng: info:  [1932] successful run completed in 60.23s (1 min, 0.23 secs)
stress-ng: info:  [1932] stressor      bogo ops real time  usr time  sys time   bogo ops/s   bogo ops/s
stress-ng: info:  [1932]                          (secs)    (secs)    (secs)   (real time) (usr+sys time)
stress-ng: info:  [1932] cpu                258     60.22     60.22      0.00         4.28         4.28

$ stress-ng --cpu 6 --cpu-method matrixprod --metrics-brief -t 60
stress-ng: info:  [1935] dispatching hogs: 6 cpu
stress-ng: info:  [1935] cache allocate: using built-in defaults as unable to determine cache details
stress-ng: info:  [1935] cache allocate: default cache size: 2048K
stress-ng: info:  [1935] successful run completed in 60.14s (1 min, 0.14 secs)
stress-ng: info:  [1935] stressor      bogo ops real time  usr time  sys time   bogo ops/s   bogo ops/s
stress-ng: info:  [1935]                          (secs)    (secs)    (secs)   (real time) (usr+sys time)
stress-ng: info:  [1935] cpu                882     60.10    359.17      0.02        14.68         2.46

$ sysbench --test=cpu --cpu-max-prime=20000 --num-threads=1 --max-time=60 run
sysbench 0.4.12:  multi-threaded system evaluation benchmark
Running the test with following options:
Number of threads: 1
Doing CPU performance benchmark
Threads started!
Done.
Maximum prime number checked in CPU test: 20000
Test execution summary:
    total time:                          14.2567s
    total number of events:              10000
    total time taken by event execution: 14.2539
    per-request statistics:
         min:                                  1.42ms
         avg:                                  1.43ms
         max:                                  6.39ms
         approx.  95 percentile:               1.42ms
Threads fairness:
    events (avg/stddev):           10000.0000/0.00
    execution time (avg/stddev):   14.2539/0.00

$ sysbench --test=cpu --cpu-max-prime=20000 --num-threads=6 --max-time=60 run
sysbench 0.4.12:  multi-threaded system evaluation benchmark
Running the test with following options:
Number of threads: 6
Doing CPU performance benchmark
Threads started!
Done.
Maximum prime number checked in CPU test: 20000
Test execution summary:
    total time:                          3.5062s
    total number of events:              10000
    total time taken by event execution: 20.9935
    per-request statistics:
         min:                                  1.42ms
         avg:                                  2.10ms
         max:                                 19.40ms
         approx.  95 percentile:               2.62ms
Threads fairness:
    events (avg/stddev):           1666.6667/498.81
    execution time (avg/stddev):   3.4989/0.00

 

[pbies]

If you want to move from default 4.4.103 kernel version to 4.4.143 it is possible just by replacing the "Image" file in "boot" folder (boot partition which is FAT when you mount it).

No need to change the .conf or .dtb files.

Tested.

 

The instruction is provided here:

http://opensource.rock-chips.com/wiki_Rockchip_Kernel

Which takes only 4 commands:

git clone https://github.com/rockchip-linux/kernel.git
cd kernel
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- rockchip_linux_defconfig
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j4

And you have "Image" file.

 

Surely some packages would be needed - all is on the Internet if you search for a specific error messages.

[tkaiser]

On 8/17/2018 at 6:37 PM, pbies said:

In 7-zip benchmark Orange Pi RK3399 gives about 5330 MIPS total, when Raspberry Pi 3 B+ gives 2833 MIPS

 

For anyone stumbling accross these numbers: They're useless.

 

It's about the SoC and how CPU and memory clockspeeds are controlled. An RPi 3 B+ might reach 3600 7-zip MIPS (cpufreq/DVFS is controlled by a closed source BLOB so we can't exceed these numbers). An RK3399 device with default settings (1.8GHz big cores, 1.4GHz little cores), LPDDR with default DRAM initialization BLOB will score  ~6300 7-zip MIPS with approriate cooling. Since RK3399 is not a closed source platform like the RPi we can also increase clockspeeds and then obviously performance increases too (of course then even more appropriate cooling being important).

 

https://github.com/ThomasKaiser/sbc-bench/blob/master/Results.md (or see here for a nicely overclocked Firefly RK3399)

 

On 8/18/2018 at 2:41 PM, pbies said:

pv /dev/mmcblk1 > /dev/null

 

Useless since pv uses a buffer size too small. I would assume with large blocksizes the 16 GB eMMC is capable of up to 300 MB/s read speeds as the other RK3399 boards using same Samsung eMMC.

 

On 8/18/2018 at 2:57 PM, pbies said:

sysbench --test=cpu --cpu-max-prime=20000 --num-threads=6 --max-time=60 run

 

Sysbench is totally useless since not able to benchmark hardware. It's only a compiler benchmark: 

 

 

[pbies]

With Wi-Fi files in /system/etc/firmware/

 

fw_bcm4356a2_ag.bin

nvram_ap6356.txt

nvram_ap6356s.txt

 

Pi is giving many errors in syslog - concerning read/write operations to/from bcmsdh_sdmmc. Then can't use the board in any way (SSH, samba).

Wi-Fi usage has no sense with this board with the provided drivers.

[TonyMac32]

4 hours ago, pbies said:

Pi is giving many errors in syslog - concerning read/write operations to/from bcmsdh_sdmmc. Then can't use the board in any way (SSH, samba).

Wi-Fi usage has no sense with this board with the provided drivers.

 

armbianmonitor -u please.

 

AP6356S on NanoPC-T4 is working without issue or complaint with that firmware. (currently attached at 585 Mb/s) 

 

I would review the kernel config you're using, especially after:

 

On 8/18/2018 at 7:12 PM, pbies said:

If you want to move from default 4.4.103 kernel version to 4.4.143 it is possible just by replacing the "Image" file in "boot" folder (boot partition which is FAT when you mount it).

No need to change the .conf or .dtb files.

Tested.

 

[pbies]

@TonyMac32 this is Ubuntu, not Armbian, so the command does not exist.

 

Also, after syslog is filled in with error messages, there is no way to use the Pi or execute any command.

 

Syslog has many lines like these:

Aug 21 11:33:03 opi kernel: [36492.358017] bcmsdh_sdmmc: Failed to Write byte F1:@0x1001f=00, Err: -5
Aug 21 11:33:03 opi kernel: [36492.361114] bcmsdh_sdmmc: Failed to Write byte F1:@0x1001f=00, Err: -5
Aug 21 11:33:03 opi kernel: [36492.364195] bcmsdh_sdmmc: Failed to Write byte F1:@0x1001f=00, Err: -5
Aug 21 11:33:03 opi kernel: [36492.366305] bcmsdh_sdmmc: Failed to Read byte F1:@0x1001f=ff, Err: -5
Aug 21 11:33:03 opi kernel: [36492.369400] bcmsdh_sdmmc: Failed to Read byte F1:@0x1001f=ff, Err: -5
Aug 21 11:33:03 opi kernel: [36492.372494] bcmsdh_sdmmc: Failed to Read byte F1:@0x1001f=ff, Err: -5

Kernel is running with these parameters:

label kernel-4.4
    kernel /Image
    fdt /rk3399-orangepi.dtb
    append  earlyprintk console=ttyFIQ0,1500000n8 rw root=PARTUUID=b921b045-1d rootfstype=ext4 init=/sbin/init rootwait 

 

[pbies]

Wi-Fi on Ubuntu Server provided by manufacturer was not working properly. It happened few times that the Pi hang-up when Wi-Fi was on. There were errors in syslog.

So I've switched to provided Debian and for some time everything was fine with Wi-Fi till the same errors that happened on Ubuntu.

Kernel version does not matter here.

 

So the Wi-Fi module is useless at this moment. Need to wait for next version of OS for this board.

[pbies]

I've changed my router yesterday to 1000Mb/s and Orange Pi RK3399 is not fully functioning with this speed. Needed to lower the speed to 100Mb/s to be able to use SSH or Samba.

 

At 1000Mb/s there were many connection issues.

 

Provided old Ubuntu Server and Debian images for this board are not compatible with newer hardware and with the board itself.

 

Still in need for new OS for this board.

[pbies]

It is about 3 months as I am contacting support for this board.

They can't make the board Wi-Fi work for longer time (more than few hours) and Ethernet at 1Gbps.

 

The support guy Steven is so stupid, that he is not reading any of my messages and trying to force their solution to load software to the board and return it back to me.

Which is a security issue and I will have no possibility to load any other software in the future even if the board will stop responding.

 

This support and all around this board is so useless that is getting me pissed off and nervous.

If you want a nicely working board please buy anything else than RK3399 Orange Pi.

[broodwich82]

Thanks for the information on this board, I was considering buying one but it doesn't seem fully baked enough for me.

[pbies]

Shenzhen Xunlong Software CO.,Limited is not taking any responsibility for the boards they are selling. I am second week trying to get refund for sent for RMA board, but Steven Zhao - their support is still talking the same that they can fix the board in their own way, which is useless for me.

 

I've made contact with this words:

 

No mister, I'll explain: 1. The board should be in the same condition as I've sent it, so nearly new - nothing was done with the board crossing any normal usage boundaries. So the board is as new. There is no reason to treat it like a lower value hardware. 2. I don't expect unlimited service, I expect standard EU RMA which you should hold for at least one year from date of purchase (over 9 months from today to the future). Basing on RMA I've sent you the board to fix the problems. Only because of that. I was suspecting hardware problem but you said the hardware is ok. 3. I am not interested in your software, as of these reasons: a) it is a security risk - I don't know what you will flash to the board - I need to do it myself b) I would not be able to flash anything if the board system hangs up and can't be started, because I will lost you work concerning Wi-Fi and Ethernet c) I would need to send you the board each time the board stops working from software reasons to make Wi-Fi and Ethernet work again 4. I've already told you what instructions I need - on email and in messages here. You still didn't read them and you need to go through them as many times as is possible till you understand what I need. 5. Software on the board was downloaded from your website - images given of operating system Debian and Ubuntu - they remain nearly unchanged on the board and with them the Wi-Fi can't work more than few hours and Ethernet can't work at 1Gbps. So if this is your software - I've already told you: sent instructions how to make these two (Wi-Fi, Ethernet) elements work on provided by you images of operating systems (too old for today Ubuntu 16.04 from year 2016). 6. I don't accept "ready on the board" solution because of point 3 - this is a security risk and I would not be able to flash any other firmware without losing your job done on the board to make things work. And this is why I am demanding refund, as you said - you can't fix it in the way normal engineer would expect to. Board with prepared by you firmware is useless for me - look point 3 a+b+c above.

 

Still they refuse to make a refund.

[chwe]

@pbies this is a review thread for the board, not a 'rant thread' towards your refund problems with the seller. I assume you bought it over Aliexpress? They have a button called 'OPEN DISPUTE' that's where such stuff should be solved. Then you can mention that you're not happy with the refund policy of Xunlong.

For the software side, understandable that they're not willing to solve your issues if you go with your own/custom rom. Similar to routers/smartphones/*fill in random device* they normally refuse any support as soon as you touch "the firmware". Indeed you're right that wifi and GbE should work 'as promised' with the stock "firmware". If this would be true for all SBCs Armbian would be a much smaller project.  

Towards Ubuntu 16.04 is outdated, LTS Ubuntus get updates so at least for the userspace related part this shouldn't be much an issue as long as the repositories are properly configured. For the kernel, different story, keep them updated is a bunch of work keep them updated is a bunch of work. Doesn't happen for most of your android phones (at least the cheap ones), doesn't happen (often) for SBCs cause it's a support nightmare (every-time Armbian breaks boards from users due to kernel/u-boot update everyone shows up here to complain). You need infrastructure (e.g. your own repository) and a lot of testing (and even then it fails sometimes).

 

2 hours ago, pbies said:

3. I am not interested in your software, as of these reasons: a) it is a security risk - I don't know what you will flash to the board - I need to do it myself b) I would not be able to flash anything if the board system hangs up and can't be started, because I will lost you work concerning Wi-Fi and Ethernet c) I would need to send you the board each time the board stops working from software reasons to make Wi-Fi and Ethernet work again

If you don't trust the boardmakers software at all, you shouldn't buy hardware from them...  I don't know if any distributions currently support this board, but if they don't build and maintain the kernels, chances are high that they simply use the kernel, uboot, atf provided by the boardmaker and stick over their rootfs. As a shady hacker I would likely hide in the kernel where I can hide such stuff a way easier than in userspace..   Armbian differs here, you see where our sources came from, and if you don't trust us you can clone the repo check the code and build it on your own (then you only have to trust the debian/ubuntu package maintainers - and if this isn't an option as well you can build them on your own as well gonna be a lot of sourcecode checking then).. 

 

As far as I've experienced RK3399 is failsave (you can mess um eMMC and simply re-flash it with RockChips flashing tools - xunlongs manual mentions this too in the documentation for their board) - nevertheless no guarantee from my side that this works, my experience with RK3399 is rather low at the moment, it's up to you if you brick it.. 

 

They also provide a 'Linux 4.4 SDK' so I assume most of the things needed will be there (e.g. DT).  ATF, ram binaries used etc. then follow @hjc's firefly thread to get a clue how to bring up an RK3399:

 

 They even share the same wifi GbE chips (just a quick look), so this stuff should be possible as long as there aren't any hardware flaws which can't be fixed. So the situation for firing this thingie up is actually not that bad.. It's just nobody interested in doing the work. Likely cause nobody has it.. IMO it's a weired mix of a evaluation board/SBC but that's my personal opinion here.. I'm sure you can make something interesting out of it (e.g. fire up the TC358749XBG and make a nice little opensource HDMI recording box out of it..  last time I had a look into RKs kernelsources the needed drivers were there.. even with DT description how to achieve it but not my field nor of interest to me). 

 

So you can either complain more and let it collect dust or you make something useful out of it cause:

at least they're honest.. 

 

2 hours ago, pbies said:

I expect standard EU RMA which you should hold for at least one year from date of purchase (over 9 months from today to the future).

I assume you didn't bought it in the Union and therefore they simply don't care (and don't have to) - but I'm not familiar with EU's law - we're not part of it.. 

[pbies]

@chwe My intention was not to rant the company, but warn potential buyers from making the same mistake. Yes, it is AliExpress and it is far after dispute possibility as the board I've bought about 3 months ago. I was fighting 2 months with the board and with the support to make things work as expected. Two weeks ago I've sent the board to support as they suspected hardware problem. It wasn't hardware problem. They offered me their own OS for the board - flashed by them - what destroys my expectation for this board to be applicable to my needs and violates the given 3 bullets list. There was no warranty given at the moment of order - that destroys all the trust to them and is first reason to not buy anything from them. If someone is selling sth, especially in computer engineering branch - he needs to take responsibility for it. Here we have "sold, money earned, GTFO client!". If company does not give any warranty and does not comply with EU regulations about international purchasing - then the company violates the law and should be prosecuted. I gave them my trust buying the hardware with specific parameters but they violated it by: 1. offering different specs - AliExpress is sensitive about that and I am fighting with company through them 2. having horrible support 3. not complying with normal market behaviors. 

 

I am not guilty here: I've ordered the hardware, it does not work as in specs, so I return the hardware and await for refund. I've not done anything wrong to be treated like that by this company.

[chwe]

18 minutes ago, pbies said:

Here we have "sold, money earned, GTFO client!". 

this statement is in conflict with:

19 minutes ago, pbies said:

Two weeks ago I've sent the board to support as they suspected hardware problem. It wasn't hardware problem. They offered me their own OS for the board - flashed by them

 

so what else can they offer in terms of 'bringing up' your device, as far as I understand European law (and I'm not a lawyer nor really interested in it) a 'free refund' is 2 weeks, actually the same time you can open a dispute on aliexpress (not sure anymore I mostly order garbage there where a refund isn't worth the efforts ).. The board has no hardware defect so it's either a users fault or a software issue right (if software is covered as well good night for cisco )? I can understand that they don't take responsibility that it works properly if you flash the image on your own.. we do it neither and it ends quite often here: https://forum.armbian.com/forum/31-sd-card-and-power-supply/ or should end there cause 'issues magically disappears after change the SD-Card'.

 

53 minutes ago, pbies said:

what destroys my expectation for this board to be applicable to my needs and violates the given 3 bullets list.

you don't trust that they flash an Image but you trust in their Images? cause you would anyway flash one that they provide.. So where's the difference? Expect a shady add-on only for you?  

 

It's up to you how you call them, but don't expect that such posts don't get recognized by the boardmakers some of them read here as well threads related to their products and this might have an impact on their goodwill.  

 

36 minutes ago, pbies said:

If company does not give any warranty and does not comply with EU regulations about international purchasing - then the company violates the law and should be prosecuted.

If and that's a big if (cause I've no clue here) the Union has regulations for international (outside EU) purchasing and warranty then you're free to do so.. 

 

43 minutes ago, pbies said:

so I return the hardware and await for refund.

well if returned already then it's to late to have fun with a board bring up.. @hjc pointed you back in august what's needed bring it up.. 

from back then:

Quote

I am not enough advanced about these boards to mess with u-boot.

you'll learn it trust me.  And if it's only copy pasting together a DT for your boards u-boot, then it's not much efforts to learn it.. DT in kernel and u-boot are similar mostly just wipe out everything not needed. 

[pbies]

@chwe you didn't understood what I've written here. You catch parts of my posts and complain about each one taken separately. Do understand the whole problem, not only parts of it! Then, after understanding the whole situation you are allowed to comply about the whole problem, not only parts of it. I won't be explaining further as normally thinking person would agree with me 100 times about the above and even didn't negotiate my undeniable right to get my money back.

 

I understand that most of you here are engineers that like to mess with such hardware, but there are also rules of normal people trying to do sth with properly provided hardware and software - and this is what I am complaining here about - the provided software and specs of the hardware.

 

Ask yourself these questions:

1. provided software lacks properly working Wi-Fi and Ethernet - how long and how much effort will you give before you give up trying to make it work if you will be able to make it work (which is still unsure)?
2. would you buy pendrive which lacks controller, because it is made for creating your own one?
3. I've written that I need instructions for making Wi-Fi and Ethernet work on any provided OS, but I am not interested in on-board ready solution - did you read this part correclty and fully understood or are you just trolling me? It is still about points 3: a+b+c.

There is such law which I was talking about, make a research, then comply about my right to get refund. About u-boot: I don't have time to mess with such low-level software, I need a board with given in specs functionalities and expect them to work. If the board does not comply with the specs - it is returned back and should be refunded - that's how EU world works and this is covered by international agreements. Users come with lower or higher levels of advancement in technology, with my 30-years experience I expect that provided hardware and software are using whole hardware abilities, and if they don't - there is no place for such hardware and software on the market - simple as that.

[NicoD]

@pbies If you buy an SBC then know there`s going to be things not working. Orange Pi is one of the worst in software support. If you would have done a little bit of research you would have known that before you bought it. Reviews on youtube, their forum, other forums...
The software on SBC`s is free. It`s a work for and by the community for a big part. Windows isn`t free, + you have to buy your computer too. The cost of apple products is a big peace for the software. 
I don`t want that sh*t on my sbc`s. 
There are enough cheap tv-sticks and tv-boxes for users with less knowledge. You should have bought something like that, or a better supported sbc. 
You didn`t do your homework, so you get burned. It`s hard to say, but you should have known. It`s not a secret that SBC`s are for "tinkerers" and are not full blown desktop pc. 

I would keep it and learn what you need to learn. There`ll come better images from the community. You`re not the only one who bought it. And it should be a solid board.
Have a nice day.
 

[pbies]

@NicoD yes, you are right. I was convinced that in case of boards like RK3399 it will be the same as for RPi3B+ and previous - that the provided boards and software will be functioning properly out-of-the-box.

[NicoD]

2 minutes ago, pbies said:

@NicoD yes, you are right. I was convinced that in case of boards like RK3399 it will be the same as for RPi3B+ and previous - that the provided boards and software will be functioning properly out-of-the-box.

Only the Raspberry Pi has got such a big community, so a lot more hands (and brains) working on/with it. 
Odroid`s also have a great community. From those you can expect things to work out of the box. But those are the only ones(I know of).
Greetings

[chwe]

53 minutes ago, pbies said:

I understand that most of you here are engineers that like to mess with such hardware,

not sure.. I'm doing in science.. My normal workplace looks like that:

Spoiler

messing with u-boot and kernel is 'just a hobby to waste time'.. 

 

58 minutes ago, pbies said:

provided software lacks properly working Wi-Fi and Ethernet - how long and how much effort will you give before you give up trying to make it work if you will be able to make it work (which is still unsure)?

quite a lot, see:

I learned a lot with it.. 

 

1 hour ago, pbies said:

would you buy pendrive which lacks controller, because it is made for creating your own one?

I don't get the point here.. 

1 hour ago, pbies said:

I've written that I need instructions for making Wi-Fi and Ethernet work on any provided OS, but I am not interested in on-board ready solution - did you read this part correclty and fully understood or are you just trolling me? It is still about points 3: a+b+c.

lets sort out 3 a-c

6 hours ago, pbies said:

3. I am not interested in your software, as of these reasons: a) it is a security risk - I don't know what you will flash to the board - I need to do it myself b) I would not be able to flash anything if the board system hangs up and can't be started, because I will lost you work concerning Wi-Fi and Ethernet c) I would need to send you the board each time the board stops working from software reasons to make Wi-Fi and Ethernet work again

a) you flash their provided image without even thinking about but you think this differ from they flashing the image? They don't create a special image for you.. they just flash their stock os but if they do it, they can ensure that everything is done correctly. So where is the security issue here? It's yet their image and if they flash it it will be their image as well

b) why not? If the description how to flash an image is correct you can simply download it as well and flash it.. If this doesn't work, it's either you doing it wrong or b there are software/hardware issues with the board/image. But if they burn the same image and it works then without issues, then chances are high that it is an operator issue.. 

c) see b

 

but I don't see a bigger security issue if they flash it or you flash it.. If you don't trust in their images well.. then it doesn't matter if it's they or you who flashes it.. 

 

1 hour ago, pbies said:

it is returned back and should be refunded - that's how EU world works and this is covered by international agreements.

that's how trade inside the EU works.. As said not en expert here.. but chances are high that such return agreements with countries outside the EU aren't covered by this law. That's why I'm buying all my SD-Cards locally even if they're ~2-3x the price compared to online, I simply don't want to deal with refund in case they don't deliver what they should (e.g. A1 rated cards).

 

An aliexpress pro tip: if you cover issues with your product, open proactive an dispute it can be closed if your problem gets resolved but then you're in the power-position. Now you can't open an dispute anymore and it's not as easy to get an refund..

1 hour ago, pbies said:

There is such law which I was talking about, make a research, then comply about my right to get refund.

A clear  NO here (it's not my job to study European law - and the 'do your research'-trend you get from everyone online is something I simply ignore, I can be wrong on the law part that's why I'm clearly point out: I'm not an expert on this, but if you want to convince me then show it, otherwise I'm quite confident that this law doesn't involve import from outside the Union). I don't complain, if you think you're right there you go: https://ec.europa.eu/info/live-work-travel-eu/consumers/resolve-your-consumer-complaint/european-consumer-centres-network_en 

 

Is it annoying when a board doesn't do what it should? Indeed it is.. But the review thread is the wrong place for complaining about refund issues, it's the correct thread to share your experience with badly working wifi or GbE, the rest is just ranting towards the seller and has not much to to with the board. 'LEAVE FEEDBACK' on aliexpress or a short annotation here would be IMO okay.

 

1 hour ago, pbies said:

30-years experience I...

I tend to ignore sentences which start with 'in my x years..' sorry for that, but it worked better for me. 

 

So a free offer from my side.. If you still have the board (or did you send it back?), and you don't care to waste a few other hours with it, I happily waste a bit of time trying to get familiar with the buildscript to build your own image with armbians buildscript, doesn't involve any sort of 'official armbian support'. It's just me giving you some hints here and there. Obviously you need an x86_64 buildmachine running ubuntu (or a virtual box) on it. No guarantee it will work better after its.. 

 

15 minutes ago, pbies said:

RK3399 it will be the same as for RPi3B+

well the RPi3B+ and its add-ons is probably the wrong example:

• they had to lower throttling temperature cause some boards didn't run stable
• 'GbE over USB2' was such a nightmare that @tkaiser set them all to fast ethernet for OMV images
• the PoE Hat seems to be a nightmare too: https://www.theregister.co.uk/2018/09/11/raspberry_pi_poe_hat_issue/
• undervoltage without the special 'RPi microUSB charger' must be considered as default not as exception 

 but that's me being cynical.. 

[pbies]

@chwe I do not clearly understood what you have written here and what you are trying to achieve. Can you please elaborate more and explain what are you trying to say and achieve?

[chwe]

If your OPi RK3399 is still there and you want to build an Image with armbians Buildscript, I may give you some hints what's needed to bring it up.. Doesn't mean the board gets ever 'official' armbian support. I had a quick look into the sources.. I don't think it's that hard to build an image based on it. Cause I've a RK3399 based TV-box which 'boots with Xunlongs Android' I've a look into the sources anyway.. The sources provided by Xunlong aren't that bad actually.. They create a Image based on rockchips buildscript, so sorting out the missing bits to transfer this to Armbians buildscript looks not that hard. You would still have to build the images on your own and do the testing (no guarantee it works reliable).. But I assume one kernel and one u-boot patch will be sufficient for some testing.