pfeerick reacted to tkaiser in Armbian 5.30 on Pine64 really wants a battery to work
Obviously not, it's just that nobody uses a power button since you need a soldering iron for. Simple workaround: don't use the power button, most probably not so simple fix: dive into BSP power management code
If the problem also occurs with other 'distros' then it might be worth to compare DT and kernel config. But zero priority of course since you're the only Armbian user around having a power button soldered (or connected to EXP header)
pfeerick reacted to zador.blood.stained in MMC: No card present error on Allwinner boards
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:
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.
pfeerick got a reaction from StuxNet in Improve 'Support over Forum' situation
@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?
pfeerick reacted to StuxNet in Problem with UART on Orange PI Zero
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
pfeerick reacted to Igor in Unable to create bootable SDcard
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.
pfeerick reacted to tkaiser in ROCK64
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
pfeerick reacted to dkmax in OrangePi Zero high temperature?
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.
pfeerick reacted to armbinator in orange pi pc - which USB sata bridge
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.
Serial for my terminal
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.
pfeerick reacted to chwe in New OPi Zero - Yet another high temperature issue...
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).
pfeerick reacted to zador.blood.stained in Quick Pinebook Preview / Review
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.
pfeerick reacted to Hamish in Orange Pi Zero /4.11.0-sun8i/ wlan0 is gone
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?
pfeerick reacted to Igor in Improve 'Support over Forum' situation
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.
pfeerick reacted to chwe in Improve 'Support over Forum' situation
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
pfeerick reacted to tkaiser in Banana Pi R2
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)
pfeerick got a reaction from tkaiser in Improve 'Support over Forum' situation
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...
pfeerick reacted to TonyMac32 in Improve 'Support over Forum' situation
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.
pfeerick reacted to Igor in Improve 'Support over Forum' situation
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"
@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.
pfeerick reacted to sean.wang in Banana Pi R2
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
pfeerick reacted to kjn260 in OTA Imaging / Remote Update / mender.io
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?
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?