Banana Pi R2

[tkaiser]

On 23.6.2017 at 7:55 PM, tkaiser said:

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)

 

It's now on Aliexpress for $89.50: https://aliexpress.com/item/Newest-arrive-Banana-PI-BPI-R2-Opensource-Router/32823351577.html

 

The pictures there show either the old version with WAN+LAN ports exchanged and only one horizontally oriented SATA port or the newer one with two upright SATA ports (what's right? At least 'product description' still reads nicely: 'support SATA interface (option support 2 stat)' which is just copy&paste from their BS collection on Gitbook they call 'technical documentation')

 

Still no schematics released of course and CEO not willing to answer such simple questions as when they do plan to release schematics (care to remember the fiasco we as customers and community went through with Banana Pi R1? Where nothing worked in the beginning and community had to reverse engineer even hardware because this insanely irresponsible vendor refused to release real schematic for over 1 year?)

[Tido]

And, it cannot hold a Harddisk like the R1 does. This was for me one of the plus points in regard to all other router in the market, beside running the Linux I prefer.

[renard]

Thanks for the nice review.
 

Quote

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).

Lol! I suspected him and you (known from github issues discussion) being the same person, but thought it to be to big coincidence. 

Quote

We also know that such multi-purpose devices combining router/firewall functionality with a graphics stack is really stupid

100% agree, absolutely no need in all those X crap on router/server, yet some useful stuff with minimal security risk (as call control with usb gsm, nas with rsync and webdav, bug trackers, gpio-based stuff, etc), imho - why not.

Quote

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)

https://github.com/BPI-SINOVOIP/BPI-R2-bsp Or am I missing something? OK he posted it on June 27.

Quote

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

Exactly the second thing that I do on this forum. First thing is configuring r1 with 5.31  and "holly" resistor soldering.
 

For the moment on official download page they only suggest Ubuntu 16.4  4.4.70.
What is the significant difference between this Ubuntu arm distros and Armbian mainline? I mean for sure not only the repository addresses?  OK on Ubuntu they as usual stuck with little older kernel between major releases (4.4 vs 4.9 for now) but I believe this is also not the main difference?    

Thanks in advance, sorry if any questions sounded stupid

[tkaiser]

4 hours ago, renard said:

For the moment on official download page they only suggest Ubuntu 16.4  4.4.70.

 

Be assured they also will provide an ultra slow Raspbian and other OS images since their way to create OS images is simply: 'take one of our smelly rootfs we fiddle around manually since ages and combine it with bootloader+kernel'. That's what this reposity here https://github.com/BPI-SINOVOIP/BPI-files is all about. BLOBs that contain bootloader+kernel which then get added to their images (that's why there's a rather huge FAT partition filled with junk) and then they have a tool called 'bpi-bootsel' or something like that that overwrites u-boot and replaces kernel and then they think they made a perfect OS image for a specific device. Since they suffer from ignorance and still don't get what's important that's all we can expect from them.

 

4 hours ago, renard said:

What is the significant difference between this Ubuntu arm distros and Armbian mainline?

 

What's the difference between don't giving a sh*t about everything important and fiddling around in a rootfs manually (dangerous since error prone!) and something that's not comparable since totally different?

 

In my eyes Armbian is the following:

