chwe

going through the links spotted something for @martinayotte (and maybe @TonyMac32)
 
https://github.com/archlinuxarm/PKGBUILDs/pull/1691/commits/dfe2881b2eaf32a5b2289005c675888345684fd7#diff-2347b909a334e35e45d31e5bb4961a3f
 
there's a a patchset for upstream u-boot for the ram part.. as OP says it's not running stable.. but at least they got upstream u-boot up.. maybe worth a look as well.. to clean the rk u-boot mess asap.

well.. that's one which you can solder without trouble.. @TonyMac32 would probably say I'm wrong.. but I would tin the first pad, press the SPI nor on it and remelt it.. once you have an anchor pad.. the rest is easy..

Thanks to all for the recent responses! It helps to keep the motivation above zero and yes, maybe it is time to search for external help.
 
But now the short guide "how to brick such a box":
It was not bad luck but active stupitidy.
Some weeks ago in a mixture of impatience, lack of time and sleep I decided to try out various commands of the u-boot-shell. Before that I had to reflash my box several times, which worked easily and besides I was under the (incorrect) impression, that things like the RPMB were already written to the box by the vendor. That led to a situation of recklessness. 
So I typed in the command:  m m c  k s (I added additional spaces here to avoid dangerous copy-and-paste-actions!!)
The I got:
 
That did not look promising and it turned out to do the bricking.
The good thing is, that you have to actively kill the box and it should not happen so easy.
So the general advice of common sense is valid here too: Do not do things in a hurry, read through every available resource before you press enter button!
 
My last try to recover the box  would be to solder a SPI flash chip onto the PCB and flash it with the REALTEK tool. Can someone provide a hint which chip type could be compatible?

@martinayotteI think many board DO explicitly provide the bus-width. Of course, I think many people haven't equipped ECC brain like me, so there could be some boards w/o bus-width.
 
You can submit patches for mainline for those boards.
 
The mainline doesn't agree to add bus-width to SoC DTSI because it's for the board's designer to decide the bus-width (of course it cannot go beyond the controller's maximum). For example, some board uses a SD card slot (which is bus-width = <4>) on a eMMC controller (which can be at most bus-width = <8>), and in this case the 4 remaining data lines can even be used as GPIO.

