Orange Pi

After randomly searching for something, I came across this: OrangePi

Anyone looked at one of these?

Stopped reading here:

It uses the AllWinner A20 SoC

It looks really good, has a nice spec, and at those sorts of prices it could easily be a Beagle (etc) killer. Seems to me to be more a clone of the Cubieboard than the Pi.

While Patric stopped reading at the mention of the AllWinner A20 chip (and he has reason to), I did manage to find some datasheets.
There is this: https://github.com/allwinner-zh/documents/blob/master/A20/A20%20Datasheet%20V1.41%2020131230.pdf – it is 3.15MiB, runs to 35 pages, and describes the A20 capabilities, the pin-out, and the electrical characteristics.
Then there is this: https://github.com/allwinner-zh/documents/blob/master/A20/A20%20user%20manual%20v1.3%2020141010.pdf – running to 20MiB, and 853 pages, it appears to be a more useful datasheet. It isn’t as descriptive as the OMAP ones, mostly describing the internal registers and configuration, but it may be enough to get RISC OS running – if anybody feels like a challenge. ;-) I’ll let somebody with more skill in porting report on whether or not the documentation is sufficient.

Here is my previous whinge about binary blobs (and it appears that AllWinner does this quite a bit), which may or may not have relevance depending upon how complete the documentation actually is:

To put this into context, I shall refer (yet again!) to my PVR. ;-) It is a “open source” design, I have the full schematics. The Debian kernel and UI are open source. I even managed to find a copy of the DM320 datasheets on a random Chinese site.

But all the codecs? All the interesting stuff? Binary blobs. I know the hardware is capable of adjusting contrast/brightness/etc of the digitised video stream. I know this because the data sheet for the part says so. It appears that it can also parse out teletext (so could record subtitling as a separate stream?). But the binary blob does not contain this functionality. Likewise, while H.263 video is generated, it is put in an MP4 wrapper. It’s a simple job to demux this into an AVI, but wouldn’t it be nicer if the PVR could do this itself? Well, maybe it can. Maybe it can’t. Much of the control to the binary blobs are a load of “magic numbers”, none of which is publicly documented. You might get somewhere by rebuilding the UI with different values to pass to see what happens, but given that this means a lot of reflashing or booting via TFTP, it is no surprise nobody bothered.
The PVR was a good idea, and I applaud Neuros for trying to make an open source bit of kit – however at the time no DM320 datasheet was available (and it still isn’t, officially – TI gave me the brush-off when I asked) and at no time have the codecs or low level controllers been available as anything other than binary blobs.
This is why the project failed. Perhaps the hardware can decode OGG? But how to make it do so? Perhaps the hardware could play or record MPEG2? But how to make it do so? The extent of “open source” was pretty much tweaking the UI and writing some additional apps and, well, that’s about it.

So to the OrangePi. Sure, it has some operating systems built for it. This is nice, I can run Android on it right away… but, the low level stuff, is it available? Is it documented? Or is it a closed binary blob? A bunch of system modules? How open is open? Open as in truly open and documented, or open as in “it runs Linux”, because if that is the case then pretty much everything with a modern(ish) processor can run some sort of Linux but I wouldn’t call it open. My S5 Mini runs Android. It isn’t open. My Livebox runs some kind of Linux with Busybox. It is only open as far as licences require (and certainly not enough to build custom firmware). I would imagine the Sky Digibox with harddisc and fancy stuff runs some sort of Linux inside – would anybody ever call the Digibox “open”?

To quote http://linux-sunxi.org/GPL_Violations : Allwinner has repeatedly violated the GPL, (and by proxy so are most hardware manufacturers and resellers using or selling products based on Allwinner chipsets). Either by not providing (Linux/Android) kernel or u-boot source at all, or by delivering trees with pre-built binaries and no matching source code. They even blatantly use LGPLed license code in their userspace libraries for media decoding. Over time, Allwinner has only increased the binary blobs present in their kernel trees, showing clearly that, even though Allwinner in the meantime joined Linaro, it is not progressing. Quite the opposite actually, and one has to worry about what value Linaro membership really has if a member is allowed to behave like this.
This suggests, to me, that the definition of “open” used for the OrangePi is very loose, if it is worth anything at all.

You know, this all seems rather familiar…

http://www.bananapi.org/

There’s a surprise. GMAC (ethernet) and SATA on the chip, not via USB interface. Still, RISC OS won’t be able to make use of SATA (p806) as the description is merely a page long…

The H3 chip used in the later versions doesn’t appear to support SATA natively. The one board with SATA has it via a chip that probably talks to USB – so your fast SATA drive will be throttled by the USB capabilities. Nice.

