pfeerick

Most of us probably do some electronics along with the small computers, I've been part of "what does you desktop look like?" threads (terrible, by the way), thought I'd put up (the electronics part of) my workbench:
I wasn't about to lie and clean it up before hand...
 

This will proove I'm older than you .... but I still use my HP48sx from when I was in the University (as a side note I still works perfectly fine after more than 20 years) .....
 
I'll post a photo of my workbench soon

We have idea, but lack of time, to provide IOT / slim version, which means rework (put under switch) those sections + conduct few tests ... 
 
https://github.com/armbian/build/blob/master/configuration.sh#L103-L139
https://github.com/armbian/build/blob/master/distributions.sh#L105-L106
 
Other option is do uninstall certain - non relevant to your case - packages.

Weyou, It may be obvious, but are you using a barrel type power supply? Looks like you are using an OTG (USB type) power supply, since you Are talking about Samsung and Raspberry Pi chargers. I have an orange Pi pc 2 and I use the manufacturer recommended AC adapter 3A, barrel type.

The "thread" is a perfect example of the Dunning–Kruger effect...
 

This isn't helping me not want one.  ;-)
 
I'm paging through the mainline kernel support, hopefully more of these make it out of the Rockhchip patchwork and into 4.12 (like RK805 support).  As it stands I think mainline support is possible, if not extremely convenient.

Folks, just don't try to behave like assholes (deleting other peoples opinions/posts, altering contents you don't understand, trying to establish BS like 'peace, love and harmony').
 
Worst case option: move posts to a subforum. Never delete, never alter, never censor. If you do this the whole project becomes irrelevant.

Agree. Maybe it's also the time to add a "Rockchip" section.
 
This section is really inactive as it is now IMO, maybe we can split it into other sections somehow.
 
Mixing reviews for supported and not supported devices? And what about adding a "Tutorials" section to reduce the number of pinned posts in "Technical support" sections?
 
"Community projects"? There we can create a section "Amlogic based TV boxes" and split Hardkernel boards from TV boxes.
Deprecated boards (formerly supported by Armbian) can go there as a section too.
Maybe put Rockchip based TV boxes there too, I don't think we will be adding official support for those anytime soon.
 
Agree with tasks, but IMO we still should split build script related development from other stuff like packages, Python libraries, etc. 

ok I'll answer my own question since i figured it out.  Start terminal emulator, type su and enter the superuser password.  then type passwd <user> and enter the user password. voila

Of course you had some problems, otherwise, you would not posted that Chinese Android screenshot !
 
Does he have a USB Serial to debug ?

some more numbers on pin 1&2 that are working (setup: orangepi zero rev. 1.4, micro USB powered, samsung evo32gb, headless ssh over LAN, with NRF24l01 radio module):
opi in idle modus: 5.16V
running cpu-miner: 5.12V
 
Edit:
Just tried to create a underpower situation on my opi zero (not easy when you throw away most of the bad usb chargers& cables). 
I got finally it with an old sony mobile phone charger and a thin noname 1m cable. Without any load on it delivers exactly 5.00V on its output (measured with a Keweisi USB powermeter). Connecting it to the opi zero voltage drops to arround ~4.8V on the USB output and ~4.5V on pin 1&2, which result in no proper startup of the opi. 
Things that indecate that opi 0 doesn't startup properly: 
-The LED (D7) does not shine (green one)
-The Opi 0 gets unexpectable hot (disconnected it after 1min to avoid burnig something on my board)
I don't wanna watch all your videos to see if D7 LED shines when you power the board but it's up to you to do that.

This is ROCK64 specific. New board with correctly working USB3 arrived 10 minutes ago. Switched to performance governor and doing the usual 'iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2' with the slowest SSD I have lying around (Intel 540):
random random kB reclen write rewrite read reread read write 102400 4 10794 14075 18413 14337 12084 13125 102400 16 38316 48250 58929 50123 33636 44383 102400 512 85148 113573 217972 226149 209220 229556 102400 1024 239054 254531 226798 261436 240226 213082 102400 16384 271696 291983 316979 323006 282067 292218 In other words: this is the new single drive NAS board. Forget about overpriced fails or slow A20 boards or their R40/V40 successors currently only available from brain damaged retards.

It is frustrating, it's also universal human nature.  I sold car parts while going to college, people always wanted to buy the generic parts instead of the original equipment and then got mad when they lasted 2 months instead of 5 years.  
 
Even now working with Automotive companies, sometimes I have to explain the laws of physics and why my products can't defy them.
 
