Tido

I chased down EMI problems with A20-Micro in the past.  We were using inside and enclosure with some sensitive ADCs.
Had no access to a DSA, but main causes in my case were(in order of importance):
 
-Power supply- We had a switching wall-wart type supply @12v. Replaced with battery, then with a better quality power supply. Ferrites on the supply cable helped a lot too.
-Buck converter on board the A20-Micro is noisy- Try powering board by the 5v_Ext pins (obviously don't exceed 5v)
 
If you get an improvement, please share another shot from your DSA.
 

ArmbianIO is not a fork of WiringOP. I wrote ArmbianIO because of the terrible situation with WiringOP and WiringNP. Using the BCM numbering on Allwinner boards is understandable for RPI compatibility, but limits what you can do with non-BCM chips. I thought a fresh start which treats all boards as unique and allows more than 40-pins of GPIO header would be wiser than another "crutch" of a hacked up WiringPi copy. I have a wide variety of boards and ArmbianIO (even running on Raspberry Pi boards) allows a consistent way to work with GPIO/I2C/SPI. I know that when I hook an LED or switch to a GPIO pin, I can run the same code on any of my boards and connect it to the same header pin and it will work without modifying my code.
 
chwe: splited from https://forum.armbian.com/topic/6197-hardware-line-is-missing-on-proccpuinfo/  cause I think it's better to keep this in this thread.
 

Earlier in the current thread :
 

I download it from here:
http://downloads.slimdevices.com/nightly/?ver=7.9

The exact command list:
wget http://downloads.slimdevices.com/nightly/7.9/sc/70b0c7c/logitechmediaserver_7.9.1~1515516449_arm.deb dpkg -i logitechmediaserver_7.9.1~1515516449_arm.deb After installation is done, WEB control is accessible on http://your_tinkerboard_ip:9000
 
Worked for me. Debian Stretch. Type lsb_release -a (since sprunge.us is currently down and I actually can't see anything)
No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 9.3 (stretch) Release: 9.3 Codename: stretch  

Did you use the search function in top right hand corner ?
https://forum.armbian.com/topic/6070-smartgear-multi-system-emulator-released-as-open-source
 
https://forum.armbian.com/topic/5744-new-bb-cp-a-replacement-for-fbtft-fbcp
 
https://forum.armbian.com/topic/5713-spi-throughput-slower-on-mainline-kernel
 
https://forum.armbian.com/topic/5824-orange-pi-zero-graphic-programming
 

well, thank god u r not the only dev
 
// sent from mobile phone //

Assuming different versions are just around the corner, I'll wait and see all the variations of specs before purchasing.
 

Just look at Orange Pi Zero Plus 2: same PCB, one batch with H3 in the reel, the other batch H5. Due to software incompatibility use cases and usability of the two variants differ a lot (and I personally have not the slightest idea why 'we' started here to support the H5 variant at all since IMO no reasonable use case exists -- H3 variant with legacy kernel + Mali and video acceleration is something different)
 
So here we're talking about the same: identical PCB, identical design flaw (SinoVoip 'forgot' voltage regulation) but different SoCs, different DRAM and AP6212 on early Bananas vs. AP6212A here, right?

@JeromeB understood.  Patched, tested, no negative consequences, and so far no hangups either.  
 
Is the recent series slated to make it into a 4.14? 
 
[edit] streaming video, 3 ssh sessions (one with X-forwarding), and moving files around in the background and no issues.  
 
Had some time, and added the series of phy adjustments as well to our 4.14.y build, everything is working quite nicely.
 
[ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 4.14.7-meson64 (root@builder) (gcc version 7.2.1 20171011 (Linaro GCC 7.2-2017.11)) #38 SMP PREEMPT Tue Dec 19 01:16:29 EST 2017 [ 0.000000] Boot CPU: AArch64 Processor [410fd034] [ 0.000000] Machine model: Libre Technology CC ... [ 17.562193] Meson GXL Internal PHY 0.e40908ff:08: attached PHY driver [Meson GXL Internal PHY] (mii_bus:phy_addr=0.e40908ff:08, irq=33)  

I saw this: https://linux-sunxi.org/FEL/USBBoot#General_description_of_the_.22sunxi-fel_uboot.22_command_implementation
 
And google this: OrangePi Zero FEL  - Result: There are no buttons or connectors to select FEL mode so the BootROM will only enter FEL mode if a special SD card is present or if there are no valid boot options.
 
And a forum search: https://forum.armbian.com/topic/2808-orange-pi-zero-went-to-the-market/?do=findComment&comment=20334
 
But by all means, I have never tried it, but I would like to do it. TK quite easily tested new Kernels that way, IIRC.

Well, I don't know if the OPi zero can do FEL https://linux-sunxi.org/FEL/USBBoot

I agree, but wish we had a way to "document-ize" the tutorial after all the discussion.  You get 40 pages of talk on a tutorial and it's easy to miss the important parts.
 
Yes, there is.  I think we run into trouble that there aren't many maintainers to begin with, and we range from " This is good enough I don't need feedback" to "I want 100% absolute direct democracy on every decision".  This is difficult, and there are pros and cons to both.100% direct democracy does quite literally mean nothing gets done in a reasonable time, but everything will be more stable.  "Good Enough" gets you more bugs, but also more on-time releases and a sense that you're "doing something" to the general public.  (See the criticism Debian gets about their definition of "Stable")
 
There is one thing I can say that is hard to dispute:  I can test something pretty thoroughly on my hardware in my laboratory with my equipment.  That doesn't mean it's going to work for anyone else repeatably.  So I test, and I commit the changes.  My changes are immediately live, there is no means to "trial" a change.  This is a discussion for another thread, but we should have a stable "release" branch that only gets updated for bugfixes.  Then our download page would have "Stable Release" and "development" images.  People want to use dev images?  Ok, but know that a 5.37-beta release may not be stable, even if it is a legacy kernel/etc. 
 
 
For the Website: I think a CMS is best.  However, if the primary maintainer of the website is not fond of that idea, then a set of templates and a github would be a wise alternative.

I also like Zador's idea for the download section.
 
This I don't understand. I always click  for SoC and if it were then in alphabetical order, would be fine by me.
H3 rush, is ending. H2, H5 and H6 is coming so the quantity of SBC is to me small enough per SoC, that I do not see the reason for a search.
Unless you see indeed a problem.
 
CMS: I agree that it would help. So Igor could count on the help from the community.
 
Docs: I was wondering if we could have another step in it:
Documentation Tutorials  - for example three lines intro text and a link to this or just a tutorial for xyz. This way it wouldn't get lost in the daily chats.

You sure about this?
 
One of our clients ordered 85K rk3288 boards to be designed and manufactured to rk-miniarm spec in August and they have contractual availability to buy upto 500K per year through till July 2021. Their OEM would have to hold a lot of rk3288 SoC stock to meet those obligations for a discontinued chip over 5 years.

Linux kernel development is anarchistic and our work is involved, dependant and related to this organizational type. Adding too strick wireframe and being harsh where is absolutely no need might be more damaging ... and a waste of time if you like that kind of word form. Scaring people not to come out with their ideas because somebody will bark at them how stupid they are might be also a waste of time. And damaging. Most people around the project are volunteers after all and demanding ultimate compliance won't work. Being a pro/cash has little effect on this either.

Talking and discussing every possible matter consumes human resources which, frankly we don't have in indefinite capacity. Nobody has. Somebody has to lead and coordinate this web redesign and until this is mostly on me, I will resolve minor disputes instantly or I will not deal with this in any way. This is not a military precision stuff! Why do we need to panic? It's plenty of time, this is not print media and mistakes can be fixed. 
 
And I will for sure do more mistakes in the future. Perhaps even repeat them, which I hope not.

If you think everything is waste of time, take a break from extreme specifics ... even this can be considered as a waste of time from a radical point of view.  

You have possible future boards in the dedicated section and there is a place for discussion if needed. There is no rush - take time. It's your right to write down that all boards sux and is pointless to deal with it. Should this change anything? Not necessarily and it should be this way.
 
Can we now stay on this topic?
 

It's not uncommon that 'Home' isn't visible on a websites navbar,  but the logo is linked to it (said someone who was on armbians main page more than 6 times today.. ).  As soon as you've a template page it's annoying to program exceptions... 
 
IMO this should be discussed in another thread. Otherwise, we fill this one also with a lot of stuff which doesn't belong to the topic.

First draft. Comments and ideas over are welcome. UX related only at this stage.

I was just thinking adding this to armbian-config: create dedicated GPIO user

I just released the source code to a very simple weather monitoring app. I wrote it to run on my Orange Pi Zero and make use of a few environmental sensors (Bosch BME280 and AMS CCS811), along with a SSD1306 OLED. It records the data every ten seconds into a CSV text file.
 
https://github.com/bitbank2/weather_mon
 
It's just a simple idea that I had to monitor the conditions overnight in my kids' bedroom since our place doesn't heat/cool evenly.

I just wanted to say that using those expressions as filters/tags is misleading.
 
I'm not sure that UX people that are not familiar with SBCs can understand what and why we are discussing some things. So, again, ideally we would need a CMS with visual design being as close as we can get to the current one + enhancements suggested in this thread.

And both are WRONG! That's the problem. Better no information than misleading/wrong information. Unless this categorization can be edited/reviewed by us (eg. part of board config files) I would really prefer to stop 'advertising' wrong features.
mSATA: the Hummingboard has no mSATA but mPCIe only, same with the Clearfogs by default: you need to rebuild u-boot and have to freeze the packages to get reliable mSATA/SATA on the mPCIe slot(s) SATA: This category is totally worthless if boards with crap SATA like the Orange Pi Plus and Plus 2 are listed here too. People look after SATA since they associate 'fast storage' with this. This is already wrong with those A20 boards but it gets bizarre when we're talking about the crappy GL830. And the only boards with real fast SATA -- not on mSATA slots but M.2 slot with key type B -- are missing here Again: user perspective. The features listed there should match user expectations (and that's fast storage and not 'technically a SATA port is on the board even if it's crap'). Just another part of the same problem...

my 2 cents.
 
1. CLI. install-armbian or armbian-install
2. In armbian-config
"Install" "Install system to internal memory"
3. first run. "Do you want to install system to internal memory"
 
How to handle exceptions?
 
When SD card boot is needed, a warning pops out when hitting NEXT.

Well, I expect the HC2 (or HC1+ or whatever HC$something will be released by Hardkernel the next time) to be fully software compatible. It will be just another variant using the same SoC and a JMicron USB-to-SATA bridge (maybe just like with their Cloudshell 2 using JMS561 which will then lead to the same issues as today with this Cloudshell thing). The thread title there has a reason  
 
 
No, since all the results of our work are still there (we don't fiddle around manually with OS images but each and every improvement gets commited to the build system so everyone on this planet is enabled to build fresh OMV images from scratch as often as he wants to). It's just that there's currently nothing to improve and it also makes no sense to provide more OMV images since every Debian based Armbian image using kernel 4.x can be transformed into an OMV installation with 'armbian-config --> Software --> Softy --> Install OMV' (takes care about almost all the performance tweaks our OMV images contain).
 
To finalize this a summary what 'Armbian + OMV' exactly means and what the result of this 7 month journey was. It was about identifying problems (both technical and user experience) and developing optimal settings for performance and energy efficiency. And now we're there.
 
So if you want to run OMV on an SBC simply check whether the board is supported by Armbian with a recent kernel and you're almost done. If you want to do yourself a favour then click here on GbE (to avoid boards that are bottlenecked by slow networking) and have in mind that some stuff that looks nice on paper like Allwinner's 'native SATA' performs pretty poor in reality (check SBC storage performance overview)
 
While you basically can turn every SBC Debian Jessie or Stretch OS image into either an OMV 3 or 4 installation the real differences are as follows:
 
1) Armbian as base:
we care about kernel support, providing for all relevant platforms pretty recent kernel versions that enable all the features needed by OMV. Difference to other distros or OS images: they often use horribly outdated kernels that lack features needed for OMV working properly (please compare with the OMV related kernel config changes) our OS images contain several performance and/or consumption tweaks, eg. we optimize IO scheduler based on type of storage, we take care about IRQ affinity (on almost all other SBC distros all interrupts are processed on the first CPU core which will result in lower performance) and optimized cpufreq governor settings (allowing the board to idle at minimal consumption but switching to highest performance immediately if needed) We try to use modern protocols, eg. enabling 'USB Attached SCSI' (UAS) where possible while taking care also of broken USB enclosures that get blacklisted automatically. UAS allows for higher USB storage performance with less CPU utilization at the same time. Armbian contains powerful support tools that allow to remotely diagnose problems very easily (only problem: here in the forum we play mind-readers instead of asking for armbianmonitor output all the time) 2) Armbian's OMV/NAS performance/reliability tweaks:
we use improved Samba settings to increase SMB performance especially on the weaker boards Several file sharing daemons that usually store caches on the rootfs are forced to use RAM instead (heavily increases performance in some areas and also helps with SD cards wearing out too fast) Enabling driver support for the only two USB3 GbE dongles (ASIX AX88179 and the better RealTek RTL8153) so even boards with only Fast Ethernet or without Ethernet can be used as NAS with those dongles 3) Armbian's OMV integration tweaks:
we take care that we set in /etc/default/openmediavault three variables that heavily influence board performance once a user clicks around in OMV's 'Power Management' settings. Without this tweak otherwise OMV defines 'powersave' cpufreq governor which is totally fine on x86 systems but can result in a horrible performance decrease on ARM boards with kernels that then remain all the time on the lowest possible CPU frequency (on some systems like ODROID-XU4 or HC1 this can make a difference of 200 MHz vs. 2 GHz!) we install and enable OMV's flashmemory plugin by default to reduce wear on the SD card and to speed certain things up. WIthout this plugin OMV installations running off SD cards or eMMC might pretty fast fail due to flash media already worn out (way higher write amplification without the plugin will lead to your storage media dying much faster) All these 9 tweaks above make the difference and are responsible for such an 'Armbian OMV' consuming less energy while performing a lot better than distros that ignore all of this. I tested the last months a lot also with other OS images where OMV has been installed without any tweaks and Armbian's way was always way faster (biggest difference on ODROID-XU4 where I tested with OS images that showed not even 50% of our performance).
 
That being said it's really as easy as: Choose a sufficient board (GbE, fast storage) supported by Armbian's next branch (so kernel version recent enough for all features to work), choose either Jessie (for OMV 3) or Stretch (OMV 4) and call armbian-config to let OMV be installed (few minutes on a fast SD card, if you have to wait ages it's highly recommended to throw the SD card away and start over from here).
 
Just as a reference: the dedicated OMV images I generated the last half year do include another bunch of minor tweaks compared to installing OMV with armbian-config:
Disable Armbian's log2ram in favour of OMV's folder2ram Automatically setting the correct timezone at first boot based on geo location (IP address) Device support for Cloudshell 2 (checks presence on I2C bus and then install's Hardkernel's support stuff to get display and fan working) Device workaround for buggy Cloudshell 1 (checks presence on USB bus) Cron job executed every minute to improve IO snappyness of filesharing daemons and moving them to the big cores on ODROID XU4 Making syslog less noisy via /etc/rsyslog.d/omv-armbian.conf Replacing swap entirely with zram
Limit rootfs resize to 7.3 GB and automatically creating a 3rd partition using the remaining capacity that only needs to be formatted manually and can then be used as a data share
All tweaks can be studied here and by using this script as customize-image.sh you can still build fully optimized OMV images for every board Armbian supports with a next kernel branch.
 
And now may I ask a moderator to lock this thread from now on so new issues will be discussed separately? Thank you!

Submitted the fixes to ASUS as well, should be included in their next kernel:  Pull request
 
 

Here's my game emulators running on an Orange Pi Zero (AllWinner H2 SoC). I use the SPI_LCD library to talk directly to the LCD for better framerates than can be achieved with fbtft/fbcp:
 
 
 
Below is a photo of a NanoPi Duo (AllWinner H2 SoC) using my oled_96 library when running my new "bb-hole" program. This is a replacement for pi-hole which acts as a DNS filter to block unwanted ads/sites. I will be releasing the source code to this shortly.