Still, I will await the imminent arrival of the CherryPi and ApplePi and BlackbirdPi and anything else the Chinese can think of to stick “Pi” to the end of… ;-)

If anybody has one of these AllWinner clone boards, datasheets here: https://github.com/allwinner-zh/documents/

running to 20MiB, and 853 pages

Pfff IIRC the OMAP 5432 has 270 pages just of contents and is about 3500 pages in all and Willi tells me is still missing vital bits:-(

But the even bigger problem is the number of people able to do the low level porting. There is I think only three such people active in the RISC OS world and all three of them are fully occupied already.

You know, this all seems rather familiar… http://www.bananapi.org/

Hmm yes I thought I recognised the “Band wagon” from somewhere before, hence searching in here before I posted!

Still, I will await the imminent arrival of the CherryPi and ApplePi and BlackbirdPi and anything else the Chinese can think of to stick “Pi” to the end of… ;-)

MinceMeatPi? .. I thing the pi foundation missed a trick with “2PiR” :@D

There is I think only three such people active in the RISC OS world and all three of them are fully occupied already.

I would love to have the skills for this, but mine are still fighting the stupid memory errors in my C coding… It’s a shame it’s not in BASIC (ducks behind the firing wall).

I know it’s an old thread but it’s still on page one of the porting subforum.
Not that I’m volunteering, but what information is needed to port RISC OS?

I was looking through the H3 Datasheet and it seems to have a lot of useful information I also know that the Orange Pi PC (and other models I think) are supported by the mainline linux kernel with open drivers. About the only caveat I know of is that the graphics are probably limited to framebuffer only.

I found a morsel of info on bare metal coding for them and am tempted to try. Only thing is the Orange Pi PC is my NAS.
I wrote it off as a cheap “clone” of a Raspberry Pi until I actually got it. Now I’m just frustrated because it is an amazing bit of hardware for the price with terrible support.

The main thing you’ll need is a half-decent manual for the SoC. The A20 user manual that Rick found earlier looks like it gives details on all of the key hardware registers, but it completely fails in telling you the correct way of programming the registers. It’s like expecting someone to be fluent in French after giving them an English-to-French dictionary but absolutely no information about the grammar. Or expecting someone to be able to pass their driving test if all you’ve done is explain what all the different controls in a car do. So unless there’s some better documentation or some licensing-safe sample code somewhere, expect to be in for a challenge.

For a general guide to porting the OS, check out this wiki page

Now I’m just frustrated because it is an amazing bit of hardware for the price with terrible support.

I would advocate full complete open source not to be a zealous beardie, but because I’ve run into that problem so many times it isn’t funny. :-/

Cool hardware, shame about the…oh never mind. <facepalm>

Now, these boards are based on H3.

Here’s a DropBox link to the H3 Datasheet I found. Don’t complain. The watermark renders with 100% opacity in !pdf making the document hard to read. Use another computer.

https://www.dropbox.com/s/26l61a4ic3j2zrk/Allwinner_H3_Datasheet_V1.2.pdf?dl=0

It seems to contain a lot of information.

I believe it probably wouldn’t be too hard to get a port through preboot as far as HAL. All the important stuff is known and there’s another perk. The UART is 16550 compatible.

This is the thread I found the datasheet on and some other bits of interesting info. I re-hosted the datasheet for reasons which become obvious if you click the link. If you are stubborn, copy paste the url text from the page, not the url itself behind the text.
http://www.orangepi.org/orangepibbsen/forum.php?mod=viewthread&tid=1934

It may still be too hard. I don’t know. From my perspective at least it seems possible to port RISC OS to the H3 based Orange Pis.

edit: I’m waiting for approval for the Orange Pi forum so I can get at the attachment for the hello world bare metal example. Already have gcc-arm-none-eabi waiting.

edit again: I downloaded the example .zip
The code is so stupidly simple I feel like I’m missing something.

…neat! the makefile worked without issue and built the binary.

Here’s a DropBox link to the H3 Datasheet I found. Don’t complain. The watermark renders with 100% opacity in !pdf making the document hard to read. Use another computer.

https://www.dropbox.com/s/26l61a4ic3j2zrk/Allwinner_H3_Datasheet_V1.2.pdf?dl=0

It seems to contain a lot of information.

That looks like about the same level of detail as the A20 doc that was posted earlier. A lot of information, but a good manual would contain a whole lot more.

I believe it probably wouldn’t be too hard to get a port through preboot as far as HAL. All the important stuff is known and there’s another perk. The UART is 16550 compatible.

