3 3
Юрий Долгорукий

Banana PI BPI-W2

Recommended Posts

7 minutes ago, chwe said:
47 minutes ago, tkaiser said:

at least for me https doesn't work

 

Of course it does NOT work which is a problem since BPi folks distribute all their software solely through their unprotected forum:

 

http://www.banana-pi.org/download.html (no HTTPS) --> http://www.banana-pi.org/downloadall.html (no HTTPS) --> http://forum.banana-pi.org/c/Banana-pi-BPI-W2/BPI-W2-image (no HTTPS)

 

For any serious or professional use cases it's impossible to continue since a MITM (man-in-the-middle) attacker would download an image from them, open/modify it adding some nice backdoors, then uploading it somewhere on Google Drive, setting up something that looks like a download page and then doing some DNS spoofing. Not very likely but software downloads in general that are not protected by at least HTTPS aren't trustworthy at all. Any potential professional customer like @botfap will immediately turn away when seeing stuff like this.

 

This was just another free community service for our beloved Banana folks which of course will result in @Lion Wang talking about some evil individual (me) constantly attacking him. :lol::lol::lol:

Share this post


Link to post
Share on other sites
1 minute ago, chwe said:

then.. I suggest you fix it.. cause the link you shared contains https... :P 

 

You don't get it. @Nora Lee edited her post above in the meantime. She posted just http://forum.banana-pi.org/t/banana-pi-bpi-w2-source-code-public-on-github/6802 directly below the http://forum.banana-pi.org/t/banana-pi-bpi-w2-source-code-public-on-github/6802 @Lion Wang already posted (you as moderator might see the edit history).

 

So I thought it would be a nice joke to again post http://forum.banana-pi.org/t/banana-pi-bpi-w2-source-code-public-on-github/6802 (which is plain stupid of course since there's no information anyway in that forum post other than a link to the sources) but then decided to switch to https:// since the last time it already worked that great.

 

Remember thishttps://github.com/BPI-SINOVOIP/BPI-W2-bsp was a 404 yesterday but an hour ago Bananas delivered. Now they can show their superior performance again and make HTTPS work with their forum so they can again repair a broken link.

 

BTW: Armbian is not affected: Accessing http://dl.armbian.com will redirect automagically to https://dl.armbian.com -- apt with HTTP only is not that much of an issue.

 

 

Share this post


Link to post
Share on other sites
3 minutes ago, tkaiser said:

You don't get it. @Nora Lee edited her post above in the meantime. She posted just http://forum.banana-pi.org/t/banana-pi-bpi-w2-source-code-public-on-github/6802 directly below the http://forum.banana-pi.org/t/banana-pi-bpi-w2-source-code-public-on-github/6802 @Lion Wang already posted (you as moderator might see the edit history).

 

So I thought it would be a nice joke to again post http://forum.banana-pi.org/t/banana-pi-bpi-w2-source-code-public-on-github/6802 (which is plain stupid of course since there's no information anyway in that forum post other than a link to the sources) but then decided to switch to https:// since the last time it already worked that great.

well, I probably need a coffee first..  :P  didn't get that much sleep tonight.. 

 

5 minutes ago, tkaiser said:

Remember thishttps://github.com/BPI-SINOVOIP/BPI-W2-bsp was a 404 yesterday but an hour ago Bananas delivered. Now they can show their superior performance again and make HTTPS work with their forum so they can again repair a broken link.

He should stated it that the repo us currently private and will be opened in the next x days. Would make things easier.. But well it's public now:

Kernel:

  • patchlevel 119 --> head is at 127 that's okay (or surprisingly high IMO)
  • there's no much of a githistory for this kernel 
  • the dts are refracted hardly..   but overall DT stuff looks quite properly made..  (I didn't saw any License headers in all related dts files)

U-boot

  • v2015.07 (as expected.. SoC makers don't give a shit about recent u-boot versions but it should understand ext4)
  • boardconfig may need some fixing
  • in their current scripts u-boot uses the provided toolchain. The makefile may need some fixing and hopefully u-boot can be built with linaro gcc in the future.. 

 

off-topic

14 minutes ago, tkaiser said:

but it's also not much of an issue to switch due to https://github.com/armbian/build/blob/71c777b3b67c4e76ddbf1866c1eae36bb0f6c955/lib/configuration.sh#L140 everything needed is there.. :) I suggest we switch this part of the discussion to https://github.com/armbian/build/pull/1117

Share this post


Link to post
Share on other sites
13 hours ago, tkaiser said:

 

You don't get it. @Nora Lee edited her post above in the meantime. She posted just http://forum.banana-pi.org/t/banana-pi-bpi-w2-source-code-public-on-github/6802 directly below the http://forum.banana-pi.org/t/banana-pi-bpi-w2-source-code-public-on-github/6802 @Lion Wang already posted (you as moderator might see the edit history).

 

So I thought it would be a nice joke to again post http://forum.banana-pi.org/t/banana-pi-bpi-w2-source-code-public-on-github/6802 (which is plain stupid of course since there's no information anyway in that forum post other than a link to the sources) but then decided to switch to https:// since the last time it already worked that great.

 

Remember thishttps://github.com/BPI-SINOVOIP/BPI-W2-bsp was a 404 yesterday but an hour ago Bananas delivered. Now they can show their superior performance again and make HTTPS work with their forum so they can again repair a broken link.

 

BTW: Armbian is not affected: Accessing http://dl.armbian.com will redirect automagically to https://dl.armbian.com -- apt with HTTP only is not that much of an issue.

 

 

When I'm in a bad mood, I'm glad to see your posts, because you're like my wife, always chattering, but I can't say no :)  hope you can help us to development BPI-W2

Share this post


Link to post
Share on other sites
29 minutes ago, Lion Wang said:

When I'm in a bad mood, I'm glad to see your posts, because you're like my wife, always chattering

I think it's more like the dentist, always complaining that I'm not flossing enough...  I don't want to hear it, but the dentist is right.  ;)

 

 

4.9 kernel, ok, 2015 u-boot, :(.  Looks like an interesting board, but I worry about drivers and any hope of mainline support. 

Share this post


Link to post
Share on other sites
15 hours ago, chwe said:
  • patchlevel 119 --> head is at 127 that's okay (or surprisingly high IMO)
  • there's no much of a githistory for this kernel 
  • the dts are refracted hardly..   but overall DT stuff looks quite properly made..  (I didn't saw any License headers in all related dts files)

 

Anyone interested in RTD1295/RTD1296 platform would need to do something like this first

  • check out upstream mainline kernel at version 4.9.119
  • import changes from RealTek's kernel above (you then end up with one giant commit like this -- context)
  • Now you can spend some days or weeks to have a look what's different, where security holes exist (remember Allwinner's 'rootmydevice'?) and what's not properly licensed

If this step is skipped there exists no reason to trust into RealTek's 4.9 at all. Especially if this step is skipped it's impossible to start with Armbian support for RTD1295/RTD1295 devices since it would harm the project repeating mistakes like with Allwinner's H3 BSP kernel again (where something like rootmydevice was only discovered by accident).

 

We can't trust Android vendor's BSP kernels since those employees forced to hack driver support into something they're not interested in (the Linux kernel and its concepts) never worked with mechanisms like peer review or code quality control. If those employees would've started to submit patches upstream where all this stuff happens (Linux kernel community) then this would be something entirely different. But RealTek just like Allwinner and the majority of ARM SoC vendors has no interest in properly upstreaming their code so this code can't be trusted.

 

If their stuff is not properly licensed this will most likely prevent developing mainline drivers for the affected hardware (but I doubt anyone will do this anyway since so far only Suse's Andreas Färber worked on the platform -- tried to inform him via CNX but no idea whether he's aware that some RealTek kernel sources are now provided).

 

Having now sources does not mean everything's fine now. Next step is looking at the mess contained (if anyone wants to spend weeks of his life with something like this).

 

 

Share this post


Link to post
Share on other sites
5 hours ago, tkaiser said:

If their stuff is not properly licensed this will most likely prevent developing mainline drivers for the affected hardware (but I doubt anyone will do this anyway since so far only Suse's Andreas Färber worked on the platform -- tried to inform him via CNX but no idea whether he's aware that some RealTek kernel sources are now provided)

He does know the repo... 

and https://github.com/afaerber/linux/tree/rtd1295-next there you go for mainline rdt kernel where the irq driver is according to andreas currently buggy.

 

5 hours ago, tkaiser said:

If this step is skipped there exists no reason to trust into RealTek's 4.9 at all. Especially if this step is skipped it's impossible to start with Armbian support for RTD1295/RTD1295 devices since it would harm the project repeating mistakes like with Allwinner's H3 BSP kernel again (where something like rootmydevice was only discovered by accident).

Indeed, this would be the perfect solution. Honestly, I don't think this will ever happen. Around linux-sunxi there was a bigger community interested. Even around the 3.4 kernel and it took years to spot rootmydevice. If you want this level of peer reviewed (and hopefully secure) code your only option is mainline/vanilla LTS.  But actually this should then be done for every BSP kernel we use (e.g. RKs 4.4 kernel is also mostly/partly an android kernel, even when they're experienced in mainlining it doesn't mean that the 4.4 kernel has the same 'standard').  Just a short overview how many kernelsources we currently use (without branches):

Spoiler
  • 'https://github.com/ayufan-pine64/linux-pine64'
  • 'https://github.com/ayufan-rock64/linux-kernel'
  • 'https://github.com/ayufan-rock64/linux-mainline-kernel'
  • 'https://github.com/friendlyarm/kernel-rockchip'
  • 'https://github.com/friendlyarm/linux'
  • 'https://github.com/hardkernel/linux'
  • 'https://github.com/Icenowy/linux'
  • 'https://github.com/igorpecovnik/linux'
  • 'https://github.com/linux4kix/linux-linaro-stable-mx6'
  • 'https://github.com/linux-sunxi/linux-sunxi'
  • 'https://github.com/MarvellEmbeddedProcessors/linux-marvell.git'
  • 'https://github.com/mihailescu2m/linux'
  • 'https://github.com/moonman/linux-stable'
  • 'https://github.com/patrykk/linux-udoo'
  • 'https://github.com/rockchip-linux/kernel.git'
  • 'https://github.com/UDOOboard/linux_kernel'
  • 'https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git'
  • $MAINLINE_KERNEL_SOURCE

 

But IMO this thread is more a 'collecting information' not a board bring up (otherwise it would be in the development sub-forums). I think/hope that Realtek does a better job than Allwinner due to:

  • Patchlevel is relatively high (I assume this work is done by RTD)
  • 4.9 is for an android kernel relatively recent. Android kernels I know are mostly 3.x or 4.4 - android Oreo (8) defines 3.18 as acceptable for old and 4.4 for newly developed SoCs to fulfill googles requirements
  • RTD1295/6 is found in millions of little NAS boxes around the world (e.g. QNAP,  Synology, Zidoo etc.).  Whereas Allwinners are only found in the cheapest TV boxes you can find.

The SoC is relatively powerful and I think Sinovoip exposed more or less every possible interface.  The SATA cable (including power-cable) is a normal one, so you don't need some fancy adapter cable (as for the BPi-W2) and from the snippets of the schematics I saw, 12V rails should be exposed too. The size matches with the BPi-W2 (not measured but face to face I didn't saw any dis-match even for the screws) with DDR4 ram. For me it's somehow similar to the BPi-R2 (except, the R2 runs on pure mainline with only one patch - the general packaging), as long as it's the only board based on this SoC, (official) support is questionable, I'm sure a bunch of NAS owners might step in (as users not as developers :lol:) as soon as they see a chance that their Synology NAS-box could probably run Armbian (and therefor OMV)..  Well, let's see what happens in the next days/weeks.. 

Share this post


Link to post
Share on other sites
2 hours ago, chwe said:

I don't think this will ever happen

 

Exactly. So no Armbian support for RTD1295 or RTD1296. My last actions around this SoC were pushing BPi folks to stop behaving stupid (switching from "let's wait a bit' blabla to opening sources and hopefully in general moving to an 'release early, release often' cycle) and informing Andreas about the repo. No more interest since the initial efforts are way too high. Let's have another look in 2020.

 

On related news, FriendlyELEC confirmed they're working on a 4 port NAS HAT for NanoPi M4 using Marvell 88SE9235 controller :)

Share this post


Link to post
Share on other sites

IMO push them to open the repo immediately only to tell them after its: well no mainline no armbian is a bit....  questionable. You knew exactly before that there won't be a mainline kernel, you knew that the only efforts in mainlining the SoC is done by Andreas Färber and not Realtek and that he as a 'lone survivor' will probably not be ready to deliver a mainline (based) linux soon.

Assuming you would be a copyright holder (for parts of the kernel) and we take https://github.com/torvalds/linux/blob/master/Documentation/process/kernel-enforcement-statement.rst as a baseline for 'being good' (at least a bunch of kernel developers signed it)

Quote

Notwithstanding the termination provisions of the GPL-2.0, we agree that it is in the best interests of our development community to adopt the following provisions of GPL-3.0 as additional permissions under our license with respect to any non-defensive assertion of rights under the license.

 

However, if you cease all violation of this License, then your license from a particular copyright holder is reinstated (a) provisionally, unless and until the copyright holder explicitly and finally terminates your license, and (b) permanently, if the copyright holder fails to notify you of the violation by some reasonable means prior to 60 days after the cessation.

 

Moreover, your license from a particular copyright holder is reinstated permanently if the copyright holder notifies you of the violation by some reasonable means, this is the first time you have received notice of violation of this License (for any work) from that copyright holder, and you cure the violation prior to 30 days after your receipt of the notice.

 

you informed them on September 4th that they have a GPL violation and on September 19th they released the sources (15 days). Assuming you're the first one who noticed the GPL violation, the majority of the kernel developers would agree that they act as they should. 

 

For sure someone more experienced in kernel-development and bsp kernel-quality would have to check it first.  But as said a full check of the BSP kernelsources was (until yet) never a prerequisite for provide Armbian with BSP-kernels. It's also obvious that this SoC is far away from mainline support and that some of the interesting features will probably never run in mainline (e.g. the whole encoding and decoding stuff cause it is partly, as far as I understand, behind some blobs e.g. 'bluecore.audio').

But as an other example, pinebook is marked as 'supported'. 3.10 got EOL a year ago (and was likely never fully reviewed too) and mainline has (as far as I know) issues with the PMIC (which will be important for a 'notebook') and only marked as beta. By those standards Pinebook should go back to wip or CSC. 

 

I completely agree that at least a headless usable mainline based linux should be available before we start to support a new SoC. I also agree that support SoCs which have only one available board is questionable (the efforts maintaining just a new set of kernels BSP/Mainline is just too much for one board - expect the MT7623 for which I might prepare a PR as soon as we reach the next LTS kernel, it works without major issues on mainline without patching, so it's only an adjustment of the config file, something I think isn't that much work I may write a THS patch cause those settings are IMO a bit conservative).

 

But a full check of the BSP kernel as prerequisite is IMO double standard - we didn't do it for any BSP kernel in the past and this should be IMO discussed in the developer subforum first before we define it as a new standard - in this case we had to drop a bunch of 'suggested' images from the download page (e.g. RK3399, RK3328 Rock64/Renegade, A64 Pine64 et al, ). For all those boards we suggest to use the BSP kernel..

Share this post


Link to post
Share on other sites
15 hours ago, chwe said:

But as an other example, pinebook is marked as 'supported'. 3.10 got EOL a year ago (and was likely never fully reviewed too) and mainline has (as far as I know) issues with the PMIC (which will be important for a 'notebook') and only marked as beta. By those standards Pinebook should go back to wip or CSC

 

Sorry, I don't find the time to answer to all of this stuff in detail.

 

My opinion on Pinebook and A64 in general: EOS for more than one reason. Also you seem to miss that I used A64 legacy kernel as an example where one developer at least took the time to rebase the vendor BSP mess on top of an outdated mainline kernel version so at least it was possible to get an idea what Allwinner changed where. A64 devices are toys, the majority of users who play with them doesn't care about security anyway.

 

Same could be said about H3 and I really wonder why you don't get how things changed over time. At the end of 2015 Armbian supported just a few boards, H3 devices looked somewhat promising based on features and costs. Back then we took another Allwinner BSP and simply added the missing 3.4.x patches on top (and at the same time few of us already started to use H3 with mainline kernel). To be clear: THIS WAS A MISTAKE (as could be seen just a few months later --> rootmydevice). Why should we repeat mistakes? Since we're totally stupid? Or just too dumb to learn from mistakes?

 

15 hours ago, chwe said:

in this case we had to drop a bunch of 'suggested' images from the download page (e.g. RK3399, RK3328 Rock64/Renegade, A64 Pine64 et al, )

 

Seriously? Are you able to spot the difference between Rockchip's 4.4 BSP kernel that is based on a clean Linux mainline version (see the +609,000 commits) and RealTek's code drop that is now available without any history? The difference between Rockchip as one the few ARM vendors who learned some lessons pretty fast and became open source friendly while there's nothing (especially zero experiences) now with RealTek?

 

And you talk about standards and 'double standards'? As in 'now we need to support this new platform since board vendor did what he had to do anyway'. Yeah! Sure, let's add more SoC families to Armbian. That's what is truly needed. More boards, less quality.

 

But hey, since this projects suffers from total lack of agreed project goals such useless babbling will happen over and over again. I have no idea why we currently support way too much boards we can handle and why constantly new stuff that requires enormous efforts should be added and why are talking about stuff like this anyway.

Share this post


Link to post
Share on other sites
9 hours ago, tkaiser said:

Seriously? Are you able to spot the difference between Rockchip's 4.4 BSP kernel that is based on a clean Linux mainline version (see the +609,000 commits) and RealTek's code drop that is now available without any history? The difference between Rockchip as one the few ARM vendors who learned some lessons pretty fast and became open source friendly while there's nothing (especially zero experiences) now with RealTek?

There is a difference that's why I mentioned it: 

On 9/19/2018 at 4:59 PM, chwe said:
  • there's no much of a githistory for this kernel 

 

If I wouldn't care about a git history I wouldn't mention it... Towards RKs kernel.. It has a githistory, but as they stated:

It all comes from their internal BSP and

Quote

the github release branch is  not maintained directly by BSP team, so it may not have maintained good enough now, I will sync with the maintainer,

 

They do a good job, and I stated it multiple time that I'm happy to have a kernel which is developed in public. It has its own issues. e.g. 

https://github.com/rockchip-linux/kernel/issues/98

https://github.com/rockchip-linux/kernel/issues/116

As one being involved in those chronicles, I'm not 100% happy with it. Some background: We were close to bring up the camera for the Tinker, and since they share the ISP (or at least its driver) with RK3399, means we were also close to bring up camera for the RK3399 boards with a MIPI interface (it's just a DT difference and maybe a TC35874X node would be needed depending on how it is solved on the board)..  before things like this or this happened. Since some of their commits where a bit older, they didn't show up properly in the git log so going through the log and just say: stop here, cause here they messed up wasn't possible.. That was a pain and still is a pain and probably why this thread was opened. 

 

9 hours ago, tkaiser said:

As in 'now we need to support this new platform since board vendor did what he had to do anyway'. Yeah! Sure, let's add more SoC families to Armbian. That's what is truly needed. More boards, less quality.

 

On 9/20/2018 at 7:48 PM, chwe said:

I completely agree that at least a headless usable mainline based linux should be available before we start to support a new SoC. I also agree that support SoCs which have only one available board is questionable (the efforts maintaining just a new set of kernels BSP/Mainline is just too much for one board - expect the MT7623 for which I might prepare a PR as soon as we reach the next LTS kernel, it works without major issues on mainline without patching, so it's only an adjustment of the config file, something I think isn't that much work I may write a THS patch cause those settings are IMO a bit conservative).

doesn't need to write the same stuff again. Mainline is far away from being usable headless, and there isn't any other board based on this SoC, so where do you get a: Let's support it with armbian now out of it? But due to the information you had before they released the sources it was obvious that you won't suggest armbian support for it. That's why I think mhmm.. well this is something which could be done from the beginning. 

 

9 hours ago, tkaiser said:

I have no idea why we currently support way too much boards we can handle

we had a board bring up for this... https://forum.armbian.com/forum/22-board-bring-up/

Last created thread there: BananaPi R2 (.csc mt7623 as new boardfamily) May22

And to be fair, I would count @hjcs 'Firefly RK3399 support efforts (potential csc board?) ' from june also as such thread. We don't write those threads. Not for the RK3399 based ones not really for the H6 based (there's one overview thread, no per board). Features wise the RK3399 is probably the most interesting platform with proper sources (in terms of price vs. horse power & interfaces). It's fairly well mainlined in kernel and u-boot. But even then, proper board bring ups should be written. And we either can stop to support new boards, find new contributors or drop boards.

 

