tkaiser

And today Steven revealed existence of two more H6 boards that might look familiar
 

 
Source is linux-sunxi IRC, no more information available yet. Looks like the H6 OPi One gets a Gigabit Ethernet upgrade (if that's a GbE PHY between H6 and Ethernet Jack), looks like an USB3 upgrade on the H6 Lite and also looks like Xunlong switched from RTL8189FTV to RTL8189ETV now. On the bottom this seems to be a PMIC on both boards and LPDDR3 now.

I'll look and I'll check with the pillow ...

I have a running obsession with sensors/motors/SBCs and have been creating a collection of C libraries as I learn/conquer each new device. I recently added a few that might interest some of the forum residents here. They include a C library to talk to the RPI Sense Hat, ST Micro VL53L0X time of flight distance sensor, and CCS811 air quality sensor. You can find them all here:
 
https://github.com/bitbank2
 
If anyone has a sensor/add-on that they would like to program in C from their Orange Pi and there isn't any code available, let me know and maybe I can add it to my collection.
 
 

First part of the journey happened here: https://forum.openmediavault.org/index.php/Thread/20464-Problem-installing-Rtc-shield-Hardkernell-on-Openmediavault-Erasmus/?postID=159296#post159296
 
IMO it's just fdtput not doing what it should for reasons I haven't checked (since not using C2 anyway). To proceed it would help if @marcellom would put the result of 'dtc -I dtb -O dts -o meson64_odroidc2.dts meson64_odroidc2.dtb' to an online pasteboard service like pastebin.com. Just paste meson64_odroidc2.dts to it and post the link.

Maybe it's normal behaviour, without armbianmonitor output not easy to tell. You would need to run 'sudo armbianmonitor -m' in another terminal while running benchmarks (to see when throttling occurs) and if this does not explain the 'performance' (which is not bad, it seems this is just the device throttling down to 648MHz at the end of the sysbench run) then 'sudo armbianmonitor -u' is needed anyway.
 
Policy is to remain at 240 MHz as long as the box is idle, then clock up to the maximum until throttling jumps in. Since heat dissipation doesn't look that great judging by the pictures I would assume 'everything as expected'

Feel free to test. Assuming we don't care about breaking pre-initrd btrfs images with old boot scripts it can be switched to module everywhere.

Since almost all ARM SBC use SoCs that were made with Android or very special purposes in mind. So each SoC maker is doing his own things and we need for every chip family own software. Besides that there's optimizations needed, when you take a vendor (Android) kernel with vendor (Android) settings and combine it with a Linux userland performance will simply suck (well, today same is even true when using community's mainline stuff). That's one of the reasons Armbian exists since we did a lot of research here and ship with 'per device' optimized settings.
 
So even if some (64-bit) SBC now start to ship with an universal bootloader I doubt you get the same overall performance booting an OpenSUSE compared to an optimized Armbian build.
 
But things will improve but not with all SBC but only starting with ARMv8 and it will need a few more years until dedicated distros like ours aren't necessary any more. As a starting point: https://www.cnx-software.com/2014/01/31/arm-unveils-system-base-architecture-specification-to-standardize-arm-based-servers/

While we have time I would propose to split armbian-config from BSP to a separate package since looks like it may need a lot more frequent updates and bugfixes that 2-3 per year, and telling users to switch everything to the beta repo is not a good solution to armbian-config problems because they will install partially broken or incomplete u-boot and kernel builds.

Please test both network and storage individually (iperf3 and iozone)

Yes, I have installed the cooling system (heatsink + fan) which at maximum load when compiling to maintain the temperature above 60 Degrees.
I didn't do any special settings. Copied code into the script and ran. For reference, the system itself Armbian installed in eMMC.

P.S. my friend purchased an OPi R1 and I may help him to make it mainlined ;-)

That's important to know. In fact we try to not be any popular just to avoid dealing with people rejecting reality and showing a bizarre attitude
 
And now let's stop, you've been asked helping us diagnosing a rare issue, you refused to, now go choose another distro and be happy with whatever you will do.
 