Oh yes, the documentation is definitely enough to get the kernel up and running (interrupts, a timer, and serial for I/O). USB, SD and other storage/expansion interfaces should be possible too since they usually follow open standards – although you may still run into trouble if there are bugs or non-standard extensions. But the real killer will be audio and video. They tend to be the things that require the most SoC-specific code and can be subject to odd bugs and edge cases.

But the real killer will be audio and video.

Time for a headless version of RISC OS? (CLI on serial port or Spice server).

Is there a change that any work on porting to the OrangePi could help out with porting to the Olimex OLinuXino boards? They all seem to use Allwinner chips…

Could be a “two boards with one image” sort of win…(I prefer that metaphor because I don’t like the idea of killing birds with stones!)

Yeah, if SoCs are from the same manufacturer then they usually have similar memory maps and sub-systems. So you can either support the different chips/SoCs all within one ROM (Pi, OMAP3 and OMAP4 ROMs all support multiple SoCs within their respective families) or you can at least use the source from one HAL as the basis for building another (OMAP3 → OMAP4 → OMAP5). The only difficult part will be if you want to support multiple SoCs/boards but there’s no way of knowing what specific SoC/board you’re running on (e.g. for OMAP3 & OMAP4 we either require the user to configure the bootloader with a board-specific entry point address, or we require it to be built as a uImage so that u-boot will tell us the Linux machine type number)

It’s not really an issue: RISC OS doesn’t support it :)

DavidS: I can’t speak for the other models but the Orange Pi PC which I have seems to be fairly spritely. I found a comparison somewhere that had it outperforming a Pi 3. I’d believe it. For the sake of it I got HDMI output working on it before I disabled X, because I use it headless. Running Ubuntu Vivid (with no heatsinks at the time and bouncing off the thermal governor cough) It performed well, and played a YouTube video without issue. I didn’t do any setup for that, although the maintainers may well have.

Jeffrey, from my quick flick through the datasheet and what I read the needed subsystems do all seem to be common.
With the framebuffer and audio, it has been implemented in the mainline linux kernel so someone has worked it out which means someone has documented it.

As pointed out, RISC OS doesn’t use hardware acceleration for graphics but it can do it with additional modules.

RISC OS is still using the Broadcom blob for some things on the Pi, isn’t it?
On the Orange Pi, unless features are wanted that go above and beyond it doesn’t seem to need a blob for anything.

What I’ve seen around the place is that the Orange Pi series are open source boards which fell victim to Allwinner’s repeated GPL violations. The Developers / admins on the Orange Pi forum appear to be incredibly eager and supportive where anybody wants to make progress in unlocking the inner mysteries of the SoC, which is helpful.

Another thing worth pointing out. The Orange Pi PC (i use it again because it’s the one I have), costs roughly 1/3 that of the Raspberry Pi 3 with slightly better performance. It also has the bonuses (bonii? ahaha maybe not) of having the USB ports directly connected to the SoC instead of via an internal hub, 1Gb ethernet (AFAIK), an IR receiver, dedicated USB OTG port, dedicated UART debug header, simultaneous HDMI and composite video out, 4K video, and a barrel connector for power instead of a micro USB connector. You all probably know how I feel about Micro USB being used for power. Come on. It’s a great little piece of kit! I think they did a great job.

I guess my point here is it seems like a good way for people to have a fast, very cheap RISC OS machine with I believe a better OOBE than linux. Does anyone else have one? If so, have you gone through the nuisance of getting an OS up and running on it? It’s a pain. Worst part is I think I wasted hours trying multiple working distributions without knowing it because HDMI wasn’t being driven.

Though it is more expensive than the RPi 3B according to the listed pricing

Thats for the Orange Pi. The Orange Pi PC is a different board (doesn’t have things like built in WiFi, “only” has 10/100 Ethernet, etc., but still has the 1.6GHz Allwinner H3):

https://www.aliexpress.com/store/product/Orange-Pi-PC-set-1-Orange-Pi-PC-USB-to-DC-4-0MM-1-7MM-power/1553371_32451459094.html

There was an effort a while ago to reverse engineer the drivers for the Mali series of GPUs but I don’t think it ever got anywhere (last time I got in touch about a year ago they were still looking for developers but I didn’t have the right skill set):

http://limadriver.org/

With the framebuffer and audio, it has been implemented in the mainline linux kernel so someone has worked it out which means someone has documented it.

90% of the time Linux kernel drivers will come from the SoC manufacturer or one of their NDA’d customers/partners (IIRC a fair amount of the OMAP drivers have come from Nokia).

The irony is that the Linux sources from the manufacturers usually contain information on components that aren’t documented in the public TRM (e.g. OMAP HDMI drivers). But because the Linux code is typically GPL we can’t use it to develop drivers for RISC OS.