• A research project trying to squeeze out the max out of the devices we support (focusing on high performance and/or low consumption and making those devices useable by a broader audience)
• A fully automated and also highly customizable build system suited for different types of developers trying to collect all the results of various research tasks into a scripted configuration (that's why Armbian ships with a startup service tuning various settings even on a per board basis, with something like armbian-config to configure various stuff in a similar way on every board supported or Armbian unique features like Device Tree overlays for sunxi devices)
• An approach to collect mainline kernel patches flying around that have not landed upstream yet for a variety of devices to make a lot of boards useable with most recent kernel months before the patches are really integrated in mainline kernel (unfortunately this is both pretty time consuming and not that rewarding at the same time since users of our mainline images simply ignore the 'work in progress' status)
• An approach to fix at least already known security vulnerabilities for the various legacy kernels we support. Where possible we patch the legacy kernels provided by SoC vendors up to latest LTS version so while you still shouldn't trust ANY vendor/legacy kernel (since hacked together by SoC maker employees most probably not understanding concepts called 'security' or at least suffering from the usual Android software management 'culture' focusing on 'Does it still crash? No? Let's ship the crap and move on to something else!') you can be ensured that the already known CVEs affecting the vendor kernels are fixed in Armbian
• An insanely high amount of testing efforts to ensure that all of the above ends up in OS images that can be built from scratch and do really work afterwards ('build from scratch' is mandatory since no one right in his mind wants to use an OS image where someone else did some stuff manually before. Or at least you must suffer from insanely naïve optimism to trust in OS images where human beings fiddled around manually since if these people are bad guys or simply had a bad day and made a mistake your OS image contains a root exploitable security flaw. All of this can be avoided by creating OS images only from scratch by scripts that live in a version control system)
• And at least one of my personal goals starting to promote Armbian heavily 2 years ago was to establish some sort of 'joint development efforts' here regardless of the distro or OS image used later. Vendor focused micro communities often suffer from being trapped in micro realities and don't realize that they could hugely benefit from work done in another micro community (good example: Orange Pi vs. Pine64 'communities'). But that's not really a 'pro Armbian' issue but one of interconnecting developers here and there.

I'm sure I missed something...

 

