Banana Pi R2

[tkaiser]

Within the next few weeks or months a new Banana Pi model called BPI-R2 will be available. The average buyer of this board thinks of the R2 being an upgrade of BPi-R1 (also known as Lamobo R1) and will also think that software support situation will be the same (trusting in Armbian, Bananian and OpenWRT here). R2 is NOT an upgrade, it's just an entirely different device using an MediaTek MT7623N SoC instead of an Allwinner chip as all the other boards of this vendor.

 

What do we know about the hardware:

 

• Quad core Cortex-A7 'up to 1.3Ghz' (no performance numbers known, no info about real clockspeeds, currently cpufreq seems still to be broken: '/cpus/cpu@0 missing clock-frequency')
• 2 GB DDR3 DRAM (no clockspeeds known but boot log talks about '1333004 KHz')
• 4 GbE LAN ports and 1 WAN port, the SoC is connected to a MTK7530 switch IC (5PHY+7MAC+GMII+RGMII, it seems WAN and LAN parts are implemented using two independent [T]RGMII connections so most probably the R2 will not suffer from R1' s most severe design flaw), no real performance information available, currently random MAC address issue -- link to official documentation
• 1 or maybe even 2 SATA ports by default (they're not able to answer such simple questions) provided by an ASM1062 connected to one of the three PCIe 2.0 lanes (ASM1062 is able to use 2 PCIe lanes!), there's a 2 pin JST XH 2.5mm header to provide 5V for one disk, there should also be a 4 pin header called CON3 providing 5V/12V/GND/GND most probably for a 3.5" disk, available performance numbers horribly low while test methodology sucked and provided numbers too high -- link to official documentation
• 1 mPCIe slot exposing another PCIe 2.0 lane but missing the USB2 data lines (in other words: a lot of mPCIe cards won't work with this mPCIe slot if they expect USB on pins 36 & 38 of the connector as it's normally the case) -- link to official documentation
• 2 USB 3.0 receptacles (one of the two ports -- not known which one -- can be deactivated to be able to use the 3rd PCIe lane available on solder holes, no information about USB3 performance available, no information how and where you would have to switch between USB3 and PCIe -- link to official documentation
• Mali450MP4 GPU, MediaTek video engine (no idea about Linux driver support for both), HDMI + MIPI DSI LCD connector -- link to random words and sentences being the try to provide 'technical documentation'
• Audio capabilities: it's either 'Audio in/out: N/A' or 'Audio outputs: HDMI, I2S audio' (go figure)
• 8GB eMMC (with an 'upgrade' option for 16G/32G/64G that will require a BGA solder station)
• There's Wi-Fi and BT onboard. Bluetooth is called 'BT4.1 BLE', Wi-Fi is sometimes 802.11 a/b/g/n 2.4GHz/5GHz (then the chip providing it is called MT6625L) and other times only 802.11/b/g/n (missing 802.11a, then the chip is called MTK6625L, something that does not exist of course). If it's really MT6625L then it's a '4-in-1 connectivity RF' chip (also featuring FM and GPS receiver and offering 2-antenna and 3-antenna configurations), FM/GPS are nowhere mentioned and a single antenna means dual band 1T1R Wi-Fi so performance will suck anyway. Every cheap 2T2R USB dongle will do a better job -- link to official documentation
• Powering: They're talking about a PoE option (not documented of course), there's a DC-IN barrel jack labeled with 12V/2A here and there, the dimensions of the jack are are either 4.4/1.6 mm or '5.5mm' or if you scroll down a bit the power connector mutated to Micro USB: 'at the very left of the bottom edge is the USB power connector. Plug in a regulated power supply that is rated at 5V ±5% / 2000mA (or 2A). Any number bigger than 700 mA will also work' -- so depending on which part of their 'technical documentation' you read it's 3 totally different connectors and 2 different supply voltages (hey, is there a difference between 12V/2A and 5V/0.7A?!). Then there's also a battery connector for '3.7V lithium battery' (LiPo? Li-ion?), they chose a pin-out nobody else is using, there are no batteries available (not even from them), they can not name the connector (the same as on all their newer boards -- see here for the 'funny' try to get such basic information out of them) so it really doesn't matter that they also aren't able to answer such simple questions as wheter a connected 2.5" disk will still be spinning if the board runs from battery or not.

 

If you look through the above links to 'official documentation' you might get immediately that the person assembling words and sentences in broken english doesn't care about correctness. It must be a copy&paste monkey not able to get why correct information might matter. So where do we have the information from?

 

There was $someone present in Banana Pi forum for the last few months posting as 'charles' who asked maybe 30 times for schematics to be released (yesterday they delivered after being kicked in the ass for a very long time) and who poked the @sinovoip support muppet again and again to release at least a boot log to see what happens (background info: this vendor has a horrible history always fucking up hardware details but they still don't get it that if they would start to open their designs early their community members could help them avoiding mistakes). 15 days ago the @sinovoip muppet delivered boot logs, 'charles' wasted his time to look through, provided an analysis and asked some questions (not answered as usual): scroll to the last archived post here: http://archive.is/Z1Z8m

 

Where's that post now? Deleted. The thread had 90 posts the day before yesterday now it's 20 less, many of them containing a lot of technical details provided by me (this 'charles' guy). Today after censorship happened it looks like this https://archive.is/c6I5z

 

Since they worked that hard on their reputation from now on I will call these guys only 'brain damaged retards' (BDR) any more since that's the best way to describe their behaviour and inability to improve on most basic things (if you ever looked through FriendlyELEC wiki or Olimex github repos you know what I mean)

 

So when looking at the above hardware 'information' we find some facts and a lot of contradicting BS (see powering for example). What else do we know? Pricing of this board is said to be around $85 (usually they talk about lower numbers first and then sell the stuff for more later but this board is already listed for €100 in ALLNET's local shop (including VAT so the $85 seem to be realistic this time)

 

We also know that such multi-purpose devices combining router/firewall functionality with a graphics stack is really stupid (you don't insanely enlarge the attack surface of a router/firewall by running proprietary graphics crap most probably needing a lot of BLOBs on it)! It's not a 64-bit ARM platform so there's also no easy way to benefit from virtualization (but to be honest: you simply don't want to run a proprietary graphics stack on anything that should be secure, that's just plain stupid)

 

We also know that MediaTek unlike in the past is currently opening themselves, their vendor kernel for this board is a 4.4.70 currently and they're also busy supporting their own hardware upstream. It might get interesting in 2018

 

So what are the potential problems with this board wrt Armbian support for it?

 

• People expect R2 being an R1 upgrade not aware that this is a totally different device and those BDR not having any software skills (they throw at their users what they got from the SoC vendors or what they could get from community) so based on their experiences with R1 potential R2 customers simply expect everything to work perfectly from the beginning totally ignoring what a shit show R1 software support was in the beginning (mostly due to BDR simply all the time behaving like brain damaged retards, not releasing R1 schematics for a whole year, not able to provide any real information but at the same time constantly lying about 'everything working fine')
• Still no u-boot and kernel sources released (we don't know whether we ever get them, the BDR are notorious liars but fortunately most of their lies are already archived)
• The BDR suffer from a general inability to understand the meaning of 'open source'. They lie constantly about their hardware being 'open source' while at the same time they fail to provide even correct schematics (and you have to waste hours of your life kicking their ass constantly to get schematics released timely). Obviously they think 'open source' is not about them opening their sources but that they get free software (free as in 'free beer') from all around without the need to steal it since available 'for free'.
• The BDR don't support their own products (just look through their forums), they don't answer support questions, they don't provide correct information, they do not correct documentation errors even if been told multiple times so even most simple stuff like getting any important information will be PITA (they don't consider this being a problem since suffering from Dunning-Kruger syndrome). In the meantime they also started to censor information/criticism in their forum.
• User expectations are most probably way too high since almost all people who will buy this board won't do some research prior to that

 

 

Edited August 16, 2017 by tkaiser
Prepare to move to chit chat or bin. Ignorance/stupidity sucks too much.

[y52]

Hello,

I am quite enthusiastic about the hardware-built features, like network acceleration, QoS and ipsec in this SOC. and I was looking for the siilar hardware at a reasonable price for quite a while.

Anyway,  I do agree (and my proper past experience also proved it), BPI's reputation could be restrictive for a buying decision.

Is there any other alternative vendor building his board around the MediaTek MT7623N SoC ?

Will you build an image for that board?

Regards,

Serge

[tkaiser]

6 hours ago, y52 said:

Will you build an image for that board?

 

Given the vendors' behaviour you must also behave like a brain damaged retard to start working on this board. Really: I had to kick their ass 30 times for them to release schematics, I had to ask maybe 10 times for a simple boot log. The person releasing this information unwillingly thinks such behaviour (asking for BASICS) would be offensive since 'wait and see', the same person is obviously too stupid to realize that their 'technical documentation' is none. They must improve in this area first and a lot (IMO they must try to get the retarded Dunning-Kruger guys out of their way which might be a bit problematic).

 

Little censorship update: http://forum.banana-pi.org/t/banana-pi-bpi-r2-open-source-smart-router-with-mtk-7623n-design/2697

 

This thread had 90 comments two days ago, yesterday it was 69, today it's 82 (it's all archived). Since 3 new posts are there only 11 of my posts are missing and the ones that re-appeared are partially edited. This is still censorship. And the censoring people don't get what they do since they suffer from this problem https://www.youtube.com/watch?v=wvVPdyYeaQU

 

It's now some of us trying for almost 2.5 years helping the brain damaged retards to improve. We fix their mistakes (but they hinder us helping them since they don't provide the information community would need), we tell them how to improve (release early, release often, provide specs/schematics, start to care about technical documentation) but they simply don't give a shit. It's such an insane ammount of efforts to get schematics or boot log while at the same time their 'technical documentation' is only a joke since totally fucked up copy&paste weirdness so you never know if you spot there some piece of real information by accident or it's just a copy&paste leftover from somewhere else.

 

Please remember that with the R1 it was not possible to get SATA functionality since the brain damaged retards simply had no idea what has to be switched on. They refused to release schematic so community members had to reverse engineer all this stuff to get such bascis like a SATA disk spinning up: http://web.archive.org/web/20150810090335/http://bananapi.com:80/index.php/forum/general/391-why-the-sata-disk-doesnt-work-on-bpi-r1?start=6#1262 (they shut this 1st forum down in the meantime but it's all archived, especially the many lies they were telling their customers at the same time)

 

The most basic requirements for starting to work on any new product from them would be

• Stop 'copy&paste gone wrong', hire a technical writer able to generate 'technical documentation'. Provide information instead of random BS, correct mistakes immediately if you get informed of (wrong VDD_CPUX value in BPi M2+ schematic, 2 x uart2 in BPi M2 Ultra schematic -- is this a problem? Yes. Does it get fixed? No)
• Release early, release often. If you have sources then open them. Without having to be asked 30 times and all the time responding like a drunken parrot 'we do all work now, all driver fine, when ready we github'. They lied simply way too often to believe them any more. If there are sources let's see them NOW.
• Cooperate with community instead of ignoring community. They provide for their new R40/V40 boards a smelly 3.10.65 kernel that is outdated 2.5 years now and contains various security vulnerabilities. Community fixed this immediately, so all they had to do get up to latest 3.10LTS version was merging commits into their Github repo (but they didn't since too stupid/lazy/ignorant/busy/whatever). Next step: Daniel even sent all his fixes as one large pull request so all they have to do is to press the 'merge pull request' button on Github (this may take a less talented person maybe 1 second?). His first PR got ignored for 5 weeks, he sent a new one with 1 fix that would bring their kernel up to most recent 3.10.106 fixing tons of security issues, let's see how long they'll ignore community TRYING TO HELP THEM this time)
• Stop lying about 'Open Source Hardware', a vendor being too stupid to release correct schematics and has to be kicked constantly to release these documents at least timely does no OSHW. I've sent them this link multiple times (there's a section in Chinese too): https://www.oshwa.org/definition/

As soon as they fix those 4 simple problems above I believe it starts to make some sense to look at their actual products again. But then we should still have in mind that we're dealing with a vendor doing evil advertising (the specs they sent out for their BPi M2 Ultra for example are wrong multiple times so once there is an Armbian image using real values -- CPU clocked up to 1.2 GHz and not 1.5GHz -- we have to deal with stupid customers blaming Armbian to be broken since too slow. I can't speak about the R2 for obvious reasons: since the brain damaged retards still successfully hinder us getting real information about this hardware)

 

 

 

[tkaiser]

OMFG: To illustrate at which insanely low level these brain damaged retards fail: http://forum.banana-pi.org/t/bpi-m2-ultra-bpi-m2-berry-github/3430

 

They make a forum post mentioning a Github repo for 2 of their other devices. This is the repo I mentioned above with an outdated 3.10.65 kernel where they ignore that they would need to spend only one single second to merge a perfect pull request to update from 3.10.65 to 3.10.106 (sitting there and waiting since weeks). At the same time they ignore this pull request they put a link to this repo in their forum. Why?

 

Since they mention another Github repo from one of their users suffering from instability issues: https://github.com/facat/BPI-M2U-bsp1 -- this is just their repo cloned with one single commit added: https://github.com/facat/BPI-M2U-bsp/commit/dff5ffe35dc22b2904993b0441c6cf6dd54efd0f -- the commit message is 'Tweak voltage and frequency of ram to solve instability issue.' and that describes the whole problem. They sell this M2 Ultra board since half a year, their forums are full of users complaining about instabilities and community speculates since a long time that this might be caused by DRAM settings.

 

The brain damaged retards don't give a shit about anything, especially not users having problems with their products. So as usual community has to do the research, starts to read available specifications/documents (after wasting huge amounts of time and efforts kicking their butts to even get this stuff) and comes up with some potential fixes: http://forum.banana-pi.org/t/banana-pi-bpi-m2-ultra-bpi-m2-berry-new-image-2017-05-25-raspbian-jessie-preview3-bpi-m2u-sd-emmc-img/3306/11

 

So the obvious fix is improving DRAM settings or at least explore this and start to test. But what do they? Nothing, just hide somewhere in their forum a link to yet another cloned github repo containing the fix they don't apply to their own repo to roll it out with OS images. I really don't know how to not call people who behave this way brain damaged retards. You can't even help them because they don't get what's going on around.

[y52]

Given the rotten Vendor's practice, it is probably worth looking for another hardware solution for the router.

Is there any other alternative vendor building his board around the MediaTek MT7623N SoC ? Could your prompt any?

[Igor]

24 minutes ago, y52 said:

Is there any other alternative vendor building his board around the MediaTek MT7623N SoC ?

 

https://wikidevi.com/wiki/MediaTek

There is one router board based on similar (but I guess different enough) chip, but it's also not very well supported.
 

There are (only) few ARM based NAS / router boards which are good enough to consider dealing with: Clearfog pro, base and upcoming Espressobin. Serious (open source oriented) vendors would stay away from Mediatek chips in first place.

[pfeerick]

BDR is an understatement. You were jumping up and down a bit there now 'Charles', but still, they shouldn't be publicly talking about this sort of stuff if they're not willing to put up the numbers and performance data. And as you said, calling it open source is just a bad joke on the community... open source is not just creating a new repo on GitHub! Sheesh! I'm glad I never bought into the whole Banana board thing now... I stuck with the Raspberry Pi for all it's faults, and then deliberately went to the Orange Pi Zero know its faults thanks to the sunxi and Armbian documentation because of it's size and price.  I certainly won't be recommending this or any other Banana board after seeing their level of support and foresight in involving the community so they don't screw up yet another (potentially) good idea/design. 

[tkaiser]

14 minutes ago, y52 said:

Is there any other alternative vendor building his board around the MediaTek MT7623N SoC ?

 

I would better move with this over to CNX to focus here on most basic requirements that have to be met before evaluating whether we want to support R2 or not (really, those 4 problems above have to be fixed first, then evaluation can start. And as long as the brain damaged retards do not open kernel/u-boot sources they claim to have there's not even a need to waste a single thought on this)

 

The m8989 guy over there seems to be from MediaTek, maybe he can share some insights. The Geekforce board also mentioned there failed on Indiegogo a while ago but maybe MTK also explored to cooperate with more reputable hardware vendors. At least I've the feeling that we're currently seeing MTK opening themselves. 

[y52]

I looked into  Clearfog pro, but I would wish at least 2GB RAM (if not more) to run other applications conveniently. I also looked into Espressobin, ARMADA 8040 Community Board and BeagleBoard-X15 ARM Cortex-A15, which are horribly expensive.

Compared to the named above, BPI-R2 offers an interesting alternative, But I do agree with you, that the lack of a stable OS and support from the vendor will diminish all the advantages to nothing.

[tkaiser]

34 minutes ago, pfeerick said:

open source is not just creating a new repo on GitHub!

 

That they ignore the meaning of 'open source' (or maybe simply don't understand what this means) is only part of the problem.

 

The people who try to help those brain damaged retards now for over 2 years still know what a shit show situation with 'the predecessor' Lamobo R1 was: you couldn't use a SATA disk, you couldn't use the network switch, there was not a single usable OS image and documenation was totally lacking (details with sources -- someone has my post unhidden and I don't think they'll delete my post another time). You could not make any use of this paperweight in the beginning and it took community unnecessarily long to fix all their stupid mistakes since they did not only not cooperate but were actively sabotaging our efforts (schematics have been released a year after the product went to market).

 

We know about MTK that (just until recently?) you didn't get sources from them unless you signed an NDA (preventing you from sharing/opening the sources) and these NDAs are pretty expensive.

 

Given the great reputation of this vendor, the amazing history of fails and their documented willingness to cheat on you as much as they can: why should we believe them they will open up sources? That's one of the most basic requirements to be able to just evaluate whether we want to invest time and efforts on this device or not.

 

But they do not even get why opening sources is important. Same with their understanding of 'documentation'. If I look today through the results of their drunken copy&paste monkey sitting on his keyboard and biting into the mouse (considering this 'writing technical documentation') then depending on which part of this 'documentation' I consult I get R2 power requirements that read either 12V/2A, 5V/2A or even just 5V/700mA and the power connector is either 5.5/2.1mm barrel, 4.4/1.6mm barrel or Micro USB. And it would take you insane amounts of time and efforts to get this information corrected since between you spotting the obvious mistake and their 'technical documentation' a brain damaged retard is sitting preventing any improvements.

 

Do we want to support devices where it's hard to get even most basic required information? Where technical documentation is just wrong all the times and will never get fixed?

 

Especially if we compare with other hardware vendors who don't behave like retards all day long. FriendlyELEC for example releases a new piece of hardware. Usually their engineers at the same time update the device's wiki page with schematics already released and of course version history. It takes just a single public complaint and their CEO writes you an email asking for details. You show them numbers, explain shortly what UAS is and why that matters, they phase out the old product and within 4 weeks there's a new and improved one.

 

You explain to FriendlyELEC people shortly why they should drop support for shitty old Allwinner kernels and use mainline kernel instead, CEO understands immediately that he doesn't understand details (not affected by Dunning-Kruger!), so their kernel dev is in CC:, it's easy to convince him to focus on mainline kernel and how to get there (just a few emails between Icenowy, me and them). In parallel you write the CEO that their kernel dev needs some time so please no pressure on him and days later we're here: https://github.com/friendlyarm/linux/tree/sunxi-4.11.y (still not perfect, but everything happens in the open, even 'community peer review' works as it should)

 

That's the difference between board vendors who respect and cooperate with community and able to learn/improve and brain damaged retards that do not even understand how horribly they actively hinder community to help them.

[chwe]

6 hours ago, tkaiser said:

There was $someone present in Banana Pi forum for the last few months posting as 'charles' who asked maybe 30 times for schematics to be released (yesterday they delivered after being kicked in the ass for a very long time) and who poked the @sinovoip support muppet again and again to release at least a boot log to see what happens

but you're still their Nr.1  (sry for the off-topic)

 

IMO it 'sounds' like a nice product from the product page, so a lot of server ideas will come up by various users. I'm not really interested in server applications on a SBC and my knowledge on this field is more than limited (I'm more the IoT intrested guy, than the server guy). But my main question is, compared to boards that are still on market, is there really a benefit compared to other boards on hardware side? Imagine every thing will work properly on software side. Will the comunity have a (real) benefit compared to other boards? Since it seems a lot of work to get this board to work (SoC without that much community support in the past etc.), I think weighting the benefits compared to the workload should be kept in mind.

[pfeerick]

And you wonder why the user couldn't be faulted for plugging in a 12v 2A PSU into a product that has a 5v 700ma requirements :-P I smell lots of burning boards and refunds in the air! Confusion to be had all around. You'd think they'd know better now... tkaiser is not to be messed with... listen to him or all hell will break loose... :-P And it's not like you're doing it to for fun or are sadistically inclined (much!)... you're just trying to tell them how stupid a mistake they're making before they can fix it and are committed on the production run and the mere mortal users (like me) get to enjoy the lemon and whinge at you lazy developers! 

 

Back to the OT, my  insignificant *vote* is hell no... let them suffer :-P I like the idea of the board, but not the companies tactics. Boycott them FWIW until they see sense.  

[tkaiser]

2 minutes ago, chwe said:

my main question is, compared to boards that are still on market, is there really a benefit compared to other boards on hardware side?

 

Thanks for the question, let's forget partially about the software side and the inability of brain damaged retards to provide information, sources, whatever.

 

As @y52already mentioned the SoC has some specific hardware features that sound nice: 'network acceleration, QoS and ipsec', so given this stuff is useable the device could serve as nice router, VPN or NAT appliance (doing specific stuff on special engines keeping the CPU cores free for other stuff). Whether this is possible or not we simply don't know yet since the brain damaged retards do not provide sources. They do not even test such important stuff since IMO they have not the slightest idea why they're doing this product (I believe MTK got in touch with them since they already sold such a 'smart home router' thingie -- the lame R1 fail -- and thought they can benefit from some expertise here or just a market ready to receive something considered an upgrade which is totally incompatible in reality).

 

In other words: since the vendor himself shows not having any idea what this product would be used for later (surely not running a Raspbian PIXEL desktop) the first thing we have to ask for is real numbers: http://forum.banana-pi.org/t/banana-pi-bpi-r2-open-source-smart-router-with-mtk-7623n-design/2697/24 (of course they're not able to answer such questions since being brain damaged retards that do not even get why someone might ask these questions)

 

This thing is advertised as 'open source smart router' encouraging users to use it for several purposes at once: firewall, router, WiFi access point, NAS, media center.

 

Let's look at stuff individually now:

• firewall/router: No idea about throughput numbers (NAT, complex and simple firewall rules, VPN numbers), it's not even confirmed that the device can be used in this mode at all. All they were able to show within the last 6 months was a simple boot log full of problems and a great lack of understanding (MTK has a reference design lying around since ages, they could've provided numbers already but since between them and interested customers are brain damaged retards sitting...)
• WiFi access point: 2.4GHz/5GHz 802.11n with 1TR1, go figure. Performance is shitty anyway unless you sacrifice the mPCIe slot for another mPCIe MIMO capable card (don't try to use combined cards with BT, the USB pins 36/38 aren't connected so mPCIe cards wanting to make use of the usual USB2 data lines available on the mPCIe connector won't work here!)
• NAS: they chose the cheapest option possible: ASM106x connected to a single PCIe 2.0 lane. Performance will be ok-ish as long as a single HDD is used, you'll run in troubles with 2 disks unless you apply speficic quirks (I mentioned that already in their forum but the post got censored since we're dealing here with brain damaged retards and not responsible vendors)
• media center: specs sound nice, GPU sounds somewhat beefy, we have not the slightest idea what will work within Linux since normally all this stuff is only supported in Android. Besides that you must be either really clueless or extremely stupid to run a graphics stack with BLOBs on a device dedicated to security functions. No one right in his mind adds complexity to a device acting as firewall/router especially not something complex like a graphics stack!)

As it's also documented over there their average customers have not the slightest idea about all those problems and issues, are perfectly fine being told 'wait and see' over and over again and consider R2 being an R1 upgrade so software support the same as today for R1 (which is only due to linux-sunxi and other communities around Allwinner doing all the work fighting against vendor stupidity at the same time while there is still NO community around MTK)

[tkaiser]

40 minutes ago, pfeerick said:

And you wonder why the user couldn't be faulted for plugging in a 12v 2A PSU into a product that has a 5v 700ma requirements :-P

 

That's not really a problem. Even if their drunken copy&paste monkey responsible for this nonsense collected on Gitbook is able to write 6 different powering options here and there anyone will get that it's 12V/2A with the usual 5.5/2.1mm barrel plug. It will only be annoying for those who order the R2 together with their usual PSU (4.4/1.6mm barrel plug and wrong voltage) since then they can throw the PSU away (but hey, since Sinovoip sold something someone at least made some money!).

 

They're also talking about a 'PoE option' (Power over Ethernet -- not documented since... why?) and according to schematic PHY0 (that's the WAN port combined with external Magnetics) can be used for that combined with an optional 'PoE' module (active so full GbE can be used). Two more questions immediately come to my mind:

• If the above 'specs' of 12V/2A are real then we're clearly not talking about PoE (IEEE 802.3af, limited to ~13W max in reality) but PoE+ instead (IEEE 802.3at, limited to ~22W in reality)
• If the PoE+ option can only be used with the WAN port what topologies do they have in mind? 'Simple' PoE+ injectors are fucking expensive, the injector has to be placed where the other end of the WAN cable will be inserted (modem? Gbit modem? WTF?). That's just brain damaged.

 

[sean.wang]

I am expected to see Armbian running on mt7623n soc/bpi-r2 board.  

I have brought it with buildroot +  4.12 rc1 kernel with some dts pending patches in linux-mediatek tree.  

I will continue to add support to/maintain MT7623n and bpi-r2 board (of course, i mean it upstream).

 

But for upstream drivers, There is still some driver can't get support like hdmi, bt and wifi.  

For those temporary solutions, they should be able to be found though sinovoip 4.4 tree. 

[zador.blood.stained]

25 minutes ago, sean.wang said:

I am expected to see Armbian running on mt7623n soc/bpi-r2 board.  

I have brought it with buildroot +  4.12 rc1 kernel with some dts pending patches in linux-mediatek tree.  

I will continue to add support to/maintain MT7623n and bpi-r2 board (of course, i mean it upstream).

First, let me make a guess and say that you are representing Mediatek here. Then - welcome.

 

Second, to summarize and rephrase @tkaiser's quite emotinal posts in this thread:

Armbian is not about building OS images for any available board (that we can get in our hands), it's about level of support that we try to provide to our users. This level of support depends on the level of support the board maker can provide to the community (including the Armbian team). 

Also when deciding to support a board, we are trying to evaluate different factors, including software support status (kernel, u-boot, additional libraries), quality of documentation, board pricing compared to similar devices on the market, etc.

MT7623N can be a good SoC for a NAS or a router board, it can even be very good if it will have competitive pricing for board makers and good software support from the SoC vendor. But here it's up to the board maker (sinovoip) to make a good use of all SoC features, to provide correct documentation (like board schematics, PCB size and position of mounting holes), to advertise the board to their end users properly by releasing correct specifications, to support their end users by releasing good enough software images. Will all of this happen? Judging by the previous boards released by them, higly unlikely.

 

Will there be Armbian images for boards based on Mediatek SoCs? Possible.

Will there be official supported Armbian images for the Banana Pi R2? Probably not, unless this board doesn't have any design flaws and gets full mainline support before it is too late.

[tkaiser]

21 hours ago, sean.wang said:

I will continue to add support to/maintain MT7623n and bpi-r2 board (of course, i mean it upstream).

 

Welcome here! Just looked through your commits and it's really great seeing MTK become commited to open source in the meantime and how far you already got!

 

MT7623 hardware features sound great (is there something like the 'MT7623N Datasheet for Development Board' available for MT7623A too?) and I'm really looking forward to devices based on MT7623N/MT7623A from reputable board makers hopefully soon.

 

Wrt Banana Pi R2 unfortunately it's challenging. You chose to cooperate with a partner here who has a horrible history: not releasing sources, not releasing schematics (timely), providing insufficient/incorrect information (no one right in his mind would call this abstruse copy&paste mess 'technical documentation'), advertising their products with wrong specs (numbers too high), not supporting their own products responsibly, not cooperating with open source community (even ignoring every try to help, see their reluctance to merge pull requests above who would fix tons of security issues on another device, or fix stability issues and so on) and most importantly their inability to even realize these problems (an unbelievable high level of ignorance, that's most probably their main problem).

 

