NicoD

I have one in the mail, was told the Armbian H64 image works except for Ethernet, I'm guessing there's a small hardware difference that needs reflected in DTS.  Or I'm completely wrong, until I can see, I cannot know.

i think the problerm is in this files these are coiming wiht the overlay, cbecuase forme the schematic its not PA oit is PD6 for the gmac
 
since you say v0.06 was working i changed back the usb settings i will upload a ne image
 
&usb2phy {
usb0_vbus-supply = <&reg_usb_vbus>;
+ usb1_vbus-supply = <&reg_usb_vbus>;
- usb3_vbus-supply = <&reg_usb_vbus>;
status = "okay";
};
 
sun50i-h6-spi-add-cs1.dts
and
 
sun50i-a64-spi-add-cs1.dts
 
 
v0.11 released and available for download

MrFixit made his Kernel available, im guessing it should help, kernell does 3d, 2d, nvme, wifi, bt etc...
 
link here

If you would read this thread you'd know that these people are working on getting a good OS working for it.
So no, there is no useable and stable os for it, no you can't use PCIe on it. This will take time.
There are other sbc's that can do what you want. I'd go for the NanoPi M4. It now has got a hat with 4xSATA.
https://www.friendlyarm.com/index.php?route=product/product&amp;product_id=254
 
A lot more work has been done for the RK3399's. It's also still a work in progress. But for what you want it's more than ready.

I wish everybody working on it good luck, I'm following this thread for a while, and have been testing a lot of @krachlatte images. I hope you're going to find the problem and may receive your unit quickly. I also had to wait a very long time for it(+1 month).
I can say that Orange Pi uses different images for the eMMC version vs without eMMC. I've tried a non-eMMC image and this didn't work on my eMMC version. So this could also be a factor to keep in mind.
Cheers.

@martinayotte sun50i-h6-emac is already gone dropped in the newest driver, and upstream DT now uses
```
            compatible = "allwinner,sun50i-h6-emac",
                     "allwinner,sun50i-a64-emac";
```
 
If someone needs me to do hack on OPi3, I can consider to purchase one. Shipment from Shenzhen to Guangzhou (where I live) usually cost <24h.

@Igor can probably arrange things so that Steven from Xunlung can ship you one for free ...

Please note, my build farm is used for cross-compiling only. I used to do native builds 20 years ago, and after having been hit several times by accidental dependencies on the build host, I stopped and am always cross-compiling nowadays, even when doing x86 on x86. That's why I can use whatever host is available for the build farm. My build farm at home is heterogeneous, it's made of the armv8 boards above, one armv7 board (odroid xu4) and sometimes some x86 hosts when the devices are up. So yes, I'm a huge proponent of cross-compiling.