Ah, yes. A by-product of all of the above are OS images that are created on a regular basis (supporting several distros, currently Debian Jessie and Ubuntu Xenial, soon on most platforms also Debian Stretch). Oh, and I forgot that we bundle bootloader, 'board support packages' and kernel images as installable packages and provide them on apt.armbian.com (so 'Armbian' is also some sort of a support/software infrastructure). Ah, ok. And we monitor security relevant information sources and act on accordingly providing kernel security fixes as soon as possible  (that's why every Armbian user on this planet had a fix for stuff like 'rootmydevice' or 'Dirty COW' within 24-48 hours on his device unlike the 'usual board maker behaviour' simply don't giving a sh*t about security issues at all. Those Banana retards are not different, they refuse to patch the vendor kernels for some of their devices even if they get everything in 'spoon feed' mode for free: https://github.com/BPI-SINOVOIP/BPI-M2U-bsp/pulls)

 

Oh, almost forgot: Armbian is also free technical support (this forum). If you compare with vendor offerings you might get the difference easily (especially when comparing with board vendors that allow morons to 'run' their forums).

 

20 hours ago, renard said:

on Ubuntu they as usual stuck with little older kernel between major releases (4.4 vs 4.9 for now)

 

Nope, Ubuntu and Debian only maintain kernels for x86/amd64 platforms, on ARM this is not covered by the upstream distro. That's why you get an Ubuntu running with a 3.4.39 kernel when you choose a BPi M3 (could be 3.4.113 instead but those Banana muppets are too lazy or stupid to patch kernels to latest LTS version), a 3.4.113 kernel when you choose BPi M2 Zero (since they took our work), and a 4.4.70 with BPi R2 (and not 4.4.78 since too lazy/stupid). Kernel version here and there happens only by accident since Bananas don't do software, they just take what they get from either SoC vendor or community. They don't give a sh*t about kernel versions and security in general.

 

 

[Lion Wang]

On 24.6.2017 at 11:54 AM, tkaiser said:

[PATCH v4 9/9] arm: dts: mt7623: add dts file for Bananapi R2 (BPI-R2) board

https://www.spinics.net/lists/arm-kernel/msg583562.html

[v2,30/30] arm: dts: mt7623: add dts file for Bananapi R2 (BPI-R2) board

https://patchwork.ozlabs.org/patch/755337/

 

Edited August 8, 2017 by Tido
deleted empty quote, cannot find posting of TK in this thread: On 2017/6/24 at 5:54 PM, tkaiser said:

[tkaiser]

6 hours ago, Lion Wang said:

Edited 46 minutes ago by Tido
deleted empty quote, cannot find posting of TK in this thread: On 2017/6/24 at 5:54 PM, tkaiser said:

 

@Tido: You as a moderator should also think about telling @Lion Wang personally that a board bring up thread in Armbian forum is related to documenting whether a specific board is worth the efforts or not FOR US to start working on it. This is a software development thread suitable to discuss and publicly document what Armbian developers think about supporting a board or not.

 

If @Lion Wang feels he needs to spam this forum by mirroring stupid posts like this here I'll start to mirror even more stupid posts like Herbal Aloe Concentrate which pretty much describes manufacturer's BPi-R2 reality: A single person too ignorant to get anything being the responsible guy posting as 'sinovoip bpi team' for censoring their forum, flodding it with BS and lies while at the same time never answering customers' technical questions. I suspect the same person is also responsible for the 'copy&paste gone wrong' collection this company considers being technical documentation and maybe he's even the same ignoring all tries to help this company on Github (these losers still don't merge the pull requests here)

 

For anyone concerned about kernel quality issues with BPi-R2 better look at https://github.com/BPI-SINOVOIP/BPI-R2-bsp/commits/master instead of upstream mainline patches. But maybe @sean.wang can comment a bit on mainlining efforts again.

[tkaiser]

18 hours ago, Lion Wang said:

 

 

So funny: http://forum.banana-pi.org/t/bpi-r2-boot-power-suppy/3647

[Tido]

12 hours ago, tkaiser said:

You as a moderator should also think about telling @Lion Wang personally that a board bring up thread in Armbian forum is related to documenting whether a specific board is worth the effort

I do not, I do not even delete the stone age links he postet. It is Igor's style to leave things until it really hurts.
We both do not understand why Lion does behave as he does and unless we meet him person to person and have an open discussion, we will never do I guess. But I have to say I would like to understand why - just because I am a curious person :-)

[RagnerBG]

2 hours ago, tkaiser said:

 

So funny: http://forum.banana-pi.org/t/bpi-r2-boot-power-suppy/3647

Like comic show . Poor people (test subjects), they have no idea what is yet to go through, with this board. Honestly, i didn't expect hardware problems (at least) this time, but sino voip manage to surprise me big time. This is even beyond R1. And it appears there really is no audio device, even HDMI, as they were announced at first. But now they claim to have HDMI/I2S Audio on Aliexpress. And even if the first is true, even if this doesn't look so, right now, it will be interesting when poor customers realize what the second means.

[TonyMac32]

Sometimes I need to feel better about my Tinker Board.  This makes it all better. 

[tkaiser]

14 hours ago, Tido said:

We both do not understand why Lion does behave as he does and unless we meet him person to person and have an open discussion, we will never do I guess. But I have to say I would like to understand why

 

Most probably he's perfectly shielded from reality by the funny guy mainly responsible for all the 'technical documentation' and forum sh*t show you're still trying to talk to for no reason?  

[tkaiser]

On 9.8.2017 at 0:08 AM, RagnerBG said:

And it appears there really is no audio device

 

Well, 'I can confirm that sound support isn't compiled into the kernel' so 1) it has been never tested by the 'manufacturer' as expected and 2) users need to compile the kernel on their own to get at least HDMI audio. Besides that combining multimedia features with router/firewall functionality on the same device without appropriate separation is still one of the most stupid goals ever.

 

 

[JohnnyWednesday]

On 11/08/2017 at 7:00 AM, tkaiser said:

 

Well, 'I can confirm that sound support isn't compiled into the kernel' so 1) it has been never tested by the 'manufacturer' as expected and 2) users need to compile the kernel on their own to get at least HDMI audio. Besides that combining multimedia features with router/firewall functionality on the same device without appropriate separation is still one of the most stupid goals ever.

 

 

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.

[chwe]

11 minutes ago, JohnnyWednesday said:

Anyway - if I can run any tests and what-not then please let me know

Maybe work on 'charles' list posted in the BPi forum:

Quote

• show us a github repo with source code for this kernel, (obviously not your business )
• show us boot logs,
• show us SATA performance numbers, (you said thats not possible at the moment)
• show us Gigabit Ethernet performance numbers,
• show us how the switch can be configured,
• show us NAT throughput with simple and complex firewall settings
• show us OpenVPN and IPSec encryption throughput numbers

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...)

