Orange Pi Lite - now available


Recommended Posts

Donate and support the project!

Also as an addition the CNX announcement (on CNX in the comments section from time to time real information will be added/collected).

 

It should be noted that the count of solder points on the PCB varies compared to Orange Pi One (obviously since Lite exposes one more USB port and IR and mic) and that currently no one knows whether Xunlong took the opportunity to expose Ethernet RX/TX to solder/test points.

Link to post
Share on other sites

But if you want Ethernet port you can buy One instead of Lite in the first place, right?

 

Of course, I just thought about being able to connect Ethernet to some sort of baseboard featuring an Ethernet switch IC through solder/test points like it's implemented with USB data lines on this USB hub for Raspberry Pi Zero: http://www.cnx-software.com/2016/02/29/hubpixed-is-a-neat-and-cablefree-usb-hub-for-the-raspberry-pi-zero-crowdfunding/

 

But since clustering with H3 isn't that efficient it's most probably not worth the efforts...

Link to post
Share on other sites

Of course, I just thought about being able to connect Ethernet to some sort of baseboard featuring an Ethernet switch IC through solder/test points like it's implemented with USB data lines on this USB hub for Raspberry Pi Zero: http://www.cnx-software.com/2016/02/29/hubpixed-is-a-neat-and-cablefree-usb-hub-for-the-raspberry-pi-zero-crowdfunding/

You can still use Ethernet emulation through USB host on both boards (with small kernel patches), and it may be slightly faster than 100Mbit/s.

Link to post
Share on other sites

Using the regular Ethernet port on OPI ONE / Armbian_5.10 you get the following performance :

 

iperf -c 192.168.3.26
------------------------------------------------------------
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.1 sec   116 MBytes  96.6 Mbits/sec

iperf -c 192.168.3.26 --dualtest
------------------------------------------------------------
[ ID] Interval       Transfer     Bandwidth
[  5]  0.0-10.0 sec   114 MBytes  95.2 Mbits/sec
[  4]  0.0-10.3 sec  47.1 MBytes  38.5 Mbits/sec

 

 

A simple USB ethernet dongle plugged into OTG-port via adapter on OPI ONE / Armbian_5.10 shows the following performance :

 

iperf -c 192.168.3.26
------------------------------------------------------------
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   333 MBytes   279 Mbits/sec

 

iperf -c 192.168.3.26 --dualtest
------------------------------------------------------------
[ ID] Interval       Transfer     Bandwidth
[  5]  0.0-10.0 sec   200 MBytes   168 Mbits/sec
[  4]  0.0-10.0 sec   209 MBytes   175 Mbits/sec

 

Using the OTG-port on OPI LITE still leaves you with two full size USB A ports for low-power fast flash storage. MIC and IR receiver are an added bonus. If wifi works reasonably well ( I'm using <$2 realtek dongles on OPI ONE ) on OPI LITE it will be quite a steal for $16 ( please tell me where you get it without shipping costs ).

Link to post
Share on other sites

Using the regular Ethernet port on OPI ONE / Armbian_5.10 you get the following performance

[...]

A simple USB ethernet dongle plugged into OTG-port via adapter on OPI ONE / Armbian_5.10 shows the following performance

 

The speed limitation of onboard Ethernet is a BSP kernel problem. With mainline kernel you get +85 MBits/sec in both directions concurrently and with BSP kernel if not both directions are used you get +90 Mbits/sec. Regarding your USB dongle: Can you give as a link where to buy or at least show lsusb output? I've one such GbE USB dongle here but that one is way slower.

 

I was talking about slightly different scenario, when board itself emulates network adapter when plugged via USB into another device - this way you get fast enough network connection between board and other device without using any extra hardware, just USB A - microUSB cable.

 

Are you referring to the g_ether driver? Any practical experiences with it? Since I assume you'll need a PC on the other end of the connection that enables one (virtual) NIC per USB connection and then bridges the interfaces between to get real 'switch like' behaviour?

Link to post
Share on other sites

Are you referring to the g_ether driver? Any practical experiences with it? Since I assume you'll need a PC on the other end of the connection that enables one (virtual) NIC per USB connection and then bridges the interfaces between to get real 'switch like' behaviour?

Not my experience, but in this article Orange Pi One is mounted inside a router (running OpenWRT) to offload OpenVPN encryption. It's connected only via USB/CDC, and raw link speed was ~100-120Mbit/s. Even without translation you should get the idea looking at photos and screenshots.

Link to post
Share on other sites

Not my experience, but in this article Orange Pi One is mounted inside a router (running OpenWRT) to offload OpenVPN encryption. It's connected only via USB/CDC, and raw link speed was ~100-120Mbit/s. Even without translation you should get the idea looking at photos and screenshots.

 

Interesting report. From what I gather from the (google translated) article kernel/modules were patched with USB CDC code from Android to create a gadget ethernet device ( virtual NIC usb0 , which can then be used like any other network interface ). On smartphones this is used to enable "USB tethering". It would be great to have this functionality for OPI boards. Sending fast data through micro USB sounds much better than abusing it to power boards.

 

https://pixhawk.ethz.ch/tutorials/omap/usb_network

Link to post
Share on other sites

Interesting report. From what I gather from the (google translated) article kernel/modules were patched with USB CDC code from Android to create a gadget ethernet device ( virtual NIC usb0 , which can then be used like any other network interface ). On smartphones this is used to enable "USB tethering". It would be great to have this functionality for OPI boards. Sending fast data through micro USB sounds much better than abusing it to power boards.

Orange Pi there is running Armbian, small kernel patch was necessary to enable CDC mode in crappy BSP kernel. USB tethering on smartphones may use other modes (like RNDIS).

 

Once USB OTG controller is supported in mainline, it should work without any patches.

Link to post
Share on other sites

BTW: Since it might be interesting for OPi Lite users: I made just a few iozone measurements comparing USB OTG with normal host ports: http://forum.armbian.com/index.php/topic/1193-orange-pi-plus-2e-now-available/?view=getlastpost

 

It might sound somewhat absurd but even OPi Lite can make up for a nice 'el cheapo' NAS due to 3 USB ports available when used with such an RTL8153 based USB-to-Ethernet dongle and mainline kernel. Ethernet throughput might exceed 300 Mbits/sec when used on the host port so putting a disk on the OTG port might make more sense then.

Link to post
Share on other sites

It might sound somewhat absurd but even OPi Lite can make up for a nice 'el cheapo' NAS due to 3 USB ports available when used with such an RTL8153 based USB-to-Ethernet dongle and mainline kernel.

 

OPI LITE with RTL8153 ( 35 MB/s ) on USB-OTG and two cheap USB 3.0 Flash Drives ( 17MB/s seq.write each ) are a nicely performing ultra-low-power (5V/1A) no-noise combination even with the current legacy kernel.    

Link to post
Share on other sites

Now information collection regarding OPi Lite is almost done. I tried to enhance the wiki article for Orange Pi One combining it with Lite and also tried to add everything that's known/relevant now: http://linux-sunxi.org/Xunlong_Orange_Pi_Lite

 

Please help improve state of information/documentation since I made mistakes for sure (as usual :) ). Get a linux-sunxi account please and correct what's wrong. Thx.

