JohnnyWednesday

Hey Armbian aficionados - it's me of 'I can confirm that sound support isn't compiled into the kernel' fame. Please don't rush me all at once, I didn't ask for this fame and glory and I've already turned to hard drugs and fast women.

Since I've got this board and I'm not entirely incompetent (open to debate) - please let me know if there's anything I can do from my end to provide you with information for your assessment.

I'm guessing from the smattering of posts I've read that I won't be encountering many fans of the manufacturers - I agree that their software practices and documentation is poor - there's basically no info on the battery connector, efficiency of the step-up, max draw etc - the barrel jack was a different size from their technical drawings (that's £1 on an adapter I'll never get back - it sits on my desk... mocking me) - I'm sceptical in regards to the simultaneous power draw of the 2-pin and 4-pin SATA power headers using the specified 2A supply  (I got a 3A for testing but I'm not ready to risk two drives just yet - definitely need to be careful in regards to lithium battery draw) and there's an unpopulated position for a cap next to the 4 pin supply on my board that's present on their pictures for the v1.1 revision of the board - I'm a little suspicious as to why it was left out in this production batch - perhaps it was determined to be superfluous but I've popped a question to support - they've been really helpful so far (just remember to throw your sentences back and forth between English and Mandarin on a translator to ensure that meaning remains intact - you get much more detailed responses when you remove the ambiguity of translation)