[JohnnyWednesday]

41 minutes ago, chwe said:

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...)

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.

[Nora Lee]

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

 

 

[tkaiser]

17 hours ago, JohnnyWednesday said:

I'm guessing from the smattering of posts I've read that I won't be encountering many fans of the manufacturers

 

I'll keep it short: you don't know these guys so you don't know in which shit show you're running.

 

I wasted few minutes and checked quickly again:

• Schematics released? Nope, still only a crippled PDF containing BS (care to remember how long we had to wait until this 'great' vendor released Banana Pi R1 schematics? A whole year)
• Has the copy&paste monkey responsible for such insane BS like '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.' (see bottom of their QUICK START GUIDE) been replaced with someone able to write technical documentation? Nope
• Any real information available? Nope
• Any real performance numbers available? Nope
• Does the vendor understand the meaning of the simple word 'open'? Nope! They still think 'open source' means they can keep their sh*t closed while everyone around has to help them out where they fail the most (software)

BTW: Is 'Below is the performance of Banana Pi R2 board: USB2.0 7.2MB/s USB3.0 115MB/s with buffer, 27MB/s w/o buffer' real or a bad joke? USB2.0 'performance' below 30MB/s can be considered broken. What is this 'with buffer / without buffer' BS? Are these hdparm numbers (-t/-T). If the latter than USB3 can also be considered broken on this board since buffered reads are from memory (kernel buffer) and 27MB/s would be disk 'performance'. It's 2017 and we're dealing with SoCs like RK3328 that achieve +380 MB/s (or ODROID-XU4 +300MB/s -- already curious how the ODROID HC1 samples perform Hardkernel sent out to me since there's no internal USB3 hub in between). Compared to this either 27 MB/s or 115 MB/s are simply shitty.

 

Since I really don't like ignorance and stupidity that much no more Bananas for me please.

 

I don't know with which IDH MediaTek partnered here to design the board but I really hope the next time they make a step into the open source direction they choose an appropriate hardware vendor (or marketing partner) at least knowing the meaning of 'open source' and acting responsible (providing correct information, not lying all the time, releasing sources/schematics early and often and everything else that can be considered normal but that won't happen with the Banana guys anytime soon or ever)

[eternalWalker]

@tkaiser

 

Can it be that you are really allergic to bananas? Imagine that quite a lot of people eat the bananas - even the light brown 

 

Gruß

[chwe]

 

2 hours ago, eternalWalker said:

 

Can it be that you are really allergic to bananas?

Maybe your definition of 'light brown' and @tkaiser differs a little bit. If you have a short look on his website, it seems that he could be a customer for a R2 board and if this board would work as expected it might be a good solution for his customers to. If you have a look the R1 board is the only board where the support of armbian was dropped although you still can buy it (it's not a good sign, when developers decide to drop support before production cycle of a device ends). I was not active in the 'armbian world' during the 'bring up R1 era' (so I can't talk about this time on first hand) and maybe tkaisers wording is a little bit harsh but also 'more calmed' persons aren't that excited to work with a Banana-Board until something changes in this company.

On 9.8.2017 at 1:54 AM, TonyMac32 said:

Sometimes I need to feel better about my Tinker Board.  This makes it all better. 

On 24.6.2017 at 10:28 AM, Igor said:

 Serious (open source oriented) vendors would stay away from Mediatek chips in first place.

On 24.6.2017 at 7:58 PM, zador.blood.stained said:

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.

