Orange Pi R1

[tkaiser]

(picture courtesy @renaudrenaud)

 

We spotted a new OPi Zero variant with one USB-A receptacle missing and replaced by a second RJ45 jack a while ago (in this report where a lot of 'information' seems a bit questionable to me)

 

Today @Icenowy confirmed existence of this board since Xunlong announced it in a chat group. I believe this is somewhat related to recently available Orange Pi Zero Plus since by looking at the picture we can see behind both Ethernet MagJacks small packages. My bet is we're talking here about RTL8211E (Gigabit Ethernet PHY connected via RGMII to the SoC) and RTL8153 (Gigabit Ethernet MAC/PHY USB2 Hi-Speed attached to the SoC). The SoC is most probably Allwinner's H5 since everything else would be a bit stupid (choosing H2+/H3 over H5 only makes some sense if you're after display output but fortunately there's no HDMI on this board). If my above assumptions are all correct (to be confirmed, I've not talked to Xunlong's Steven for more than half a year) then we deal with the following:

 

• Orange Pi R1 software support done once OPi Zero Plus is supported (only relevant part here: H5 mainline support matured and then adjusting device tree to use Gigabit Ethernet with an external PHY )
• Ethernet performance: 940 Mbits/sec on the RTL8211E port and +350 Mbits/sec on the RTL8153 port (both ports physically separated so unlike some board fails like Banana Pi R1 this device separates the two Ethernet ports physically even in bricked state)
• Most probably 512 MB single bank DRAM configuration (ok for routing use cases, not that great for NAS use cases since USB2 storage is slower than network and so the more DRAM is the better to buffer writes to the board in memory before flushing to disk)
• Possibility to combine this Zero with available Expansion boards (eg. NAS Expansion board or the $2 thing with exposes the two other USB2 ports and other interfaces)
• Based on OPi Zero Plus price tag I would expect this here to go for less than $18 (also tbc)

 

So let's wait for official information, schematics and price tag and then decide what to do (if the above is correct I vote for official support once requirements are met).

 

Edit: silly me, I should've better checked Icenowy's pictures before

 

So it's H2+, I'm not that sure about Gigabit Ethernet capabilities with this OPi R1 any more and the board has wireless capabilities. Anyway... then this OPi R1 is not what I was waiting for and you can treat all of my above writing as a wishlist for an OPi R1 Plus (or whatever Xunlong's crazy naming scheme allows to describe a dual GbE capable OPi)

 

Edit 2: After some more looking at the pictures it seems we're talking about 2 x 100Mbits/sec max. H2+ is said to support only Fast Ethernet (though SinoVoip claims the opposite) but to be able to use GBit Ethernet you would need an external PHY like RTL8211E (48 pins package). For USB-Ethernet also a separate chip is needed but since one of the two chips if for wireless the other one must be USB-Ethernet and based on package format (24 pins) it can't be GbE (RTL8153). So it seems we're talking about H2's internal PHY routed to one MagJack and a Fast Ethernet RTL8152 behind the other MagJack connected to usb1. In other words: waiting for OPi R1 Plus  

 

Edit 3: According to a somewhat official Xunlong announcement the Wi-Fi is 'RTL 88189 ETV' -- there exists RTL8818, there exists RTL8189 but no 88189 (visiting most vendor forums is such an insane waste of time). At least judging by pictures it seems to be RTL8189ETV which is good news for users since 8189es driver is part of Armbian OS images with both kernel variants.

[Tido]

I understand the 'R' in the naming scheme for R=Router but  does it have to be just like BPi.  Why not RT1 or such. This sucks.

mistaken identity are ahead

[zador.blood.stained]

It's still a useful board IMO since it can be used i.e. for transparent VPN proxying where due to CPU preformance you wouldn't be able to saturate even 100Mbit link, and also not everybody in this world has uplink speed higher than 100Mbit (especially in SOHO class environment).

 

@tkaiser In the BPi R2 thread you are talking about splitting multimedia and router to different devices which is not really necessary if/when R2 gets a proper mainline support because if GPU, VPU and display engine are completely disabled you don't have to worry about them as possible security threats. And I think that splitting NAS and router (which connects to untrusted network from one side) is a must too. So let's leave the Zero Plus for the NAS duties, this board for for a simple router or AP and let's hope for an upgraded version (don't know if you could fit a gigabit PHY and a gigabit USB Ethernet chip in this form factor) if this one becomes popular enough.

