We care not only performance but also long term running stability to protect users under safer computing environment.
We care not only performance but also long term running stability to protect users under safer computing environment.
@Tido Plz don’t laugh too hard at the comment above. I can’t even hold back my laugh.
Customers are carrying thousands goods, product’s stability is priority, as their application is not over clocking. As to power users who should have ability to DIY for reworking or speed up performance by themselves but impact major shipments.
Nora, please start listening and click on this link from above:
These are benchmarks containing results for your boards and the closest competitors. The last 3 would be interesting if you would start to listen and not defending your messy software ‘development style’ with lies.
If you don’t fix your THS settings then all people who start benchmarking the BPi M2+ will get very low benchmark scores, will publish them and will simply recommend the other H3 based alternatives since they’re way faster. Your market gets smaller by not fixing the problems. The problems are called ‘killing CPU cores instead of throttling’ and ‘understanding max cpufreq and THS’.
All this is just caused since your engineers seem to need some help understanding the THS settings. You are free to take the settings from Armbian (we and the linux-sunxi community do a lot of research on thermal issues and longevity). Just look at https://github.com/BPI-SINOVOIP/BPI-M2P-bsp/blob/master/sunxi-pack/chips/sun8iw7p1/configs/BPI_M2P_1080P/sys_config.fex#L383-L419 then adopt Armbian settings and you’re done.
If it would be true what you tell (caring about longevity) then you would have used a programmable voltage regulator like on the Orange Pis to lower VDD_CPUX voltage on demand. You didn’t. Instead you advertise the BPi M2+ as being capable of running at 1.2 GHz (true but not with your settings) and your engineers use the wrong settings so that in reality 1008 MHz are the maximum. So if you wouldn’t again telling lies you would either advertise the board as being capable of 1.0GHz or fix the settings.
But instead just another lame excuse. And you still provide wrong ‘specs’ on the pages here (the H3 has only one led and is not CAN capable). It’s such a mess, if you just would set up processes that prevent spreading wrong information, start to think about the accuracy of information, listen to customers/community and stop spreading lies again and again your whole hardware business could enlarge a lot.
BTW: The aforementioned Armbian settings will not be available any longer if you provide bold Armbian rip-offs like you do here: BPI-M2+ new image:How to build armbian for bpi-m2+
You are free to use any of our sources and experiences. You’re free to link to armbian.com from your site. You’re free to use our build system (I suggested that to you again and again almost a year ago when the forum was at bananapi.com instead). But DO NOT create Armbian rip-offs. An Armbian image is genuine and has not been touched by any human being but was created from scratch. Your images are always manipulated with pre-created users and maybe other manipulations as well. Don’t call this Armbian and provide google drive links for. If you don’t stop providing Armbian rip-offs NOW my next Armbian commit will remove all support for BPi M2+
Fixed that for you…can you see the difference?
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.
I provide adoptions of RPi-Monitor for all of your Bananas except the M2 since a long time: http://www.cnx-software.com/2016/03/17/rpi-monitor-is-a-web-based-remote-monitor-for-arm-development-boards-such-as-raspberry-pi-and-orange-pi/#comments
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.
so , please keep your base demeanour.
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.
the time spent on excuses is better invested in improving your software and reading what’s already been written (for example above in this thread).
Xunlong’s settings for H3 (known to be wrong)
Now your settings (I already referenced them above but you think it’s better to ignore this):
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.
We at Armbian do test our OS images, you don’t. The tools to do so are also provided above (for free and with an installer that requires ZERO knowledge). All what’s needed is to use them. And then start to test your settings. Might then look like this: http://forum.armbian.com/index.php/topic/1005-alternative-h3-legacy-kernel/?p=7700
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)
hey AGAIN…more insults
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!
so you want we sotp this board.
so just let armbian and orxxxx pi to do H3.??? even you can do a hardware , with armbian + hardware???
if not ,so BPI-M2+ just add a option for user .
you say we 99% copy orxxxx pi, and BPI-M2+ CPU perfomance is the best bad , you always catch our “issue”, and attack us .
why not just do a support ,and let user to choose .
we also very like armbian ,we ever not to say " so bad ” to armbian.
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.
no, tkaiser , wifi driver will update soon. mikey working hard on it. once ready , we will update to github.
BT 4.0, now just working on android ,linux still have issue.
I thought you were going to do us all a favour and go away?