This could all be problems of the past but as you can see clearly it's not. All of the above still applies, Sinovoip fails at unbelievable low levels and just recently they crossed a red line and censored in their forum posts they found to be 'useless' (eg. the only one analyzing R2's boot log and giving some hints). In the meantime they stepped a bit back and reverted their censorship partially but the whole situation is still a mess and just inacceptable. Almost all parts of open source community simple gave up on them and only a few people still try hard to help them (even if they're too ignorant to realize this).

 

You know better than anyone else that MTK has not the best reputation in open source circles based on the past (no sources available, NDA required and so on). And while I highly appreciate MTK opening themselves now and becoming part of the open source world all your efforts are at risk! Soon your first open source dedicated board will available. The board maker you cooperate here has obviously no clues what people want to do later with your device (otherwise they would test network and storage performance and so on and focus on reasonable use cases and not moronically try to use this board as a 'Desktop Linux' thingie). And all of the above listed problems unfortunately still apply in 2017, it's only needed to read through this thread: http://forum.banana-pi.org/t/banana-pi-bpi-r2-open-source-smart-router-with-mtk-7623n-design/2697 (at the time of this writing still 11 posts of mine censored/hidden).

 

Soon all of the above will also be associated with MTK and your open source efforts if you don't step in now. I already fear the first R2 reviews appearing in the wild (since software/support situation will be as horrible as it was all the times in the past with SinoVoip). Please try to escalate this problem with a manager, let representatives get in touch with responsible people at SinoVoip (is Foxconn/Nora Lee also involved?). I think it's really necessary that your partner wakes up and ensures that the problems outlined above get addressed. Otherwise I fear that your whole 'dev board' and open source engagement will fail with the first device since without situation improving R2 starting to sell will just be the same fiasco as with R1 back then (but this time all those people talking about 'If you want open source avoid MTK' will simply move into 'told you so!' mode and blame Mediatek instead of your hardware partner here suffering still so badly from the same problems they had already 2.5 years ago -- most notably ignorance) 

 

[giri@nwrk.biz]

Mediatek = EOL Product

From my knowledge mediatek only provides binary blobs to OEMs. They only hand out kernel sources if someone pays for it.

 

I really really have made bad expiriences with mediatek based devices.... and really really hope @sean.wang's words are true.....

[tkaiser]

9 hours ago, giri@nwrk.biz said:

From my knowledge mediatek only provides binary blobs to OEMs. They only hand out kernel sources if someone pays for it.

 

Yep, this is what everyone a bit familiar with the various SoC vendors knows from the past and that's the simple reason why I was asking in Banana Pi forums over and over again: 'show us the sources'.

 

Now imagine something has changed at Mediatek (look at Sean Wang's upstream commits -- obviously there is a change), they want to become open but this time their partner here fucks everything up since too stupid to get even the meaning of Open Source. Even if @sean.wangis doing his best the R2 will just be an absurd fail judging by all experiences with SinoVoip product launches so far (they don't get it since plagued by ignorance) but all those not familiar with SinoVoip will blame MTK instead being still worst choice for open source enthusiasts. I wonder if Mediatek is aware of this...

[giri@nwrk.biz]

9 hours ago, tkaiser said:

'show us the sources'.

Yeah, like it is that much work to upload the sources -.-

This makes me think back to the shit omate did, shortly before they started selling their Omate truesmart2. Claimed to share sources but in fact uploaded a broken archive.

They also did LOADS of forum shilling + whitespacing by flooding forums with lies and silly rethorical posts without real context to make everyone look bad who said something against thery product, just to fool the average byer who believes everything he finds in the first google result.

[Lion Wang]

Banana pi BPI-R2 source code open on github

http://forum.banana-pi.org/t/banana-pi-bpi-r2-source-code-open-on-github/3445

[tkaiser]

8 hours ago, Lion Wang said:

Banana pi BPI-R2 source code open on github

 

Thank you for that. That's a great move into the right direction but why so late? You have a repo with code and hardware documentation (device tree files are essentially just that) since over 4 months now and with this commit here (24 Feb: 'add mt7623n-bpi-r2.dts for bpi-r2') you would've immediately had to open the Github repo if you would take 'OPEN SOURCE' seriously (at least the software part, nobody expects from you doing 'open source hardware' even if you claim this again and again for no reason).

 

Doesn't it look absolutely stupid if you're claiming doing 'OPEN SOURCE' all day long when we as community have to waste insane amounts of time poking you again and again just to get you OPENING SOURCES?!

 

Ok, looked quickly in the repo (looks a bit strange since structure of an Allwinner BSP while this is MTK stuff) but I checked it out and running build.sh created successfully u-boot/kernel archives (log). So what's next? Your usual approach is now combining the created archives containing bootloader, kernel and modules with one of your many rootfs (Raspbian, Ubuntu, this and that). All your OS images are essentially the same just with exchanged bootloader/kernel without any device specific tweaks.

 

All these rootfs suffer from suboptimal settings which lead to poor performance and even strange behaviour. For example your Ubuntu rootfs still enables Ubuntu's unpatched irqbalanced which is plain stupid on ARM since this daemon does nothing useful but due to a memory leak only eats up all available DRAM over time until the board finally crashes after weeks/months depending on DRAM size. Breaking news? No, 'told you so'! Many, many times (do a web search for 'irqbalanced site:forum.banana-pi.org', we told you also in your old forum below bananapi.com:80/index.php/forum which you shut down last year being responsible for destroying a lot of information/knowledge collected/developed by YOUR OWN COMMUNITY).

 

Why is that? Since you installed a perfect way to be cushioned against anything that happens outside. Talking to the guy known as 'sinovoip bpi team' in your forum is like talking to a wall. The level of ignorance there is unbelievable high and also the reason why there's no 'vendor community' existing and everything has to happen outside of your territory. Care to remember how software support situation evolved with R1? At the end of 2014 you started to sell a paperweight with no useable OS images, incorrect/missing information/specifications, no schematics released. All work has been done by community with you actively hindering community trying to do your work. It took you one and a half years to provide first working OS images in summer 2016 relying on Armbian's build system, settings and tools. In the meantime all users had no other choice than using either Bananian, Armbian or David Bentham's OpenWRT.

 

This will not happen again even if you're enthusiastic now about 'try to get support from community'. Why/how community should support you?

 

You ignore suggestions, you ignore support requests, you ignore community telling you where information/specification are wrong, you don't provide correct information (please look at this insane BS you collected below https://bananapi.gitbooks.io/bpi-m2-ultra-open-source-single-board-computer/content/allbananapiproduct.html), you refuse to release schematics and sources (timely). It needs insane amounts of efforts and time for community to get even most basic stuff from you EVERY TIME you release something new.

 

That's the reason why almost every part of open source community already gave up on you. Since most importantly you even fail to understand what's happening (ignorance). That's the real problem (maybe it's just the filter you installed in form of your official voice known as 'sinovoip bpi team').

 

