hi, you can build one for r1 plus (not lts).
thanks.
I built one a week or so go and it seems fine
Can you show me how can do it?
I don't know how to build custom fw for myself.
Thanks.
https://github.com/orangepi-xunlong/openwrt
Should get you started.
Step 3 of Quickstart is where you will need to configure a few things
Here are the minimal steps
$ make menuconfig
target System Select Rockchip
Subtarget Select RK33xx boards (64 bit)
Target Profile Select Xunlong OrangePi R1 Plus
Exit by typing <esc><esc>
Save Configuration
$ make -j5
This will probably take over one hour.
You may get a warning or two. They should be OK
Errors are in RED
If all works OK then copy the image in
.../21.02/bin/targets/rockchip/armv8/openwrt-rockchip-armv8-xunlong_orangepi-r1-plus-squashfs-sysupgrade.img.gz
to an SD Card and boot in OrangePi
Good Luck
1 Like
Someone make a good build and video guide. Why it still not support by official openwrt?
pls update kernel version.
i cant install wireguard, because
Details for package kmod-wireguard
Version: 5.4.179-1
Size: ~36.5 KB installed
Dependencies:
kernel VERSION INCOMPATIBLE
kmod-crypto-lib-blake2s (4.6 KB) NOT INSTALLED
kmod-crypto-hash (241 B) NOT INSTALLED
kmod-crypto-lib-chacha20poly1305 (4.0 KB) NOT INSTALLED
kmod-crypto-lib-chacha20 (5.7 KB) NOT INSTALLED
kmod-crypto-lib-poly1305 (4.5 KB) NOT INSTALLED
kmod-crypto-lib-curve25519 (19.4 KB) NOT INSTALLED
kmod-crypto-kpp (1.7 KB) NOT INSTALLED
kmod-udptunnel4 (2.9 KB) NOT INSTALLED
kmod-udptunnel6 (2.2 KB) NOT INSTALLED
Description
WireGuard is a novel VPN that runs inside the Linux Kernel and utilizes state-of-the-art cryptography. It aims to be faster, simpler, leaner, and more useful than IPSec, while avoiding the massive headache. It intends to be considerably more performant than OpenVPN. WireGuard is designed as a general purpose VPN for running on embedded interfaces and super computers alike, fit for many different circumstances. It uses UDP.
The installed version of package kernel is not compatible, require 5.4.179-1-a76fa007… while 5.4.179-1-7d37680f… is installed.
I might try to do a vanilla OpenWrt 22.03.1 build and just pull in the device support patches from the Orange Pi version. My previous 21.02.1 build has been running for 287+ days:
1 Like
I just finished builds of stock OpenWrt 22.03.2 with patches from the xunlong repo that add support for the R1 Plus and R1 Plus LTS (update: removed LTS builds after report of them not working)
It includes kernel 5.10, luci + luci-https, adblock, banip, legacy firewall, wireguard, sqm, ddns, curl, and nano. Since it is based on 22.03.2, additional packages from the repo should work (not sure about kernel modules though). Root partition is 512MB.
I just yolo flashed a remote device over a wireguard connection using the R1 Plus squashfs build and luckily it worked. I have not tested the other 3 builds.
R1 Plus squashfs:
https://drive.google.com/file/d/1zdHlI9AmwGFTeu7ZPiJSloLMyvZMKBcD/view?usp=sharing
R1 Plus ext4:
https://drive.google.com/file/d/1o7nHU0q7lPAz6Y0fq0x4suCx_UWUv3HX/view?usp=sharing
1 Like
Very good job, I appreciate that you are posting these. This version/kernel seems even smoother. Running collectd stats along with everything OpenWRT normal, I'm averaging 48M RAM usage on my OP-R1_Plus:
Thanks for your work.
Unfortunately the image for r1 lts does not seem to boot. The orange LED flashes on the WAN side and the interface does not request a dhcp lease. Nothing behind the lan too.
Tried both ext4 and squashfs 
That's great work. Do you by any chance have the merged/patched versions in a github repo so that folks can start conversing around this? It seems the orangepi has stopped maintaining their repo after 21.02, no surprises unfortunately.
Thanks!
Thanks for testing, I took down the LTS builds. Unfortunately I don't have an LTS to test with, so I'm not sure I'll be able to figure it out.
I just created a fork on github for the R1 Plus based on 22.03. Looks like I missed one patch for the LTS in the previous build so I pulled that in and hopefully LTS builds will work now. Doing an initial test build now. To try your own build:
$ git clone https://github.com/walmartshopper/openwrt-orangepi-r1-plus.git
$ cd openwrt-orangepi-r1-plus
$ git checkout v22.03.2-orangepi-r1plus
$ ./scripts/feeds update -a
$ ./scripts/feeds install -a
$ make menuconfig
- select Target System = Rockchip
- select Target Profile = Xunlong OrangePi R1 Plus or Xunlong OrangePi R1 Plus LTS
- select your root partition size and whatever packages you want to include
- exit
$ make download
$ make world
If it completes without errors, the builds should be under bin/targs/rockchip/armv8
Note: if you want to include banip, it is currently marked as @BROKEN in the makefile because it does not yet support firewall4. After you install the feeds, you will need to edit the Makefiles under feeds/luci/applications/luci-app-banip and feeds/packages/net/banip and remove the "@BROKEN". Then in make menuconfig, you will now be able to select Luci > Applications > luci-app-banip. You will also need go into Base System and select firewall instead of firewall4.
If we get some reports of success for both LTS and non-LTS builds using this repo, we can try to submit it upstream for official support.
Can you try these new builds? I found an LTS patch that did not get applied to the previous non-working build. Hopefully it works now.
LTS squashfs:
https://drive.google.com/file/d/1VbC8gVn4A7UW4MS7O5TxLPmqRT4PBJWb/view?usp=sharing
LTS ext4:
https://drive.google.com/file/d/1RxgYQe44Blh3_0JHj37tisbV08IDCCs6/view?usp=share_link
This was built from the new fork I just set up (see above post), so if it works then you can do your own builds if you want.
Thanks for sharing the repo and images.
I tried testing your compiled LTS image and my own built image from your repo, unfortunately neither works. I noticed that the LAN activity led just stays solid green without any activity. The WAN activity blinks green as expected, but not sure if it's working because I can't access the device due to the lack of LAN connectivity.
@walmartshopper I created a PR which looks like it may have been missed. It initializes the network interfaces, which could explain why the LAN interface was having issues.
I built it with this update and I am able to connect and restore my configs from 21.02. Everything looks good so far.
There was also an issue compiling iproute2, which based on this bug, libbpf also needs to be enabled in the config. Appears to be fixed upstream
Thanks for figuring that out, I also cherry picked it to master. Did a new LTS build with the extra patch. Banip seems to not be working even with the legacy firewall, so I removed it from this build and changed to firewall4:
squashfs:
https://drive.google.com/file/d/1PCrMgWWwXy0Tv5Mu9ZN5388kcC3M9TvN/view?usp=share_link
ext4:
https://drive.google.com/file/d/1r0-qA7n5mJnrT_AIAIVywJG5Hvv8GXPo/view?usp=share_link
Also did a release
Thanks! I've running the version (edit: big omission, I built it from sources in your repo and not used the already compiled binary you provided) before adding the patches referred by @pitchdarkice in an Orange Pi R1 Plus LTS with an uptime of 2d 23h 5m 12s. It had a kernel panic and some USB resets (I don't know if they are triggered by the USB Ethernet driver when the device fails to communicate):
[79826.228881] ------------[ cut here ]------------
[79826.229369] NETDEV WATCHDOG: eth1 (r8152): transmit queue 0 timed out
[79826.230063] WARNING: CPU: 2 PID: 0 at net/sched/sch_generic.c:467 dev_watchdog+0x2f8/0x300
[79826.230796] Modules linked in: zstd xt_quota xt_pkttype xt_physdev xt_owner xt_cgroup xt_addrtype nft_compat lzo_rle lzo br_netfilter ip6table_nat ip6t_NPT ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT veth btrfs xor zstd_decompress zstd_compress xor_neon raid6_pq lzo_decompress lzo_compress crypto_acompress pppoe ppp_async nft_fib_inet nf_flow_table_ipv6 nf_flow_table_ipv4 nf_flow_table_inet iptable_nat xt_state xt_nat xt_conntrack xt_REDIRECT xt_MASQUERADE xt_CT wireguard pppox ppp_generic nft_reject_ipv6 nft_reject_ipv4 nft_reject_inet nft_reject nft_redir nft_quota nft_objref nft_numgen nft_nat nft_masq nft_log nft_limit nft_hash nft_flow_offload nft_fib_ipv6 nft_fib_ipv4 nft_fib nft_ct nft_counter nft_chain_nat nf_tables nf_nat nf_flow_table nf_conntrack libchacha20poly1305 iptable_mangle iptable_filter ipt_REJECT ip_tables chacha_neon cdc_ncm cdc_ether xt_time xt_tcpudp xt_multiport xt_mark xt_mac xt_limit xt_comment xt_TCPMSS xt_LOG x_tables usbnet slhc r8152 poly1305_neon
[79826.231506] nfnetlink nf_reject_ipv6 nf_reject_ipv4 nf_log_ipv6 nf_log_ipv4 nf_log_common nf_defrag_ipv6 nf_defrag_ipv4 libcurve25519_generic libchacha crc_ccitt ip6_udp_tunnel udp_tunnel sha256_generic libsha256 kpp gpio_button_hotplug
[79826.241065] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 5.10.146 #0
[79826.241607] Hardware name: Xunlong Orange Pi R1 Plus LTS (DT)
[79826.242129] pstate: 20000005 (nzCv daif -PAN -UAO -TCO BTYPE=--)
[79826.242671] pc : dev_watchdog+0x2f8/0x300
[79826.243037] lr : dev_watchdog+0x2f8/0x300
[79826.243397] sp : ffff800010f9bd70
[79826.243699] x29: ffff800010f9bd70 x28: ffff800010b435a8
[79826.244187] x27: 00000000ffffffff x26: 0000000000000002
[79826.244674] x25: ffff0000016ac480 x24: 0000000000000140
[79826.245166] x23: ffff0000016ac3dc x22: ffff0000016b0480
[79826.245655] x21: ffff800010c66000 x20: ffff0000016ac000
[79826.246144] x19: 0000000000000000 x18: 0000000000000030
[79826.246632] x17: 0000000000000000 x16: 0000000000000000
[79826.247119] x15: ffff800090f9ba47 x14: 0000000000000006
[79826.247606] x13: ffff800010c7d200 x12: 000000000000042c
[79826.248093] x11: 0000000000000164 x10: ffff800010c7d200
[79826.248580] x9 : ffff800010ddd200 x8 : 00000000ffffc000
[79826.249070] x7 : ffff800010c7d200 x6 : 0000000000000003
[79826.249558] x5 : 0000000000000000 x4 : 0000000000000000
[79826.250046] x3 : ffff800010c6b9f8 x2 : 0000000000000004
[79826.250534] x1 : ffff0000004e3000 x0 : 0000000000000039
[79826.251021] Call trace:
[79826.251256] dev_watchdog+0x2f8/0x300
[79826.251603] call_timer_fn.constprop.0+0x24/0x80
[79826.252025] __run_timers.part.0+0x1d4/0x20c
[79826.252417] run_timer_softirq+0x3c/0x74
[79826.252777] _stext+0x124/0x290
[79826.253071] irq_exit+0xdc/0xfc
[79826.253367] __handle_domain_irq+0x80/0xe0
[79826.253744] gic_handle_irq+0x58/0xe0
[79826.254081] el1_irq+0xc8/0x180
[79826.254378] cpuidle_enter_state+0x134/0x31c
[79826.254768] cpuidle_enter+0x38/0x50
[79826.255102] do_idle+0x1d8/0x230
[79826.255400] cpu_startup_entry+0x24/0x60
[79826.255763] secondary_start_kernel+0x128/0x150
[79826.256172] ---[ end trace 5cf52343c127ce81 ]---
[79826.256651] r8152 4-1:1.0 eth1: Tx timeout
[79828.289359] r8152 4-1:1.0 eth1: Tx status -2
[79828.289854] r8152 4-1:1.0 eth1: Tx status -2
[79828.290320] r8152 4-1:1.0 eth1: Tx status -2
[79828.290790] r8152 4-1:1.0 eth1: Tx status -2
[79829.003633] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci-hcd
[79829.042146] r8152 4-1:1.0 eth1: Promiscuous mode enabled
[80516.247954] r8152 4-1:1.0 eth1: Tx timeout
[80516.251282] r8152 4-1:1.0 eth1: Tx status -2
[80516.251733] r8152 4-1:1.0 eth1: Tx status -2
[80516.252165] r8152 4-1:1.0 eth1: Tx status -2
[80516.252592] r8152 4-1:1.0 eth1: Tx status -2
[80518.411699] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci-hcd
[80518.448794] r8152 4-1:1.0 eth1: Promiscuous mode enabled
[247936.034216] r8152 4-1:1.0 eth1: Tx timeout
[247938.074888] r8152 4-1:1.0 eth1: Tx status -2
[247938.075384] r8152 4-1:1.0 eth1: Tx status -2
[247938.075846] r8152 4-1:1.0 eth1: Tx status -2
[247938.076318] r8152 4-1:1.0 eth1: Tx status -2
[247938.778987] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci-hcd
[247938.815254] r8152 4-1:1.0 eth1: Promiscuous mode enabled
[249646.081561] r8152 4-1:1.0 eth1: Tx timeout
[249648.122142] r8152 4-1:1.0 eth1: Tx status -2
[249648.122634] r8152 4-1:1.0 eth1: Tx status -2
[249648.123111] r8152 4-1:1.0 eth1: Tx status -2
[249648.123587] r8152 4-1:1.0 eth1: Tx status -2
[249648.826977] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci-hcd
[249648.864058] r8152 4-1:1.0 eth1: Promiscuous mode enabled
But I remember seeing that also with a build of OpenWrt 21.02 from Xunlong repo and I vaguely remember reading something about fixes for this issue included in kernel 5.15. In any case, the WAN interface seems to keep working.
It will have to be something to see if I encounter it in a few days. I didn’t have any issues with the xunlong 21.02 build, but that was on kernel 5.4. Will have to see how this 5.10 holds up.
Interesting you were able to get LAN working without the network update.