[martinayotte]

@Igor, is Steven planned to ship us Dev's samples ?

 

[reverend_t]

What a wasted opportunity. Even an H5 sitting behind a 3 port switch chip would have been fantastic (as long as the switch was booted in the sane deny all connections mode) as the switch could have taken easy care of switching packets on the same VLAN and brought in the SOC to handle inter VLAN stuff (Netgate's horrifically overpriced sg-1000 is essentially this).

 

(At some point I'm really hoping someone combines an RK3328 with an ax88179 and a decent switch chip so that we can have a genuine dual nic gigabit routing device)

[tkaiser]

15 hours ago, zador.blood.stained said:

It's still a useful board IMO

 

Well, from a technical point of view it's just an OPi Zero with an USB-Ethernet dongle attached to the USB port in a much nicer form factor. Software development efforts needed: close to zero since the only two things that are interesting is whether the used Ethernet chip is supported by legacy kernel and runs stable (testing efforts hardware vendors usually skip) and same for Wi-Fi (since it's RTL8189ETV an /etc/modules modification should do the trick).

 

If Armbian wants to support this board IMO we should focus on providing a single OS image for both H2+ OPi Zero variants. But let's wait until schematics are released or at least real information is available (especiall type of Ethernet chip -- if it's RTL8152 then we could at least test a bit with legacy kernel since Pinebook shipped with such a dongle)

 

15 hours ago, zador.blood.stained said:

let's hope for an upgraded version (don't know if you could fit a gigabit PHY and a gigabit USB Ethernet chip in this form factor)

 

Well, it can always grow to one side without affecting mechanical compatibility to add-on boards.

[zador.blood.stained]

6 minutes ago, tkaiser said:

Well, it can always grow to one side without affecting mechanical compatibility to add-on boards.

Based on previous designs Xunlong is rather conservative with creating new form factors, and I'm not sure if Zero Plus would be already compatible with existing enclosure designs for Zero with minimal cutting for the second Ethernet port instead of USB.

And IMO this device calls for standalone operation without any add-on boards, I don't see that many reasons to prefer it over the first Zero or Zero Plus 2 for using video output, extra USB ports or the NAS expansion board.

[tkaiser]

Now price is available and also USB-to-Ethernet chip (RTL8152B) and amount of DRAM (256MB): https://aliexpress.com/store/product/Orange-Pi-R1-H2-256MB-Quad-Core-Cortex-A7-Open-source-development-board-beyond-Raspberry-Pi/1553371_32827494728.html

 

Still no schematics available but given Xunlong's conservative approach I don't think we need them anyway.

[Igor]

And there is one small change in description - Armbian is now noted as "supported OS"

[martinayotte]

[chwe]

Seems that they soldered 16MB instead of 2MB SPI on this board. Maybe a noobs question. But would this SPI flash be fast enough to boot a small footprint linux from it? When I think back to my first openWRT router, this one hadn't more memory for the OS.

[malvcr]

I just acquired two BPI-R2 for prototyping ... big cards (compared with other ARM based machines).

I was thinking on making some type of blade enclosure with them, where each blade could be assembled around some opi or similar machine.  And now these two lan port machines appear.  And also the opi zero plus.  And I have a bunch of 2G-IOT in a corner waiting to see if I can use them (I still have some hope).

 

A cheap two ports 100Mbps machine it is useful on an Internet secure gateway where you encrypt with one machine and decrypt with the another one in a distant place.

 

Also, for marguerite cluster (just invented the term ... I don't know if this exist with other name), where you have many machines linked one with the other in a ring, sharing responsibilities (as a token ring on ethernet).  Without a switch between them.  For many usages, the H2+ it is enough ... right now I have a OPI zero dealing with production level responsibilities and behaves very well.

 

So complicated business it is the SBC one, right?   :-) ...  the problem is not to have enough time and/or resources to play with so many toys.  And that there is no a good standard for all the makers to work around.  This could help to guide all these efforts.

[thanh_tan]

I just order 1 OPi R1 for testing. Which OS can I use for it? Armbian?

 

And I still don't know which application i can apply to this booard

[tkaiser]

9 minutes ago, thanh_tan said:

Which OS can I use for it? Armbian?

 

