TonyMac32

I have thrown myself out of the forums at least 6 times today by clicking on the "Armbian" banner image.  

Well, after upgrading to artful, I discovered that the official FFMPEG project pulled a patch provided by LongChair which enable MPP support in FFMPEG directly...
 
So I now need to recompile FFMPEG... On Ubuntu... I'll try to recompile ffmpeg with just h264 support for now.

The nightly you uploaded, and linked is working.  Thank you.

root@P3X-422:~# kubectl get po --all-namespaces
NAMESPACE     NAME                              READY     STATUS             RESTARTS   AGE
default       hypriot-5747f86854-4c25v          1/1       Running            0          4h
default       hypriot-5747f86854-9nk45          1/1       Running            0          4h
default       hypriot-5747f86854-dvsj7          1/1       Running            0          4h
kube-system   etcd-p3x-422                      1/1       Running            0          5h
kube-system   kube-apiserver-p3x-422            1/1       Running            0          5h
kube-system   kube-controller-manager-p3x-422   1/1       Running            0          5h
kube-system   kube-dns-66ffd5c588-cfsft         3/3       Running   0        5h
kube-system   kube-flannel-ds-867wz             2/2       Running            0          5h
kube-system   kube-flannel-ds-hbt8v             2/2       Running            0          5h
kube-system   kube-flannel-ds-vxdj2             2/2       Running            0          5h
kube-system   kube-proxy-f4f6n                  1/1       Running            0          5h
kube-system   kube-proxy-gmtpq                  1/1       Running            0          5h
kube-system   kube-proxy-sfm4k                  1/1       Running            0          5h
kube-system   kube-scheduler-p3x-422            1/1       Running            0          5h

I had a meeting today and all except last two posts, since not existing at the time, were checked. In general, I was more or less presentation our pain with existing ideas how to solve this and that. Wordpress stays since they are familiar and since the problem is not there. Data will go into temp database (from GitHub config files as it comes now) that any possible search/filtering is possible, used or not. UX redesign has top priority than graphics tuneup and then backstage improvements. Estimated due ... hardly this year. Rather slow and good.
 
Now waiting for the first prototype, then arguing further.