So was it the need to moderate the posts, or the constant onslaught of said posts that caused the issue with the orange pi zero?  I was thinking of a garbage collection thread that would be slightly more polite than deletion, and less distracting for devs trying to answer real questions.
 
Example:. "Why can't my nanopi neo transcode 6 video streams simultaneously while cooking me breakfast?"
 
From moderator:. "post moved to "collection of insane and redundant questions.  See FAQ in OP of thread."

Two things I want to bring up:
"Trial period" is a great idea, and this is what I was getting at: During the "trial period" nightly/stable builds are not available. Anyone wanting to test out the board during the trial period has to build an image from git themselves. This prevents devs from being mobbed by people for support when there are still lingering issues. Forums suck for finding information, and no one ever uses the search feature. So, wiki software. MediaWiki is FOSS, but the syntax sucks. Confluence isn't FOSS, but it is free for Open Source projects, and they have a really excellent editor. I'm not affiliated with Atlassian in any way, I just think if you want a usable, low-friction wiki, Confluence would be a good choice. I realize since Confluence is not FOSS, this has some negative appeal in some corners. Also it's Java...   
 
 
We tried this already with the Orange Pi Zero. It just ended up pissing off everyone who was working on it (including me). No user seems willing to accept our explanations about performance and what is feasible. They think because the manufacturer says "WiFi" it will do the same things as their $1,200 laptop with dual-band 3x3 802.11ac.
 
Why should I sit here and take shit from people who expect perfect WiFi from a $9 SBC and pay nothing toward Armbian? Especially after we calmly explain what isn't possible, they say "well I was thinking about giving you money, but since you can't make magic unicorns out of thin air, forget it" Seriously?! Seriously?!!! No. Please go away.

No, this all is what I wanted to discuss here in the first place. The '[Example]' in the thread's title is there for a reason. Is Armbian willing and able to change some 'habits' or not? Is it possible that the inner circle allows other people to participate or not? Is the 'inner circle' aware how some stuff looks like from the outside (eg. taking decisions out of nowhere that should be result of a discussion process).
 
But I'm really too tired to continue...

Agree. Categories like "Recommended by Armbian for building a medium level NAS", "Recommended by Armbian for building a powerful router" or "Recommended by Armbian as a low cost IoT node" would be better - still suggesting users (that decided to check the software situation before buying the board) what to choose without creating false assumptions regarding product quality and support.
Unfortunately even if we tag i.e. Orange Pi Zero as "Not a good choice for making a multimedia center" and "Not a good choice for making a wireless AP", it won't stop people from trying to use the board for exactly those use cases.

Current situation with WIP/EOS boards:
➜ armbian % find lib/config/boards -name '*.wip' -o -name '*.eos' | xargs grep BETA_TARGET | grep -v '\"\"' lib/config/boards/orangepiprime.wip:CLI_BETA_TARGET="xenial:dev" lib/config/boards/orangepiprime.wip:DESKTOP_BETA_TARGET="xenial:dev" lib/config/boards/orangepipc2.wip:CLI_BETA_TARGET="xenial:dev" lib/config/boards/orangepipc2.wip:DESKTOP_BETA_TARGET="xenial:dev" lib/config/boards/lamobo-r1.eos:CLI_BETA_TARGET="xenial:next" lib/config/boards/nanopineo2.wip:CLI_BETA_TARGET="xenial:dev" lib/config/boards/orangepizeroplus2-h5.wip:CLI_BETA_TARGET="xenial:dev" lib/config/boards/orangepiwin.wip:CLI_BETA_TARGET="xenial:dev" lib/config/boards/orangepiwin.wip:DESKTOP_BETA_TARGET="xenial:dev" ➜ armbian % As proposed in the discussion thread, we should think about disabling prebuilt nightlies for configurations that we won't support, so I propose disabling them for all boards listed here.
 