Back to the basics. I asked 9 days ago for 3 simple things: http://forum.banana-pi.org/t/bpi-r2-ubuntu-16-04-with-kernel-4-4-70-function-test/3393/8

• 'release schematics as early as possible': 5 days ago you delivered, that's not entirely 'as early as possible' but great!
• 'release sources (release early, release often)': Delivering few hours ago after being poked way too many times is neither early nor often but... great! You did it!
• 'start to write technical documentation': what about hiring someone who is able to do so? I know you even wanted to pay for community support but this CAN NOT WORK based on this insane mess you create. It's impossible to support you if you fail to provide correct information/specification. So I hope in a few weeks you also address this problem which simply would be great!

And then also please try to address the mess in your forum (especially censorship happening -- every occurence documented BTW -- that will successfully prevent people sharing knowledge there since they know that it gets deleted due to your staff behaving absolutely stupid. For example this guy will never be told how to use hdparm command).

 

I could now elaborate lengthy how much fun it was yesterday to improve network settings for ROCK64, identifying problems and possible tweaks and improving network throughput from 150 Kbits/sec to 942 MBits/sec while at the same identifying what's still missing and what we need from the hardware vendor. I save you from this but it's basically having correct information/specifications, not always talking to a wall, sources available. Please try to improve and stop behaving like a brain damaged retard. You can do! Thanks.

