Orange Pi 3
Tristan M. (2946) 1039 posts |
I purchased on when they came out. It arrived today after what I imagine to be a slow trip around Venus and back. I just thought I’d share my thoughts on it given that it’s an ARM SoC based board. I chose the version with 2GB RAM and 8GB eMMC. Shortly after receiving it I added an SPI NOR to the empty pads on the board with the intent of eventually putting U-Boot on it. There are only SunXi OSes available as yet from what I can tell. I chose Debian Jessie Desktop eMMC (although I’m not sure what the eMMC component actually is). Running Jessie off the MicroSD slot is interesting. It booted up okay. However I had to sign into a desktop manager using the root account and use my initiative to create an account. Later I discovered that the default orangepi account existed. The board seems to have at least 3 LEDs on board. Red initially, green when booting begins, and a third red one that comes on when I plug a USB device into one of the USB3.0 ports. I plugged the Logitech wireless adapter into the USB2.0 port because why not? It still has the oddly sized barrel connector. Same size that the Sony PSP takes. This model however can also be powered by the MicroUSB plug which is also a USB OTG port. The footprint is a little larger than a Raspberry Pi. It does have a lot on it though so it’s understandable. I haven’t tried Bluetooth or the GBit ethernet yet. WiFi seems to work nicely. No dropouts in the time I was playing around with it. Apparently the MiniPCIe port isn’t much good. I don’t have any reason to use it so I don’t really care. if it supports eMMCs like the Pine64 products that’d be nice. No idea if it does. The eMMC to my surprise has some sort of Android based set top box software on it. It’s Chinese so I didn’t get too far. According to the schematics the GPIO port is essentially compatible with an RPi 1 B. It’s only 26 pins like the 1B. Not sure if it was because of board space or all the other stuff they stuffed on board needed the Processor IO pins. Didn’t look at that part of the schematics. I was only after the GPIO header. It’s not a perfect product and not amazingly well supported yet, but I’m happy with it. When I get some time I’m giving it a USB3.0 SATA adapter with a notebook harddrive attached. Maybe shift /home to it. My intent was to do that and have the OS installed on eMMC, when I work out how. Just thought I’d give my honest impressions of it. |
Tristan M. (2946) 1039 posts |
The logitech mouse / keyboard dongle needs to have a USB extension cable otherwise the range is reduced to centimeters. My guess is either the WiFi or board RF noise is deafening the receiver. It seems to be functioning happily with the Sunxi Debian Jessie image installed on the eMMC and /home bound to a directory on the notebook HDD connected via USB3.0 to notebook SATA cable. As yet I have been unable to change the resolution with the BSP kernel. This is a common issue. I’ll be happy when there’s mainline kernel support. |
Tristan M. (2946) 1039 posts |
Apparently the GPU, driver permitting of course, supports OpenCL. Interesting. |
Tristan M. (2946) 1039 posts |
It’s proven to be a great little workhorse. Although I got the eMMC version, I have it running off a 64GB MicroSD, and a 500 odd GB HDD plundered from a notebook at the rubbish tip for /home. I use it for running RISC OS Linux set up with networking, no graphics frontend (so headless I guess) and !VNCServer running. SO if I want to use linux I log in via RDP, and RO, via VNC. |
David Feugey (2125) 2709 posts |
Good to know. The only real problem, for a RISC OS only user, is that the VNC client for RISC OS is very unstable. I wonder if a client+server solution made specifically for RISC OS (with sound redirection, mode change support, ssl, etc.) would not be better for us. |
Jeffrey Lee (213) 6048 posts |
That would mainly be an exercise in wheel reinvention. The VNC protocol is flawed and poorly documented, but it’s also widely supported and very extensible. The (QEMU) audio protocol is fairly straightforward – the main difficulty would be finding the right place for the server to extract the audio from RISC OS. For backwards-compatibility, this would probably have to be done as a new feature in SharedSound. Mode change support has been supported by the server for a few years now, and I’m fairly certain at least one of the RISC OS clients supports it. The SSL/TLS protocol (VeNCrypt) also looks like it’s fairly straightforward – lack of support for it in the VNC server is mainly because AcornSSL doesn’t support server-mode operation (Yes, I could statically link with OpenSSL or similar, or maybe use the SecureSockets module, but I don’t want to). Not sure about whether any RISC OS clients currently support the protocol, but since I’m not currently the maintainer of a RISC OS client, that’s not my problem ;-) And for situations where “standard” VNC doesn’t fit the bill (e.g. the clipboard protocols look a bit poor), we can always define our own extensions. |
David Feugey (2125) 2709 posts |
Anyway, Avalanche crashes a lot… |
andym (447) 473 posts |
Which version are you using? It’s reasonably stable here with version 0.22. Are you connecting to another RISC OS machine or some other platform? |
David Feugey (2125) 2709 posts |
http://www.effarig.co.uk/riscos/
The same here. But not for several hours, or under heavy load (then it can crash every minute). On the other hand RDPClient works perfectly. Only a little problem with dead keys (for example ^+O should give Ô, but this doesn’t work on RDPClient). Anyway, Avalanche has the same problem :) |