Armbian legacy images for Orange Pi Zero. You should be able to use Wi-Fi out of the box (since SDIO bus should be probed and then approriate 8189es driver be loaded automagically) but take a look at /etc/modules (remove xr819 and add r8152) and /etc/network/interfaces to configure networking for your needs.

 

https://www.armbian.com/orange-pi-zero/

[tkaiser]

Update: still no schematics but some OS images and another Android source code drop dating from 2017-04-01 provided by Xunlong: http://www.orangepi.org/downloadresources/orangepiR1/2017-08-18/orangepiR1a8ec1de21ce78b0942f9be38ab.html

 

I booted this 'Debian Server' image on a NanoPi M1 with attached RTL8152 dongle and only connected this to my network. Booted successfully with a smelly 3.4.39 kernel built on 'Apr 14 14:05:55 CST 2017' (WTF?) an OS image obviously based on loboris' work. Hopefully all relevant information collected here: https://pastebin.com/XZ5vM0df

 

'Fortunately' bash history was not cleared so we're able to see that this here has been added to /etc/rc.local:

dmesg -n 1
install --group=root --owner=root --mode=0644 /root/50-usb-realtek-net.rules /etc/udev/rules.d/

And this udev rule that gets installed on every boot looks like this:

root@OrangePizero:~# cat /etc/udev/rules.d/50-usb-realtek-net.rules 
# This is used to change the default configuration of Realtek USB ethernet adapters

ACTION!="add", GOTO="usb_realtek_net_end"
SUBSYSTEM!="usb", GOTO="usb_realtek_net_end"
ENV{DEVTYPE}!="usb_device", GOTO="usb_realtek_net_end"

# Modify this to change the default value
ENV{REALTEK_NIC_MODE}="1"

# Realtek
ATTR{idVendor}=="0bda", ATTR{idProduct}=="8153", ATTR{bConfigurationValue}!="$env{REALTEK_NIC_MODE}", ATTR{bConfigurationValue}="$env{REALTEK_NIC_MODE}"
ATTR{idVendor}=="0bda", ATTR{idProduct}=="8152", ATTR{bConfigurationValue}!="$env{REALTEK_NIC_MODE}", ATTR{bConfigurationValue}="$env{REALTEK_NIC_MODE}"

# Samsung
ATTR{idVendor}=="04e8", ATTR{idProduct}=="a101", ATTR{bConfigurationValue}!="$env{REALTEK_NIC_MODE}", ATTR{bConfigurationValue}="$env{REALTEK_NIC_MODE}"

# Lenovo
ATTR{idVendor}=="17ef", ATTR{idProduct}=="304f", ATTR{bConfigurationValue}!="$env{REALTEK_NIC_MODE}", ATTR{bConfigurationValue}="$env{REALTEK_NIC_MODE}"
ATTR{idVendor}=="17ef", ATTR{idProduct}=="3052", ATTR{bConfigurationValue}!="$env{REALTEK_NIC_MODE}", ATTR{bConfigurationValue}="$env{REALTEK_NIC_MODE}"
ATTR{idVendor}=="17ef", ATTR{idProduct}=="3054", ATTR{bConfigurationValue}!="$env{REALTEK_NIC_MODE}", ATTR{bConfigurationValue}="$env{REALTEK_NIC_MODE}"
ATTR{idVendor}=="17ef", ATTR{idProduct}=="3057", ATTR{bConfigurationValue}!="$env{REALTEK_NIC_MODE}", ATTR{bConfigurationValue}="$env{REALTEK_NIC_MODE}"
ATTR{idVendor}=="17ef", ATTR{idProduct}=="7205", ATTR{bConfigurationValue}!="$env{REALTEK_NIC_MODE}", ATTR{bConfigurationValue}="$env{REALTEK_NIC_MODE}"
ATTR{idVendor}=="17ef", ATTR{idProduct}=="720a", ATTR{bConfigurationValue}!="$env{REALTEK_NIC_MODE}", ATTR{bConfigurationValue}="$env{REALTEK_NIC_MODE}"
ATTR{idVendor}=="17ef", ATTR{idProduct}=="720b", ATTR{bConfigurationValue}!="$env{REALTEK_NIC_MODE}", ATTR{bConfigurationValue}="$env{REALTEK_NIC_MODE}"
ATTR{idVendor}=="17ef", ATTR{idProduct}=="720c", ATTR{bConfigurationValue}!="$env{REALTEK_NIC_MODE}", ATTR{bConfigurationValue}="$env{REALTEK_NIC_MODE}"