Update on HC2: Mass production will start in approx. 2 weeks. HC2 will be fully software compatible (same SoC, SATA bridge and even same schematics design except 12V power rails for a 3.5" HDD added on HC2). The hardware changes should be obvious: 12V DC-IN and much larger enclosure/heatsink to fit the size of 3.5" HDDs.

Le Potato Dev updated with 4.14 Libretech patchset, thanks to @Neil Armstrong . 
 
Anyone willing please build/test, the intention is this become the "next" image.

#TinkerFire 

Good, please tell me if an issue appears with this patchset ! I cleaned it up because it was insane !

The current image is a "testing" release for that reason.  Also, 4.13 is an "in progress" support situation for the meson-gxl, I'm running 4.14 with the current patchset through some testing to move NEXT to it.

http://www.x-powers.com/en.php/Info/product_list/cat_id/31
 
The AXP8036 seems a lot like the Realtek USB audio on the Tinker Board, it doesn't exist.  ;-)  (I assume it physically does, but datasheets seem impossible)
 
Does not look like there is any hope for voltage scaling however, that is a fixed regulator.
 
Hmmm...

 
Is this supposed to go back to VDD-CPUFB on the SoC?  That would be my guess, otherwise why not tie them together?
 
There are fuses on a lot of boards, the RPi's, Le Potato, the Khadas VIM, it is one of the hazards of bypassing the factory connector (even if it is u-USB).  They're always self-resetting thermal polyfuses, although it's always extremely important to understand how long it takes one of those things to "blow".  for instance, if that's a 2 Amp "hold" fuse like the Littlefuse 1812L series, it will take 8 amps a maximum of 2 seconds to make it go fully open.  In that example it also has a series resistance of 20 to 70 m-ohms. 
 
I don't see a header for DC-in, but that's not surprising.
 

Also remember these TV boxes are not usually cooled very well, so they go into thermal throttling quickly.
 
As you'll see reading below, the closed-source Amlogic bootloader blobs may also have a say in the quality of your experience, they seem to vary significantly.  I'm experimenting with a TV box right now which runs horribly no matter what "ROM" I put on it, so I'm starting to suspect the bootloader.  If the Khadas VIM was a Bugatti Veyron, the mini M8S II is currently a Volkswagen Rabbit with a dead cylinder and bad fuel...
 
 

Not to me. USB hub by itself is a very light load but it results in a measurable voltage drop on DC IN. And I have a couple of USB hubs that can reboot a microUSB powered RPi if you connect them - most likely because of a filtering capacitor on the input causing a large enough current spike.

I tested this out, I can control those pins.  Is the issue that the SPI driver can show up and smash everything?  And if so, is this possible accidentally, or would it have to be triggered by an unsuspecting user?
 
Side note for @tkaiser I was getting about 160-190 mA consumption (varied widely) on the vendor image, with the nightly Armbian I get about 150.
 
 

Feedback and requests appreciated, obviously I don't have infinite resources and time, but ideas are always good.
 
Also, there is a test image specifically for the Duo, so far so good.  https://www.armbian.com/nanopi-duo/

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

Any reason you're not using 4.13?  4.14 is still a Dev release, it's not fully patched.

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

I have to disagree with a lot of points on that FAQ since I'm monitoring some other forums and see complaints towards Armbian from a perspective of an inexperienced user.
For people that want to use CSI cameras, C or Python GPIO libraries that have questionable (at best) hardware detection by parsing /proc/cpuinfo or want to run Kodi or Android Armbian won't be an answer. For poor souls that bought an OPi 2G-IOT or its lighter variant Armbian won't be an answer either. For boards that (currently) have rather poor mainline support (OPi Win/Win+) Armbian may have more problems than vendor's images.
Please keep in mind that an average person may not care about security or performance optimizations but may want specific software features that won't work on our images out of the box.

I have a RP1 2 with HifiBerry Dac+ Pro  Running Volumio, so yes, I understand.  I also put together an MPD player on a NanoPi AIR with the FriendlyARM DAC, I believe that blog entry is linked on the FriendlyARM site.  (Very simple, and used Armbian before I started contributing)  My only thought was, looking at the pile of SBC's I have, the RPi is the most expensive one I would ever use that way.  Now, others may wholly disagree, which I can completely understand.  Also, having better multimedia support on Armbian?  A definite win.
 
I picked up a Khadas VIM, by far the best vendor Android distro I've used so far.  No heat sink though out of the box is a concern, no matter how cool the S905X seems to run. (I'm too cheap to buy a Pro)

Maybe someone interested in the direction of Volumio platform Amlogic S9xxx (S905 S905X S912). At the same time, savvy users can tell the direction, to fix the problem with sound through HDMI in this way.
 
https://volumio.org/forum/volumio-for-box-amlogic-s905-s905x-s912-t8028.html

https://github.com/BPI-SINOVOIP/BPI-files/commit/f4a6651ae5cd4f5ebb2fba5101454fcabfedd2d5
 
MIKEY have update it.

