Heisath

Since - in my eyes - at least - there is a likelihood of confusion regarding the "Supporter" tag of members that actually (recurring) donating to the project. People could think "Supporter" means staff member that actually support people with their issues. The real staff rank, Moderator and Administrator to say, is "hidden" in their individual profiles. Since I like the idea of flat hierarchy I do not suggest to make the actual staff visible in forum postings but simply rename the Supporter to something like "Donator" to make it clear that these people donated to the project but are not necessarly involved into it.
 
Tell me what you think,

You could just add some larger capacitor in parallel to the power bank. If chosen right it should surpress the voltage spike and buffer enough so it does not drop. Might even use more than one to get a better frequency response. Or put a 5.2 volt zener / tvs diode across the board to protect it from the spike. 
 
I can edit this with some wiring later if needed. 
 
EDIT: Some wiring idea:
 

 
Use some resistor voltage divider on the powerbank input (eg. 10k to 10k which gives you 0.5) to get some measurement to your sbc. With the given voltages this would be: 5V in -> 5V * (10k / (10k + 10k)) = 5V * 0.5 = 2.5V .
If you feed this to some GPIO you can either use some analog pin to measure it directly (and initiate shutdown if it goes to low) or you can hook it up to some digital one if you only want to know wether it is high or low. Might need to change the resistor ratio then. Do not exceed your max gpio voltage!
 
On the Powerbank output add either D1 or D2  (zener or transient voltage surpressor diodes) rated for slightly above 5V. These will get rid of nasty voltage spikes for you. Additionally use some small capacitor (to remove high frequency ripple) and some larger one in parallel (to reduce low frequency ripple / voltage drops) to buffer over the voltage drop when powerbank is switching on / off.
 
 
 
Cheers, 
count-doku

I was not expecting you to put more time into it. It was more directed at the original poster, to address the issues pointed out by you. And to give him an idea what he could do to make it work with a powerbank...

I agree with the previous posters. Any supported / recommended board will run stable with most features working if you use good PSU (not micro-usb), sd card (or even better root on emmc or sata) and is sufficiently cooled. I'd suggest you go for boards with good mainline linux support (ie. 4.19 or 5.4) because more hardware is supported & if something breaks there are possibly more people fixing it versus boards which only have some old vendor kernel.
 