# TP-LINK
ATTR{idVendor}=="2357", ATTR{idProduct}=="0601", ATTR{bConfigurationValue}!="$env{REALTEK_NIC_MODE}", ATTR{bConfigurationValue}="$env{REALTEK_NIC_MODE}"

# Nvidia
ATTR{idVendor}=="0955", ATTR{idProduct}=="09ff", ATTR{bConfigurationValue}!="$env{REALTEK_NIC_MODE}", ATTR{bConfigurationValue}="$env{REALTEK_NIC_MODE}"

LABEL="usb_realtek_net_end"

Contents of script.bin look reasonable: led pins still PA17/PL10, mmc1_para/module_para/wifi_para (Wi-Fi), usbc0 (OTG) and dvfs_table (voltagae regulation) all match (only dram_clk seems a bit too high).

 

In other words: If we can rely on the above script.bin contents Armbian images for Orange Pi Zero should work out of the box.

[tkaiser]

Same NanoPi M1, RTL8152 attached to usb1, only the USB-Ethernet connected to network, our OPi Zero image booting flawlessly (no need for udev rules IMO): http://sprunge.us/eLJP

 

The xradio driver fails as expected and with Zero's default /etc/network/interfaces contents (none) it should be also easy to bring up RTL8189ETV if present on the board (to be confirmed). Since I don't have any devices with RTL8189ETV maybe someone else (@Igor?) can give it a try booting our Zero image on an OPi Plus and check whether nmtui just works?

 

If that's ok, all further development efforts are two lines adding to documentation / download page.

[Igor]

39 minutes ago, tkaiser said:

can give it a try booting our Zero image

Opi+ with Zero image no network works. Opi+ has gmac. Opi+ with Zero image and orangepiplus.bin and "modprobe 8189es" also wifi works.

[tkaiser]

8 minutes ago, Igor said:

Opi+ with Zero image no network works. Opi+ has gmac. Opi+ with Zero image and orangepiplus.bin and "modprobe 8189es" also wifi works.

 

Thank you for the test. Wrt Ethernet I was thinking about adding the USB Ethernet dongle that came with the Pinebook (RTL8152) since this works out of the box with the network config we use on the OPi Zero image (zero contents and therefore interfaces under NM control). So most probably an own download page pointing to OPi Zero images and mentioning

sed -i 's/xradio_wlan\ g_serial\ xradio_wlan/8189es g_serial/' /etc/modules && reboot

is enough. Dealing with up to 4 interfaces here (USB Ethernet gadget, Wi-Fi and two times Fast Ethernet) would also be a nice opportunity to write up an article dealing with OPi R1 but more generally explaining how to configure networking here (and focus on common mistakes like connecting more than one interface to the same network and then wondering why eg Wi-Fi stops working after the Ethernet cable is disconnected  )

[zador.blood.stained]

IMO let's not try to reinvent the wheel and add a separate board configuration which will have its own fex and device tree files.

[tkaiser]

16 minutes ago, zador.blood.stained said:

IMO let's not try to reinvent the wheel and add a separate board configuration which will have its own fex and device tree files.

 

Hmm... while I don't really care I fail to understand how/why fex and device tree files should differ (given the Xunlong script.bin was correct). The only difference from a settings point of view is the Wi-Fi chip needing a different driver (and I thought it wouldn't be necessary to load this driver manually or through /etc/modules since IIRC @jernej invented SDIO bus autoprobing over a year ago?). The RTL8152 present on usb1 all the time is nothing we need different settings for (IMO no need to ship with a different interfaces file).

[chocomega]

By the way, here is the original article (in french) where the photo comes from

http://www.minimachines.net/actu/orange-pi-steven-zhao-52858

[tkaiser]

9 minutes ago, chocomega said:

By the way, here is the original article (in french) where the photo comes from

 

Please note that I gave the author credit and also already referenced the link in post #1. Please also have a look what I've written there (the most important part to not trust in every stuff you find somewhere on the Internet!)

On 15.8.2017 at 10:25 AM, tkaiser said:

We spotted a new OPi Zero variant with one USB-A receptacle missing and replaced by a second RJ45 jack a while ago (in this report where a lot of 'information' seems a bit questionable to me)

 

People interested in this part of the story should better read through http://www.cnx-software.com/2017/07/15/office-factory-business-model-and-ambitious-plans-of-shenzhen-xunlong-software-orange-pi-maker/ since there you can find also Statements from Steven and Igor 'correcting' the french 'report'.