BTW: the only reason I answered is since the threads here in this subforum can help other users stop rejecting reality and to realize that low-level hardware issues (using ultra slow SD cards -- we block booting from such crap by intention and it's not that hard to understand why) can't be solved one layer above. Life's just too short to deal with this.

Nice! Thank you for reacting so promptly on me complaining here and there  . Which eMMC modules do you now use on the Air?
 
 
BTW: this kernel is now somewhat outdated (ok, not that much as the 3.4 other H2+/H3 board makers use), please ensure that as soon as 4.14 is ready Weidong switches to this version since 4.14 will become an LTS release (long term support). IMO you should also overthink maintaining your own mainline kernel fork since it will be just PITA to merge in all upstream changes (I recommended it already to Weidong back in March: adopt Armbian's build system to your needs -- soooo easy -- and submit patches for your own devices here just like other responsible vendors do -- eg. Olimex)
 
On a related note: Weidong chose to implement DRAM configuration in an incompatible way compared to how it's done upstream. This led already to a lot of confusion since Linux and u-boot maintainers now look into your sources and overtake settings that aren't valid.
 
Please remind Weidong of the problem: https://github.com/armbian/build/commit/b57c9d767ead528a54001d8728d39470e9faf5e4#commitcomment-23045104
 
Upstream maintainers now use wrong settings (eg. just 408 MHz for NanoPi M1 Plus while choosing 672 MHz for NEO 2 and so on) and there's a lot of confusion. The best idea would be if he could simply join this thread here: https://groups.google.com/forum/#!topic/linux-sunxi/coQGctAipgI (telling he's from FriendlyELEC and explaining which DRAM clockspeeds are meant to be used for which board and maybe why you chose to go another route than the standard way defining RAM parameter definitions)
 
Thank you a lot for the heads-up. Such feedback from vendors is always welcome!

We have a search function (in the upper right of this web site, eg. enter tvheadend there if you need information about tvheadend), we have some documentation, we have device pages like this where you should click on 'hardware details' that should be able to answer all those questions.
 
If you expect Orange Pis to be 100% compatible to Raspberry Pis then better stay with what you have now. Also due to this here being a way smaller community you'll need to help yourself a bit to succeed (use the search function for example).

And for new boards in the future a better solution would be adding a eMMC connector compatible with Hardkernel and Pine boards.

Quick iozone benchmark with Hardkernel's red 16GB eMMC module on ODROID-XU4:
random random kB reclen write rewrite read reread read write 102400 4 15188 17623 20108 19593 14499 17071 102400 16 32269 34309 47927 47609 40564 33184 102400 512 41923 41838 97742 99609 96272 40443 102400 1024 41208 41125 100828 101495 100518 40068 102400 16384 38858 37916 145011 144954 144665 39192 Though my benchmark is somewhat stupid since I'm running OMV on the eMMC transferred with nand-sata-install and using btrfs as filesystem which by default uses transparent file compression (which is another way to reduce wear on the media of course and speeds up writes to disk):
/dev/mmcblk0p3 / btrfs rw,noatime,nodiratime,compress=lzo,ssd,space_cache,commit=600,subvolid=5,subvol=/ 0 0 But on the rootfs the most important performance metric is random IO with rather small blocksizes and HDDs totally suck here for obvious reasons (rotating platters, moving heads, waiting half a rotation on average for a random sector to appear below the drive's heads). This is a 2.5" HDD (7200 rpm) on my HC1 (ext4 formatted). Random IO performance with small block sizes is magnitudes lower than Hardkernel's eMMC:
random random kB reclen write rewrite read reread read write 102400 4 11623 12880 16891 17099 668 1155 102400 16 41366 44853 46099 46464 2577 4961 102400 512 89816 87068 94534 97074 39159 43801 102400 1024 87287 84807 91958 98266 56494 55865 102400 16384 73295 76457 91464 94123 91582 79349 And you should always keep in mind how HDDs work:
They're twice as fast when they're emtpy compared when they're full (detailed explanation) Especially when used for the rootfs fragmentation can become an issue after some time on a small partition and then performance further drops down

XU4 and HC1 are fully software compatible (check the readme) and heat dissipation on HC1 is WAY BETTER than with XU4. But you're limited to 2.5" disks here and should keep in mind that Hardkernel already announced a HC2 without that much details (so maybe using the same JMS561 as on Cloudshell 2 minus the interconnection problems -- better ask in their forum).
 
Wrt new boards being interesting for NAS use cases:
Pine folks want to provide something called 'Cloudmedia Transformer' (same idea as XU4 vs. HC1, the Transformer is a 100% software compatible ROCK64 + JMS578 on the PCB in an heat emitting metal enclosure that fits a 2.5" HDD, they also thought about a 3.5" variant) Similar to 'Le Potato' a so called 'Le Fly' also with RK3328 might appear (the bottom one here) A bunch of RK3399 devices will be available (all with PCIe 2.x x4 and USB3), I expect software support next year on par with RK3328 EspressoBin might have stable software support next year (you can use the native SATA port there and add mPCIe SATA cards with 2 or even 4 additional real SATA ports) Allwinner H6 boards with both PCIe (single lane, PCIe 2.x) and USB3 will appear (see here and keep in mind that Banana Pi people also have an H6 board in the works) Banana Pi R2 might be ready next year (MTK software support looks promising so maybe next year when mainline kernel support matured we'll support the board) The GnuBees are not listed by intention.
 
 

I checked today and found that @megous is currently pretty active here too (though with an A83T tablet and different camera).

I disagree with this for 2 simple reasons:
this device is listed as supported there are prebuilt images for this board Remove all prebuilt images and force users to read documentation and build images themselves and you won't get these types of messages. But instead we are adding new boards, new nightlies and new testing images that are marked as "stable".
 
This will only get worse.

To stop wasting my and other's time on this boring 'issue' here a final summary:
Close to unbelievable but after another 'evil tkaiser attacking us' event today the hardware vendor 'fixed' voltage regulation description. Just to remind you: this file has to be correct in the first place, there's no excuse for such wrong information there, it's simply the hardware vendor describing how the board works. So now that PL01 is used for voltage regulation (now in conflict with another active PL01 entry for s_rsb_sda -- good luck!) only all gmac* entries are still wrong and cooler_table not using the 912 MHz OPP is most probably a great recipe for poor performance when overheating occurs. So in case someone from SinoVoip wants to fix their pseudo Armbian build it would be wise to fix the fex first since afterwards Armbian's h3consumption tool can work without issues (today not due to still wrong fex file) On their Gitbook pages the size of M2 Zero increased by 5mm (now at least this most basic info is correct), most of the other 'information' is still sparse, wrong, missing, bogus. But fortunately the hardware is still too small on their product page and of course soon everywhere around the globe in advertisements and product listings since all resellers use the wrong dimensions they've been provided with back in July. So anyone interested in this board running with the outdated legacy kernel: chances are great that you get a working OS image over at bananapi.org (soon). As a reminder: Armbian follows the policy to not officially support Raspberry Pi boards which of course also applies to deliberately compatible looking but mostly incompatible RPi clones like this M2 Zero here (we don't want to see this forum/community dying when RPi users or fooled M2 Zero customers arrive) Armbian also tries to phase out legacy kernel support (3.4.113 which is not supported any longer since over half a year now). CSI/camera support with mainline kernel is still WiP so when switching from legacy to mainline camera functionality will also be missing. Again no reason to officially support such a device Third 'problem': dishonest advertising. Nowhere is mentioned by the vendor that M2 Zero is totally incompatible to RPi cameras (which is something average buyers expect) and RPi software (which is something clueless buyers expect from something that mimics the look of an RPi Zero and is said to run 'Raspberry Pi image'). There's really no reason for us here wasting our spare time with support efforts like this: https://forum.armbian.com/topic/5579-power-off-with-hdd-over-active-hub/?do=findComment&comment=43088  
Exactly. @Lion Wang's problem is that he wants to sell hardware and his company earned a very negative reputation over the last years (believing this would be caused only by evil people outside and not related to their internal and pretty real problems). That's something where some idiots here at Armbian could help working for him in their spare time and doing his software and support work.
 
@lvmc has the problem that he wants to use this BPi board with his own camera modules. Should work now so let's please stop babbling about community and so on.
 
We have the problem that even if we wanted to support SinoVoip products they don't allow us. They refuse to cooperate, do not provide correct hardware descriptions, do not listen to community, delete community knowledge, ignore(d) even patches they got for free just due to ignorance, ignorance, ignorance.
 
A few people here suggested to give SinoVoip a final chance. I support this. The problem is... I and others are dealing with Banana madness now in the 3rd year. We have heard that so often that it simply got too boring. So let's step back now, give them 6 months of time to show that they're willing to improve, deal with their internal ignorance/stupidity problems and then let's have a look again.
 
In the meantime it would be great if people would stop asking us for anything Banana related. Thank you.
 
 

I'm working on CSI/camera for 4.X

To stop wasting my and other's time on this boring 'issue' here a final summary:
Close to unbelievable but after another 'evil tkaiser attacking us' event today the hardware vendor 'fixed' voltage regulation description. Just to remind you: this file has to be correct in the first place, there's no excuse for such wrong information there, it's simply the hardware vendor describing how the board works. So now that PL01 is used for voltage regulation (now in conflict with another active PL01 entry for s_rsb_sda -- good luck!) only all gmac* entries are still wrong and cooler_table not using the 912 MHz OPP is most probably a great recipe for poor performance when overheating occurs. So in case someone from SinoVoip wants to fix their pseudo Armbian build it would be wise to fix the fex first since afterwards Armbian's h3consumption tool can work without issues (today not due to still wrong fex file) On their Gitbook pages the size of M2 Zero increased by 5mm (now at least this most basic info is correct), most of the other 'information' is still sparse, wrong, missing, bogus. But fortunately the hardware is still too small on their product page and of course soon everywhere around the globe in advertisements and product listings since all resellers use the wrong dimensions they've been provided with back in July. So anyone interested in this board running with the outdated legacy kernel: chances are great that you get a working OS image over at bananapi.org (soon). As a reminder: Armbian follows the policy to not officially support Raspberry Pi boards which of course also applies to deliberately compatible looking but mostly incompatible RPi clones like this M2 Zero here (we don't want to see this forum/community dying when RPi users or fooled M2 Zero customers arrive) Armbian also tries to phase out legacy kernel support (3.4.113 which is not supported any longer since over half a year now). CSI/camera support with mainline kernel is still WiP so when switching from legacy to mainline camera functionality will also be missing. Again no reason to officially support such a device Third 'problem': dishonest advertising. Nowhere is mentioned by the vendor that M2 Zero is totally incompatible to RPi cameras (which is something average buyers expect) and RPi software (which is something clueless buyers expect from something that mimics the look of an RPi Zero and is said to run 'Raspberry Pi image'). There's really no reason for us here wasting our spare time with support efforts like this: https://forum.armbian.com/topic/5579-power-off-with-hdd-over-active-hub/?do=findComment&comment=43088  
Exactly. @Lion Wang's problem is that he wants to sell hardware and his company earned a very negative reputation over the last years (believing this would be caused only by evil people outside and not related to their internal and pretty real problems). That's something where some idiots here at Armbian could help working for him in their spare time and doing his software and support work.
 
@lvmc has the problem that he wants to use this BPi board with his own camera modules. Should work now so let's please stop babbling about community and so on.
 
We have the problem that even if we wanted to support SinoVoip products they don't allow us. They refuse to cooperate, do not provide correct hardware descriptions, do not listen to community, delete community knowledge, ignore(d) even patches they got for free just due to ignorance, ignorance, ignorance.
 
A few people here suggested to give SinoVoip a final chance. I support this. The problem is... I and others are dealing with Banana madness now in the 3rd year. We have heard that so often that it simply got too boring. So let's step back now, give them 6 months of time to show that they're willing to improve, deal with their internal ignorance/stupidity problems and then let's have a look again.
 
In the meantime it would be great if people would stop asking us for anything Banana related. Thank you.
 
 

To stop wasting my and other's time on this boring 'issue' here a final summary:
Close to unbelievable but after another 'evil tkaiser attacking us' event today the hardware vendor 'fixed' voltage regulation description. Just to remind you: this file has to be correct in the first place, there's no excuse for such wrong information there, it's simply the hardware vendor describing how the board works. So now that PL01 is used for voltage regulation (now in conflict with another active PL01 entry for s_rsb_sda -- good luck!) only all gmac* entries are still wrong and cooler_table not using the 912 MHz OPP is most probably a great recipe for poor performance when overheating occurs. So in case someone from SinoVoip wants to fix their pseudo Armbian build it would be wise to fix the fex first since afterwards Armbian's h3consumption tool can work without issues (today not due to still wrong fex file) On their Gitbook pages the size of M2 Zero increased by 5mm (now at least this most basic info is correct), most of the other 'information' is still sparse, wrong, missing, bogus. But fortunately the hardware is still too small on their product page and of course soon everywhere around the globe in advertisements and product listings since all resellers use the wrong dimensions they've been provided with back in July. So anyone interested in this board running with the outdated legacy kernel: chances are great that you get a working OS image over at bananapi.org (soon). As a reminder: Armbian follows the policy to not officially support Raspberry Pi boards which of course also applies to deliberately compatible looking but mostly incompatible RPi clones like this M2 Zero here (we don't want to see this forum/community dying when RPi users or fooled M2 Zero customers arrive) Armbian also tries to phase out legacy kernel support (3.4.113 which is not supported any longer since over half a year now). CSI/camera support with mainline kernel is still WiP so when switching from legacy to mainline camera functionality will also be missing. Again no reason to officially support such a device Third 'problem': dishonest advertising. Nowhere is mentioned by the vendor that M2 Zero is totally incompatible to RPi cameras (which is something average buyers expect) and RPi software (which is something clueless buyers expect from something that mimics the look of an RPi Zero and is said to run 'Raspberry Pi image'). There's really no reason for us here wasting our spare time with support efforts like this: https://forum.armbian.com/topic/5579-power-off-with-hdd-over-active-hub/?do=findComment&comment=43088  
Exactly. @Lion Wang's problem is that he wants to sell hardware and his company earned a very negative reputation over the last years (believing this would be caused only by evil people outside and not related to their internal and pretty real problems). That's something where some idiots here at Armbian could help working for him in their spare time and doing his software and support work.
 
@lvmc has the problem that he wants to use this BPi board with his own camera modules. Should work now so let's please stop babbling about community and so on.
 
We have the problem that even if we wanted to support SinoVoip products they don't allow us. They refuse to cooperate, do not provide correct hardware descriptions, do not listen to community, delete community knowledge, ignore(d) even patches they got for free just due to ignorance, ignorance, ignorance.
 
A few people here suggested to give SinoVoip a final chance. I support this. The problem is... I and others are dealing with Banana madness now in the 3rd year. We have heard that so often that it simply got too boring. So let's step back now, give them 6 months of time to show that they're willing to improve, deal with their internal ignorance/stupidity problems and then let's have a look again.
 
In the meantime it would be great if people would stop asking us for anything Banana related. Thank you.
 
 

To stop wasting my and other's time on this boring 'issue' here a final summary:
Close to unbelievable but after another 'evil tkaiser attacking us' event today the hardware vendor 'fixed' voltage regulation description. Just to remind you: this file has to be correct in the first place, there's no excuse for such wrong information there, it's simply the hardware vendor describing how the board works. So now that PL01 is used for voltage regulation (now in conflict with another active PL01 entry for s_rsb_sda -- good luck!) only all gmac* entries are still wrong and cooler_table not using the 912 MHz OPP is most probably a great recipe for poor performance when overheating occurs. So in case someone from SinoVoip wants to fix their pseudo Armbian build it would be wise to fix the fex first since afterwards Armbian's h3consumption tool can work without issues (today not due to still wrong fex file) On their Gitbook pages the size of M2 Zero increased by 5mm (now at least this most basic info is correct), most of the other 'information' is still sparse, wrong, missing, bogus. But fortunately the hardware is still too small on their product page and of course soon everywhere around the globe in advertisements and product listings since all resellers use the wrong dimensions they've been provided with back in July. So anyone interested in this board running with the outdated legacy kernel: chances are great that you get a working OS image over at bananapi.org (soon). As a reminder: Armbian follows the policy to not officially support Raspberry Pi boards which of course also applies to deliberately compatible looking but mostly incompatible RPi clones like this M2 Zero here (we don't want to see this forum/community dying when RPi users or fooled M2 Zero customers arrive) Armbian also tries to phase out legacy kernel support (3.4.113 which is not supported any longer since over half a year now). CSI/camera support with mainline kernel is still WiP so when switching from legacy to mainline camera functionality will also be missing. Again no reason to officially support such a device Third 'problem': dishonest advertising. Nowhere is mentioned by the vendor that M2 Zero is totally incompatible to RPi cameras (which is something average buyers expect) and RPi software (which is something clueless buyers expect from something that mimics the look of an RPi Zero and is said to run 'Raspberry Pi image'). There's really no reason for us here wasting our spare time with support efforts like this: https://forum.armbian.com/topic/5579-power-off-with-hdd-over-active-hub/?do=findComment&comment=43088  
Exactly. @Lion Wang's problem is that he wants to sell hardware and his company earned a very negative reputation over the last years (believing this would be caused only by evil people outside and not related to their internal and pretty real problems). That's something where some idiots here at Armbian could help working for him in their spare time and doing his software and support work.
 
@lvmc has the problem that he wants to use this BPi board with his own camera modules. Should work now so let's please stop babbling about community and so on.
 
We have the problem that even if we wanted to support SinoVoip products they don't allow us. They refuse to cooperate, do not provide correct hardware descriptions, do not listen to community, delete community knowledge, ignore(d) even patches they got for free just due to ignorance, ignorance, ignorance.
 
A few people here suggested to give SinoVoip a final chance. I support this. The problem is... I and others are dealing with Banana madness now in the 3rd year. We have heard that so often that it simply got too boring. So let's step back now, give them 6 months of time to show that they're willing to improve, deal with their internal ignorance/stupidity problems and then let's have a look again.
 
In the meantime it would be great if people would stop asking us for anything Banana related. Thank you.
 
 

OK, I started the Sunxi wiki page ... http://linux-sunxi.org/Sunvell_R69
Is a pice of crap, yes I know.
Hi @guidol may I use your board images in the wiki?
Anyone interested in sent me info to fill the info.
Thanks!!