Edit: @parrotgeek1 thanks for the code overview in https://github.com/BPI-SINOVOIP/BPI-W2-bsp/issues/1#issuecomment-423584202

Quote

@ThomasKaiser I am somewhat wrong in my initial assessment. The platform code is fine (uses 100% device trees, very clean) but the video/audio/decoder drivers are just horrifying. Almost like 2 different teams.

 

would mean the SBCs main purpose (doing 'fancy' audio/video encoding decoding stuff) would be at least 'questionable' even when someone would rebase it on top of a vanilla 4.9 kernel?

Share this post


Link to post
Share on other sites
On 6/3/2018 at 6:42 AM, Юрий Долгорукий said:
  • Realtek RTD1296, Quad-core ARM Cortex-A53
  • Mali T820 MP3 GPU
  • 2G Nox Vidmate VLC DDR4 SDRAM
  • PCIE 2.0 interface.PCEe 1.1&SDIO
  • 2 SATA interface
  • Mini DP
  • HDMI In/Out

 

w2-0.jpg

Is it planned to support (create an ARMBIAN firmware) this board?

I will not reply any messages to you. the best way : You can show your support or stand by and look,

Share this post


Link to post
Share on other sites
On 9/19/2018 at 11:19 PM, tkaiser said:

We can't trust Android vendor's BSP kernels since those employees forced to hack driver support into something they're not interested in (the Linux kernel and its concepts) never worked with mechanisms like peer review or code quality control. If those employees would've started to submit patches upstream where all this stuff happens (Linux kernel community) then this would be something entirely different. But RealTek just like Allwinner and the majority of ARM SoC vendors has no interest in properly upstreaming their code so this code can't be trusted

 

I always worry about Android kernels in any event - looking at AOSP vs the Android OEM closed stuff, drivers can be a real pain - so I basically discount it - nice for study perhaps, but Android is about as open as my closed fist.

 

Android is heavily based on Linux (as is ChromeOS), but it's not Linux, except in the very narrow case - so it makes it a real challenge.

 

(apologies to the AOSP and ChromiumOS teams, the work they do is good - sometimes just not useful)

 

Anyways - with SoC vendors in general - I'd like to see mainline first, not as a second thought - when I get a BSP for an SoC, and it's likely old, so to bring it up to current - even simple things like UART can be abstracted into a vendor specific thing, and with many SoC's, it's not just the primary Application Processor (that might be open), but there is the underlying stuff that just is not cleanly documented...

 

I've seen projects where you think you're running clean on a Cortex-something or other, but underneath, there is an ARM11 running all the IO, with a shim looking up into what the ARM11 things is an application - so one has to deal with abstracts - this is not good... 

 

If one is trying to get close to the metal - these Android based BSP's are very, very difficult to work with.

 

Just my two cents.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
3 3