Yes, and believe me, total time difference is not that big compared to a core i7 cross-compiling on a VM (we're talking about the high-end ARM SoC's, the ones with A15's, A17's and A72's). Plus, it saves you the time and boredom of setting a cross-compiling environment. And it's funny to do anything on a small $50 device made with random TV box pieces soldered to a cramped PCB

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..

Thanks for sharing, dude. That is super cool!

Sent from my SM-G950U using Tapatalk

Hi @lanefu.
I took some pictures of all my tech gear I take with me on trips.

The most important thing is my solar panels(I've got 2). It's a RavPower 24W 5V solar panel with 3 usb ports. Each USB can load up to 2.4A, and a total of 4.8A over all 3 the ports. In a nice sunny day it's quickly at it's maximum power.
Then the RavPower power banks(also 2). These are beasts of 26 800 mAh. With this I can work for 15 hours with my Odroid C2 + 7" display. It does take a bit more than a day to fully charge it with my solar panels. I always use one, while charging the other.

For video editing and rendering I used the Odroid C2(on the right) with a 7" display. This because it's the only one that's fast, and doesn't need active cooling. When it's cold and wet you don't want to sit in a tent with a fan blowing.
The Odroid also has it's own 3.5" HDMI display to watch video that I've filmed on it. So it's also a handheld. The C2 I'll replace with a RK3399 board. I still need to make a new metal case for everything. I also got a 13.3" 1080p display with speakers for the new "laptop"
The one on the left is my Raspberry Pi 2B with a 3.5" gpio display. This has a usb audio adapter, and a Sony lavalier microphone. This uses only 0.25A idle with the display included. So I can leave that on the whole day. It's totally protected with rubber on the sides, and a plexi glas in front of the display. So I can throw it arround and nothing happens. The same for my 7" display. Plexiglass, and then a rubber layer between the glas and the display.
 

For entertainment I've got the Raspberry Pi 3B+ also with a 3.5" hdmi display, and a PS3 controller. That fills up the rainy days when I ain't got anything better to do. Or when my Odroid C2 is bussy rendering new videos.

I often travel with my bycicle, and go wild camping everywhere in Europe. With this I film everything, I edit it in the evening. And when I go to a camping I upload everything to Youtube. 
Many people would not want to travel like this. But for me it's my heaven.

I couldn't do all that with my laptop. The thing is heavyer, a lot more power consumption, battery only lasts about 1,5hours, ... So SBC's are the greatest pieces of tech ever for me.
I used to carry around a lot of thick books while traveling. I'm happier with all this.
I love to watch a movie with a beer while the sun goes down on a beautiful spot. I can't wait to leave again.

In daily life I also use them, I don't have a smart phone. So these replace that.

I made a quick video on my last trip about it all. Also about my new 13.3" display.
But I didn't do any video editing on that trip since it was not a long trip(less than 2 weeks)

I hope that fulfills your curiosity.
I use my SBC's for a lot more than that alone. But it's because of this I fell in love with sbc's.
I was a giant tech nerd when I was young. I started working as a programmer when I turned just 15, but lost my job at 19(bankruptcy of the company I worked for) and didn't have a school degree. So I then lost all interest in computers for almost 15 years. SBC's have brought me back that joy of the early days. I just love them....
Greetings.

 

@nicod I saw it on the other thread. It’s worthy of its own post. That rig captures the essence of what makes hacking on SBCs so great.
 
Lane
 
 
Sent from my iPad using Tapatalk

I've got a very special use case that I don't think anybody else uses it for. I use them (among many other things) to edit and render videos on location(while traveling, while visiting interesting stuff...)
I must do this with power banks charged with solar panels. So for that reason ARM is the best choice(power efficient). I've got my "render bread box" for a long time with the C2(fastest while best passive cooled) for editing and rendering. The RPi2B with small display to record sound(because it's most power efficient). And I also just love sbc's...

I'm now putting together something better with a 13" 5V display and probably with the RockPi4B for this summer. The case will need to be the cooling for it. I've got more solar panels, so I can power more.
And I hope in the future to be able to make a new more powerful handheld sbc with the Pine H64.(if it's ever released, I've seen TL Lim on FOSDEM and he said it would be out first half of Februari) Video Pine64@FOSDEM

Since I couldn't get the right info for my use case(because nobody else uses it like this) I filmed some tests when I bought the Tinker Board and put it on Youtube. That video got a few thousand views. So I just kept making videos about new boards.
I try to do this a good as I can. That's why I love it when somebody comes with information I didn't know about what you often do.

Many people get their info on Youtube, it is mostly another public then we meet here in the Armbian forum, that uses SBC's for other tasks(gaming, desktop use). So that's what I show.
 
I'll follow it. Thanks for the info.
 
But that's what people want. They want to see them lined up in an order. So it's the reviewer his choice what order he shows to the viewers/readers. That's why I try to find the better tools for the job, but none of those I've used are even near to perfect.(as I've shown in my videos) So I try to minimise the variables as much as possible by using the same distro, no throttlin, the same software version, the same settings, only ARMV7->V7 - V8->V8 ... But it's never possible to do this well. Most Youtubers don't even care about that, and show very weird results of sysbench or so.
I'll keep using 7zip, CPUMiner and blender for now because even with their faults. They still manage to make the most sensible line up. And I'll keep saying it only shows how well it does that task only. And there's a lot more to SBC's than how powerful the CPU is.
Well the last 2 days we've managed to keep you bussy here. And I enjoyed it, and I bet many readers will have too. So it's only a tiny step to stay and end the self-censorship.
Have a great day. Read you soon.

I can't help but think this will be a cyclical issue for that community then, he is far too sentimental (tunnel vision perhaps), and the platform is far too closed hardware wise.  Typical market forces will render them noncompetitive over and over as they cling to the familiar.
 
As always, the "open source platform" would be on a non-distributor SoC with a most likely closed source VC5, with all the typical paywalls up to be "permitted" to use the HEVC/etc.  Since Eben was willing to hide his camera tuning behind DRM on the VC4 devices, I can only imagine the uses for the improved security core... 
 
Again, not a problem, except they sit their in their tiny little hardware sandcastle with the tide coming in and claim to build unquestionably superior supercomputers.
 
 
I was a lot less sarcastic on this topic before I started reading their forums and seeing the excuses they give for basic lacking functionality, the technical 1/4 truths, some outright deception, hiding behind "millions sold" numbers instead of engaging technical questions...  The GbE one was too much, their assertion was that achieving 30% Gb throughput was irrelevant since it was attached to the network at GbE bit rates.  That's like me putting 300 kph rated tires on a Lada Riva and claiming to compete with Ferrari because the physical contact between the car and the street was capable of high speed operation...  (to be fair, the Lada may be more reliable than a Ferrari...  )

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 have the means to see power usage, as time and situation permits I will test this as well.
 
Thanks for the kind words.

You, @chwe the people
I do watch a lot of benchmarking on Youtube pure out of entertainment. I love Gamers Nexus on Youtube. I don't care a bit about x86 hardware. I'm not planning to buy anything new. But it seems to have an entertainment value that I like.
 
Indeed, a lot of people who are new to SBC's. So I try to keep it as simple as possible, and show how to set up everything for a new user, and what's the best OS available, gaming, video playback, energy consumption, ease of use, ... My viewers seem happy, I almost never get bad comments. I many times get the comment that I've saved them days of searching. So that's what I keep doing.
I try to test as much as possible, and only when I don't know anymore what more to test I make my videos.
Most other sbc reviewers on Youtube make their video after only a few hours of working with them. That's where I try to be different. That also means my videos are later than the more popular Youtubers.(ETAPrime can't even install a simple Linux distro on an sbc, and he's got +200 000 subscribers)
I now get boards for free, and I share my findings with the board makers. FriendlyElec and Radxa have done a lot with my data for the M4 and RockPi4B. I'm happy with that. Other makers don't seem to care as much.
I also don't make a video as long as a novice user can't use a board easily and well.
 
 
I've done a lot more of them with the RK3399. When settings haven't changed Blender has very little changes when done multiple times. (I'll do 3 now with the M4)
Ignore gimp, gtkperf and sysbench. That was just to show you're nothing with that.
I don't think the Rock Pi 4B had CONFIG_HZ=250 but HZ=1000. The NanoPi M4 now did 5minutes better than the RPi4B with HZ=250 at the same clockspeed. So my assumption that the RockPi4B was faster because of faster ram is untrue.  Still need to do more with the RockPi4B. I'm waiting for the Armbian images to mature.
Rock Pi 4B |SBC bench result |CPU Miner |7-zip s/c |7-zip b/c |7-zip multi avg. of 3 |Blender |GIMP |GTKPerf |Sysbench Ubuntu http://ix.io/1uVr 9.50kH/s 1242 1818 7802 1h17m22s NanoPi M4 |SBC bench result |CPU Miner |7-zip s/c |7-zip b/c |7-zip multi avg. of 3 |Blender |GIMP |GTKPerf |Sysbench Armbian bionic hz1000 http://ix.io/1nLh 10.23kH/s 1335 2005 8352 1h13m50s 0m29s5 5.06s 26763 CONFIG_HZ=250 http://ix.io/1BLW 10.45kH/s 1335 2007 8320 1h08m28s Armbionic@1.4/1.8 hz250 1253 1828 7821 1h12m52s Armbian bionic nightly http://ix.io/1pDo 10.24kH/s 1329 1990 8292 1h13m28s 0m29s 5.12s 26733 Armbian stretch desktop http://ix.io/1odF 8.66kH/s 1350 1977 8400 1h14m12s 0m31s 5.24s 3.1s Armbian stretch dsk nightly //ix.io/1pM0 8.80kH/s 1359 1993 8500 1h15m04s 0m31s 5.32s 3.3s Armbian stretch core no fan //ix.io/1pKU 8.80-8.65kH/s 1353 1989 8461 Armbian stretch core //ix.io/1pL9 8.76kH/s 1354 1988 8456 Armbian stretch core nightly //ix.io/1pLf 8.82kH/s 1357 1994 8494 Lubuntu Bionic arm64 http://ix.io/1oGJ 9.24kH/s CPU Miner 1056 1551 6943 1h28m13s Lubuntu Bionic armhf http://ix.io/1pJ1 1111 1769 7705 2h02m54s 0m57s 6.97s 1666 32-bit Lubuntu Xenial armhf http://ix.io/1oCb 989 1507 6339 2h20m51s 0m59s 49.77s 49.7s 32-bit  
 
Of course @tkaiser has a lot more knowledge than me, and I'd rather see someone like him making good videos to well inform people. As long as that doesn't happen, there's still a place for me on Youtube (TKaiser, the Derbauer of SBC's??)
I don't think he'll ever aprove using Blender, but I also use SBC-Bench. I don't think there's much to say against that. 
Blender does have a few advantages for me. It shows if a system is stable(crashed if not), it takes a long time so I can see the heat characteristics, it uses close to 100% of all cores(7zip doesn't, and this differs a lot from board to board, distro to distro). But small changes can effect the performance a lot.

@rooted I'm also interested in seeing how the H2 does against the N2. Also power consumption while maxed out interests me in both. Until now the NanoPC T3+ has the lead in horsepower per watt for me(I need to retest that with HZ=250 too). I think the N2 can beat it.
But time enough for that. Take good care of each other. May everything be well and safe for your son.
 
That's a nice filosofy to live by, but we don't have faith in our own hands. Health is something we can only be thankful for having it.


 

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.

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..
 

Take good care of him. More important than an sbc. Greetings.

Take good care of him. More important than an sbc. Greetings.

There's a lot more. I just updated my post above with GCC 8.2 results. When Blender is built with a more recent compiler rendering gets faster (this is one of the many reasons why this Phoronix stuff is so bad -- Michael Larabel doesn't educate his users about such basics but throws a bunch of meaningless numbers and graphs at them to create the impression benchmarking would be something magic).
 
And if you build Blender from source with appropriate compiler flags (not those ultra conservative distro defaults, especially not with 'stable' distros like Debian and Ubuntu) then it will be even faster.
 
 
Very unlikely. And performance is already known, check sbc-results for PineH64 (board vendors don't matter, it's only about the SoC in question). And of course settings matter. If you use one of those crappy Xunlong images there's no need to test further since they're known for using crappy Allwinner defaults that suck.

'Around for a long time'? The point is not since when settings exist but what the defaults are and why people interested in maximum performance should care about such settings. This was the context:
 
 
And by looking at both tinymembench and Blender scores it should be pretty obvious that this makes a difference for workloads that utilize CPU cores fully... just to explain why comparing RK3399 and S922X benchmark scores doesn't make that much sense as long as such essential stuff is not also considered.
 
@NicoD: I explained in my former post how to check for such settings, simply check the spoiler.

Blender test. Checking the relevance of SETTINGS instead of focusing on irrelevant hardware details like DDR3 vs. DDR4:
RockPro64, Ubuntu Bionic with LXDE, 2.0/1.5GHz, CONFIG_HZ=1000: 1:15:31 RockPro64, Ubuntu Bionic with LXDE, 2.0/1.5GHz, CONFIG_HZ=250: 1:06:59 RockPro64, Ubuntu Cosmic with LXDE, 2.0/1.5GHz, CONFIG_HZ=250: 1:01:11  
That's 8:30 minutes difference due to switching from CONFIG_HZ=1000 to CONFIG_HZ=250. Check %sys vs. %user below (iostat 60 output). And why is Cosmic faster than Bionic if it's exactly same Blender version? Since Cosmic (18.10) uses GCC 8.2 while Bionic (18.04) uses GCC 7.3 to build the packages. So by switching from default SoC vendor kernel settings to something better and by letting modern compilers do their job we get almost 25% performance 'for free'.
 

Same with S922X, simply check @rooted's sbc-bench results (where even the cpufreq OPP are checked and confirmed). The problem is not thermal but reliability/undervoltage due to the firmware running on the Cortex-M3 controlling DVFS which can be clearly seen by running the most heavy load called cpuminer. 
 
Quoting myself: ''Overclocked' executions with both CPU clusters set to 2.0 GHz showed reliability issues most probably due to DVFS undervoltage (cpuminer quit almost immediately here while it ran only 50 seconds there -- this tool since being a load generator checking for data corruption can also be used for reliability testing but I would prefer our StabilityTester instead)'
 
I already suggested to Justin and Dongjin to take our StabilityTester approach to provide N2 users with an easy way to check for undervoltage/instabilities since a lot of those users will activate the 'overclocking' settings (most probably these are undervolting settings at the same time based on results) and then end up with silent data corruption and/or crashes (all the great results of trying to get laughable 7%-8% performance gain almost nobody is able to notice).
 
 
Simply do a web search for CONFIG_HZ