BPI-R2 new image: BPI-R2 OpenWrt(LEDE) Souce code : 2018-05-09


(Daniel) #187

I compiled an openwrt image using this source :

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

(Frank W.) #188

Maybe

dmesg -D

I don’t know if it is available in openwrt/lede…


(Daniel) #189

root@LEDE:~# dmesg -D dmesg: unrecognized option: D

I changed printk values to 2 4 1 7…without success. Defaults are : root@LEDE:~# cat /proc/sys/kernel/printk 8 4 1 7

I build few sysupgrade images to which I disabled various kernel debug options and no luck so far.


(Frank W.) #190

maybe

dmesg -n 1

if you have a /etc/sysctl.conf you can try to add this:

kernel.printk = 3 4 1 3

maybe you can change it by bootargs

loglevel=<number>

try 3 as number (without <>) here, see kernel loglevels


(Alexey Loukianov) #191

Hi Gary,

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:

  1. 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?

  2. 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?

  3. 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?

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

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

  6. 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?

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

  8. 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 in advance for answers. Regards, Alexey


(gary) #192

@Jackzeng Please help answer Alexey’s questions.


(ZB) #193

hello,thanks for your questions and advice, I could answer you in brief, we could discuss more detail in future.

1:yes,we are preparing 18.06 code.

2:R2 mainline is supported by mtk team,they help a lot.

3:frank works for linux kernel mainline mainly, if he could help in openwrt, that would be better.

4:R2 supports Vlan

5: for hardware NAT acceleration doesn’t need to configure by software.

6: we could think about boot from emmc, and mount rootfs on SATA,and we have wiki docs now,but still need to improve it.

http://wiki.banana-pi.org/Getting_Started_with_R2

7:yes,it controls where R2 boot from,but if don’t have sd,it will boot from emmc.


(Frank W.) #194

I don’t know openwrt-internals because i have only debian/ubuntu-systems running. So i can only answer generic questions