Firstly, tks for your effort on BPI SW development, secondly tks for clear explanation to point out root cause on THS setting. I’ll deliver this issue to our SW RD who may need time to fix it. If our RD can’t conquer it, pls DO help us, we really need SW experts to join and discuss with us to improve BPI performance.
Currently, our SW RDs are busy doing devices SW development such as camera, WIFI and BT etc. can work fine, that’s why we released Armbian image for developers who can test camera, WIFI and BT functions then. If devices SW are not ready, thus customers will think that HW has problems to return goods, we’ll get lots of complaints and trouble, except we need to do validation and certification, above devices SW must be ready before summit samples to Labs.
As to Orange Pi who adopts different components with ours, we won’t on board components without ROHS and UL certified, BPI not only insist better components quality but also follow HH manufacturing stations to keep quality and stability, each BPI board must work fine before delivery. We’ll evaluate voltage regulator based on better quality and certified before we use it.
Hope above conditions, you can understand our situation, I’ll appreciate it very much! As our BPI belongs to open source, we need all of you to join and give us good advice. We also expect all developers will love to use BPI and enjoy development.
You should start to monitor the behaviour of your OS images before releasing them. You are engineers and seem not to care how fast the chips are clocked, how hot they get, how much CPU cores are shut down when running a test and so on. And this is all known since we had the whole discussion not once but many times back (especially with M3) already.
You’re welcomed to use Open Source Software made by the community (and think about contributing back) and should also stop to misuse the term Open Source Hardware since you don’t act like a OSHW manufacturer at all.
Remember the time with BPi R1 when we the community had to reverse engineer the board’s power scheme just to find out how to enable the SATA port? And also how to fix the powering problems since Micro USB is simply crap when you need more than a few mA? If you would’ve at least released the schematics back then and not weeks ago it would have saved us community members days of work to get your job done and your users months of waiting to use the board as advertised.
Remember the times with BPi M2 when this happened again? No WiFi on some images, no GBit Ethernet on the others? Some hardware functions still not working since you simply never released correct hardware descriptions? I had to buy an M2 back then and send it to one of the linux-sunxi experts in Netherlands on my own costs just to get a working device tree file that can be used with mainline kernel now. If you would produce Open Source Hardware and release informations early all this would have happened months earlier.
Remember the time with BPi M3 when you tested the board with a sane DC-IN solution internally (no problems!) just to replace it with crappy Micro USB prior to sending out the production batches? If you would’ve listened to the community and relied on the countless already available information on this topic and if you would’ve done some monitoring (see above) this would’ve never happened.
And now the same happens with M2+ again and you ask us to start contributing?
Please don’t overstress this ‘Open Source’ term all the time and start to respect your customers and the community who does the real work (I do not refer that much to Armbian here but to linux-sunxi)
for micro USB power , you can test our newest image , it will let you know , with micro USB ,also working fine. real reason is allwinner AXP is only for PAD， so AXP limited power . AXP parameter need try and try
for we not any code,allwinner just answer us , this chip is for PAD，can not support any more , so we need time to fixed.
instead of telling stories can you please assist and look at M3 PCB revision 1.2 and confirm whether FB7 is present or not? Highly appreciated!
Seems you tried to fix the AXP issue in hardware between 1.1 and 1.2. Here’s another one of your customers desperately waiting for help: Difference between BPI M3 version
I know that your preferred way to deal with customer questions is normally just to answer “Everything fine, will upload on Github” but please have a look at the PCB and help one of your customers. Thx a lot!
I already asked our SW RDs to listen your advice and improved SW sooner. But we can’t release image too late to impact other developers on SW development, validation and EMI certifying schedule. If our image is not mature such as few functions can’t work, we’ll release those images on “FORUM” but “DOWNLOAD” page.
As to R1 came from anther PM project, I need to ask why he released sch so late.
About M2 kernel v3.3 is too old, we took a long time to solve WIFI and GbE issues, Allwinner is not willing to speed up on M2 assistance due to its SOC profit is nothing and they prefer to allocate resource on H3. Sorry about that!
Regarding M3 from DC-IN changed to micro USB connector due to some developers request it, however, we already changed back, current mass production goods on board DC-IN connector and ship them out.
Your good advice on M2+, we try to improve but need your help to tell us how to do THS setting? About VGA regulator, we r surveying it which need ROHS & UL certified before we adopt it.
Woohoo. Exactly the same with exactly the same consequences: Wrong/slow. All this is known since a long time since Allwinner’s defaults in this area are crap and this applies to the BSPs for A83T (M3), M2+ (H3) and also A64. If you would start to respect the community and listen to them you would know all this.
And I already wrote several times where you find more apppropriate THS settings that are based on days of work done by many linux-sunxi community members. But you still prefer to ignore everything. Time to finally give up. The last paragraph here sums it up (I’m pretty confident you won’t look into).
The only recommendation left is simply to stay away from your OS images and use the community’s where available (no support for M3 --> don’t buy it)
You are right about Armbian code is better but more complicated! However, we studied Allwinner datasheet about THS, currently M2+ performance is better about 4 cores are running fine as well as audio bug is solved!
We’ll improve performance and release new images sooner.
Thx for confirmation that it’s useless to make recommendations.
Do some REAL testing (use cpuburn-a7 for example to get the idea what’s wrong with both the fixed voltage regulator on M2+ and Allwinner’s THS settings) and do some REAL monitoring (Ubuntu’s System Monitor is crap since it doesn’t show throttling/cpufreq behaviour, the graphs are 100% meaningless and if you would REALLY test your OS images you would know that)
Ubuntu’s System Monitor will show that the system is more busy (50% CPU utilisation when running at 504 MHz) when it’s less busy in reality (compared to 49% CPU utilisation when CPU clockspeed is at 1200 MHz). So it’s always 100% misleading on any system that implements cpufreq scaling especially on SBCs. Using this tool is proof enough that you don’t care about what’s REALLY happening. Good luck with this approach!
thx for the confirmation that you did not even looked into it. It’s not about code it’s just about settings. It’s not about Armbian it’s about Allwinner’s H3 THS defaults (that you chose without thinking and that are known to be wrong over half a year) vs. community derived THS settings.
You could benefit from this work if you would start to look into it and then do copy&paste of a few lines of settings (Click on the following link! Just do it! Yes, the most important part is the so called cooler_table you won’t see otherwise! This makes the difference. Just click on it. Or let your devs do. Please don’t try to please people that post critical stuff but try to improve the situation instead):
Instead: Lame excuses about complicated ‘code’ where it’s just about trying out a few settings and checking them (again: Installation of RPi-Monitor is easy, just start reading this thread, clicking on the links provided and trying it out)
look they are working with Allwinners information, ie they are using the suppliers recommended specs…if they knowingly deviate from those specs they may violate any arrangement they have with them regarding returns, assurances of quality. guarantee of supply, etc…They most likely have a legal contract that insists they stay within certain operating parameters…they probably also have an NDA that prevents them saying that outright.
The best solution is to ask them to discuss this with Allwinner, if Allwinner agree that your Settings provide stable and reliable conditions they may be able to make the changes, right now, as it stands its very clear they cannot. But you can, so feel free to recommend your settings to the community.
LOL, you’re really too funny. Keep having fun in this little world and don’t try to escape from here since then you would realize what’s really going on. The same boring discussion regarding H3 THS settings has already happened over at Orange Pi forums half a year ago, the same discussion regarding A83T (M3 – pretty similar situation) has happened before you joined in here and the same boring discussion has been already happened regarding A64 (BSP settings for all three SoCs pretty similar). M2+ is just another boring H3 board. But since you believe at banana-pi.org the wheel has been invented you’ll never realize how funny all your assumptions are.
Don’t put away the blinkers! Reality could be irritating!
It’s like talking with a wall. But since you don’t even try to understand what this is all about it’s useless to continue.
We currently support M2+ in Armbian, if you stop violating the GPL (holding back WiFi drivers) we will continue to do so. The THS settings you use in your OS images are not the best and will lead to very low benchmark scores and your market share will get smaller since especially people like Michael Larabel from phoronix.com always tests with manufacturer provided OS images. This was just a friendly reminder that you should try to fix this before it’s too late since then you get the same low benchmark scores the Orange Pis got since they also used Allwinner’s broken defaults (you should really start to read what’s written here in THIS THREAD, start from the beginning again, click on the links, look at the graphs and numbers)
And it seems you don’t mind or don’t read what’s written in the posts your answering to or don’t understand. Keep on suffering.
One final word since it happened again and again. You already know that you can’t rely on Allwinner’s defaults. Remember the problem with all your OS images for M3 back then? Simple user processes getting killed? Since you used a setting from Allwinner that the linux-sunxi community identified long time ago as being broken: BPI-M3 new image:ArchLinuxARM Lite for BPI-M3 (20151209)
It would save you so much time and hassles if you would start to accept the community’s role (linux-sunxi – not Armbian). But it’s still up to you to ignore this.
Regarding the issue this thread was initially about. As soon as you will provide your distributors (eg. LoveRPi who did the tests you linked to in your 1st post here) with BPi M2+ Michael Larabel from Phoronix will get a M2+ in his hands and will test it with your Raspbian. And if you didn’t fix the THS settings until then it will just look like it did with Orange Pi One (also limited dvfs/cpufreq behaviour): http://www.phoronix.com/scan.php?page=article&item=orange-pi-one&num=2
Please don’t do Phoronix the favour to tell the world another sunxi board would be slow crap. Please fix the issue before 3rd parties start benchmarking and publish the results. It’s easy and… already done. Take Armbian’s settings, take our sun8i-corekeeper.sh service and you’re done. And when Michael Larabel starts testing the M2+ will even look better than the Orange Pis he tested before since they also used the broken Allwinner defaults.
And now please read the 2nd post in this thread again.