pfeerick

Symptoms:
Board does not boot Armbian from inserted SD card, but may boot other distributions (based on old/legacy u-boot).
Following or similar output can be grabbed from the serial console:
U-Boot SPL 2017.01-armbian (Feb 02 2017 - 03:04:04) DRAM: 2048 MiB Trying to boot from MMC1MMC: no card present spl: mmc init failed with error: -123 SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ### The key message here is "MMC: no card present"
 
Most likely cause:
Malfunctioning microSD slot card detect switch.
It can be verified either visually (with a magnifying glass) or electronically (with a multimeter) - at least in the slots used on Orange Pi boards and on Pine64 the pin near the switch should be shorted to the ground (i.e. SD slot casing) when card is inserted.
 
Illustration (example) of a working switch:

 
Verification (with a multimeter):
Probe 1 - slot pin near the switch (may be different for different slot types, but at least true for Oranges and Pine64)
Probe 2 - microSD slot casing or other parts connected to GND (not shown on the photo)
No card - circuit is open
Card inserted - circuit is shorted
 
Photos - card is not inseted on the left and is fully inserted on the right:
Orange Pi
 
Pine64 (switch is more visible)
 
Can it be fixed?
Yes if the switch is not broken completely, by carefully adjusting (bending) the stationary contact (left on the pictures and photos, it usually is a part of the SD slot casing) i.e using a needle so it touches the moving contact (mostly hidden inside the slot on the photos) when card is inserted and not touching it when it is not inserted.

@Igor I've edited both announcements a bit, see what you think of the changes. And please, please, please change "Before you think to report a problem with your board running Armbian' to something a little less... sharp? I know I would do that tongue in cheek (and do... hence why you sometimes see strikethroughs in my text)  , but that could be a little less unfriendly... "Before reporting problems with your board running Armbian" or ""Before reporting problems with your board running Armbian, check the following" ... something like that?

Simply, no. Not that I'm aware of.