Maybe some of these opinions changed since they were written, probably not (or not that much). If you go to aldi (since you're from austria, it would be hofer) and they sold you more than once a bananashake which has some hard to swallow pieces in it you might trust Aldi anymore until they showed that they are able to make a real good bananashake. 
But how are you reacting to this? You can be silent and don't give a fuck about BPis anymore. Maybe someone decide to make a 'stable' armbian or an 'armbianalike' image (which happened for example with the OPi 2G-IoT). Guess where these peoples would ask for support? Since tkaiser is an active supporter here he would see threads about a board he claimed/saw from the beginning that it would make trouble. So, being loud and force them to improve their behavior is IMO not the worst way to act. If you want a perfect example what happens if a boardmaker decides to make a 'cool board', just have a look on the Rockchip subsection of this board. The Asus tinker claimed to be a 'overpowered' raspberry pi and @TonyMac32 is now hammered daily why 'random board feature' does not run at all or not smoothly.  Maybe he's not that harsh in wording but I'm sure he thinks often quite similar about Asus than tkaiser does it about the Bananas  (Btw, as soon as I'm in michigan please remind me to bring you some beers for all the efforts you made with the tinker).

 

@eternalWalker can you delete all your empty places in your signature? It just makes threads longer without any informations? (there are about 5-6 backslashes in your signature).

 

[JohnnyWednesday]

3 hours ago, tkaiser said:

 

I'll keep it short: you don't know these guys so you don't know in which shit show you're running.

 

I wasted few minutes and checked quickly again:

• Schematics released? Nope, still only a crippled PDF containing BS (care to remember how long we had to wait until this 'great' vendor released Banana Pi R1 schematics? A whole year)
• Has the copy&paste monkey responsible for such insane BS like '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.' (see bottom of their QUICK START GUIDE) been replaced with someone able to write technical documentation? Nope
• Any real information available? Nope
• Any real performance numbers available? Nope
• Does the vendor understand the meaning of the simple word 'open'? Nope! They still think 'open source' means they can keep their sh*t closed while everyone around has to help them out where they fail the most (software)

BTW: Is 'Below is the performance of Banana Pi R2 board: USB2.0 7.2MB/s USB3.0 115MB/s with buffer, 27MB/s w/o buffer' real or a bad joke? USB2.0 'performance' below 30MB/s can be considered broken. What is this 'with buffer / without buffer' BS? Are these hdparm numbers (-t/-T). If the latter than USB3 can also be considered broken on this board since buffered reads are from memory (kernel buffer) and 27MB/s would be disk 'performance'. It's 2017 and we're dealing with SoCs like RK3328 that achieve +380 MB/s (or ODROID-XU4 +300MB/s -- already curious how the ODROID HC1 samples perform Hardkernel sent out to me since there's no internal USB3 hub in between). Compared to this either 27 MB/s or 115 MB/s are simply shitty.

 

Since I really don't like ignorance and stupidity that much no more Bananas for me please.

 

I don't know with which IDH MediaTek partnered here to design the board but I really hope the next time they make a step into the open source direction they choose an appropriate hardware vendor (or marketing partner) at least knowing the meaning of 'open source' and acting responsible (providing correct information, not lying all the time, releasing sources/schematics early and often and everything else that can be considered normal but that won't happen with the Banana guys anytime soon or ever)

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.

[JohnnyWednesday]

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

[Tido]

39 minutes ago, JohnnyWednesday said:

and what good are the PCB schematics in terms of development?

On the R1 the SATA connector had no power for the Harddisk. SinoVoip sold a product with software that would not turn on the main feature of the board.

Thanks to a hw engineer who tinkered and reverse-engineered it could be powered in the end. Still months after that the sw of SinoVoip was not fixed and people in the forum were asking for help.

What was your question again

 

I wrote that begin of 2016, first contact with Nora - can you see improvement?

Edited August 14, 2017 by Tido
2016, Nora

[eternalWalker]

@chwe

As I see a friend, you misunderstood my comment  
If I do not like bananas at all (or am allergic to them) - I do not buy them IN GENERAL (!) And even more I do not look for them in Swiss ALDI

And when I see these brown somewhere - I miss them from afar 

 

Regards too

[Tido]

43 minutes ago, JohnnyWednesday said:

By all means have a go at the person that maintains the documentation - it needs to be better

Been there, done that.

 

Johnny, you remind me about David.

You see TK was quite friendly at the begin.

[JohnnyWednesday]

