All my needs are met, except the log spam messages when I access the samba usb share.
I believe there is a kernel debug usb option enabled…but I don’t know where to find it.
I already tried a new kernel compiled with “CONFIG_KERNEL_DEBUG_KERNEL off” and “CONFIG_KERNEL_DEBUG_INFO off” without success.
Anyone have an idea how to get rid of these messages?
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.548775] scsi cmd done, result=0x0
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.552490] *** thread sleeping
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.555746] *** thread awakened
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.559006] Command (unknown command) (16 bytes)
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.563753] bytes: 88 00 00 00 00 00 e4 ff 18 d0 00 00 00 08 00 00
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.569981] Bulk Command S 0x43425355 T 0xfee L 4096 F 128 Trg 0 LUN 0 CL 16
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.577126] xfer 31 bytes
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.579866] Status code 0; transferred 31/31
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.584169] -- transfer complete
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.587552] Bulk command transfer result=0
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.591631] xfer 4096 bytes, 1 entries
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.595526] Status code 0; transferred 4096/4096
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.600280] -- transfer complete
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.603537] Bulk data transfer result 0x0
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.607605] Attempting to get CSW...
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.611231] xfer 13 bytes
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.613970] Status code 0; transferred 13/13
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.618348] -- transfer complete
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.621635] Bulk status result = 0
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.625063] Bulk Status S 0x53425355 T 0xfee R 0 Stat 0x0
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.630559] scsi cmd done, result=0x0
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.634313] *** thread sleeping
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.637483] *** thread awakened
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.640620] Command (unknown command) (16 bytes)
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.645407] bytes: 88 00 00 00 00 00 e5 3e 61 00 00 00 00 08 00 00
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.651570] Bulk Command S 0x43425355 T 0xfef L 4096 F 128 Trg 0 LUN 0 CL 16
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.658743] xfer 31 bytes
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.661403] Status code 0; transferred 31/31
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.665773] -- transfer complete
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.668997] Bulk command transfer result=0
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.673101] xfer 4096 bytes, 1 entries
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.677047] Status code 0; transferred 4096/4096
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.681754] -- transfer complete
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.685028] Bulk data transfer result 0x0
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.689120] Attempting to get CSW...
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.692752] xfer 13 bytes
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.695432] Status code 0; transferred 13/13
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.699814] -- transfer complete
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.703151] Bulk status result = 0
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.706550] Bulk Status S 0x53425355 T 0xfef R 0 Stat 0x0
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.712024] scsi cmd done, result=0x0
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.715835] *** thread sleeping
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.719095] *** thread awakened
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.722296] Command (unknown command) (16 bytes)
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.727073] bytes: 88 00 00 00 00 00 e4 ff 01 00 00 00 00 08 00 00
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.733273] Bulk Command S 0x43425355 T 0xff0 L 4096 F 128 Trg 0 LUN 0 CL 16
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.740411] xfer 31 bytes
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.743160] Status code 0; transferred 31/31
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.747547] -- transfer complete
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.750764] Bulk command transfer result=0
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.754965] xfer 4096 bytes, 1 entries
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.758914] Status code 0; transferred 4096/4096
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.763555] -- transfer complete
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.766868] Bulk data transfer result 0x0
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.770861] Attempting to get CSW...
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.774592] xfer 13 bytes
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.777343] Status code 0; transferred 13/13
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.781667] -- transfer complete
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.784917] Bulk status result = 0
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.788385] Bulk Status S 0x53425355 T 0xff0 R 0 Stat 0x0
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.793881] scsi cmd done, result=0x0
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.797605] *** thread sleeping
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.800840] *** thread awakened
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.804152] Command (unknown command) (16 bytes)
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.808826] bytes: 88 00 00 00 00 00 f3 be 11 00 00 00 00 08 00 00
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.815082] Bulk Command S 0x43425355 T 0xff1 L 4096 F 128 Trg 0 LUN 0 CL 16
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.822086] xfer 31 bytes
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.824765] Status code 0; transferred 31/31
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.829099] -- transfer complete
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.832318] Bulk command transfer result=0
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.836558] xfer 4096 bytes, 1 entries
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.840491] Status code 0; transferred 4096/4096
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.845224] -- transfer complete
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.848572] Bulk data transfer result 0x0
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.852562] Attempting to get CSW...
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.856206] xfer 13 bytes
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.858964] Status code 0; transferred 13/13
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.863333] -- transfer complete
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.866618] Bulk status result = 0
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.870017] Bulk Status S 0x53425355 T 0xff1 R 0 Stat 0x0
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.875478] scsi cmd done, result=0x0
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.879228] *** thread sleeping
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.882503] *** thread awakened
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.885766] Command (unknown command) (16 bytes)
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.890453] bytes: 88 00 00 00 00 00 e5 7e 41 00 00 00 00 08 00 00
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.896709] Bulk Command S 0x43425355 T 0xff2 L 4096 F 128 Trg 0 LUN 0 CL 16
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.903898] xfer 31 bytes
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.906629] Status code 0; transferred 31/31
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.911009] -- transfer complete
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.914341] Bulk command transfer result=0
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.918490] xfer 4096 bytes, 1 entries
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.922422] Status code 0; transferred 4096/4096
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.927127] -- transfer complete
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.930353] Bulk data transfer result 0x0
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.934374] Attempting to get CSW...
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.938034] xfer 13 bytes
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.940764] Status code 0; transferred 13/13
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.945197] -- transfer complete
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.948419] Bulk status result = 0
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.951808] Bulk Status S 0x53425355 T 0xff2 R 0 Stat 0x0
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.957264] scsi cmd done, result=0x0
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.961017] *** thread sleeping
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.964263] *** thread awakened
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.967400] Command (unknown command) (16 bytes)
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.972072] bytes: 88 00 00 00 00 00 e5 7e 31 00 00 00 00 08 00 00
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.978392] Bulk Command S 0x43425355 T 0xff3 L 4096 F 128 Trg 0 LUN 0 CL 16
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.985501] xfer 31 bytes
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.988230] Status code 0; transferred 31/31
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.992553] -- transfer complete
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6736.995842] Bulk command transfer result=0
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6737.000005] xfer 4096 bytes, 1 entries
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6737.003913] Status code 0; transferred 4096/4096
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6737.008592] -- transfer complete
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6737.011818] Bulk data transfer result 0x0
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6737.015924] Attempting to get CSW...
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6737.019562] xfer 13 bytes
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6737.022211] Status code 0; transferred 13/13
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6737.026553] -- transfer complete
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6737.029876] Bulk status result = 0
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6737.033315] Bulk Status S 0x53425355 T 0xff3 R 0 Stat 0x0
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6737.038788] scsi cmd done, result=0x0
Thu Jan 31 15:38:21 2019 kern.debug kernel: [ 6737.042444] *** thread sleeping
I had recently bought myself BPi R2 board to evaluate the possibility to use in in place of existing linux-based x86 mini-server that handles NAT and routing over several internal and VPN networks (OSPF2 used for automated routing table management as implemented in quagga/zebra), acts as a primary DNS server for several intranet-only and public domains, provides HTTP(s) traffic filtering and cacheing through squid and acts as a corporate MTA and SMTP relay with full-blown in-flight virus and spam filtering for in-transit mail. Existing server is an anciet one (~8 y.o.) but it is able to cope with the load really well – mostly due to a fact that the load level is low to none.
My target OS of choice for BPi R2 is the OpenWRT as I had been using (and developing for) it for ages – like 8+ years. When I was considering if BPi R2 is a viable choice I’ve seen that there’s a vendor-supported fork of OpenWRT/LEDE for this board that is recent enough to make the purchase viable. I do not care about WiFi support as in general the quality of linux open source WiFi drivers as they ship with OpenWRT has a long-standing history of being bad compared to vendor-based closed source solution. It might be OK to use OpenWRT-based device as a WiFi AP for a home use when the speed and reliability of the connection is not that important but for SOHO and small corporate use one would have to use DD-WRT at the very lease or to stick with an external AP solution using vendor-supplied binary blob firmware. For me it mean that I only care about 2xSATA and 5x1000baseT side of specs. Thus I had ordered myself a BPi R2 board coupled with a “metal” case that is suitable to hold two 2.5" HDDs inside. Parcel arrived a week ago so I had started to gather more info on what is what with BPi R2.
Following is a list of questions I had gathered so far that I am interested to get answers for:
What should I expect from the support PoV for the OpenWRT distro for this board? As far as I can see last vendor-provided update was this very forum thread that uses upstream commit cdb494fd as a base. It dates back to Aug 2017. Are there any plans to rebase bpi-r2 support patches to more recent upstream versions like 18.06.2 that was released recently?
What is the status of mainlining BPi R2 specific kernel patches? Are there any hopes of getting them mainline or is it the usual “China low cost sh**ty board” case with no attempts to provide normal upstream support from the vendor side?
Kernel version for vendor fork of OpenWRT seems to be a quite outdated 4.9.44. I’ve seen more recent kernels available for this board from some friendly chaps on this forum, namely from frank-w. Any chance to get them integrated into the vendor’s fork of OpenWRT?
Looking at the live system running vendor’s OpenWRT fork I can see that DSA was used to support internal board switch chip. That is a good thing but I’m wondering to a what degree DSA had been implemented for this board. Does DSA implementation use the hardware acceleration for linux bridges? What about VLAN support? I do need it, as board will be connected to top-of-the-rack dedicated switch with several networks that BPi R2 will be tasked to route between being put into a single port as different VLANs (bandwidth is not an issue here as it is a full duplex gigabit port with networks routed being fast Ethernet based).
Are there any documentation available on how to configure and use MTK hardware NAT acceleration? I can see some files that are related to it in the /etc/config directory but still would like to get some adequate docs to read instead of trying to figure it out on a try-and-fail basis.
What about image filesystem support for something other than squashfs + jffs2? Having pure ubifs or jffs2 based system running from eMMC would be of a great joy instead of using squashfs coupled with overlayfs on the jffs2. Even better possibility would be to have rootfs (and – if possible – kernel) to be located on the SATA devices the same way it was traditionally done for linux-based servers: boot partition on md raid1 coupled with LVM2-based storage on second raid1 partition. Is it possible to force BPi R2 u-boot to boot from SATA device? Are there any docs out there for u-boot variant that BPi R2 uses?
I can see SD<->eMMC switch soldered to the board. But I hadn’t seen any docs on “getting started” page outlining the functionality of this switch. What is it for? How to use it properly? Will u-boot boot from eMMC instead of SD in case switch is set to “SD” position but there is no SD card inserted into the device?
Where to look for documentation of the onboard buttons? Which one does what? What is “R” button for? Are there any “hidden” features to access by some actions like “hold R button for X seconds and then….”?
Thanks for providing so extensive answers *sarcasm*.
“Preparing 18.06”: it’s almost Q2 of 2019 now, 18.06.2 is already out and there’s even a some form of “official upstream support” for R2 from OpenWRT team - at least they do generate images that are available to download from their site. I understand that your resources are scarce but won’t it be smarter to cooperate with OpenWRT guys in getting official image into a better shape rather than falling into the usual pit trap China manufactures tend to fall by providing a low quality and outdated software for their otherwise high quality products?
Your answer contain no information actually answering original question. It is good that Mediatek team is helping with getting mainline support for their products. What’s about actual state of things? Any ETAs for two GPHYs in mainline? For hwnat? I believe that required kernel infrastructure support for HW nat accelerators was merged quite some time ago, so are there anybode out in a wild working on implementing it for R2? I have no hopes for WiFi driver to ever land to compat-wireless - Mediatek has a well known record with bad wireless drivers. What is the status of VLAN support and its compatibility with DSA in mainline? I can go on with the list but these are main ones to deal with first IMO.
Ok, thx. I think that it’d be easier for me to have a direct chat with frank regarding porting his changes to openwrt kernels. Looks like a more productive thing than simply waiting with hope.
And that’s your answer? Really? How exactly does it “suppor VLAN”? Which kernel version should I use? How does it co-exist with DSA? You hadn’t provided any answer for DSA implementation degree. Does it use HW acceleration or is it a simple fallback to software-based bridging?
What do you mean by “no need to configure anything in software”? Does it mean that I can configure iptables-based NAT and it will work? Or should it be nftables instead? What about QoS implementation?
It is obvious that it’s technically possible to have rootfs on any device supported by the linux kernel in case we boot this kernel from eMMC or SD card. But my question was if there were a special u-boot for R2 + an internal support to load this u-boot from SATA. Judging from your answer my conclusion is that there’s no such thing available.
this is currently in discussion between DSA-Maintainer how this should be implemented. My current way (define cpu-port in dts) is too static…they prefer a user-configurable option to change the mapping (maybe via ip command). Just follow patchset i’ve posted to Mediatek-Mailinglist
I want to install “Openvswitch” in R2 using this source code. But I can’t select package of Openvswitch in “Network >Open vSwitch”.
And there are no “kmod-openvswitch” to be selected in “Kernel modules > Network Support”.
If I choose other “Target System” , such as “Atheros AR7xxx/AR9xxx”. Packages of openvswitch and kmod-openvswitch are available.
Yeah, frank, thanks for pointing to that patchset. I know that original DSA RFC and implementation had some limitations with lack of support for two CPU ports being one of them. It’s nice to know that there’s a competent person trying to work on getting rid of this limitation, thanks a lot for this.
Back at it after an illness and hospital stay. I have a Banana Pi R2 and now am looking for either OpenWRT or Ubuntu build that us stable and offers full use of ALL eth ports and USB and HDMI. I know not asking for much. Also if a little coaching could be offered to get everything downloaded and installed that would be excellent.
-Brian-
OpenWRT is not a good choice if you’re aiming at using HDMI and local console. I think better off would be to take a look at latest Debian Buster image from Frank.