Sorry to necro an old thread, but I didn't find a more suitable one and I didn't want to start a new one. 
Anyway, to the point.
When I install or build any of the Armbian dev/nightly images with kernel 5.x, the sdcard is practically unusable after the installation. 
hdparm shows read/write speeds of max. 5 MB/sec. The reason is that unless the bus-width for mmc@4020000 is explicitly set to 4 bits in 
sun50i-h6-orangepi-one-plus.dtb mmc@4020000 { compatible = "allwinner,sun50i-h6-mmc", "allwinner,sun50i-a64-mmc"; reg = <0x4020000 0x1000>; clocks = <0x2 0x43 0x2 0x40>; clock-names = "ahb", "mmc"; resets = <0x2 0x12>; reset-names = "ahb"; interrupts = <0x0 0x23 0x4>; status = "okay"; #address-cells = <0x1>; #size-cells = <0x0>; pinctrl-names = "default"; pinctrl-0 = <0xb>; vmmc-supply = <0xc>; bus-width = <0x4>; cd-gpios = <0xd 0x5 0x6 0x1>; phandle = <0x2f>; }; the bus width defaults to 1 bit as seen in 
root@orangepi:~# cat /sys/kernel/debug/mmc0/ios clock: 50000000 Hz actual clock: 50000000 Hz vdd: 21 (3.3 ~ 3.4 V) bus mode: 2 (push-pull) chip select: 0 (don't care) power mode: 2 (on) bus width: 0 (1 bits) timing spec: 2 (sd high-speed) signal voltage: 0 (3.30 V) driver type: 0 (driver type B) which practically cripples the SD card interface. By default there is no bus-width entry in sun50i-h6-orangepi-one-plus.dtb for mmc@4020000. I don't know if this is Armbian specific or not or if this has been mentioned again, I just thought I'd share my findings in case this helps someone. 

The changes by "Squonk42" have been integrated into mainline buildroot something like two weeks ago. So if you checkout the current git, you can just build it.
 
I also did something similar using the external layer feature of buildroot. This keeps custom changes separated from the "official" buildroot, so hacking is a bit more straight forward and migration to a new version of buildroot is easier. It's available at:
https://git.h8u.de/Allwinner_V3s/buildroot-v3s
I can also create a mirror on github if anyone is interested in joining in.

perfect solution. works fine. thank you!
 
For thus who try to C&P the above clock-frequency string: Attention it contains non-standard space chars after the number. So compiling to dtb fil fail with an error. Better use
 
clock-frequency = <400000>;  

If I didn't miss something the Rockpro is still marked as wip in the downloadpage right?
 

 
but well, maybe we should rename it back to wip so that only expert=yes can build images for it.. to make it more obvious..
 
but also this sub-forum has a nice reminder:

 
My RockPi 4b was used in a pure CPU numbers crunshing project for 17 days between 75°C and 80°C without any crash.. Would I call the RockPi stable.. for sure not. It seems that it did well for this test but I've no idea if it runs stable under all the other use-cases people can imagine for the board in question.
 
Just another reminder: https://forum.armbian.com/guidelines
especially this points here:
 
 
what makes you sure the powering issues are gone? Did you check voltage on 5v rail after replacing the PSU under stress?

This is only for sake of booting it somehow, but at least:
_ _ _ | | __ _| | _____ / | | | / _` | |/ / _ \ | | | |__| (_| | < __/ | | |_____\__,_|_|\_\___| |_| Welcome to ARMBIAN 5.77 user-built Debian GNU/Linux 9 (stretch) 4.19.16-rtd1295 System load: 2.81 1.25 0.47 Up time: 2 min Memory usage: 5 % of 1932MB IP: CPU temp: 42°C Usage of /: 15% of 7.1G  
This is useful for nothing at the moment (no usb, no net, no straightforward installation method), but I am not yet in the state to give up.
It is a buggy mess at the moment and again I have not uploaded all stuff to my repo.
To reach this pseudo-success, I had to boot with kernel 4.9.y, then let armbian resize the initial image (which does not work with 4.19.y for whatever reason) and then write the 4.19.-kernel and the DTB to the SD-card. So it is a bit of a click-bait 
 

The schematics were upload:
https://wiki.radxa.com/Rockpi4/hardware

Access to a console can be mandatory when you SBC doesn't work as expected (e.g Network or HDMI output doesn't work). When SSH/Display access isn't possible access to console via UART is the best way to get a clue where your SBC hangs. This short tutorial should give you an introduction how this works. For some boards, armbian implements an USB gadget mode (a 'fake' serial console over microUSB) describen below. As a reminder an USB-UART bridge is always prefered over USB gadget mode whenever possible (UART get's initialized before the gadget driver and also before HDMI, means even if you don't get a proper output from HDMI or gadget mode console, it is possible that UART will give you the needed information).
 
Prerequisites:
We need an Terminal program to access the console. If you use Linux on your host system I prefer picocom (something like minicom will also do the job) which can be installed:
on debian a like systems:
sudo apt-get install picocom from arch community repo:
https://www.archlinux.org/packages/community/x86_64/picocom/
 
on fedora systems:
yum install picocom on Mac OS X:
brew install picocom on Widows we use PuTTY:
 
https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html
 
UART USB Adapter:
There are various USB-UART bridges e.g FT232 (and fakes of them, cause FDTI is expensive ), CH340/1,PL2303 or CP2102
Normally it doesn't matter which one you use. I prefer the (probably fake) FDTI on the right side, but the CH341 does also a good job:

The only thing which is needed is that the signal-level matches with your SBCs needs (this is mostly 3.3V expect some Odroids e.g HC1 which has only 1.8V!).  Most of these USB-UART bridges have jumpers for 5V and 3.3V, make sure that you use the 3.3V.  
You've to figure out which pins on your SBC are debug UART (they've mostly a own 3 pin header, sometimes it's on the large pin header e.g. Tinkerboard) and then connect:
GND --> GND RX --> TX TX --> RX You've to check dmesg (linux) or run devmgmt.msc (windows) to know which device you use. 
Linux:
[256597.311207] usb 3-2: Product: USB2.0-Serial [256597.402283] usbcore: registered new interface driver ch341 [256597.402341] usbserial: USB Serial support registered for ch341-uart [256597.402392] ch341 3-2:1.0: ch341-uart converter detected [256597.404012] usb 3-2: ch341-uart converter now attached to ttyUSB0 --> Device will be /dev/ttyUSB0
Windows:
for windows 10 (https://www.google.ch/search?client=opera&amp;q=find+arduino+port+windows+10&amp;sourceid=opera&amp;ie=UTF-8&amp;oe=UTF-8)
Something like the picture in USB Gadget Mode part of the tutorial should show up)
 
Armbians default settings are (expect some RK devices):
For Picocom:
picocom -b 115200 -r -l /dev/ttyUSB0 and for some RK devices:
picocom -b 1500000 -r -l /dev/ttyUSB0 For PuTTY:
You've to set configuration in 'Serial'. COM11 is just an example and needs to be checked first, Speed (baud) needs to be changed when you deal with the few RK boards which need 1500000.

 
OS X:
TBD
should be similar to Linux whereas the naming differs a bit. See: https://forum.odroid.com/viewtopic.php?f=53&amp;t=841 as an example with minicom.
 
Normally you connect the USB-UART bridge to your host computer (and the SBC) and start picocom/putty before you power the board to ensure you get the full bootlog and not only parts of it. 
 
USB Gadget Mode
Several board (see list) for which official armbian images exist (or csc images can be built) have no HDMI display. On those boards there's USB gadget mode driver activated so that you can have console access to them via USB connection. The following short tutorial describes how you can access to console from Linux (don't have a windows machine here at the moment, I may check it later):
 
install picocom connect your board via USB to your host computer (it should be one which is able to power an SBC via its USB port) check dmesg for the device showing up:  [184372.603816] usb 3-2: Product: Gadget Serial v2.4 [184372.603818] usb 3-2: Manufacturer: Linux 4.14.65-sunxi with musb-hdrc [184372.660041] cdc_acm 3-2:2.0: ttyACM0: USB ACM device [184372.660402] usbcore: registered new interface driver cdc_acm [184372.660403] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters  
connect to it via picocom (in this case 'picocom /dev/ttyACM0'):  chwe@chwe-acer:~$ picocom /dev/ttyACM0 picocom v2.2 port is : /dev/ttyACM0 flowcontrol : none baudrate is : 9600 parity is : none databits are : 8 stopbits are : 1 escape is : C-a local echo is : no noinit is : no noreset is : no nolock is : no send_cmd is : sz -vv receive_cmd is : rz -vv -E imap is : omap is : emap is : crcrlf,delbs, Type [C-a] [C-h] to see available commands Terminal ready Debian GNU/Linux 9 orangepizero ttyGS0 orangepizero login: root Password: You are required to change your password immediately (root enforced) Changing password for root. (current) UNIX password:  
I assume if you use the same settings in something like putty on windows and you check which 'serial' device shows up in *where windows shows connected devices - I forgot it* you should be able to access it from windows (someone motivated may confirm this).  
For Windows:
run devmgmt.msc and search for the serial device (in this case COM3) and connect to it via PuTTY (thanks to @hjc):

for windows 10 (https://www.google.ch/search?client=opera&amp;q=find+arduino+port+windows+10&amp;sourceid=opera&amp;ie=UTF-8&amp;oe=UTF-8):
(even the tutorial is for arduinos, it should be similar for every 'COM device')
 
Currently boards with USB gadget mode:
bananapim2plus bananapim2zero nanopifire3 nanopim3 nanopineo2 nanopineocore2 nanopineoplus2 orangepizeroplus nanopiair nanopiduo nanopineo olimex-som204-a20 orangepilite orangepi-r1 orangepizero orangepizeroplus2-h3 orangepizeroplus2-h5 tritium-h3  
The silly approach
For those, who want to save 1$ for an USB-UART bridge, you can spend 10$ for an OrangePi Zero and use its spare UARTs to log into an other SBC...  SSH --> opi, ttl --> Tinkerboard
For those loving text more than videos:
SSH to your SBC sudo armbian-config --> system --> hardware  to activate an spare UART (in this case it was UART2, will give you ttyS2) reboot picocom -b 115200 -r -l /dev/ttyS2  
 

See:  https://asciinema.org/a/B87EOGhc0gx9oikMAGEG94lXR

 
 

No problem - for me what I donated to was the project, the people, and not necessarily the specific ARM hardware/software support.
 
The devs here are certainly passionate, as well as the users, and that passion is what I donated to.  I think there is a lot of unspoken appreciation for the work under the hood, but unless one raises their voice, or contributes in some fashion, it can become easy to be discouraged and wonder what's the point?
 
It's not about the money.  If you use Armbian, lurkers drop a little donation to keep it up and running.  It's one small way to let the devs know they aren't operating in a vacuum.

https://www.chiark.greenend.org.uk/~sgtatham/putty/changes.html
 
These features are new in 0.71 (released 2019-03-16):
 
Download at
https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html
Windows Binary 32Bit: https://the.earth.li/~sgtatham/putty/latest/w32/putty.zip
Windows Binary 64Bit https://the.earth.li/~sgtatham/putty/latest/w64/putty.zip

https://github.com/armbian/build/blob/92bb6f0b66b85cc166d869fd99f6d76f3c088cd5/config/kernel/linux-rockchip64-default.config#L2370
https://github.com/armbian/build/blob/92bb6f0b66b85cc166d869fd99f6d76f3c088cd5/config/kernel/linux-rockchip64-default.config#L5100
 
everything is there.. just activate the needed modules and build your own kernel.. But probably none of us tested if it works on RKs kernel. Fire up a virtualBox with ubuntu, build kernel, try it, report and if everything works create a PR.
 
https://docs.armbian.com/Process_Contribute/
 
 

Thanks for pointing it out. I will have out engineer look at it and clean the device tree. We would like to contribute to Armbian and get some decent support on ROCk Pi 4. Apparently, we should do it in the right way.

You probably should link to the original post cause the Register tends to be a bit....
https://www.realworldtech.com/forum/?threadid=183440&amp;curpostid=183486
 
His statements in the whole context sound a way more reasonable:
besides a few SBCs, ARM SoCs are 'only' found in Android, where power-consumption matters a way more (it matters for servers as well but it's not the 'main' thing, whereas for mobiles it is).. Routers etc. are mostly driven by MIPS. Intel tried once (with throwing a bunch of money into it) to enter the android world but they horribly failed and canceled more or less their low consumption small chips...
 
and that is actually true, Armbians buildscript is also x86 only, cause it might be hard to find good build servers to natively build our images on ARM.
Price matters.. The more volume, the lower the price.. See (android) TV-boxes.. where intel has no chance to enter the market..
well, I quoted this one just cause it's funny.
I programmed once my calculator, it was painful cross-platform an on itself.. But that's more related to the capabilities of it.. I think @JMCC is one of the few here who compiles debian packages on the SBCs itself (except @wtarreau)..
 
and followup:
https://www.realworldtech.com/forum/?threadid=183440&amp;curpostid=183500
 
make a nice case and don't tell him that there's a pinheader on it, maybe he don't see a difference..
 
Don't get me wrong, willy's buildfarm (https://www.cnx-software.com/2019/01/07/nanopi-neo4-build-farm-rk3399-overclocking/) is great, but not everyone wants to build such a farm just to avoid cross-compiling.
 
besides merging he probably never contributed a single bit to ARM development on Linux (I could be wrong here, I don't have record on which sub-systems he contributed in the beginnings). But as he stated multiple times, he's more 'kernel manager' and gate-keeper than programmer.. Just read through a few speaks from him to get a clue about his job in kernel development.
 
https://www.zdnet.com/article/linus-torvalds-would-like-to-see-an-arm-laptop-but-he-doesnt-expect-it/
https://www.zdnet.com/article/linus-torvalds-still-wants-the-linux-desktop/
 
It's not that he dislikes arm.. There are multiple statements where he was in favour for an arm based machine (especially during the spectre/meltdown phase he made some of them). But where others try to be as polite as possible, he prefers a rather strong wording to make his points clear. And I would say he has enough valid arguments to point out why arm is nowhere on server at the moment.
 
https://lkml.org/lkml/2018/1/21/192
 
IMO not at all, development of linux on arm won't stop cause Linus says that he doesn't think that arm will make it on the server market.. All our SBCs (except maybe the SolidRun) aren't server SoCs. We deal mostly with TV-box SoCs here.. As long as they push their stuff upstream and the code quality is good, he will merge it.. He just points out clearly why (in his opinion) arm won't enter the server market.. There aren't (m)any affordable workstations nor notebooks nor simple desktop computers based on arm, so that people deploy stuff on ARM. Even on bigger distros (Debian, Ubuntu, Suse etc.) arm is only the side-kick of x86 or AMD64. I don't think that this will change soon. Just look at commercial binary only software... If there's Linux support for it, it's mostly x86 only.. More or less nobody provides arm64 or armhf packages of their binaries..

You probably should link to the original post cause the Register tends to be a bit....
https://www.realworldtech.com/forum/?threadid=183440&amp;curpostid=183486
 
His statements in the whole context sound a way more reasonable:
besides a few SBCs, ARM SoCs are 'only' found in Android, where power-consumption matters a way more (it matters for servers as well but it's not the 'main' thing, whereas for mobiles it is).. Routers etc. are mostly driven by MIPS. Intel tried once (with throwing a bunch of money into it) to enter the android world but they horribly failed and canceled more or less their low consumption small chips...
 
and that is actually true, Armbians buildscript is also x86 only, cause it might be hard to find good build servers to natively build our images on ARM.
Price matters.. The more volume, the lower the price.. See (android) TV-boxes.. where intel has no chance to enter the market..
well, I quoted this one just cause it's funny.
I programmed once my calculator, it was painful cross-platform an on itself.. But that's more related to the capabilities of it.. I think @JMCC is one of the few here who compiles debian packages on the SBCs itself (except @wtarreau)..
 
and followup:
https://www.realworldtech.com/forum/?threadid=183440&amp;curpostid=183500
 
make a nice case and don't tell him that there's a pinheader on it, maybe he don't see a difference..
 
Don't get me wrong, willy's buildfarm (https://www.cnx-software.com/2019/01/07/nanopi-neo4-build-farm-rk3399-overclocking/) is great, but not everyone wants to build such a farm just to avoid cross-compiling.
 
besides merging he probably never contributed a single bit to ARM development on Linux (I could be wrong here, I don't have record on which sub-systems he contributed in the beginnings). But as he stated multiple times, he's more 'kernel manager' and gate-keeper than programmer.. Just read through a few speaks from him to get a clue about his job in kernel development.
 
https://www.zdnet.com/article/linus-torvalds-would-like-to-see-an-arm-laptop-but-he-doesnt-expect-it/
https://www.zdnet.com/article/linus-torvalds-still-wants-the-linux-desktop/
 
It's not that he dislikes arm.. There are multiple statements where he was in favour for an arm based machine (especially during the spectre/meltdown phase he made some of them). But where others try to be as polite as possible, he prefers a rather strong wording to make his points clear. And I would say he has enough valid arguments to point out why arm is nowhere on server at the moment.
 
https://lkml.org/lkml/2018/1/21/192
 
IMO not at all, development of linux on arm won't stop cause Linus says that he doesn't think that arm will make it on the server market.. All our SBCs (except maybe the SolidRun) aren't server SoCs. We deal mostly with TV-box SoCs here.. As long as they push their stuff upstream and the code quality is good, he will merge it.. He just points out clearly why (in his opinion) arm won't enter the server market.. There aren't (m)any affordable workstations nor notebooks nor simple desktop computers based on arm, so that people deploy stuff on ARM. Even on bigger distros (Debian, Ubuntu, Suse etc.) arm is only the side-kick of x86 or AMD64. I don't think that this will change soon. Just look at commercial binary only software... If there's Linux support for it, it's mostly x86 only.. More or less nobody provides arm64 or armhf packages of their binaries..

You probably should link to the original post cause the Register tends to be a bit....
https://www.realworldtech.com/forum/?threadid=183440&amp;curpostid=183486
 
His statements in the whole context sound a way more reasonable:
besides a few SBCs, ARM SoCs are 'only' found in Android, where power-consumption matters a way more (it matters for servers as well but it's not the 'main' thing, whereas for mobiles it is).. Routers etc. are mostly driven by MIPS. Intel tried once (with throwing a bunch of money into it) to enter the android world but they horribly failed and canceled more or less their low consumption small chips...
 
and that is actually true, Armbians buildscript is also x86 only, cause it might be hard to find good build servers to natively build our images on ARM.
Price matters.. The more volume, the lower the price.. See (android) TV-boxes.. where intel has no chance to enter the market..
well, I quoted this one just cause it's funny.
I programmed once my calculator, it was painful cross-platform an on itself.. But that's more related to the capabilities of it.. I think @JMCC is one of the few here who compiles debian packages on the SBCs itself (except @wtarreau)..
 
and followup:
https://www.realworldtech.com/forum/?threadid=183440&amp;curpostid=183500
 
make a nice case and don't tell him that there's a pinheader on it, maybe he don't see a difference..
 
Don't get me wrong, willy's buildfarm (https://www.cnx-software.com/2019/01/07/nanopi-neo4-build-farm-rk3399-overclocking/) is great, but not everyone wants to build such a farm just to avoid cross-compiling.
 
besides merging he probably never contributed a single bit to ARM development on Linux (I could be wrong here, I don't have record on which sub-systems he contributed in the beginnings). But as he stated multiple times, he's more 'kernel manager' and gate-keeper than programmer.. Just read through a few speaks from him to get a clue about his job in kernel development.
 
https://www.zdnet.com/article/linus-torvalds-would-like-to-see-an-arm-laptop-but-he-doesnt-expect-it/
https://www.zdnet.com/article/linus-torvalds-still-wants-the-linux-desktop/
 
It's not that he dislikes arm.. There are multiple statements where he was in favour for an arm based machine (especially during the spectre/meltdown phase he made some of them). But where others try to be as polite as possible, he prefers a rather strong wording to make his points clear. And I would say he has enough valid arguments to point out why arm is nowhere on server at the moment.
 
https://lkml.org/lkml/2018/1/21/192
 
IMO not at all, development of linux on arm won't stop cause Linus says that he doesn't think that arm will make it on the server market.. All our SBCs (except maybe the SolidRun) aren't server SoCs. We deal mostly with TV-box SoCs here.. As long as they push their stuff upstream and the code quality is good, he will merge it.. He just points out clearly why (in his opinion) arm won't enter the server market.. There aren't (m)any affordable workstations nor notebooks nor simple desktop computers based on arm, so that people deploy stuff on ARM. Even on bigger distros (Debian, Ubuntu, Suse etc.) arm is only the side-kick of x86 or AMD64. I don't think that this will change soon. Just look at commercial binary only software... If there's Linux support for it, it's mostly x86 only.. More or less nobody provides arm64 or armhf packages of their binaries..

@Myy The patches I have in my rockchip-5.x-vpu branch is on top of v5.0-rc6 + mmind/for-next and not a rockchip tree.
 
All vpu related patches needed on top of v5.0-rc6: https://github.com/Kwiboo/linux-rockchip/compare/v5.0-rc6...rockchip-5.x-vpu (patch)
List of mmind/for-next patches rebased on v5.0-rc6: https://github.com/Kwiboo/linux-rockchip/compare/v5.0-rc6...rockchip-5.x (patch)
VPU related patches on top of mmind/for-next: https://github.com/Kwiboo/linux-rockchip/compare/rockchip-5.x...rockchip-5.x-vpu (patch)
 
I have started to send some of my patches to linux mailing list and more will follow.

if I would speak for others I wouldn't write I.. right?
 
well, most of my serious work depends on windows, ergo depends on a flawlessly working x86 machine.. software support for the tools I need is nowhere either on arm and/or linux (something simple as a chemical structure editor which fulfills my needs simple doesn't exist on linux and I'm not a masochist using the few structure editors available which are open-source).
 
Or you calculate some statistics without meaning to let it look like a professional..
 
If I'm not completely wrong it should be:
x_mean = 01:07:27.56 (+-6s)
std. deviation = 24s
 
Assuming it's a Gaussian type distribution. Or otherwise called: the easy way to look results more trustfully even if there's absolutely no reason to do so!

I'm not sure on this one.. I seriously don't read many benchmarks.. I bought my notebook without looking at any benchmark.. I decided against another one cause it's a known not properly working one on linux.. I had a few other requirements which a bunch of them didn't fulfill (e.g. browsers are ram hungry and no way in heaven I go back to a 8gb ram one).. Whats about showing how a random board with the current available OS's perform on the use-cases you and others might have? E.g. lightweight desktop scenarios etc.
Personally, I think benchmarking makes sense to compare the same board with various distros or find bottlenecks.. e.g. is my SBC capable of saturating a GbE link with encrypted storage.. and when not why? Can this part be improved or not? If I've a desktop usage in mind should I use a Debian, an Ubuntu or might something like a Arch or Gentoo be the better option. For sure this is difficult due to Linux on Arm (especially in desktop scenarios, except android) is nowhere compared to x86 world.
 
This approach doesn't benchmark the max. performance a *random SoC* is capable to deliver (and should also not be sold as such) but instead it represents the current state of what you can expect by buying random product. The majority of users don't spend as much time as some of us do to tweak settings. Such 'benchmarks' have then to be repeated over time to see if *random distribution for random board* improves or not. A board might be badly supported in the beginnings but hopefully they get it and pick up such tweaks so that it gets better over time. As a customer of a board I'm interested that the board producer makes my board better over time (e.g. as a beginner I would never buy a xunlong board, cause they're notoriously known to provide no support at all for their SBCs - the whole story differs as a more experienced guy, I can fix some flaws of a OPi as long as they're only software wise). But you target audience is more the end-user side right? So it might be interesting for them what they can expect by buying *random board* from *random boardmaker*.
 
This approach differs from @tkaiser benchmarking. He tries to benchmark the hardware and tweaks settings to ensure that the software impact is as marginal as it can be. Don't get me wrong, this is important as well, but as long as I don't have a distro which delivers those tweaks in their stock Images, I can't benefit from a powerful SoC (e.g. if thermal settings are badly on every distro for a random board I can't benefit from better settings as a end-user). Somehow the same counts for the blender benchmark:
How often did you run those tests? Roughly 25% looks indeed like a real difference but I would prefer to have at least a triplicate to get a clue how much error margin I expect for such a test. I'm quite sure you'll still see a difference but the dataset locks not complete (e.g. 'RockPro64, Ubuntu Cosmic with LXDE, 2.0/1.5GHz, CONFIG_HZ=1000: 1:01:11' is missing). So you could twice see a difference between config_hz and twice a difference between cosmic and bionic. By a triplicate with an error margin you could also show that those numbers are somehow reliable (my current work outside SBCs has error margins of ~30-100%, means I run a lot of triplicates to ensure that there's a real difference before I get excited about something).
 
This isn't grass root benchmarking, it's more a treetops benchmarking and it should also be sold as such. Means that you've to be honest to your viewers that such numbers can change if distributions tweaks their settings and you can elaborate why a board-distribution combination might perform worse compared to another combination.

I wish you and your family the best that your son recovers soon. Just ignore all wishes from other users as long as you've more important issues.

The concept of 'alternative facts' isn't it?
 
Sine I'm barely interested in benchmarks I didn't even read the whole benchmarking tests from odroid (https://www.hardkernel.com/blog-2/odroid-n2/).. But a few things which are for sure misleading.
 

a graphical trick which is quite often used by populists to make a thing bigger than it is.. There are only a very few cases where a graph shouldn't go thorough zero as a nomination.. If we do so here:

the whole story looks different.. doesn't it? (using 3d-ish plots for 2d data is also useless, but different story.)
 
Besides the benchmarking which is somehow boring for me.. I still think about use-case for this board.. Lightweight desktop replacement? TV-box on linux? Or 'cluster like' replacement? For the first I would prefer to have at least on USB on the other side, for the second I don't care cause not my field and for the third others may comment on this. Btw. the same counts for this graph:

which would better be summarized in a table not a graph..
 

Well that one went into personal insults of each other which is for sure not what both of you want... Let's try to figure out where and why this went wrong.  Starting from here:
 
Well the answer was more or less there:
 
understandable, it's frustrating. when 'your board' gets dropped.. But you must also understand that we can't support every board for years, especially if it's not sold anymore.. It's work to adjust the related patches everytime, to test it before we provide a new image and the support over forum. This thread was meant as a 'board support - general discussion / project aims' not a how to I get *random board supported*. For such a topic you should open your own thread.. E.g. here: https://forum.armbian.com/forum/25-peer-to-peer-technical-support/ (Armbian support ended or never existed - 3rd party boards and external hardware). Hint (since the SoC is still supported you basically need an ubuntu image, a device tree (or fex file in case you deal with the old kernel which I don't recommend) for your board, a defconfig for uboot, the buildscirpt and some time to build your images and see if and what's working (so you get also a clue what it means to support a board... and we support a few more than one)..
Such questions show up constantly.. This can be frustrating.. Sometimes you get then a less polite answer.. that's human.. your first post maybe wasn't a rant.. the follow up here clearly were.. From there you can answer (as @Igor did) or as I do quite often... Just ignore it.. I'm mostly not in a mood to answer to stuff which just annoys me, why should I? As others, I donate my time for free and it's not worth to deal with annoying stuff. There's enough funny stuff to do on a project like Armbian. Even helping other people to get familiar with the buildscript can be fun, but clearly not if someone drops partly into the wrong thread, complaining multiple time why his question isn't the most important one we should answer to.. and then complaining about bullying... In case you still want to bring back your board working:
 
Here's one where I implemented a whole new SoC family into armbian:
 
And in this thread I tried to basically show *my workflow* to patch a kernel and u-boot to bring in a feature into an existing board:
 
with those two, and enough time, you should be able to bring back your board into the buildscript.. And if there are still open questions, you can open a thread in P2P and maybe someone is willing to give you some guidance who knows.. I hope we can keep this thread now as for what it was for, in case not I'll either close it for a cool down phase or just delete the off-topic part, depending if I've a good day or not..

Well that one went into personal insults of each other which is for sure not what both of you want... Let's try to figure out where and why this went wrong.  Starting from here:
 
Well the answer was more or less there:
 
understandable, it's frustrating. when 'your board' gets dropped.. But you must also understand that we can't support every board for years, especially if it's not sold anymore.. It's work to adjust the related patches everytime, to test it before we provide a new image and the support over forum. This thread was meant as a 'board support - general discussion / project aims' not a how to I get *random board supported*. For such a topic you should open your own thread.. E.g. here: https://forum.armbian.com/forum/25-peer-to-peer-technical-support/ (Armbian support ended or never existed - 3rd party boards and external hardware). Hint (since the SoC is still supported you basically need an ubuntu image, a device tree (or fex file in case you deal with the old kernel which I don't recommend) for your board, a defconfig for uboot, the buildscirpt and some time to build your images and see if and what's working (so you get also a clue what it means to support a board... and we support a few more than one)..
Such questions show up constantly.. This can be frustrating.. Sometimes you get then a less polite answer.. that's human.. your first post maybe wasn't a rant.. the follow up here clearly were.. From there you can answer (as @Igor did) or as I do quite often... Just ignore it.. I'm mostly not in a mood to answer to stuff which just annoys me, why should I? As others, I donate my time for free and it's not worth to deal with annoying stuff. There's enough funny stuff to do on a project like Armbian. Even helping other people to get familiar with the buildscript can be fun, but clearly not if someone drops partly into the wrong thread, complaining multiple time why his question isn't the most important one we should answer to.. and then complaining about bullying... In case you still want to bring back your board working:
 
Here's one where I implemented a whole new SoC family into armbian:
 
And in this thread I tried to basically show *my workflow* to patch a kernel and u-boot to bring in a feature into an existing board:
 
with those two, and enough time, you should be able to bring back your board into the buildscript.. And if there are still open questions, you can open a thread in P2P and maybe someone is willing to give you some guidance who knows.. I hope we can keep this thread now as for what it was for, in case not I'll either close it for a cool down phase or just delete the off-topic part, depending if I've a good day or not..