TonyMac32

Just pushed re-organized thermals to repo, cpu_thermal is zone0, gpu_thermal is zone1.  This is for dev, next, and default.  All I did was move the "reserve_thermal" entry to the end of the list of three.
@tkaiser

You can actually squeeze a NanoPi Duo, RJ45 MagJack (LED,GND pins off), a USB port, and tiny buck converter on a half-size breadboard.


 
Seems to be working fine with a user built stretch image for the Orange Pi Zero target, at least initially.
Max current @12vDC I saw was under 400mA with sysbench and WiFi running but more tests are needed.

Images at download section are updated with 4.13.3 and 4.4.88

Just pushed re-organized thermals to repo, cpu_thermal is zone0, gpu_thermal is zone1.  This is for dev, next, and default.  All I did was move the "reserve_thermal" entry to the end of the list of three.
@tkaiser

I bought one a couple weeks ago, it cleared customs yesterday so I hope to have it in a few days.  I saw the price of extra memory and the shield separately and got the kit.
 
https://www.sparkfun.com/products/13021
 
One like that with the built-in transformer should do it.  Anyone knowing better correct me, it's just been my go-to and has worked out so far. (not tried with this particular SoC/board)

I can boot a 4.12 momentarily, I was debugging 4.13.  I found what *I think* is the culprit, the gpu node was changed and somehow omitted the cooling-cells property.
 
 
[edit]  zone1 is cpu_thermal, zone2 is gpu_thermal 
 
The device tree has the tsadc channel 0 as a "reserve_thermal", with 1 and 2 cpu and gpu. 
 

You're absolutely right. The few hundred people a day downloading these broken and totally untested images (check statistics yourself: https://dl.armbian.com/_download-stats/) are all fooled since these images can't work (broken, untested, 'armbian style'). And only you are brave enough to publicly inform those lazy Armbians about this severe problem. Last image has been released back in June so those lazy Armbians already fooled thousands of poor users with providing broken and untested images. It's almost a miracle that you're the first to tell the truth! Keep on rocking!

http://www.zdnet.com/article/linux-gets-blasted-by-blueborne-too/
 
Not sure if we'd seen this/had exposure.

The current nightly Dev image will be the release 4.13
 
[edit]  This image does not have Bluetooth support

No, I mean the stock Armbian OS of course! Armbian for the win!

I wished to have the AP6212 WiFi working on my NanoPi-K2 !
BTW, it is a AP6212 Non-A ...
So, at first it didn't work. After investigation and few tries, I figured out that a another firmware was needed :
 
as discuss by Hans back in June https://patchwork.kernel.org/patch/9791523/
 
http://jwrdegoede.danny.cz/brcm-firmware/brcmfmac43430a0-sdio.bin.7.10.1.244.ucode940.1020
 to be rename as brcmfmac43430a0-sdio.bin
http://jwrdegoede.danny.cz/brcm-firmware/brcmfmac43430a0-sdio.txt.jumper-ezpad-mini3
 to be rename as brcmfmac43430a0-sdio.txt
 
Hans patch is already merged in 4.13...
 

For the M.2-2242 SSD socket, It will be NanoPi NEO Core.

Since I'm playing around with a M.2/2242 SSD currently (overheating badly when operating at 'native speeds' connected to a SATA or USB3 port) I just checked in Photoshop whether another 'Mini Shield' could provide the ability to use M.2 instead of mSATA:

2242 seems to fit, with 2230 it shouldn't be a problem at all. I added also a little DS1307 based RTC module on the pin header.  

Kernel 4.4 does support bluetooth.  If you look at the original post you'll see a status for the different kernels, a link, and a command that must be run at boot.  A program "rtk_hciattach" is necessary to make the bluetooth stack talk to the bluetooth hardware.
 

Bad news for z28 pro owners.
There is no possible way to boot from micro sd card, because internal rockchip loader can only boot from SD card port 0 btw on z28 pro sd card module soldered out on port 1...
The only way to get working linux on z28 pro is flash it directry to eMMC from android, i will write step-by-step manual in few days.
 
 
 

So the issue is now resolved in linux-next, which is one of the official git repository that pull the changes that will happen in the next version following the current Release or Release Candidate.
 
I imported the patch and here it is :
https://github.com/Miouyouyou/RockMyy/blob/master/patches/kernel/v4.13/0012-net-phy-Deal-with-unbound-phy-driver-in-phy_attached.patch
 