But all that said - it's a really great bit of kit  very well made, general IO is nippy, the mPCIe is great for development (got a lovely little mPCIe FPGA board coming for my SDR project) SATA is working (tested a an old 2 inch spindle drive - need better kit to probe bottlenecks) sound is working perfectly (when compiled in), GPIO, WAN/LAN, USB3, OTG all seem to be functioning fine (wrote 30gb of data to a flash stick on the device from a CIFS mount - calculated hashes match) - so far it's not crashed on me once - SoC gets a bit hot under load - fine with a heat sink - don't think the thermal sensor is supported yet or perhaps that's not selected for compilation either (there's a lot of MediaTek stuff in this kernel that's not enabled but a lot of it is for other MTK chips - some of it is ambiguous in description so I'm not 100% sure yet)

Waiting on support for the internal WIFI/BT - hardware video decoding isn't working or not enabled (480p mp4 ran smooth as silk at 1:1 - the moment you scale, performance bombs) - obviously no GLES on the Mali450MP4 (userspace blobs for 3.x kernels - 4.x kernel for the board - that old chestnut) - not eeeeentirely sure if the X11 driver currently used is optimal (gallium on llvmpipe reported under Xorg - will dig into that a bit more now).

I'm sure the experts here are rubbing their temples at this stage - please don't geek attack me - I'll probably cry. It'll be really pathetic and my face will be a mess - nobody wants to see that.

Anyway - if I can run any tests and what-not then please let me know - I'm fine compiling/tweaking my own distro for my needs but I'd be a lot happier with a pro distro like Armbian - if you ever deem this board a viable target that is.

Right - we have a dialogue with the vendor, we know why some people are unhappy and we know what's needed to assess the board. There's a language barrier and there are elements of documentation that have changed or are incomplete. Not every tiny thing is clear but certainly enough is clear to make a start. The vendor wants to help, they're here right now trying to. Let's stop going on about the past, things change - if they don't then I'd like an apology from Thomas for killing my grandfather in world war 2.

I've got this board, I'll answer questions to the best of my ability. It's running, it's stable, it's definitely more achievable than some boards that have been bought up in the past for Armbian.
 
The R2 uses a 12v supply with a 2.1 x 5.5 mm connector - at least a 2 amp supply is needed.  The first production batch is board revision v1.1. It has two upright SATA ports, a 4 pin power connector to the one side of the SATA ports, a 2 pin power connector between the SATA ports and a molex branded clip to hold full length mPCIe cards - mounting holes are present for half length cards - standard risers of 2mm height, 2mm width should be used for half length cards. This is what the v1.1 of the board looks like :

The WIFI/BT chip is the MT6625L - it may be the case that they used a different chip in a previous revision - I don't know, but the manual says MT6625L - the chip says MT6625L. I've searched high and low on google - I can't find AP6212 in reference to this board. If you're upset by this then please elaborate because I might be missing something obvious. The 6 pin connector for the battery appears to be a micro JST SH connector with a 1mm pin spacing. I have such plugs and they fit, I will ask the vendor for confirmation. In the meantime, here is a page where the connector I have can be purchased (http://www.hobbyrc.co.uk/jst-sh-6-pin-connectors-10mm-pin-spacing-w-150mm-wires) Here is a link to the current logical schematic for this board - https://drive.google.com/file/d/0B4PAo2nW2KfnbVZzeDJERGd2SDg/view?usp=sharing Here is a link to the current physical layout of the board - https://drive.google.com/file/d/0B4PAo2nW2KfnenRRNGhmc29IZ2c/view?usp=sharing Here is a link to the datasheet for the MT7623N - https://drive.google.com/file/d/0B_YnvHgh2rwjR3pwSzNrS1Nqdjg/view?usp=sharing If you need to know the ID of certain chips, please ask me and I'll tell you what's written on the chips I have. Here is a link to the github of the R2-BSP kernel. U-boot sources are also in this repository - https://github.com/BPI-SINOVOIP/BPI-R2-bsp Here are some patchwork links to various developers currently working on drivers/patches for Mediatek chips :
https://patchwork.kernel.org/project/LKML/list/?submitter=169671
https://patchwork.kernel.org/project/LKML/list/?submitter=13291
https://patchwork.kernel.org/project/LKML/list/?submitter=166241
https://patchwork.kernel.org/project/LKML/list/?submitter=133171
https://patchwork.kernel.org/project/linux-mediatek/list/?submitter=171503
(This list may not be exhaustive) Here is a link to the BPI-R2 section of the Banana Pi forum - http://forum.banana-pi.org/c/Banana-Pi-BPI-R2 The board is incapable of time travel, opening portals to other dimensions or fixing failed marriages. Hopefully this isn't a problem.

That was one issue with one board - Rasberry Pi had voltage issues with one of their past boards if I remember correctly - 100ma draws on the USB ports causing large voltage drops on the 5v rail?

I seem to remember millions of xboxes dying due to overheating issues - tesla's catching fire - these things happen.

Again pointing out faults in past boards isn't a reflection on new designs - with enough research I'd wager I could find design issues with at least one past board from nearly all of the established vendors.

I believe it fills a niche that nothing else currently does in that price bracket. The R1 was popular and no doubt many people here at least initially were keen to try it - the R2 packs more of a punch and it's early days.

I will return when I have more knowledge to draw upon regarding the R2 if people are keen to discuss it with me.

Yes I can, I'll also provide the output of any commands/tests you want me to run - I'm in the middle of something right now but I'll provide the logs as soon as I have time in the next few days. If required I will also be willing to provide SSH access into the R2 to yourself and anybody you trust subject to your word that you'll treat the gear and my home internet connection with respect.

I have tried a 2.5" 750GB seagate spindle drive in both SATA ports - mounted an NTFS partition, transferred multiple gigs of data both times, placed the drive back into my laptop and then calculated and compared hashes - no problem. A blue LED near the SATA ports flashed on disk activity.

This is certainly not an exhaustive test and I'm afraid I don't have two SATA+power connectors to test two drives simultaneously. I will order another for that purpose.

Yes the power-up is fine - you currently have to hold the power button down for around 10 seconds to boot the board - I may be imagining things but it seemed the length of time needed to hold the button down was shorter when I used a recompiled kernel that was smaller by around 1MB - if I wasn't imagining it then that suggests that u-boot/kernel/whatever is being loaded at this point. The spindle drive spun up during this phase.

I made one attempt to boot from the eMMC and I was unsuccessful - I may have done something wrong so I will try again for you. I am able to create partitions on the eMMC and read/write data just fine however.

I see and understand -it's definitely the MT6625L - I can't speak for the vendor but yes - that was naughty. Somebody probably saw the table, noticed it was a close match for the current status but didn't look closely enough. I doubt that action was looked upon kindly at BPi either and I certainly don't believe that such things are a reflection of the hardware design.

I like the people I've spoken to so far, they're a friendly bunch  manners and respect are very important in China - please understand that they want to help, they really do care and they'd like a good working relationship with the open source community. They are improving matters and they are aware of the problems of the past. I implore people to extend the same courtesy that is given to other vendors - I've read about endless faults and flaws with Orange boards right here on this forum - far more than anything I've seen for a Banana board - yet people that attack BPi happily defend serious flaws elsewhere.

I became convinced that people here were being paid by OPi after a couple of days of reading the hypocrisy - I can't be the only one that thinks this - things seem to be very biased - citing issues that have nothing to do with the hardware - while covering up the flaws of other vendors. This is not good for Armbian - the close association with Sunxi whom bash every banana board in the opening sentence of their wiki - while lauding the professed faults as features on other boards.

I wonder who's prominent in both the Armbian community and the sunxi community - can you think of anybody? if they're not being paid to vilify Banana then I'll eat my hat. Well I'll buy a hat and then eat it - you can pick the colour.
 
This situation and attitude is untenable - I really like Armbian, I want to work with you, contribute - I really do! but if the bias and fragile logic doesn't stop when it's obvious that concerns have been met? then I'm sorry - I'll have no choice but to fork into a new project - one that supports everything Armbian does - plus all the things they're paid not to. Yes I know it's hard work, yes I know community matters but if such bias becomes known in the world of SBCs? I won't have a problem supporting RPi, Banana - in fact I'll specifically add anything Armbian refuse to support and I and my associates are more than capable if currently less experienced - what outcome do you predict in the long term?

For my part I chose the board that best suited my requirements - which are already met by the R2 and the current state of support. It's quite unique and offers great potential given the two mPCIe (well one plus a through hole pinout that will disable one USB3 port - who doesn't like soldering?  ), GB switch/wan and so forth - yes I know specs <> functionality because the software support is critical - but if the software support is there - is this not a great board?

I'll do all I can and exhaust every option of working with Armbian that I can - that's what I really want.

i am not do development now . more than 7 years , so , i make a mistake .  i will let gary join this discuss . 
 
anymore , i not  badger with you, you can do everything if you like .  i also do banana pi ,  this is my love.  even it make you not happy , I have chosen to ignore you for more than a year.  you want me still ???
 
 

we now main working on Linux 4.4, this is our development in progress , now about issue for kernel 4.4 
 
have support :
 
support HDMI support GMAC * 5 (2 real GE ports, 1 is WAN port, another is connected to 4 LAN ports) support SATA * 2 support eMMC (support boot from eMMC) support IR support OTG support PWM (PWM1/PWM2/PWM3, PWM4 and PWM5 are not supported) support USB 3.0 * 2 support mPCIe  
issue: 
 
1：wifi  driver for MTK6625L
2：VPU&GPU 
3：MIPI driver
 
update : launcher have running success on linux 4.4 kernel ,maybe wifi will ready soon ,it is a hard work
 

 
i will let gary add this group ,and he will maybe answer more .

Tks for some Armbian devlopers' feekback and good advice that is real SBC spirit to assist Banana Pi HW and SW progress. We improve HW in order to achieve max. performance by our customers' requirement as well as developers welcome that too. 
 
Happy to hear many developers give us positive comment and would like to support R2 development. Once we have new models, we'll notice sooner.
 
 
 
 

please note below:
1, you look at all your statements, whether it's for any banana a product, how terrible it is, and why we should pay attention to someone who makes me feel sick. 
2. Look at all the statements you made on armbian BBS, and everyone thinks you are the face of armbian.I even think of you are one of orange PI member .You're out of your normal moral compass.You may never learn to respect others. 
3,note ,you are not a god for arm community.
 
PS:  i want to know , why you always attack us , what can you get or what are you want to get .
 

Unfortunately this is not the first time I hear this, but you still wasted your time in this thread, BPi M2 berry thread or almost every recent article on the cnx-software related to hardware made by Sinovoip.
 
Again, my point is that a "board bring up" thread should be started with the intention of adding support for the device, and it should consist mostly of the discussions related to the hardware, and software and documentation for this specific device.
 
Until the board in question meets the basic requirements already (somebody has a sample, all necessary documentation and sources were already released) let's keep these threads in a different format - review, discussion, speculation based on the public information, but not a "board bring up".
 
The first and third posts in this thread already have a drama regarding deleting forum posts, questioning the vendors reputation, comparison to other unrelated devices, a history lesson regarding different efforts to improve the vendor or even helping them, and the 4th post focuses on a different (completely unrelated) device, and I don't see how this can help us with bringing this device to our build system.
 
I intend to move it to the "General chit chat" section and remove the [Board Bring Up] prefix in the title.
Also BPi M2 Berry thread can be moved to the reviews subforum since you tested an actual hardware sample.
 
If/when vendor releases updated/corrected specifications it would be easy to copy-paste them into a newly created board bring up thread, but I don't have to tell you what are the chances of this happening.

I'm sorry, but why starting it in the first place? For the sole purpose of humiliating the vendor?
As I said previously, I'm against creating a "board bring up" threads without an actual intent to add support for the hardware in the nearest future. And while the M2 berry thread can be called a "quick review" because it is based on evaluating an actual hardware sample, this thread is based mostly on speculations and it contains more than 3 pages of anything but a board bring up related discussion.
The worst part of it is that a personal opinion (that at first glance can only be described as "toxicity towards a specific vendor") can be associated with the Armbian project and community as a whole, and I wouldn't be surprised if some other vendors that wanted to establish contact with us decided to not do it because they don't need a shitstorm in their direction for a couple of bad decisions made in the past.
IMO this thread belongs in the "General chit chat" section if not in the recycle bin.

1. I respect all the work done by armbian, and they do a lot of work, especially igor. I respect anyone who does anything for the open source community, and all work should be respected.I also want to work closely with armbian at Open source development, but the way must be correct.
2. All of TK's comments, I don't know where I have offended him, and you can see that his comments are full of malice and disgust, so most of them, I can only choose to ignore them.A product, especially an open source product, can't be perfected all at once, and if you try to find a reason to attack, there will be countless ways to attack, but it won't improve anything.We need all of us to do what we can to support ourselves, even if it's a little bit of a word of affirmation.Sometimes, standing and watching, not talking, is also a support.
3. I have been working on LINUX product software and hardware development for 17 years and have learned how to cooperate with the chip original factory.What I do now is try to make the chip plant open source a bit, provide as much information and technology as possible, and slowly promote the development of open source.
4. Regarding R2, I want to really understand the hardware people, understand how much work we have done, and how much effort MTK has made to support this project.That's what's going on.TK can't easily veto everything just because of the subjective judgment of his own knowledge. It's unfair.
5, we must have done many things wrong, which is a process of learning.If this process makes some people uncomfortable, I'm here to say I'm sorry.
6. For TK, he even attacks my English very bad, YES, maybe we can communicate in Chinese, rest assured, here I will not make fun of your poor Chinese.

As you wish but you're kinda proving my point by doing so. You're biased for whatever reason - after reading a year of hostility from you I even wondered if you were being paid by a competitor - probably not but for somebody that has dismissed BPi? you sure spend an awful lot of time going out of your way to drag them through the mud.

I don't believe any of the points you've raised can be seen as a logical reflection on new designs and developments - you've not had any experience with the Mediatek SoC in question - you don't own an R2 - it's impossible for you to dismiss this board on technical grounds at this stage - there's not a criticism I've ever seen you raise that couldn't be applied to companies, SoCs and boards you happily advocate.

If you don't like them and don't wish to support them? that's your prerogative but your continued attack in light of your professed leanings comes across as petty.

Did a Banana Pi steal your girlfriend?  

When things are sufficiently developed and performance of the drivers is up to a production standard  - I hope that you and the team will consider reassessing at least the R2 - I'm perfectly happy to actually do the work if you don't want to touch it.

But regardless of the respect I have for you and how much I like Armbian - if personal bias gets in the way of technical progress? then expect to be forked - it's the natural order of things.

Take care

@chwe as long as it is not banana Aldi beer...   (There is Aldi here, it does quite well)
 
There is an old saying, I feel it applies here:. "Fool me once, shame on you.  Fool me twice, shame on me."   I know for a fact I would not buy another ASUS board, if they send me one to evaluate and it turns out to be amazing, my mind could be changed.  And that is with only one bad board, imagine 3,4,5?  "Same old story, same old song and dance".
 
 
 
 

Oh believe me - I absolutely don't want the headaches and yes - the strength comes from the community most certainly. There's a lot of talented and dedicated people here!

I'd like to see support for the R2 too - I expect OpenWRT will want support the device given its nature but support requires the will,  feasibility and hardware knowledge available to draw upon.

As a side note - I used an mPCIe to PCIe extender/adapter and got an NVIDIA GTX 1070 working with the board using the binary ARM drivers (a setup I use for a laptop) -  I felt all warm and fuzzy inside.

A feat any ARM board with mPCIe/PCIe could achieve of course but I just thought that was both cool and insane - a great combination

It's not my job no but if we all followed that ethos then we'd not have open source software at all.

I think this is a very different beast in terms of support - MediaTek have been reasonably busy adding support for their various chips - there's a datasheet that's complete from a development standpoint (currently assessing the possibility of PiFM like functionality) - the switch driver is done, ethernet, USB3, IR, sound blah blah - there's full source for uboot and the kernel. Capability wise the board is nicely priced - true SATA, USB3.0, mPCIe - don't use the media features and it's a solid router platform - do use them and it's feature packed board with a built in GB switch - the perfect little ARM cluster controller for robotic projects or other such low power distributed projects (I'm using mine as the main controller for a distributed wideband SDR project - GPIO and relays controlling banks of filters - that kind of nonsense)

The hardware is good - sinovoip rightly or wrongly have slapped together a crazy little board with extensive capabilities at a good price.

I know sinovoip are terrible when it comes to communication and specs but given MediaTek have at least 4 competent developers working on kernel support and it's already progressed to an advanced stage?

This is quite the flagship for MTK and they appear to have correctly taken on the responsibility of supporting their SoCs under Linux which is more than you can say about most.

Things are different with this board - I'm not bothered about sinovoip and nobody has to get anything out of them anymore - what's already available is light years ahead of their previous efforts even though they're not responsible for basically any of it - MTK are carrying the torch.

I know there's much I don't know - in this field? people here are the experts and I deffer to your wisdom but at least from my limited perspective - I currently think I raise reasonable points.

Dear Johnny,
 
I appreciate it very much for your great effort on Banana Pi R2 development, I am the Banana Pi PM, we're working with MTK linux team for months. If you are interested to get a R2 new version sample, pls contact me (nora.sh.lee63@gmail.com). Any further advice will be welcome, we're making next version PCB this week.
 
Nora
Banana Pi PM
 
 

Hey Armbian aficionados - it's me of 'I can confirm that sound support isn't compiled into the kernel' fame. Please don't rush me all at once, I didn't ask for this fame and glory and I've already turned to hard drugs and fast women.

Since I've got this board and I'm not entirely incompetent (open to debate) - please let me know if there's anything I can do from my end to provide you with information for your assessment.

I'm guessing from the smattering of posts I've read that I won't be encountering many fans of the manufacturers - I agree that their software practices and documentation is poor - there's basically no info on the battery connector, efficiency of the step-up, max draw etc - the barrel jack was a different size from their technical drawings (that's £1 on an adapter I'll never get back - it sits on my desk... mocking me) - I'm sceptical in regards to the simultaneous power draw of the 2-pin and 4-pin SATA power headers using the specified 2A supply  (I got a 3A for testing but I'm not ready to risk two drives just yet - definitely need to be careful in regards to lithium battery draw) and there's an unpopulated position for a cap next to the 4 pin supply on my board that's present on their pictures for the v1.1 revision of the board - I'm a little suspicious as to why it was left out in this production batch - perhaps it was determined to be superfluous but I've popped a question to support - they've been really helpful so far (just remember to throw your sentences back and forth between English and Mandarin on a translator to ensure that meaning remains intact - you get much more detailed responses when you remove the ambiguity of translation)

But all that said - it's a really great bit of kit  very well made, general IO is nippy, the mPCIe is great for development (got a lovely little mPCIe FPGA board coming for my SDR project) SATA is working (tested a an old 2 inch spindle drive - need better kit to probe bottlenecks) sound is working perfectly (when compiled in), GPIO, WAN/LAN, USB3, OTG all seem to be functioning fine (wrote 30gb of data to a flash stick on the device from a CIFS mount - calculated hashes match) - so far it's not crashed on me once - SoC gets a bit hot under load - fine with a heat sink - don't think the thermal sensor is supported yet or perhaps that's not selected for compilation either (there's a lot of MediaTek stuff in this kernel that's not enabled but a lot of it is for other MTK chips - some of it is ambiguous in description so I'm not 100% sure yet)

Waiting on support for the internal WIFI/BT - hardware video decoding isn't working or not enabled (480p mp4 ran smooth as silk at 1:1 - the moment you scale, performance bombs) - obviously no GLES on the Mali450MP4 (userspace blobs for 3.x kernels - 4.x kernel for the board - that old chestnut) - not eeeeentirely sure if the X11 driver currently used is optimal (gallium on llvmpipe reported under Xorg - will dig into that a bit more now).

I'm sure the experts here are rubbing their temples at this stage - please don't geek attack me - I'll probably cry. It'll be really pathetic and my face will be a mess - nobody wants to see that.

Anyway - if I can run any tests and what-not then please let me know - I'm fine compiling/tweaking my own distro for my needs but I'd be a lot happier with a pro distro like Armbian - if you ever deem this board a viable target that is.

Maybe work on 'charles' list posted in the BPi forum:
It's clearly not your job to provide this data (team bpi never showed the willingness to work wit 'charles'), but as you noticed, lot of people's here aren't that excited to work on a sinovoip device (again). Maybe you can give them a reason to change their behaviours.
I followed quite a while the boot up thread in de BPi forum, is there now a possibility which doesn't involve more steps than build up a ikea furniture? (never thought that boot up a sbc can be so hard...)

Hey Armbian aficionados - it's me of 'I can confirm that sound support isn't compiled into the kernel' fame. Please don't rush me all at once, I didn't ask for this fame and glory and I've already turned to hard drugs and fast women.

Since I've got this board and I'm not entirely incompetent (open to debate) - please let me know if there's anything I can do from my end to provide you with information for your assessment.

I'm guessing from the smattering of posts I've read that I won't be encountering many fans of the manufacturers - I agree that their software practices and documentation is poor - there's basically no info on the battery connector, efficiency of the step-up, max draw etc - the barrel jack was a different size from their technical drawings (that's £1 on an adapter I'll never get back - it sits on my desk... mocking me) - I'm sceptical in regards to the simultaneous power draw of the 2-pin and 4-pin SATA power headers using the specified 2A supply  (I got a 3A for testing but I'm not ready to risk two drives just yet - definitely need to be careful in regards to lithium battery draw) and there's an unpopulated position for a cap next to the 4 pin supply on my board that's present on their pictures for the v1.1 revision of the board - I'm a little suspicious as to why it was left out in this production batch - perhaps it was determined to be superfluous but I've popped a question to support - they've been really helpful so far (just remember to throw your sentences back and forth between English and Mandarin on a translator to ensure that meaning remains intact - you get much more detailed responses when you remove the ambiguity of translation)

But all that said - it's a really great bit of kit  very well made, general IO is nippy, the mPCIe is great for development (got a lovely little mPCIe FPGA board coming for my SDR project) SATA is working (tested a an old 2 inch spindle drive - need better kit to probe bottlenecks) sound is working perfectly (when compiled in), GPIO, WAN/LAN, USB3, OTG all seem to be functioning fine (wrote 30gb of data to a flash stick on the device from a CIFS mount - calculated hashes match) - so far it's not crashed on me once - SoC gets a bit hot under load - fine with a heat sink - don't think the thermal sensor is supported yet or perhaps that's not selected for compilation either (there's a lot of MediaTek stuff in this kernel that's not enabled but a lot of it is for other MTK chips - some of it is ambiguous in description so I'm not 100% sure yet)

Waiting on support for the internal WIFI/BT - hardware video decoding isn't working or not enabled (480p mp4 ran smooth as silk at 1:1 - the moment you scale, performance bombs) - obviously no GLES on the Mali450MP4 (userspace blobs for 3.x kernels - 4.x kernel for the board - that old chestnut) - not eeeeentirely sure if the X11 driver currently used is optimal (gallium on llvmpipe reported under Xorg - will dig into that a bit more now).

I'm sure the experts here are rubbing their temples at this stage - please don't geek attack me - I'll probably cry. It'll be really pathetic and my face will be a mess - nobody wants to see that.

Anyway - if I can run any tests and what-not then please let me know - I'm fine compiling/tweaking my own distro for my needs but I'd be a lot happier with a pro distro like Armbian - if you ever deem this board a viable target that is.