JohnnyWednesday

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.

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.

Or is the official stance of the Armbian team : "do things exactly how we want or not only will we not bother to support your boards, we'll go out of our way to insult your company at every turn, on our forums, your forums and anywhere else that even mentions your products"? If that's the case? then that's your prerogative but please let me know so I can spend the next week making sure that everybody else knows it too.

My apologies - you're quite right, forgive me. I got frustrated and I shouldn't have. I just feel that refusing to even consider it on grounds completely unrelated to the design and resources available? is unreasonable and stinks of petty bias. So the company wasn't the model of open source perfection in the past - so what? neither is almost every tech company in the world - pretty sure Linux runs on Intel chips. They're working hard and have really improved matters - isn't that what people wanted? I see no technical reason why this board shouldn't be assessed. It's been released, we have schematics, data sheet, source. You've got a developer right here with the board willing to provide information and work on support. So somebody please, with all the sincerity I can muster - tell me what's holding this up without bringing up the past.

Very fair points! well we have the schematics so there's no problem then, is there?

I have no desire to - the idea is to reflect tkaiser's attitude - he's done nothing but insult the vendor for months, even going as far as to criticising their grasp of English - that's not just insulting - it's borderline racist.

OK let's be clear - board schematics are released (we don't need them to develop software - please explain why you need them and please link us to all the posts you've made about other vendors not releasing schematics) the data sheet for the SoC is released (not enough for you? I thought you knew what you were doing) Today this - today that - Mediatek have been contributing updates/patches for nearly a year - or are you unable to use google? You know what? don't waste your time - I'll do the work - you go throw your toys out of the pram while the professionals get on with the job. I don't want to work with somebody with such petty and atrocious attitudes as yours. You're an embarrassment to this project - you're single handily saying to all vendors out there "Hey we're Armbian, we'll treat you like s**t unless you bow down to tkaiser's every little whim" There's kernel sources, uboot sources, datasheet, board schematics - tkaiser - you're so full of crap I'm surprised it's not leaking out of your ears.

"Folks, be assured that I won't monitor this thread any more." Sounds like you're the one full of s**t to me

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

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

Thank you - it's a pleasure to be here - I shall try my best to be objective and helpful when I can be. Opinions are almost impossible to change when formed so no I won't try and change them in that regard - if I make cases then it shall be from a technical perspective for review by your good selves. I'll be working a lot with these boards over the next few months to quite a low level. Have a few mPCIe FPGA boards coming that I'm using for an SDR project - sexy little things I shall take my leave for now - thanks again all for taking the time to discuss with me

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.

And yes sorry - those performance figures are not good - obviously the SoC is capable of better. The drivers have received numerous patches that are not present in the current preview kernel - I will assess the source and patches and do a bit of debugging when I have the time. If you're enjoying the discussion then I shall return when I know more so we can talk numbers. Thanks again for taking the time to reply

Thank you for taking the time to write such a detailed reply - I do understand your points and I've read many of your posts over the past week or so, you've been very unhappy with them for over a year and the wiki entries on their boards (here) generally start with criticism that seems to be lacking from entries for other boards - so I know I'm fighting an uphill battle here. Your points are valid - to be fully open would require such things but isn't it the case that almost all of the other SBCs are at least partially closed too? even Raspberry? and what good are the PCB schematics in terms of development? we have the datasheet for the SoC - we know the chips and the ports and it's not like we could take a multi-layered PCB with tiny surface mount components and make any substantial changes any way - isn't that the case for any SBC? what would you do with a schematic in a different format? fabricate your own board? we're developers and system adminstrators - the datasheet is what we care about and we've got it. Intel isn't open - AMD isn't open - GPU vendors - all sorts - yet open source software exists for them all - even ARM themselves whom could *easily* provide a few Mali userspace blobs for a few kernel revisions? refuse to do so - it's clear that this is deliberate. Where's the beef with them? board vendors could buy the DDK and compile blobs for their users - did Orange do this? where's their criticism? I know you're a very intelligent person and I would deffer to you when it came to technical criticism but short of quoting early performance scores on the board - all you've done is attack the companies practices. If that's what's important then lets start with Apple no? ARM themselves? By all means have a go at the person that maintains the documentation - it needs to be better - have a go at poor translations - they could sort that. But to cherry pick a few points that are unrelated to the board design isn't a logical way to assess the boards themselves. I couldn't design something like the R2 or any of the other boards and I suspect that you couldn't either or you'd certainly have produced the ideal device by now given the amount of experience you have with SBCs. My point being is that SBCs aren't for amateurs - if somebody doesn't know what they're doing then they should get an RPi - hook up some LEDs and smile to themselves - then put it in the draw and forget about it like a significant number of people do. They're development boards - we're developers - we don't need our hands held - so why complain that nobody is holding them? I'm sure I could go on google now and quote far worse performance figures and note all kinds of things I believe are missing or wrong with other boards - Orange Pi in particular. It's not like I didn't do my research first. I respect you all and I think Armbian is fantastic - I would very much like to see support for more Banana boards and I would be more than happy to help in any way I can. But this is open source software and I'm a very experienced developer - I work on the kernel too amongst other things. If political motivations and biases are preventing this team from working on a perfectly valid target then I will simply fork Armbian and do it myself. I'm sorry but I fail to see any technical reason why you'd fail to support a board that's even closer to mainline than half the boards you currently do. I mean no disrespect but if you can't add support for an ARM SBC with advanced kernel support, open source uboot, kernel and a full datasheet? then I struggle to believe that's for technical reasons.

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.