Apart from that unfortunately it is like you said, not every feature works on every board. In my experience this is mainly due to hardware producers advertising (hardware) functions although there is no real software support for it. Or randomly changing hardware (see espressobin) which breaks existing software... I suggest thinking about stuff you really need and picking a board afterwards. (You probably don't need an "Eierlegendewollmilchsau").
 
Personal experience: I'm running a Router/NAS based on ClearfogPro with M.2 SSD for OS, 2x HDD for storage (with mPCIe-SATA bridge) for about  3 years now with no problems (apart from stuff which I broke be installing dev kernels and so on). 
 
So, I am sending in the Clearfog Army!
 

Hi Xavier,
 
Kernel 5.5 is currently not supported by us. Our current kernel 4.19 has complete hardware support, dev kernel (5.4; which you need to compile yourself with https://github.com/armbian/build) should also have working PWM. 

If you need to use Kernel 5.5 you are on your own, you can try to use the patches from 5.4 (https://github.com/armbian/build) to get PWM working...
 
Cheers,
count-doku

Hi Xavier,
 
Kernel 5.5 is currently not supported by us. Our current kernel 4.19 has complete hardware support, dev kernel (5.4; which you need to compile yourself with https://github.com/armbian/build) should also have working PWM. 

If you need to use Kernel 5.5 you are on your own, you can try to use the patches from 5.4 (https://github.com/armbian/build) to get PWM working...
 
Cheers,
count-doku

Release Candidate Code Freeze Date: 2020-01-25
Release Date: 2020-02-??  (will update thread)
Current Release Candidate Branch Link: v20.02-rc1
Release Changelog: (will update)
Release Coordinator: @lanefu
Testing Tracking Sheet: https://bit.ly/2TGaeZN  (google sheets)
 
The goal of this thread is to discuss testing, bugfixes, and the overall quality of the release.  Once the release is complete, this thread should be locked and unpinned.  Our Hotfix process for completed releases is TBD.
 
First of all I'm sorry I'm kicking this off so late.  I should have started a few weeks ago.  I'll continue to update this post with more information.  I will also update release process documentation as we progress.
 
I am going to go ahead and cut a release branch to learn and further document the process, but the official release branch won't be cut until the Release Candidate Code Freeze Date.
 
Tagging a few devs here from memory.. please tag others....  @Igor @gprovost @martinayotte @chwe @TonyMac32 @count-doku @balbes150 @Tido
 
 

My two cents.
 
- once we made a fork from a master branch, version must be adjusted accordingly (also on master)
- master remains the place for new contribution and we merge them into 
- when we are satisfied with the state of the build, RCx -> .1
- hot-fix releases. For now IMO, using master branch and just going up with the number. Unless we have resources which will stay behind and tinkle old releases, send fix to master, merge back, bump version and tell me what to build
 
I do plan to create a Jenkins server for this one day, that you will be able to push things up without me in the loop.

I've added some more detail here on merge policy and release process.  Keep an eye on it. I'll be updating it as we go through this process https://github.com/armbian/documentation/blob/master/docs/Process_Release-Model.md#release-coordinating
 
and to clarify.. I have cut an rc0 branch, but it's just to test the process.   rc1 will be the first official rc branch and will happen on our freeze date.
 

Adding @aprayoga

Looks good, I like the definitive freeze / release dates. 
 
I will do remaining work (mostly testing recent mvebu changes on Helios4) today.
 
Another dev: @aprayoga
 
EDIT:
Not worth the extra post, I completed testing on Helios4 and Clearfog looks good:
mvebu-legacy
    Helios4 lk 4.14.y u-boot 2018.11-armbian
   http://ix.io/27Ou
 
    Clearfog (Pro) lk 4.14.y u-boot 2018.01-armbian
    * SFP working but only up to 1Gbps    
   http://ix.io/27OL
 
mvebu-current
    Helios4 lk 4.19.y u-boot 2019.04-armbian
   http://ix.io/27Ox  
 
    Clearfog (Pro) lk 4.19.y u-boot 2018.01-armbian
    * SFP working but only up to 1Gbps
   http://ix.io/27OM

Hi,
 
these PIN Names are possibly considered "general knowledge" once you worked with some microprocessors or similiar. Most are just abbreviations. And the different functions on a pin.
 
I'll try to explain some of them based on the linked OrangePi Extension header table (from their wiki):

3.3V -> obviously 3.3V output
TWI0_SDA / PA12 / GPIO12:
TWI0_SDA -> Two Wire Interface also known as I²C | SDA -> Serial Data
PA12 -> Pin from internal pin register a, number 12
GPIO -> General Purpose Input/Output Pin Number 12
the last two are essentially the same with the first one based on the internal registers and the other one just numerated over all pins.
 
TWI0_SCK / PA11 / GPIO11:
TWI0_SCK -> Two Wire Interface (i2c) | SCK -> Serial Clock
 
GND -> ground, minus, (-), return or whatever you're gonna call it.
 
UART2_RX -> Universial Asynchronous Receiver and Transmitter 2 -> also known as Serial Port (RS232 like) | RX -> Receiving or Receiver. This pin is read by software.
UART2_TX -> see above, TX -> Transmitter. This pin gets set by software (and sends the data)
UART2_CTS -> see above, CTS -> Clear to Send. Used for flow control, to tell the partner you are ready to receive. (or they are cleared to send) 
(Googling for UART, USART or RS232 will probably give good explanations on this)
 
SPI1_MOSI:
SPI -> Serial Peripheral Interface -> Another kind of serial port. -> google.
MOSI -> Master Out / Slave In -> this is the transmitting port for a master perspective
SPI1_MISO -> Master In / Slave Out -> receiving port
SPI1_CLK -> the clock signal. 
Just search for spi for more info.
 
SIM_CLK / PA_EINT7:
SIM_CLK -> can probably attach a SIM Card here (then this will be the clock line). I don't know stuff about sim cards though.
PA_EINT7 -> Internal Port Register A, External Interrupt 7. Read about Hardware Interrupts for microprocessors for more info. Essentially a software component can be instantly triggered on some predefined signal on this pin.
 
The rest has the same prefixes, so you can probably deduce the meaning by using the internet. If something remains unclear, just ask.
 
Kind regards,
count-doku

Looks good! Congrats to the Kobol team for designing another interesting NAS board.
 
Is the 12V 10A power supply neccessary though? I mean thats 120W, with that much power one can easily run a real x86... 
How much does the board itself consume? 
 
 

@Igor 
This is not a problem on deb2016 side. This is a general problem.
 
You posted some armbian-monitor link above, of your setup:
 
 
Did you read the results? Because if you check your 'lspci' output, you would realise that your 4x marvell sata card is not detected in linux:
 
### lspci: 00:02.0 PCI bridge: Marvell Technology Group Ltd. Device 6828 (rev 04) 00:03.0 PCI bridge: Marvell Technology Group Ltd. Device 6828 (rev 04) 02:00.0 Network controller: Qualcomm Atheros QCA986x/988x 802.11ac Wireless Network Adapter  
So this is the same problem @deb2016 is facing.
 
In my opinion this is a big problem (maybe even with the drivers for 88se9215 (which is probably your sata card)) and we should try to fix this together with current work on mvebu. See also github issue. 
https://github.com/armbian/build/issues/1426
 

One other thing to check if the disks are faulty / just doing the clicking -> connect them to some computer. Listen there.
 
 

PCB is same.
FriendlyArm img. 2GB RAM 32bit work OK. So 2GB !!!
PSU 2.4A

Excuse this double post / push.
 
But I think I found your problem Techni and a simple solution.
 
I built a new armbian image using newest kernel and debian and made sure to check the ath10k pci driver option.
 
Then burned it to my sd card and booted my clearfog -> voila same error as yours in dmesg. And no firmware files in /lib/firmware/ath10k!
 
A simple apt install firmware-atheros got me the firmware and after a reboot the card is detected and available in ifconfig.
 
So just try it using lan and install the atheros firmware.
 
I will also provide my testimage (login: root and 1234) in case you have no network connectivity.
(Upload will take some time, will update this with link when its done...)
EDIT: couldnt get a running image resized from my 64GB SD Card in time. Will try again if you need it...
 
Greetings,
count-doku
 

You don't need additional packages (except ifupdown) for a manual network configuration.
 
Just edit /etc/network/interfaces, you can check here for reference https://wiki.debian.org/NetworkConfiguration
Or have a look at my config attached to this post.
 
Greets,
count-doku
 
 
# Bring up automatically: auto lo auto eth0 auto eth1 lan1 lan2 lan3 lan4 lan5 lan6 br0 # Configure loopback interface iface lo inet loopback # Configure eth0, my outgoing public interface allow-hotplug eth0 iface eth0 inet dhcp post-up iptables-restore < /etc/iptables.up.rules post-up ip6tables-restore < /etc/ip6tables.up.rules # Bring up eth1 manual w/o ip config. This is neccessary to communicate with the switch / dsa iface eth1 inet manual # address 169.254.100.100 # netmask 255.255.255.255 # Do with the SFP Port whatever you want iface eth2 inet manual # Set all switched lan ports to manual iface lan1 inet manual iface lan2 inet manual iface lan3 inet manual iface lan4 inet manual iface lan5 inet manual iface lan6 inet manual # Create bridge over all lanports and ip config them iface br0 inet static bridge_ports lan1 lan2 lan3 lan4 lan5 lan6 address 192.168.1.1 netmask 255.255.255.0 network 192.168.1.0 broadcast 192.168.1.255