The official patch being :
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=fcd03e362b1cd17de487953aac34f2d4574895cf

update schematic : 2017-08-24
https://drive.google.com/file/d/0B4PAo2nW2KfnbzQ5MTB5eXNEN1U/view?usp=sharing

The more ignorant of those internals you are, the happier your life will be.  I wrote some simple drivers in assembly language for USB 2, and being totally honest, I kind of wish that standard would have sunk to the bottom of the ocean in the late 90's before it hit revision 2.0.
 
USB has some special bus modes to handle mass data traffic (UAS), all data on USB is of a "type", it doesn't easily have a type-agnostic transfer like PCI(e).  If it were exposed as a SATA device, this would be a software layer translating to do so, and would most likely be less efficient.  Now, the experts will know more and (most probably) make me look foolish, but it's part of the job. 

Thanks, @balbes150 !
I so used to play with Mainline, that I feel like a newbie and playing with Legacy ...
The "modprobe dhd" worked.

Some consumption numbers. My measurements are done at mains with a powermeter (Brennenstuhl Primera Line PM 231E bought after german c't magazine reviewed it as one of the more precise powermeters available). Hardkernel's official 5V/4A PSU is also included in the numbers so this is neither comparable with my other consumption measurements over here or what Hardkernel provides there (since measuring between PSU and device, please also keep in mind that Hardkernel's Ubuntu uses AFAIK performance cpufreq governor keeping all CPU cores always at upper clockspeeds). Based on the efficiency of the PSU numbers might vary a lot (eg. using an usual 400W ATX PSU to provide 5V and you can add 10W easily measured on mains) but on the other hand this is a more realistic scenario given that these HC1 units need a PSU anyway to be usable (and my recommendation is to choose Hardkernel's own offers here!)
 
First a brief look at idle consumption (to get an idea how to define cpufreq settings) and with some light to medium load (sysbench --test=cpu --cpu-max-prime=2000000000 run --num-threads=`grep -c '^processor' /proc/cpuinfo`) when walking through a few different cpufreq/dvfs operation points:
little/big idle sysbench 200/200 3.7W 4.1W 600/600 3.75W 5.1W 800/800 3.8W 5.7W 1000/1000 3.85W 6.5W 1200/1200 3.95W 7.4W 1400/1400 4.0W 8.6W 1400/1500 4.05W 9.2W 1400/1600 4.1W 10.1W 1400/1700 4.2W 11.0W 1400/1800 4.2W 12.0W 1400/1900 4.3W 13.5W 1400/2000 4.5W 13.6W As we can see there's not that much difference in idle consumption numbers below 1000 MHz so it doesn't really matter how low we define minimum cpufreq (Armbian chose 600 MHz here since some cpufreq governors really behave strange when you allow them to clock really low: taking ages until cpufreq gets increased even with heavy loads so overall performance sucks a lot). It's also quite obvious that the higher dvfs (dynamic voltage frequency scaling) OPP require much more energy due to increased core voltage to let CPU cores still run reliably.
 
The numbers above were made with a disk connected but sent to sleep/standby (hdparm -y /dev/sda). As soon as a connected disk is awake numbers differ:
with most SSDs it's a short peak consumption and then it might be 0.1W more as long as the SSD is idle. Most if not all SSD only need more juice when really accessing/transferring data with HDDs things are different. Peak consumption when platters start to spin up can be really high (up to 1.2A@5V --> 6W with 2.5" HDD). Then we have some controller logic inside the HDD needing juice when data is transferred, one motor that lets the spindles rotate (while they rotate all the time consumption can vary based on HDD firmware --  a nice buzzword to search for is 'IntelliPower' for example) and then there's another stepper motor(s) to position the drive heads. Consumption increase by the latter highly depends on workloads. Sequential stuff eg. streaming a movie from a HDD that is not (much) fragmented results in nearly zero head movements while a highly random IO pattern causes the heads to be repositioned always and so consumption will increase. With NAS use cases we also have to keep in mind that Ethernet needs some energy. Most Gigabit Ethernet capable SBC use an internal GbE MAC combined with an external GbE PHY (usually an RTL8211). When using such an external PHY we see a nice consumption decrease when we force the PHY to Fast Ethernet only. On most boards this results in 350mW less consumption compared to negotiating a Gigabit Ethernet connection. The only exceptions are funnily all ODROIDs: With C1+ there is no difference in consumption, C2shows only 230mW consumption difference (maybe since using a RTL8211F PHY instead of RTL8211E as used almost everywhere else) and with XU4/HC1 it's again no consumption difference (here Ethernet is done via an USB3 implementation: RTL8153).
 
How does Ethernet utilization changes consumption? I tested with 600, 1400 and 2000 MHz one time with Fast Ethernet ('performance' always the same since saturating a 100 Mbits/sec connection is easy and results in ~94 Mbits/sec on the TCP/IP layer without problems). And then after switching back to Gigabit Ethernet:
600 MHz Fast ENet / GbE TX +300mW +1000mW (580 Mbits/s) RX +500mW +1300mW (790 Mbits/s) 1400 MHz Fast ENet / GbE TX +350mW +1900mW (940 Mbits/s) RX +800mW +2300mW (940 Mbits/s) 2000 MHz Fast ENet / GbE TX +550mW +1900mW (940 Mbits/s) RX +1300mW +2800mW (940 MBits/s) All consumption numbers are relative (!) since compared to the idle numbers above. As can be seen we have no performance difference between 1.4 and 2.0 GHz but consumption varies a lot (TX numbers remain the same which is an indication that here only little cores were involed). RX consumption (receiving data from the outside) is always higher since here IRQ processing is involved and with USB Ethernet as on XU4/HC1 this is a bit more 'costly' compared to other boards that rely on RGMII here to connect an external GbE PHY with an internal MAC.
 
So from a NAS point of view limiting the big cores to eg. 1.4 GHz seems to be sufficient since we have no performance drop but some energy savings. But doing this only based by looking at iperf3 results might not be sufficient.
 
New tests with LanTest keeping both Ethernet and storage busy at the same time: First test again with the Samsung EVO840 SSD, second test with an older 2.5" Hitachi 7.2k HDD (SMART output here):
EVO840 SSD RX TX 600 MHz: 46MB/s 6.7W 48MB/s 6.4W 1400 MHz: 80MB/s 8.0W 87MB/s 7.8W 2000 MHz: 90MB/s 10.8W 98MB/s 10.0W Hitachi HDD RX TX 600 MHz: 42MB/s 7.3W 46MB/s 7.2W 1400 MHz: 66MB/s 8.8W 81MB/s 8.8W 2000 MHz: 78MB/s 11.5W 88MB/s 11.2W (all detailed LanTest screenshots available here. I tested only one run since running with userspace governor so no surprises wrt dynamic clockspeed adjustments) 
 
Why testing with 600, 1400 and 2000 MHz? 600 MHz seems like a reasonable minimum cpufreq (given that lower frequencies do not provide sufficient idle consumption savings and that most cpufreq scaling governors behave better when minimum cpufreq isn't too low). The 2000 MHz are just the upper level that's possible. And 1400 MHz seem to be a nice compromise in between wrt consumption savings under load while not that much of a performance drop happens.
 
With those 3 different clockspeeds we see consumption differences in synthetical benchmarks. But if we also have the use case in mind in many situations these theoretical differences defining upper limits do not matter at all any more. 
 
If we use HC1 with a 2.5" HDD as backup target for example and let the necessary encryption on the clients happen (running macOS backing up with TimeMachine to our HC1 running OMV): While almost all Macs that can use TimeMachine (encryption) can also make use of AES-NI since Apple already started in 2010 using solely Intel CPUs with this feature most probably backup 'performance' is still that low that it really doesn't matter whether we let HC1 clock at 600 MHz or 2000 MHz. With such a scenario most probably switching the cpufreq governor from ondemand (constantly jumping between min and max cpufreq) to conservative we get some nice energy savings at same backup performance (which I consider more or less irrelevant anyway as long as incremental backups DO happen regularly)
 
With such a TimeMachine scenario HC1 NAS performance is only really needed when it's time for huge restores or desaster recovery (your MacBook got stolen, you buy a new one, start it, choose 'restore from backup', click on the HC1 and are two hours later up and running again). So most probably with this use case switching from ondemand to conservative governor saves 1-2W per when backing up (since keeping CPU cores at low clockspeeds most of the time) while providing same speed/consumption with large restores.
 
With different approaches (eg. letting encryption happen on HC1) this might differ a lot and to really get any insights how overall consumption with different settings might look like I lack the equipment (would need something like Hardkernel's SmartPower2 to be able to feed consumption data in my monitoring system)
 
 

modprobe dhd
 
or
 
modprobe wifi_dummy
 
 
PS
In order to better understand the features of these images Armbian (they have a number of differences from the official versions), I recommend to read the latest pages of the topic.
 
 

Why can't things just work???    Thanks for the heads up @Myy

Welcome here!
 
 
Interesting. No one here talked about patches or active development. The person you quoted only reported over in your forum that he did a 'make menuconfig' to fix stuff you forgot to enable in your kernel (according to your indtroduction it's the kernel you maintain?). It might be a surprising experience but you can modify the kernel config and enable/disable stuff there. That's what the person did you ask now for patches.
 
 
Things are slightly different this time but we got the chance to realize this just recently since SinoVoip blocked successfully every insights for almost half a year.
 
The R1 is crap in so many areas that it's just a waste of time to list all the issues. So let's try to be positive and look only at what's different now:
 
Software:
Unlike back then with R1 which received zero support by the SoC vendor (Allwinner) we know in the meantime that MediaTek (who have/had a horribly bad reputation based on their 'closed' behaviour in the past requiring everyone to sign NDAs and to pay insanely high amounts of money to get access to sources) opened up themselves and are becoming part of open source community. This is really great news but also somewhat surprising. MTK partnered with a vendor not able to understand the meaning of 'open' and so SinoVoip was sitting on a closed MT7623 kernel repo and prevented every member of open source communities to participate/improve for almost half a year for exactly no reason ('just wait and see' was everything we got from their official voice 'sinovoip bpi team') A couple of MTK engineers are active upstreaming software support for both SoC and the R2 so as already said in post #1 in this thread: 'We also know that MediaTek unlike in the past is currently opening themselves, their vendor kernel for this board is a 4.4.70 currently and they're also busy supporting their own hardware upstream. It might get interesting in 2018'. @sean.wang already explained what might be missing currently with mainline kernel in this thread and I really look forward to MT7623 designs in 2018 when mainline kernel support matured. Since MTK is providing mainline kernel support it's just a matter of time until *Wrt/LEDE support will be available (R2 becoming the main development vehicle for MT7623 devices) Hardware:
 
At the time I could poke SinoVoip's copy&paste monkey censoring their forum and not supporting users to provide a boot log a few weeks ago we also know a bit more about the hardware (it's amazing that their BS collection they call 'technical documentation' still lists so much wrong or contradicting information). Since a few end users now have this hardware in their hands we can expect at least some performance and other numbers soon since for whatever reasons SinoVoip never tested any of their boards wrt performance/usability.
 
R2 does not suffer from R1's Achilles heel (the shitty Micro USB connector to power the board responsible for so many under-voltage drama), maybe we get some information from users soon how powering connected SATA disks work (isn't it amazing that the hardware vendor is not able to answer such simple questions?) so soon we know a bit more what to expect with regard to specific use cases and overall performance.
 
MT7623 platform looks great, we've been asked by a Taiwanese company planning to build an 'open' NAS device already about software support (they also mention MTK being really supportive) and at least I'm really looking forward to more devices based on MT7623. But unfortunately I'm allergic to stupidity/ignorance and stuff like this https://archive.is/tY9gt is all we can get from the respective 'vendor' now. I fail to understand the purpose of 'borrowing' a table from a competitor totally unrelated to your own hardware/software to 'demonstrate' whatever. That's not a mistake you make by accident but that's just bizarre. It's now year 3 in Banana land dealing with stupidity/ignorance for whatever reason (unfortunately zero improvements). And that makes me really sad since I fail to understand why...

In the case of specific hardware with partial or incorrect device trees, etc, the schematics are quite useful for pin numbers etc.  There are always examples of features not fully implemented, even when advertised. 
 
As an Electrical Engineer, I would politely remind you that code does not execute in a magical place where no physics exist.  Things like "can this board be powered via GPIO?"  "What is the maximum current available via USB?".  "Is the SD regulator capable of switching to 1.8V for high speed?" "How are the processor opp voltages derived?". All require schematics to verify, especially when the company spends all their time on new boards and almost none on support.

Well shit.