I've personally tested onboard UART and over USB-OTG for days on end. I've not experienced any problems (that weren't of my own doing ;D) Then again, I'm also using a small heatsink and mini 5v fan.
What are you doing with OPi/Arduino? The reason I ask is because I've experienced 'drop outs' in connection over SSH/UART, etc... (which exhibit similar behavior to what little description you provide) as result of power for various reasons on OPi. 
Updating/installing/compiling large packages High CPU usage Poor power cable Combination of the above + Heat Are you cooling OPi at all? Heat is a known issue with OPi Zero. Provide logs and/or more description. ie: armbianmonitor -u
 
 

Isn't convincing enough evidence for me to rule out:
Problem with UART, not necessarily "on Orange PI Zero." Problem with the Arduino's communication to the UART  

Um... maybe tell us what your problems actually is? What did you do? Did you have wifi and ethernet running, and then unplug ethernet and this is the result of route -n? 

Most if not all of our images are tested. Those assumptions might not stand - stock images use different u-boot which could lead to differences and if you use HDD and power via micro USB you are on the power supply edge by bad design. A tiny difference in boot process could crash / not boot the board.
 
Your SD card could be half failed  ... in any case we would need a serial console output to nail the problem down. If you get there.

There's a reason Apple sent truckloads of engineers to USB Implementers forum technical commitees for 'next generation connector' and power delivery specs to avoid such BS (or that Micro USB crap). But it will take some time until we see USB-C everywhere -- especially implemented correctly  

Just a note that internal human body temperature is 37C, not surface temperature - unless you're bleeding profusely. The interface between internal (37C) and external (ambient) must necessarily be inbetween. This is why we stick the thermometer in our mouth and not on our finger. I would say 32C is the correct reading.

[SOLUTION]
 
As you can see my setup with hooked up "things", only my lte stick is not attached.
 
LOT (list of things)
SDD Samsung in the (ICY)box.
Camera attached
Serial for my terminal
Network LAN
Network USB Edimax 300 GB or MB (who cares, hehehe)
3G Modem working
 

 
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 032: ID 0e8d:00a5 MediaTek Inc. Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 032: ID 152d:2509 JMicron Technology Corp. / JMicron USA Technology Corp. JMS539 SuperSpeed SATA II 3.0G Bridge Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 002: ID 7392:7822 Edimax Technology Co., Ltd Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub I have this precision power supply and had it set to 5.00, where any (but only) external SATA->USB Bridge failed. All of a sudden I had this crazy idea to crank up the voltage a little and voila -> approx at 5.2 I had a crazy dmesg output that the drive had read errors and  cache issues. Then later I got it running at 5.25 and further perform without errors at 5.3. So I set the perfect safe level of no failure to 5.35. So what do you say about that? OPI -> into the bin?
 
Now this setup, where it is fully headless (no HDMI/DVI, etc. -> all powered off, the DRAM set to lowest 480, but all cores powered up) we can definitly say on peak performance it uses 5W.
Peak performance is Modem SMS and internet up/down from and to harddrive and surfing through hotspot.
 
all the best and I hope to solve a lot of SATA problems here and gave a real view of performance/consumption.
 
 
 
 
 

Do you ever thought about alternatives (Maybe C.H.I.P or Omega 2 are better for battery powered IoT devices. This is a little bit out of my knowledge, not sure if these two are good proposals)? From my experience, the opi 0 is a little bit bitchy as soon as it runs into a undervoltage situation. I realized that the SoC (OPi 0, rev. 1.4) gets really hot (finger test) as soon as there's not enough power to start up the board. I'll investigate this as soon as I have more time and my second OPi 0 arrives (I would be annoyed, if I grill the only one which I have at the moment). 

I would prefer to collect all known issues first, and @tkaiser most likely would prefer if you started a "board bring up" thread.
 
Then we should look at the mixer values or maybe extract asound.state from a fresh ayufan build.

I signed up to the forums just so I could add my voice to this ticket.
 
I've been using the Orange pi zeros for a couple of months and was really happy with how well the wifi worked as an access point.  So I am a little disturbed to discover that the wifi driver has been disabled and that I need to pin my kernel version (especially since I told thirty other people to get their own Orange pi zero based on my testing...)
 
Is there a list of issues with this driver somewhere?
 

Look at rockchip patchwork area, they are adding the RK805, which I believe is the pmic involved here? They are very similar, but not quite the same.  https://patchwork.kernel.org/project/linux-rockchip/list/?q=rk805

W25Q128 are now cheaper than 1 year ago ...

https://github.com/igorpecovnik/webpage
 
It did a lot of cleanup but still it's dirty. Perhaps it needs to be done from scratch. Essentially git clone + run.sh ... it makes cache files, which are included into Wordpress blog which handle those special tags and there is one bug with md parsedown library under php7 which results in some missing translation between md and html.

If they want not read stuff, give them more stuff to read.  I did some tests with cheap USB chargers (bought two only for this test) and cables and thought I would publish it somewhere here in the forum. Cause I knew, that this would give a longer thread I collected all my data in Word (yeah, I'm normally a Windows user.  ) and thought to copy paste everything when I'm finished.  During the collection of data, I thought why shouldn't make something like a 'white paper' out of it? If I jump into a new topic I'm always interested  in application notes or white papers. 
So, this is a draft (language has to cleaned up and some 'peer review' process should also been done before publishing it) about micro USB and what's to consider when using it. Maybe a set of such 'white papers' with common tasks, mistakes etc. about SBC could be something for armbian?
 
BTW: I started this test with four USB chargers, the 0.60$ one from china didn't survive the test...

Powering throught micro USB.pdf

And a small documentation update. Our friends at SinoVoip provided a great piece of information called 'Banana Pi BPI-R1 BPI-R2 smart router board Comparison 20170612'. http://forum.banana-pi.org/c/Banana-Pi-BPI-R2
 
Well, for whatever reasons the 'Comparison' isn't there any more. I don't know what might be the reason for (censorship maybe?) but fortunately the Internet remembers: http://archive.is/ibTTg
 
Since I get comment updates via email here the last piece of information @RagnerBG(one of the many users not so happy with BPi R1 -- see here for his full list of hardware modifications needed to be happy with the R2 predecessor) added over there:
 

 
(dear SinoVoip friends, you should have a look at https://en.wikipedia.org/wiki/Streisand_effect to avoid such stuff in the future. Also it would be great if you can immediately unhide all posts of mine you currently censor away)
 

I'll shush for a while so we get some other voices here in the conversion, but let me be the first to say Thomas, you're a brain damaged retard for hoping (in my opinion against all hope) that somebody might listen and actually do something about it. But no, they insist on making excuses, and saying that they're doing a good job. And you know what I think we should do... boycott all the way until they learn the error of their evil ways.
 
I don't think you missed any discussions on the forum, as I didn't see anything either, but who am I to argue with the boss. But then again... unsupported WIP, and new toys...

I've run a couple small forums for Assembly Language programming/etc, I can say that no amount of quiz keeps out the machines.  And let's face it, do we want to make the bots smarter by feeding them harder puzzles?  Soon they will gain sentience. 

I think the idea of the quiz is more harmful than the quiz itself.  "Who are these guys to put barriers in the way?" etc.  In general it comes across as unfriendly, snobbish, unwelcoming.

Perhaps we can make a quiz after all  It does the job: "promote members to a group when they reach a specific rank in the quiz"
https://invisioncommunity.com/files/file/8381-quizzes/
 
@tkaiser Would you like to design this member evaluation quiz?  Even if we have only this quiz its worth the trouble.
 

Well, some people would want to know more and some explanation must be present.

Added yet another link - directly to "Getting started". @pfeerick I hope words are not too harsh ?

For all I did there, I would say I can't represent the whole MediatTek, the contributions mostly comes from those passionates in MediaTek internally
and the core member in LEDE/Openwrt.  Many people still don't recognize importance gained from open source I admit.  I don't blame them because
everyone has different experiences for defining what success is for them although I still have a little complaining on them as @tkaiser did it for sinovoip
why let me do the unnecessary and repetitive thing again wasting so much time and energy if they are done well in the initial.
 
Instead, I would like to change their mindset as much as possible through upstreaming activity to help to link irrelevant groups among MediaTek internal,
various communities, existing developers, potential users and so on to produce more chemical changes getting more attention on the importance of open source
and prove commercial product still can be done well with combining appropriate open source project and finally allow us all together walking on the right path.
 
Maybe there'll  a lot blames/questions/suggestions on coming bpi-r2, but I will be glad to listen to and reflect them into the MediaTek internal, and even
welcome delivering patches to me making more robust to BSP

This pretty much sums up the situation with SinoVoip. Even if you want to help them it's not possible since they're behind a wall of ignorance higher anyone could imagine. The most frustrating part is that they don't get what they do

Hi Guys,
 
I have recently been contracted to a new project where I have moved out of my comfort zone (embedded 8-bit/32-bit uC) and have started my work on a H3 based device (currently NanoPi Neo) with Armbian.
Over the course of my work I have managed to get up to speed with the basics; configuration, scripting, hardware and interfaces and device trees to a point where I can now work on the device as a proof of concept.
The work that has been contributed so-far to the armbian project is impressive as is the active and knowledgeable forum - to which I hope I can contribute.
 
One element which I cannot find an easy solution to is one of remote update. In the embedded world because your whole program/environment is loaded from flash into device ram it is very easy (if you have a device with network connectivity) to have a RPC to download and reflash new firmware - this is very useful for installations where physical access is restricted or unavailable and changes must be made to the firmware.
 
While it is possible to for example remote access (via SSH or some other means) to do system upgrades, I think a "whole-image" approach has some benefits especially when considering critical system deployments.
 
So I have been researching options that may be easily deployed into the Armbian build environment - there are quite a few options I have found (https://wiki.yoctoproject.org/wiki/System_Update), however on looking at all the options the best suited to the Armbian environment is mender.io in my opinion.
It is compatible with block devices (uSD/eMMC), compatible with uboot, has a "secure" and robust update mechanism with fallback, is open source and has agreeable licencing for integration with Armbian/Commerical Products etc.
 
The only downside is that it is currently built for integration with the Yocto project and only has a reference hardware of a Beagle Bone Black. There has been some information provided for custom target/build integration: https://mender.io/blog/porting-mender-to-a-non-yocto-build-system.
After reading this I have made some notes, but I am obviously still learning and feedback from those more experienced than I would be appreciated.
 
1) Partition Layout
At the moment the RESIZE_FS flag in the armbian build enviroment causes the rootfs partition to expand to the whole size of the available device, this can be overwritten to a fixed size at build time. Presumably with some modification to the script it could partition the device as required: https://docs.mender.io/1.0/devices/partition-layout
 
2) Go/mender Client libraries
These should be possible to be added as user-packages in the build stage?
 
3)uBoot Patches:
0001-Generic-boot-code-for-Mender.patch
0002-Integration-of-Mender-boot-code-into-U-Boot.patch
 
Should be able to be applied as user uboot patches at build stage?
 
4)Artifact creation (e.g. update images):
Can be completed with an additional post-build script using the mender artifact tool or integrated as an script in Armbian build environment.
 
I suppose my questions are:
-is there interest in such an addition of this feature into armbian?
-for the people that are well versed in the armbian build environment - is there any potential pinch points for integration?
 
 
 
 

Absolutely agree on that and was more talking about what happens in the future. In this specific case I see myself at fault since announcing to duplicate/recreate the thread and then not doing so timely. But fortunately we identified the issues quickly and those were fixed either internally or externally (thanks @Igorand Alasdair!).
 
But these issues should remind us that Armbian forum is not only used for internal discussion but also to have some impact on the outside (at least that's one of my uses, I still refuse to run my own thing/blog and try to collect knowledge here as part of a community to try to help letting the community grow).