[tkaiser]

8 hours ago, Lion Wang said:

source code open on github

 

Even if you 'open source code on github' this happens:

• You 'open' what the Soc vendor gave you (sometimes with minor modifications), eg. https://github.com/BPI-SINOVOIP/BPI-M2U-bsp
• Since you, Lion Wang, are a chip head obviously not able to understand what software is I try to explain to you one last time: This is a 3.10.65 kernel now 2.5 years old containing a lot of security vulnerabilities. No one right in his mind wants to use this with Linux.
• 'The community' you think should help you in fact still tries to help you all the time as they did the last 2.5 years already. They do your work, invest many many hours to patch this smelly old kernel up to most recent 3.10 LTS version 3.10.106: https://github.com/dan-and/BPI-M2U-bsp (you ignore this now since over half a year, Daniel started to fix your failures on 15 Dec 2016)
• Since your level of ignorance is that insanely high (it would take you maybe 10 minutes to merge Daniel's patches into your repo to save your users at least from most severe security vulnerabilities), Daniel decided to send you all his work as a pull request. N° 1 sent on May 17 got ignored for over 5 weeks, now N° 2 containing another fix gets ignored since 4 days. (you have to click a button on github, takes 1 second max)
• Your level of ignorance is that high that you're able to ignore someone wasting hours of his life trying to fix your failures while at the same time cherry picking this. In other words: you are aware that there's an open source community member wasting his time to provide you with fixes for your smelly kernel release, you ignore all of his work but choose one single improvement to be merged into your sources. I miss words for that.
• At the same time a lot of people experience instabilities with the same device. Users are on their own since you simply ignore this. Users in your forum are discussing DRAM settings being the issue, several users all on their own at least try out some improvements and this is what happens: https://github.com/facat/BPI-M2U-bsp/commit/dff5ffe35dc22b2904993b0441c6cf6dd54efd0f#commitcomment-22739082

 

Please tell me how 'community' should be able to help you? You're behind a wall of ignorance stronger than anything at least I could imagine. What about exploring how to fix this?

 

@sean.wangwish you good luck when hell breaks loose as soon as R2 starts selling.

 

 

[sean.wang]

On 6/25/2017 at 1:58 AM, zador.blood.stained said:

First, let me make a guess and say that you are representing Mediatek here. Then - welcome.

 

Second, to summarize and rephrase @tkaiser's quite emotinal posts in this thread:

For all I did there, I would say I can't represent the whole MediatTek, the contributions mostly comes from those passionates in MediaTek internally

and the core member in LEDE/Openwrt.  Many people still don't recognize importance gained from open source I admit.  I don't blame them because

everyone has different experiences for defining what success is for them although I still have a little complaining on them as @tkaiser did it for sinovoip

why let me do the unnecessary and repetitive thing again wasting so much time and energy if they are done well in the initial.

 

Instead, I would like to change their mindset as much as possible through upstreaming activity to help to link irrelevant groups among MediaTek internal,

various communities, existing developers, potential users and so on to produce more chemical changes getting more attention on the importance of open source

and prove commercial product still can be done well with combining appropriate open source project and finally allow us all together walking on the right path.

 

Maybe there'll  a lot blames/questions/suggestions on coming bpi-r2, but I will be glad to listen to and reflect them into the MediaTek internal, and even

welcome delivering patches to me making more robust to BSP

[tkaiser]

5 hours ago, sean.wang said:

why let me do the unnecessary and repetitive thing again wasting so much time and energy if they are done well in the initial.

 

This pretty much sums up the situation with SinoVoip. Even if you want to help them it's not possible since they're behind a wall of ignorance higher anyone could imagine. The most frustrating part is that they don't get what they do

[tkaiser]

16 hours ago, tkaiser said:

Back to the basics. I asked 9 days ago for 3 simple things: http://forum.banana-pi.org/t/bpi-r2-ubuntu-16-04-with-kernel-4-4-70-function-test/3393/8

• 'release schematics as early as possible': 5 days ago you delivered, that's not entirely 'as early as possible' but great!

 

An impressive update on stupidity and ignorance: In the meantime we know thanks to Olimex' Tsvetan looking a little bit closer why it took @Lion Wang4 days to release schematics: Since they needed to make them unusable prior to releasing: http://www.cnx-software.com/2017/06/28/banana-pi-bpi-r2s-u-boot-linux-4-4-source-code-mediatek-mt7623n-datasheet-released/#comment-543406

[tkaiser]

And a small documentation update. Our friends at SinoVoip provided a great piece of information called 'Banana Pi BPI-R1 BPI-R2 smart router board Comparison 20170612'. http://forum.banana-pi.org/c/Banana-Pi-BPI-R2

 

Well, for whatever reasons the 'Comparison' isn't there any more. I don't know what might be the reason for (censorship maybe?) but fortunately the Internet remembers: http://archive.is/ibTTg

 

Since I get comment updates via email here the last piece of information @RagnerBG(one of the many users not so happy with BPi R1 -- see here for his full list of hardware modifications needed to be happy with the R2 predecessor) added over there:

 

 

(dear SinoVoip friends, you should have a look at https://en.wikipedia.org/wiki/Streisand_effect to avoid such stuff in the future. Also it would be great if you can immediately unhide all posts of mine you currently censor away)

 

[moore]

comparison table can be found in the link.

https://bananapi.gitbooks.io/banana-pi-bpi-r2-open-source-smart-router/content/bpi-r1-bpi-r2-board-comparison.html

[tkaiser]

11 minutes ago, moore said:

comparison table can be found in the link.

 

I knew. I was more talking about the usual censorship that happens over at SinoVoip forum

 

Your link archived. Now let's look through in detail (that's what @RagnerBGalready did -- he immediately spotted the 'Audio Output: N/A' stupidity):

• R1: 'SD Card(up to 64GB)/SATA(up to 2TB)' --> both not true but also not important, A20 on R1 supports both larger SD cards as well as larger disks
• R1: GPIO: 'CAN bus' (not true, CAN can only be used on some Olimex boards), I2S (also not true, it's not available here since nowhere exposed)
• R2: Audio Output: N/A (well, in reality it's HDMI audio -- no one knows about drivers yet -- and also I2S on the 40 pin header, so I2S is theoretically available here unlike on R1, it's just the exact opposite what this piece of 'technical documentation' claims. Besides that the I2S pinout on the header seems not compatible to Raspberries but hey...)
• R1: USB Ports: '2 USB 2.0 ports, 1 OTG microUSB port' (no, it's just 1 USB 2.0 port only since the other USB port is used internally for Wi-Fi)

It's the usual insanely stupid 'copy&paste gone wrong' bullshit that @Lion Wangconsiders being 'technical documentation'. Obviously this company doesn't get the meaning of 'technical documentation' since they still allow one copy&paste monkey to destroy their whole external reputation (most probably that's the same guy responsible for censoring and the whole mess in their forum and the same one closing/ignoring github issues  ).

 

Anyway since @Lion Wangpublicly declared that his company is fine with producing incorrect documentation all the time, releasing schematics only after making them unusable and also publicly declaring that they are not able to merge important security fixes they get for free from community I'm done. It doesn't really matter any more, no one is able to help them.

[eternalWalker]

or

??  same or not same

to be or not to be  (?)