To stop wasting my and other's time on this boring 'issue' here a final summary:
Close to unbelievable but after another 'evil tkaiser attacking us' event today the hardware vendor 'fixed' voltage regulation description. Just to remind you: this file has to be correct in the first place, there's no excuse for such wrong information there, it's simply the hardware vendor describing how the board works. So now that PL01 is used for voltage regulation (now in conflict with another active PL01 entry for s_rsb_sda -- good luck!) only all gmac* entries are still wrong and cooler_table not using the 912 MHz OPP is most probably a great recipe for poor performance when overheating occurs. So in case someone from SinoVoip wants to fix their pseudo Armbian build it would be wise to fix the fex first since afterwards Armbian's h3consumption tool can work without issues (today not due to still wrong fex file) On their Gitbook pages the size of M2 Zero increased by 5mm (now at least this most basic info is correct), most of the other 'information' is still sparse, wrong, missing, bogus. But fortunately the hardware is still too small on their product page and of course soon everywhere around the globe in advertisements and product listings since all resellers use the wrong dimensions they've been provided with back in July. So anyone interested in this board running with the outdated legacy kernel: chances are great that you get a working OS image over at bananapi.org (soon). As a reminder: Armbian follows the policy to not officially support Raspberry Pi boards which of course also applies to deliberately compatible looking but mostly incompatible RPi clones like this M2 Zero here (we don't want to see this forum/community dying when RPi users or fooled M2 Zero customers arrive) Armbian also tries to phase out legacy kernel support (3.4.113 which is not supported any longer since over half a year now). CSI/camera support with mainline kernel is still WiP so when switching from legacy to mainline camera functionality will also be missing. Again no reason to officially support such a device Third 'problem': dishonest advertising. Nowhere is mentioned by the vendor that M2 Zero is totally incompatible to RPi cameras (which is something average buyers expect) and RPi software (which is something clueless buyers expect from something that mimics the look of an RPi Zero and is said to run 'Raspberry Pi image'). There's really no reason for us here wasting our spare time with support efforts like this: https://forum.armbian.com/topic/5579-power-off-with-hdd-over-active-hub/?do=findComment&comment=43088  
Exactly. @Lion Wang's problem is that he wants to sell hardware and his company earned a very negative reputation over the last years (believing this would be caused only by evil people outside and not related to their internal and pretty real problems). That's something where some idiots here at Armbian could help working for him in their spare time and doing his software and support work.
 
@lvmc has the problem that he wants to use this BPi board with his own camera modules. Should work now so let's please stop babbling about community and so on.
 
We have the problem that even if we wanted to support SinoVoip products they don't allow us. They refuse to cooperate, do not provide correct hardware descriptions, do not listen to community, delete community knowledge, ignore(d) even patches they got for free just due to ignorance, ignorance, ignorance.
 
A few people here suggested to give SinoVoip a final chance. I support this. The problem is... I and others are dealing with Banana madness now in the 3rd year. We have heard that so often that it simply got too boring. So let's step back now, give them 6 months of time to show that they're willing to improve, deal with their internal ignorance/stupidity problems and then let's have a look again.
 
In the meantime it would be great if people would stop asking us for anything Banana related. Thank you.
 
 

Right, my comment on eMMC is purely about reducing/removing interconnects, the primary failure point in most systems.  Speed is secondary in such embedded systems.  I would ideally use the SD card only for data storage, for instance data logging/etc.  

I have to agree with@chwe on this, I am in the automotive industry, not only would I be fired for such documentation of a design, there could be federal charges brought against myself and my company ending with me in jail if incorrect documentation could be linked to a failure or unexpected behaviour. Not to mention losing all OEM business, etc.

It is not such an impossible task to document properly. But attacking anyone who points out factual errors in your paperwork causes animosity and people will refuse to support these products. Trust me, I am no stranger to poor documentation. But at least for the ASUS Tinker Board the problem is missing documentation, not incorrect documentation. Were it incorrect I would have immediately recommended Armbian drop all support for the board, no matter how popular it may be.

Now, as an engineer I am accustomed to dealing with suppliers. In this situation, that is your role. You are a supplier of single board computers to a marketplace. That gives the user (customer) a certain amount of agency over you, the customer can require correct documentation, the customer can provide negative feedback and refuse to use your product. As a supplier it is your duty to provide a product the customer wants. In the single board computer world that is more than a board, it is also the means to use it. Your product cannot simply be defined as a board, your product is a board and a manual. And that manual needs to make it possible to use the board. The manual includes complete and correct schematics, diagrams of all exposed connections, a basic board support package (device tree or equivalent, vendor-specific drivers, uboot if not mainline, etc)

As you have pointed out, most SBC suppliers in this market have flaws. But I have seen none that are outright confrontational and generally unprofessional. Do you think I don't have customers and coworkers just as disagreeable as Thomas is capable of being? Of course I do, many far worse actually. Do I respond the way you do? No, or else I would not have a job. Do I always agree with the magnitude and force of Thomas's quick anger? No. But I certainly understand it. I actually refused to reply several times during this thread because I felt my feedback would be less than professional. However, my reserved tone has apparently caused some confusion which I felt it necessary to clear up.

I want to see a good competition between board makers, and the obvious benefits that come with it. So to that end I want to see you succeed. However, for that to happen you need to also compete in documentation. You have said you will, but be aware I will not engage in any development, privately or for Armbian, until there is some proof of that effort. A big step would be addressing the concerns you have heard here so many times that I'm even tired of reading about them.

[/rant]

Sent from my Pixel using Tapatalk

This is now different:
root@tinkerboard:/home/tido/myy-s/mali# LD_LIBRARY_PATH=. glmark2-es2-drm Error: eglGetDisplay() failed with error: 0x3000 Error: eglGetDisplay() failed with error: 0x3000 Error: main: Could not initialize canvas Error: Failed to restore original CRTC: -13 I try after  chvt 1, et voila:
root@tinkerboard:/home/tido/myy-s/mali# LD_LIBRARY_PATH=. glmark2-es2-drm ======================================================= glmark2 2017.07 ======================================================= OpenGL Information GL_VENDOR: ARM GL_RENDERER: Mali-T760 GL_VERSION: OpenGL ES 3.2 v1.r14p0-01rel0-git(966ed26).810f535757d8c9adaaa72f5da29c688e ======================================================= [build] use-vbo=false: FPS: 55 FrameTime: 18.182 ms [build] use-vbo=true: FPS: 55 FrameTime: 18.182 ms [texture] texture-filter=nearest: FPS: 55 FrameTime: 18.182 ms [texture] texture-filter=linear: FPS: 55 FrameTime: 18.182 ms [texture] texture-filter=mipmap: FPS: 55 FrameTime: 18.182 ms [shading] shading=gouraud: FPS: 55 FrameTime: 18.182 ms [shading] shading=blinn-phong-inf: FPS: 55 FrameTime: 18.182 ms [shading] shading=phong: FPS: 55 FrameTime: 18.182 ms [shading] shading=cel: FPS: 55 FrameTime: 18.182 ms [bump] bump-render=high-poly: FPS: 55 FrameTime: 18.182 ms [bump] bump-render=normals: FPS: 55 FrameTime: 18.182 ms [bump] bump-render=height: FPS: 55 FrameTime: 18.182 ms [effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 55 FrameTime: 18.182 ms [effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 50 FrameTime: 20.000 ms [pulsar] light=false:quads=5:texture=false: FPS: 55 FrameTime: 18.182 ms [desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 27 FrameTime: 37.037 ms [desktop] effect=shadow:windows=4: FPS: 55 FrameTime: 18.182 ms [buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 55 FrameTime: 18.182 ms [buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 55 FrameTime: 18.182 ms [buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 55 FrameTime: 18.182 ms [ideas] speed=duration: FPS: 55 FrameTime: 18.182 ms [jellyfish] <default>: FPS: 55 FrameTime: 18.182 ms [terrain] <default>: FPS: 13 FrameTime: 76.923 ms [shadow] <default>: FPS: 55 FrameTime: 18.182 ms [refract] <default>: FPS: 27 FrameTime: 37.037 ms [conditionals] fragment-steps=0:vertex-steps=0: FPS: 55 FrameTime: 18.182 ms [conditionals] fragment-steps=5:vertex-steps=0: FPS: 55 FrameTime: 18.182 ms [conditionals] fragment-steps=0:vertex-steps=5: FPS: 55 FrameTime: 18.182 ms [function] fragment-complexity=low:fragment-steps=5: FPS: 55 FrameTime: 18.182 ms [function] fragment-complexity=medium:fragment-steps=5: FPS: 55 FrameTime: 18.182 ms [loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 55 FrameTime: 18.182 ms [loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 55 FrameTime: 18.182 ms [loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 55 FrameTime: 18.182 ms ======================================================= glmark2 Score: 51 =======================================================  
Wow, in  htop  CPU is close to Zero !
Temperature: around 50° C  steady.
It does need more RAM than before, but not more than 352