tkaiser

Based on your original thread title and the forum you chose I'm assuming you used the nightly Xenial dev image (marked as experimental) Please be aware that according to our homepage the next major release is 4 days away: https://www.armbian.com (that said I've no idea whether this will be the case since I simply don't understand 'our' release, testing and board bring up policy). Anyway, the fix is in the repo since ages, I just added the next target to the board and enabled a new nightly build (still marked as experimental). Please check https://dl.armbian.com/nanopim1plus/nightly/ tomorrow, then a new (nightly/experimental!) build should appear. Stable Armbian releases still use the old outdated legacy kernel and as far as I know that won't change with the next release cycle since we're awaiting kernel 4.14 with a bunch of additional fixes before we release official mainline images for H3 boards.

From the official documentation https://docs.armbian.com/User-Guide_Getting-Started/#how-to-install-to-emmc-nand-sata-usb

It's just generating a new Armbian image with the (simple) fix applied. I'll do that now. @Tido please stop playing 'moderator from hell', thank you (still waiting for you splitting the two display threads you merged today)

Nah, please not. Armbian forum tried to avoid 'moderator actions' (deletion, bans) in the past and this should remain the same. And as @zador.blood.stained pointed out he mentioned an Armbian QA problem (we're talking about a stable image here). We could take this (again) as a chance to overthink release and board support policies.

In fact Igor for reasons unknown to me politely pointed @Thorsten to instructions how to build an image himself containing the fix. I don't know why he did that since users yelling in big red letters should simply be ignored.

I checked today and found that @megous is currently pretty active here too (though with an A83T tablet and different camera).

I've my Espressobin somewhere and didn't find it since weeks so I can't answer. I remember network throughput being not that great but I tested only with pretty bad settings (800 MHz, low DRAM clockspeed). I would suggest testing in parallel with iperf3 and if there you get to the maximum (~940 Mbits/sec) then file transfers might be bottlenecked maybe by a smbd process (or NFS, or whatever) maxing out a single CPU core. Different platform but also applying here: http://linux-sunxi.org/Sunxi_devices_as_NAS#Benchmarking_.2F_Identifying_bottlenecks

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.

https://forum.armbian.com/topic/4845-marvell-based-4-ports-mpci-sata-30/?do=findComment&comment=37704 Please keep in mind that we've tested there 'advanced' stuff with mPCIe SATA controllers. On the onboard SATA port EspressoBin should in a single disk configuration easily exceed 500 MB/s (or in other words: Fast enough for any HDD imaginable)

http://kaiser-edv.de/tmp/NumpU8/Armbian_5.34_Pinebook-a64_my-hacks-1.2-with-mmc3_desktop.img.xz (MD5 hash: fb55152f986680bf116f31f4061409e9) http://kaiser-edv.de/tmp/NumpU8/Armbian_5.34_Pinebook-a64_my-hacks-1.2-with-drm_desktop.img.xz (MD5 hash: e036ba00177df5fd5288ff7d96d581e9) http://kaiser-edv.de/tmp/NumpU8/Armbian_5.34_Pinebook-a64_my-hacks-1.2-with-drm_Packages.tar (MD5 hash: 0245611abf4863aafba7794aad8d6623)

I just let full desktop images with both kernel branches build (DRM as module so it would need sunxidrm being loaded anyway). So DRM is disabled by default, the higher speed MMC modes are also disabled by default so it should be save to test but obviously we need users with MMC issues

I still wonder how to proceed. His branch we're currently using on Pinebook has not been updated since 4 months, there's also outdated my-hacks-1.2-with-mmc3 and most recent my-hacks-1.2-with-drm. Has anyone here already tried switching branches in the build system? Then I realized that we got the last 3.10 LTS update recently: VERSION = 3 PATCHLEVEL = 10 SUBLEVEL = 108 EXTRAVERSION = NAME = END-OF-LIFE

Only on H2+/H3 boards (sun8i architecture) our RPi-Monitor installation routine will detect this and installs improved templates (should work with both legacy and mainline kernel, at least I added/tested this last year). No other platforms (PC2 --> H5 --> sun50i) are supported in this way, especially the background daemon collecting detailed CPU (and voltage) information isn't installed. I do not plan to change anything here since the above 'OPi-Monitor mode' was mostly implemented to let users help us supporting new boards (especially needed for the overheating Banana Pi M2+ back then). The other reason why I will not touch this is since work on Armbian got so frustrating especially the last days. My templates were uploaded to Github https://github.com/armbian/build/tree/master/packages/bsp/armbianmonitor/templates -- sun8i dev would be the best starting point.

Can you please split both threads again? IMO it's important to keep the Xunlong display separated from WaveShare and software configuration issues since Xunlong's thing targets their own boards and with legacy H3 kernel the display won't work anyway at the native resolution (it's important for future buyers to spot this problem -- Xunlong board + Xunlong display != working) This here is a software config issue with a totally different kernel. And if the WaveShare display provides correct EDID data (the Xunlong one doesn't!) then it should work with mainline u-boot/kernel flawlessly. This stuff should not be merged/mixed!

Then you might check /proc/cmdline there and contents of script.bin ('apt install sunxi-tools' then using bin2fex) Seriously? Please keep this separated since it's about two different displays that show different behaviour (up to now no one provided EDID info/compatibility of the WaveShare displays)

They provide an image for Banana Pi? Or Raspberry Pi? This is important since on Raspberry Pis the real config happens in /boot/config.txt being read by the VideoCore GPU.

http://forum.lemaker.org/thread-15430-1-1.html

And it will remain like this since why fixing the hardware description even if told already multiple times: https://github.com/BPI-SINOVOIP/BPI-files/blob/c4bdb2b5d928042c5f592fafd4796f4b9f24e229/others/armbian/build/config/fex/bananapim2zero.fex#L741-L742 This (an 'Armbian build' with wrong settings) is the direct result of you trying what @Tido and me tried for more than 2 years now.

This is what I was telling you already. H2+ on this TV box and H2+ on OPi Zero are obviously the same, Ethernet MAC and PHY live inside the SoC so there are NO differences to expect other than a mechanical issue (MagJack or cable broken, this is easy to spot with iperf3 as already suggested)

@Lion Wang and @Nora Lee: can you please comment on why you combine Micro USB for DC-IN on your devices with a SATA power port and sell even an adapter cable for 2.5" HDDs?

Huh? Those Banana boards are all designed to create the impression that SATA HDDs can be powered by the board. At least that's how @Lion Wang designed this board back then and he even repeated this 'design' this year with Banana Pi M2 Berry: Micro USB for DC-IN, SATA power connector on the PCB, knowing that this will cause trouble for an awful lot of his customers. Why shouldn't users not expect that this works? And why do we as Armbian users do here peer-to-peer support for boards that were designed poorly in a deliberate way? Do we as Armbian project have also a responsibility to save users from buying stuff that can't work properly since as soon as Armbian supports a board it could be considered a recommendation?

Did you read what has been written just one post above? It's up to users of the device taking care of it since obviously TV box manufactuers don't care about such stuff. Is there a wiki page? Has a user started to provide DT modifications? I don't think so. You could use iperf3 but should be aware that there can't be hardware related networking differences between OPi Zero and this box since the whole network functionality lives inside H2+ and only the external MagJack can make a difference. With Fast Ethernet also trace lengths on the PCB don't matter so if you get network issues with same software you're most probably already talking about defective hardware -- which wouldn't be a surprise especially given that the box is now on sale. I never understood why people expect quality hardware from dirt cheap TV boxes.

What is going on here? Which fixes and improvements are you talking about? As already said multiple times adding support for this Zero thingie could have happened in less than an hour months ago if the vendor would be willing to fix his most serious issue (the 'don't give a shit about correct information' attitude caused obviously by someone seriously retarded doing the 'technical documentation' job and censoring in their forum. This is nothing new, they know this since ever -- funnily in the meantime this also affects resellers since they also specify this Banana Zero thingie wrong, not even the physical dimensions are advertised correctly) Here at Armbian we have (or had? Has this changed? When and why?) a policy to NOT support Raspberry Pi and that applies to lame Raspberry Pi clones like this one as well: https://forum.armbian.com/topic/483-support-of-raspberry-pi/ -- the reason is obvious: we can neither afford to deal with clueless RPi users nor would it make any sense. With this BPi M2 Zero thingie it would be even worse since BPi M2 Zero is totally incompatible to any Raspberry Pi so why would anyone right in his mind want to deal with fooled customers who thought they bought an RPi compatible clone that is none (explained many times in this thread already). All you could get is a 'community supported config'. I had three files open in my editor since months already (thank you @chwe for reminding me when I started to look into this, it's really already months and not weeks), all that was missing is the 'don't give a shit about correct information' vendor telling us how and in which way they implemented voltage regulation. This here happened one week ago: https://forum.armbian.com/topic/4801-banana-pi-zero/?do=findComment&comment=42458 -- instead of providing the needed information @Lion Wang chose to remain silent. I had PL01 already in Armbian's bananapim2zero.fex variant just waiting that stupidity/ignorance might settle down a bit and the board vendor starts to support his own hardware. But then @lvmc kindly asked me to stop supporting this board and so I deleted bananapim2zero.fex and bananapim2zero.csc. What should happen now? Yes, I wasted my time already dealing with this infamous hardware vendor another time. Yes, you could do your projects already on this hardware if you wouldn't have asked me to throw away the work already done. Yes, Raspberry Pi clones won't be supported officially by Armbian (or otherwise Armbian needs to redefine itself from a volunteer project trying to support a variety of interesting ARM boards in the best way possible to a support project for clueless people -- why and how should this happen? Who wants to pay for this?). What should happen now? @Tido: Can you please check the link to Banana forum here: https://forum.armbian.com/topic/971-quick-review-of-banana-pi-m2/?do=findComment&comment=7596 (that was the thread where users discovered that BPi M2+ only runs with 1.0 and not 1.2 GHz and CPU cores were killed immediately and where you and I explained a lot to @Lion Wang and @Nora Lee how/why they should use better settings (I provided for free but they ignored it as usual). It seems they did not only delete all of my posts but also the whole thread with a lot of interesting insights and knowledge shared. You're moderator over there so can you restore the deleted contents?

Have you compared 'ulimit -n' on your host and running inside chroot?

As a reference: mPCIe specification. USB2 is part of the interface.