Current situation with "supported" boards:
➜ armbian % find lib/config/boards -name '*.conf' | xargs grep BETA_TARGET | grep -v '\"\"' lib/config/boards/orangepizero.conf:CLI_BETA_TARGET="xenial:dev" lib/config/boards/miqi.conf:DESKTOP_BETA_TARGET="xenial:dev" lib/config/boards/cubieboard2.conf:DESKTOP_BETA_TARGET="xenial:default,next" lib/config/boards/pine64.conf:CLI_BETA_TARGET="xenial:dev" lib/config/boards/pine64.conf:DESKTOP_BETA_TARGET="xenial:default" lib/config/boards/odroidc1.conf:DESKTOP_BETA_TARGET="xenial:default" lib/config/boards/cubox-i.conf:CLI_BETA_TARGET="xenial:dev" lib/config/boards/cubox-i.conf:DESKTOP_BETA_TARGET="xenial:next" lib/config/boards/odroidxu4.conf:DESKTOP_BETA_TARGET="xenial:next" lib/config/boards/orangepilite.conf:CLI_BETA_TARGET="xenial:dev" lib/config/boards/pine64so.conf:CLI_BETA_TARGET="xenial:dev" lib/config/boards/pinebook-a64.conf:DESKTOP_BETA_TARGET="xenial:default" lib/config/boards/orangepiplus2e.conf:CLI_BETA_TARGET="xenial:dev" lib/config/boards/cubietruck.conf:CLI_BETA_TARGET="xenial:next" lib/config/boards/nanopineo.conf:CLI_BETA_TARGET="xenial:dev" lib/config/boards/clearfogbase.conf:CLI_BETA_TARGET="xenial:default" lib/config/boards/orangepione.conf:CLI_BETA_TARGET="xenial:dev" lib/config/boards/nanopiair.conf:CLI_BETA_TARGET="xenial:dev" lib/config/boards/tinkerboard.conf:DESKTOP_BETA_TARGET="xenial:dev" lib/config/boards/bananapi.conf:CLI_BETA_TARGET="xenial:next" lib/config/boards/orangepizeroplus2-h3.conf:CLI_BETA_TARGET="xenial:dev" lib/config/boards/orangepipc.conf:CLI_BETA_TARGET="xenial:dev" lib/config/boards/bananapim2plus.conf:CLI_BETA_TARGET="xenial:dev" lib/config/boards/beelinkx2.conf:DESKTOP_BETA_TARGET="xenial:default" lib/config/boards/orangepipcplus.conf:CLI_BETA_TARGET="xenial:dev" lib/config/boards/clearfogpro.conf:CLI_BETA_TARGET="xenial:default" lib/config/boards/lime2.conf:CLI_BETA_TARGET="xenial:next" lib/config/boards/odroidc2.conf:CLI_BETA_TARGET="xenial:next" lib/config/boards/odroidc2.conf:DESKTOP_BETA_TARGET="xenial:next" ➜ armbian % In my opinion this is too much, so we should disable some nightlies fron this list too.

Yes, let's move all out and enable upon developers requests?

Small note to moderators:
Sometimes when posting several duplicates of new post or thread may be created (with the same content and timestamp). Please don't blame the poster for this, simply hide or delete the dupes. Thanks.

This function is (was) not enabled by default - just hover over the username -> "More options" -> "Flag as spamer" / "Warn user" . When flagging someone as spammer - posts are also hidden and AFAIK user info goes upstream to general spam database. Spammers busted on any IPB forum are blocked everywhere ... with one click. In reality there are some problems with this service - sometimes prevents humans to login - and it's currently disabled. I'll check again upon next major forum upgrade.
 

Welcome on board  - this requirements above shell be updated but remained simple, unambiguous and understandable to everyone, not just to us. 

I guess I will need to rewrite the text saying "rare" to "extremely rare" since forum crew expanded this quickly  Closing recruitment for this year or until someone decides to have enough of this.

I'm quoting myself here from my previous post :
 

Added the -ings for you..
 
The dashboard things came from a add-on. At the moment I'm a little bit annoyed from the mysensor stuff. So much of their sensor nodes are fix configured which makes it hard to me to understand, how their library work. My purposes for the hole IoT thing isn't that my opi recognizes when go to the toilet or other senseless homeautomatization stuff (senseless to me, if someone else needs this feel free to make a toilet node ). I want to use it in lab-automatization (mostly chemistry labs). So most of their predefined nodes are useless to me. Nevertheless, I'll start with things, where an error doesn't burn my labratory.
IMO knowlege should be shared to give something back to the armbian community who makes it possible to me, even thinking about doing lab-automatization on an sbc. 
 

I've just managed to build Devuan/Aarch64 for the Odroid C2 using the traditional debootstrap (on an Ubuntu host) way, so I might be able to patch the armbian/build scripts in order to generate a Devuan image.

Thank you.  I will try to change a new power supply.
 
I was not intent to making multiple posts,  it was just an accident   Maybe my network issue, the edit page didn't have any response after my first clicking on the submit button.  So I clicked twice...  And I didn't find how to delete the duplicate one.