[zador.blood.stained]

15 minutes ago, tkaiser said:

Hmm... while I don't really care I fail to understand how/why fex and device tree files should differ (given the Xunlong script.bin was correct).

Different wireless chips may have different powering scheme and different wake/enable/reset GPIOs. I.e. OPi Zero has a separate GPIO controlled regulator for the wireless while OPi Lite drives wireless from the main 3.3V bus directly.

[chocomega]

15 minutes ago, tkaiser said:

 

Please note that I gave the author credit and also already referenced the link in post #1. Please also have a look what I've written there (the most important part to not trust in every stuff you find somewhere on the Internet!)

 

People interested in this part of the story should better read through http://www.cnx-software.com/2017/07/15/office-factory-business-model-and-ambitious-plans-of-shenzhen-xunlong-software-orange-pi-maker/ since there you can find also Statements from Steven and Igor 'correcting' the french 'report'.

Oups my bad ! Thanks for the second link (more info about the donation part).

It's also funny to read in that report that one of the selling point of the orange pis is their thermal dissipation design when we know there are overheating issues with opi zero v1.4 ...

 

Sorry for the off topic.

[Xer0]

On 17.8.2017 at 11:58 PM, chwe said:

Seems that they soldered 16MB instead of 2MB SPI on this board. 

I really hope they've not mistaken Bits&Bytes (Flash is often stated in Megabits)

[zador.blood.stained]

On 15.08.2017 at 11:25 AM, tkaiser said:

At least judging by pictures it seems to be RTL8189ETV which is good news for users since 8189es driver is part of Armbian OS images with both kernel variants.

Unfortunately 8189es mainline driver needs some work, current mainline images don't have it because it needs patches to compile on top of fresh kernels.

[tkaiser]

Quick update on RTL8152 with legacy kernel. I booted a NanoPi M1 with our Zero legacy image connected to network through an external RTL8152 dongle, fired up 'iperf3 -s' and let another board continually 60 second iperf3 tests run:

• TX direction 94.5 Mbits/sec with less than 1 retransmits per minute (test ran 27 hours): http://sprunge.us/eEWY 
• RX direction 94.2 Mbits/sec with ~70 retransmits per minute (test ran almost 17 hours): http://sprunge.us/NSWE

Though dmesg output on the simulated R1 doesn't look that promising: http://sprunge.us/TZji

 

So maybe in addition to work needed on 8189es with mainline kernel on legacy kernel cdc_ether driver might need some attention or maybe even r8152 backported to 3.4:

tk@orangepizero:~$ lsmod
Module                  Size  Used by
bmp085                  3487  0
pcf8591                 3363  0
cdc_ether               3679  0
usbnet                 14096  1 cdc_ether
g_serial               27617  2
mac80211              358445  0
btrfs                 712409  0

 

Edit: IMO we should think about skipping legacy kernel support at all if H3/H5 boards are likely to move from dev to next status within the next month(s).

 

Edit 2: Please forget about dmesg output mentioned above, eth0 is H3's PHY while RTL8152 is the enx00e04c360630 interface.

enx00e04c360630 Link encap:Ethernet  HWaddr 00:e0:4c:36:06:30  
          inet addr:192.168.83.43  Bcast:192.168.83.255  Mask:255.255.255.0
          inet6 addr: fe80::2e0:4cff:fe36:630/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:888981157 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1046880511 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1847320595 (1.8 GB)  TX bytes:3844189838 (3.8 GB)

eth0      Link encap:Ethernet  HWaddr e2:86:8e:35:71:8c  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:572 (572.0 B)
          Interrupt:114

 

[yanzixiang]

They have publish the schematics here

https://pan.baidu.com/s/1qXZky5m#list/path=%2FOrangePi_Office%2FDocument-Tools%2FOrangePi R1&parentPath=%2FOrangePi_Office%2FDocument-Tools

[zador.blood.stained]

8 hours ago, yanzixiang said:

They have publish the schematics here

Looks like it's not correct - it shows one Ethernet via integrated EPHY and another one via EMAC+RTL8211* PHY. Probably an older design attempt since it's dated January 19.

[thanh_tan]

I have another schematic which downloaded from store server, hope that it can helps 

ORANGE_PI-R1-V1_0_Schematic.pdf