But because the Linux code is typically GPL we can’t use it to develop drivers for RISC OS.

How totally rubbish…(not the statement, but the act)

Progress is always halted by insane-ness. :@(

Instead of sharing (or working out a way to veneer to hid protected content) let’s re-invent the wheel 100,000,000,000 times… just as stupid as the apple / Samsung court wars (you are using my stuff, so I will sue you, then you will sue me as I am using your stuff)

Lawyers always win.

:@(

How totally rubbish…(not the statement, but the act)

The rubbishness is endemic throughout all types of computer and society in general. We as a species generally don’t like cooperative behaviour. We like to have our little slice of pie and keep it to ourselves.

Lawyers always win.

Depends how you define winning. If you mean that they get a bit more cash that they can spend on some more crap that will ultimately (during the course of their life or afterwards) end up in landfill then yes they win. I don’t think anyone is really a winner in that scenario (even though the lawyer in question would tell you otherwise…or imply it as he races past in a fancy, shiny pre-landfill automobile).

Can I have a good quality and happy life without “winning” in that sense?

The monks in the temple I used to live next to would say “yes” but they also wouldn’t hesitate to sell you a bunch of incense sticks or soap made to a secret recipe. Would they reveal that recipe to me? In truth I never asked but it would likely depend on the individual monk. They might even tell me that I could only have the recipe if I didn’t tell anyone else…but then how would they control that other than out of a belief that I would respect them?

All rather off topic…

I guess the crux of it is this: there are only a handful of us in the world who are interested in RISC OS and there are already a handful of people selling systems that can run RISC OS – if there are a 1001 boards out there that have some CPUs on them that are vaguely similar to the boards that have been ported to RISC OS then there is a chance that they might now (or at some point in the future) run RISC OS. The only way to really guarantee that they may run RISC OS, and guarantee that RISC OS continues is to spend our scant resources on the companies who are already producing hardware that runs RISC OS.

Taking this further – if I want to run RISC OS as my desktop computer – then if I ever get any spare cash I don’t want to spend it on a random ARM based board, or even buy another Raspberry Pi. I want to spend it with CJE, R-Comp, RISCOSbits, RISC OS Open, or whomever in the community, in the knowledge that at least a portion of that money will go towards furthering the development of RISC OS.

Perhaps there is no need to re-invent any wheels here…just use the wheels we already have available to us.

How totally rubbish…(not the statement, but the act)

The GPL applies to the software. Why would it not be possible to look at the GPL to work out what the hardware is doing, and then use the spec to write something else?

usually contain information on components that aren’t documented in the public TRM

Sounds dangerously close to the “private API” thing that Microsoft got clobbered over?

The GPL applies to the software. Why would it not be possible to look at the GPL to work out what the hardware is doing, and then use the spec to write something else?

It is possible, it’s just a bit of a ball ache to do it properly (i.e. safely from a legal POV).

https://en.wikipedia.org/wiki/Clean_room_design

It is possible, it’s just a bit of a ball ache to do it properly (i.e. safely from a legal POV).

In this instance (and similar ones) I’d suggest that someone in one country studying the GPL code could write an english description of the code and it’s actions and pass that to someone in another country who could code things up.

Physical separation and change of language, twice, when pushed through two grey-matter interpreters should suffice.

if there are a 1001 boards out there that have some CPUs on them that are vaguely similar to the boards that have been ported to RISC OS then there is a chance that they might now (or at some point in the future) run RISC OS.

The big problem, and I believe this is something the venerable Mr. Thorvalds had a sweary rant about, was that in the ARM SoC world, there is absolutely no concept of device discovery. There is scant compatibility. One might as well say that every single device is an entirely different beast. It would be entirely possible to take the Pi’s BCM2xxx and wire it up a little differently inside. Nothing major, just tweak the addresses of stuff. It would quite possibly need an entirely different version of RISC OS just to boot.
This is very different to a PC where serial ports are at known locations, memory can be identified and initialised, you know where the video hardware is and can usually get at least CGA text out of it, the keyboard port is in a known place, as is USB. You might not know about fruity sound cards and such, but the (south?) bridge chip ought to at least manage a beep. There is also a BIOS that can be interrogated for more device information. On the ARM? Absolutely no such equivalent exists, and given the predilection for making stuff “secret” (can anybody point me to a modern RISC OS machine with a fully open and documented GPU?), I don’t see this changing in a hurry. :-(
That, by the way, is why we need system-specific versions of RISC OS. It’s the same for Linux – you need to download device specific versions of OSMC, for example.