1 minute ago, Tido said:

On the R1 the SATA connector had no power for the Harddisk. SinoVoip sold a product with software that would not turn on the main feature of the board.

Thanks to a hw engineer who tinkered and reverse-engineered it could be powered in the end. Still months after that the sw of SinoVoip was not fixed and people in the forum were asking for help.

What was your question again

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.

[Tido]

@JohnnyWednesday, having people like you in our community is great and appreciated.

Just don't try to convince us that SinoVoip is a great manufacturer - because the past and current proof different.

And please, when you find errors and patch fixed it, send pull requests to SinoVoip and report back when they were added. I say this because we have seen it for more than 2years, not months, not days.

 

[JohnnyWednesday]

Just now, Tido said:

@JohnnyWednesday, having people like you in our community is great and appreciated.

Just don't try to convince us that SinoVoip is a great manufacturer - because the past and current proof different.

And please, when you find errors and patch fixed it, send pull requests to SinoVoip and report back when they were added. I say this because we have seen it for more than 2years, not months, not days.

 

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

[chwe]

43 minutes ago, JohnnyWednesday said:

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?

As you can see, he gave them some hints about the R2. 

Spoiler

Quote

Yes, thank you. So we know now at least a little bit:

• /cpus/cpu@0 missing clock-frequency property means cpufreq not working yet? What's the clockspeed the cores are running with?
• An ASM1062 is providing SATA functionality. Have you or MTK already explored the NCQ problem when accessing two disks in parallel. Does it need echo 1 > /sys/block/sdX/device/queue_type to slow the disks down when 2 disks are accessed in parallel? Have you ever tested with more than one disk?
• sda is a 32 GB SDCZ80 USB3 thumb drive. 93.3 MB/s write performance looks ok until you look how fast this device is in reality: http://usb.userbenchmark.com/SanDisk-Extreme-USB-30-32GB/Rating/14661 (so your dd test is xxx, you test buffers not the device and you miss either conv=fdatasync or oflag=dsync flag)
• sdb is a 320 GB SATA disk connected to ASM1062. 65.2 MB/s is horribly low given that you test wrongly and the thumb drive scores better
• it seems WAN port is eth0 and LAN ports appear as single eth1 port (or vice versa). Random MAC-Address with both interfaces. Will you fix this?
• Starting LSB: daemon to balance interrupts for SMP systems... really bad since does nothing and contains a memory leak eating up all the RAM over time (your Ubuntu rootfs from 2 years ago already contained this flaw, reported several times in forum, happily ignored every time)

If you would not have hold back this log for almost half a year this feedback could've arrived earlier (useless anyway, you ignore community feedback usually). Now imagine if you would immediately open your github repo to allow third parties to look through R2 kernel sources to improve stuff?

 

 

57 minutes ago, JohnnyWednesday said:

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.

The strength of armbian isn't only the github repo. The strength here is the community, a lot of peoples with various knowledge & boards, lot/some of them contribute to armbian in one or the other way.

1 hour ago, JohnnyWednesday said:

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?

Raspberry is close as hell,  that's of course one reason why armbian does not support RPis at all.

 

 

Don't get me wrong, I would also love to see a working armbian on the R2 (maybe, this could be a cool board for some ideas which are almost finished in my head  ),  but I can understand that not everyone is excited at the moment (I would also love to see armbian on the orange pi 2g-iot, but that would never happen, different story...). Maybe people here are wrong with their feelings and the R2 is a perfect product, maybe not. Only time will show who's right.  As you can see, Rock64 isn't supportet by armbian at the moment, but people work on it and share their efforts here.  So feel free to contribute and share your findings here. I'm sure, a lot of people here would like to see a successful development on software side for the R2!

[JohnnyWednesday]

15 minutes ago, chwe said:

As you can see, he gave them some hints about the R2. 

  Hide contents

 

 

The strength of armbian isn't only the github repo. The strength here is the community, a lot of peoples with various knowledge & boards, lot/some of them contribute to armbian in one or the other way.

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

[TonyMac32]

@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".