Link to post
Share on other sites

I've received my OPi-Lite today !

 

I didn't get chance to follow every threads, is the RTL8189FTV soon be supported ?

 

Also, I think a bug has been introduced recently :

 

I've build tonight the image Armbian_5.14_Orangepilite_Debian_jessie_4.6.2.raw and it was hanging during boot :

[    7.575548] systemd[1]: Started udev Coldplug all Devices.
[    7.638570] systemd[1]: Mounting FUSE Control File System...
[    7.647639] systemd[1]: Mounted Configuration File System.
[    7.653293] systemd[1]: Starting Apply Kernel Variables...
[    7.670604] systemd[1]: Starting Create Static Device Nodes in /dev...
[    7.690248] systemd[1]: Starting Syslog Socket.
[    7.703836] systemd[1]: Listening on Syslog Socket.
[    7.713512] systemd[1]: Starting Journal Service...
[    7.722884] systemd[1]: Started Journal Service.
[    7.851371] systemd-udevd[227]: starting version 215
[    8.339502] cpufreq: cpufreq_online: CPU0: Running at unlisted freq: 1008000 KHz

I've then use the previous image I've built 2 weeks ago, at a time the image still common for all H3, the Armbian_5.12_Orangepih3_Debian_jessie_4.6.0.raw, and it booted properly.

 

 

Link to post
Share on other sites

is the RTL8189FTV soon be supported ?

 

Also, I think a bug has been introduced recently :

 

Regarding Wi-Fi: As far as I understand the driver we're using with legacy kernel is backported from mainline so should work there too. And yes, I experienced the same behaviour after trying to get THS stuff working with vanilla. Please see:

Link to post
Share on other sites

Is it simply of adding the 1008000 entry in the DTS ?

 

I still don't understand where to adjust what and had some hope that megi enlightens me on IRC... but to no avail :(

 

No, RTL8189FS driver is not backported. It is provided by Realtek. It doesn't use mac80211 but it's own implementation, so it might not be so good, but it's the only one we have.

 

Uh, thx for correcting this. I thought it would be the same as with 8189es driver.

Link to post
Share on other sites

@TKaiser, I will try again with tweaked DTS, if it doesn't work, maybe it is Megi's change here : https://github.com/megous/u-boot/commit/85dddd9bbbd2e57aad1718579e552bd936716866

 

Did you look into https://github.com/igorpecovnik/lib/blob/master/patch/u-boot/u-boot-dev/u-boot-set-safe-axi_apb-clock-dividers.patch already? I tried to ensure that we still are on the same level of u-boot patches but maybe I missed something?

Link to post
Share on other sites

I will also give a try with Hans drivers. (I though first to grab Legacy folders and move then into Mainline, but I presume that would be lost of time)

 

That won't work with OPi Lite because that code doesn't have support for 8189FS. You have to take Realtek code and fix it the same way Hans did.

Link to post
Share on other sites

Ok, for the THS, adding back the 1008000 entry is a kind of ugly workaround : during boot FREQ switch is crashing, but at least it continue to boot completely.

I presume that real fix would not be adding it, but change the value at the origin of that 1008000, which is probably in u-boot, but this is outside of my knowledge.

@Tkaiser, the patches you mentioned, and even Megi's change doesn't seem to be part of the Armbian build process. Maybe patches are not applied for some reason.

 

@jernej, I started doing what you've said, I got some part done, but now I'm a bit lost about platform files searching for the legacy sys_config.h

Link to post
Share on other sites
Guest
This topic is now closed to further replies.