> I don't understand why they go through so much effort to churn out these boards that are made useless by lack of upstreaming.
Because the board vendor, generally, doesn't know any more about this stuff than you do. They buy an SoC from a manufacturer (Allwinner in this case) and drop it on the board. Whatever "Linux" BSP the vendor provides then gets hacked into form for their product and shipped. They aren't really in any sane position to take maintainership of this code or upstream it on their own.
And going further, Allwinner is themselves just assembling IP blocks from other vendors (companies like ARM and Synopsys) that they don't completely understand. They get a sample driver, drop it in a tree, fix bugs, and ship it.
It's a big mess. The bigger vendors (e.g. Intel and Qualcomm) do a decent job of putting together solid BSPs (even if they don't always play well with the community -- the packages received by board vendors usually work and come with solid docs). The little guys just aren't there yet.
The datasheet is a copyrighted document received under NDA. They literally can't.
And again, a datasheet from Allwinner is going to just tell you what the instantiation parameters for all the various IPs are. To write a driver for, I dunno, the I2C controller (or whatever, I know nothing about this SoC in particular) you're going to need a Synopsys databook or something.
There's a framework in place for distributing all that stuff between OEMs and first-tier customers. But with the exception of a handful of hardware vendors, no one's ever cared about getting it out to the public.
The datasheets are released and you can freely download them. For the Allwinner A64 documentation (another 64-bit SoC, which is very similar to H5) you can check https://linux-sunxi.org/A64#Documentation
And no, it is not a "stolen" or "leaked" documentation (I have actually seen such ridiculous claims in the phoronix forum). It is hosted on the Pine64 website with the permission from Allwinner. And the Pine64 people specifically asked Allwinner to remove the misleading "confidential" watermarks from the PDF files.
Allwinner H5 is very new and this Orange Pi PC 2 board is probably the very first piece of hardware using it. But I expect that the H5 documentation will become available in public access shortly. Just like the documentation for the older Allwinner chips. Maybe initially with the "confidential" watermark again, because the Allwinner people are a little bit lazy and don't seem to understand why the open source people are making so much fuss about this.
> I don't understand why they go through so much effort to churn out these boards that are made useless by lack of upstreaming.
I don't believe that this sort of business venture requires that much effort. It appears that in essence they only repackage a currently available soc, and hope that the market bites.
The main reason why these small boards come with a quad-core processor and 1GB of RAM is that currently that's precisely the standard for low to mid-end smartphones running Android.
Of course, the people behind the Raspberry Pi foundation do a bit more than repackaging a bare-bones SoC. Hence, they do manage to sell quality products that actually work.
The board requires custom modifications to the kernel. These modifications never get cleaned up and submitted as patches to the kernel. So you are stuck with a kernel frozen in time.
And this is the situation with damn near every ARM board you can buy! It's depressing. I finally had to give up on my Efika MX smartbook because they never got past a 2.6 kernel, which IIRC eventually meant I couldn't upgrade libc past a certain point, which meant I couldn't upgrade anything else.
Yes it is and it is terrible. The lack of upstreaming also makes things like applying the PREEMPT_RT patches much more difficult than it should be. You might be stuck at a version of the kernel where PREEMPT_RT was never released, not to mention you will be missing the PREEMPT_RT changes in the custom code.
Phone hardware is absolutely infuriating in this regard. People figured out how to standardize bootloaders and do drivers on the PC decades ago, why can't SBC and phone manufacturers figure this out?
Why can't their be a generic build of Android that will at least boot on every phone, even if there might be some driver issues on different devices? This situation has gone on for so long it is past the point of being a joke. And don't try to tell me that there is a good technical reason why it has to be this way, we're talking about machines that are as powerful as a mid 2000s PC, you can afford the overhead of a bootloader on there.
They have a bootloader, they just don't have a BIOS, or ACPI, which you would need for the operating system to detect and interface with peripherals.
I think right now they are trying to decide between Device Tree (FDT) and ACPI for ARM, in the mean time nothing gets done and I'm not confident anything will get done until ARM the IP holder itself mandates something.
Shouldn't this have been done years ago? Do all of these manufacturers like reinventing the wheel every time they spin a new silicon? Didn't building custom bootloaders for every device get old a long long time ago?
The systems powered by these ARM processors were typically bespoke embedded software anyway, so not many people cared. Hardware vendor provides a bootloader of sorts and some shitty SDK or RTOS patch, you heap your own custom code on top and ship it. Never update any of the components, that's just asking for extra work.
Now that the processors are powerful enough to replace what would ordinarily run Windows or Linux it's very painful. The Linux code is littered with support files for a bazillion of different boards and hardware platforms.
Every new mainline kernel release includes improvements for Allwinner chips. Older Allwinner chips, such as A10 and A20, are already supported very well. The support for newer chips is progressing nicely, but there is always a bit of delay.
Yes, you can't expect this newly released Orange Pi PC 2 board to be already supported in the mainline kernel today. But maybe half a year later everything is likely going to be much better. And even right now, there should be some sort of a legacy 3.10 kernel available too, so it is not like you can't use the board at all.
... only if you actually need particular features of the CPU. We're running a dozen of these boards with mainline bootloader, kernel, and Xenial.
But they're headless servers. We don't need the GPU, which is the major component lacking support in mainline. You have to run a legacy 3.4 kernel and binary driver for GPU acceleration and OpenGL. :(
I think this chunk of industry is going right now through its enthusiastic adolescence. It's a phase. It will pass. It will eventually mature, and will separate the wheat from the chaff.
Crappy upstream kernel support on alternative boards is probably why the Raspberry Pi is king of this kingdom.
I chose to forgo all the cheaper options from China for a recent project, and instead go with (considerably) more expensive Raspberry Pi 3's, because I didn't want to risk the shite software support. I know I'm going to get kernel and firmware upgrades on those boards for a good long while, and that's one less thing I have to worry about.
You could have gone with the one of the BeagleBone varieties. BeagleBoard seems to be the only real contender that the Pi line faces, from a community standpoint. Each unit is a few bucks more, but that'll go towards strengthening an ecosystem around boards that are even more open than what you get with the Pi.
It's hard to get the benefits of volume when everyone keeps going for the cheaper-right-now board in order to maximize their own short-term benefits. Contributing to the network effect by buying a Pi because it's cheaper and more popular is not exactly the thing that will lead to Broadcom getting rebuffed and having to answer for all their problems.
I bought one board with an Allwinner chip on it. Great specs, but utterly useless. There is no support for the graphics driver, tons of bugs in the chipset, and virtually no help online unless maybe if you speak Mandarin.
All this talk has made me glad to pay the premium to stay with x86/amd64 supported boards. I've been buying PC-Engines for years, and run whatever I please on them (but mostly OpenBSD). They are 3x the price of the RPi (more if you want WiFi, bluetooth etc), but for certain applications, are quite a bit more powerful and flexible. This is especially true if you want to remain up to date for years. I have never been left without an upgrade path.
If not for boards, I just bought this https://www.amazon.com/dp/B019Z8T9J0 complete, passive PC for less $150, it has four Ethernet ports and a HDMI and a Broadwell (not Atom!) CPU. It's rather incredible how cheap PCs gotten.
It could have been so great, but wasn't meant to be. I got exited for a moment, and then my hopes were dashed. 49RMB for a zero is like cereal money. It's the price of 490g Kellogs Fruit Muesli on Taobao. There had to be a catch. But at least I didn't spend 128RMB on a SBC that doesn't work, then 8 hours on trying to make it run.
Edit: Having looked checked for authorized resellers of Raspberry Pis in China, it just got more confusing.
What happened to EGOMAN, which the Raspberry Pi foundation partnered up in 2013 to produce Raspberry Pis? They only have the first model red pi, and they have stopped advertising them. They make waterproof heartrate monitors now.
Seed studio is one of 2 authorized resellers of element14 in China. They're based in Shenzhen. They sell in JPY, but not RMB. How does that work?
The only authorized reseller that actually sells on taobao is Hangzhou Junroc Electronic Technology co ltd. They sell Model 3 B's for 195RMB + 10RMB shipping. Why do Element14 and RS China charge 260RMB? How do they sell these for cheaper than their distributor? Overhead? Aren't they made here?
How does the ODROID2 work? It's 40USD, or 52,800 won in Korea. 52,800 won is 46USD. Granted, there's 16$ shipping for international orders.
My take is that nobody is doing better than Pi in terms of the community Pi targets, e.g. students, amateurs and greenhorns alongside professionals. There's a critical mass with Pi that attracts industry players to be on the platform with what counts for decent support in the embedded world, e.g. Microsoft and Canonical.
Always. Everywhere. Wanted 25 units to teach a robot class to some local kids at the Hackerspace. Had to buy 3's instead. Even if I'd placed 25 separate orders, the cost of individual shipping on each vs the cost savings of the combined shipping on the 3's put the price within spitting distance.
Pi zero is an ad. A loss leader. A way to have an answer, any answer, to the flood of $7 Allwinner wonder-boards on AliExpress.
The Zero is a very different devboard, though - you will need to invest in assorted adapters and hubs if you want to connect it to just about anything other than power... it is useful in small spaces, but for anything else spending a little more to get something like the CHIP is well worth it, and for use a small PC, going to the RPi 3 is probably wiser.
The Raspberry Pi 3 is available from many vendors for $35 + sales taxes. You can pick it up on our site for £32 including VAT (that's EUR30 before taxes or EUR36 including taxes): https://shop.pimoroni.com/products/raspberry-pi-3
Texas Instruments am335x also is a popular chip with upstream support (Beaglebone Black & Olinuxino am3352-som and quite a few other vendors have modules based on it.) If you want a canonical list, look in the kernel arch/arm/boot/dts source: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-st...
Actually it looks like there are quite a few Allwinner devices listed (look for sun__...)
ODroid C2 and XU4 have been making progress, though last I saw they weren't really stable yet. I think HardKernel, the manufacturer, is providing some level of support for the mainlining effort.
Next Thing says the C.H.I.P. (or at least the C.H.I.P. Pro) runs mainline Linux, but that's not really comparable to the current Raspberry Pi.
Does it have support for the graphics though? That's the first big stumbling block these alternate SBCs run into. Without support for graphics acceleration you won't be able to play video properly or run fancy desktop apps. It's a huge drawback these days.
The Kodi people are not to be trusted on this matter, it's just an ugly political game. See http://forum.pine64.org/showthread.php?tid=1497&pid=13513#pi...
And also https://github.com/linux-sunxi/libvdpau-sunxi if you are actually interested in a working hardware accelerated video decoding. To sum it up, hardware video decoding acceleration works fine with fully open source drivers on Allwinner hardware, but the Kodi application just does not want to use them. Fortunately there are also other open source media players, which can do the job.
As for the lubuntu image, anyone can take any ARM Linux distribution rootfs and combine it with the Linux kernel, built for Allwinner hardware (both mainline and legacy kernels exist). You can find a lot of tutorials at https://linux-sunxi.org
But if you are not a very experienced user, I strongly suggest you to try something like the armbian distribution first.
Do the above arguments apply to the board range, or just their distro? Whilst not yet supporting Orange Pi PC2, what about Armbian? http://www.armbian.com
While AllWinner provides dismal driver support, there's quite a big third party effort to get proper mainline support for their chips (Free Electrons being the biggest contributor, I think).
A good reference of what you can expected can be found here:
Of course it takes time to clean it up into a mainlineable state. Some years ago I got a "Cubietruck" (A20) and it was somewhat disappointing - the gigabit ethernet (which was the selling point for me) only got to only about double of 100Mbit, using up one of the two cores. It would also have network connections hang once in a while.
This spring I dusted it off and managed to install the latest mainline kernel, and with the exception of onboard NAND (not really necessary since it has SATA), everything I care about works perfectly. I get proper gigabit without CPU stress, and everything is rock stable.
tl;dr: it's worth looking at older devices of they fit your need
So, having the GPU on the same SoC qualifies as "standalone" now?
So any Intel with iGP also has a "standalone" graphics chip?
Or is this Tech Crunch writer just clueless?
> physical power switch
No. It has a GPIO mapped button that can be used for soft power down. The original Orange Pi has the same button and to my knowledge it can only be used to turn the board off. The board powers on as soon as power is applied.
So much negativity and misinformation here. Orange PI PC boards are well designed, with attention to things that many other board makers fail at, like heat spreading, space for heat sink (you don't really need one usually), quality DC connector, fine grained CPU voltage regulation, USB not being crippled by on-board hub, etc.
Mainline support is also progressing well. With some patches you can get temperature regulation, HDMI support, audio support now on mainline kernel.
Video decoding is also progressing as someone noted in other comments.
SoC on Orange PI PC is also very nice for people who care about not having binary blobs running show on some hidden internal processor. There is additional OpenRISC CPU on the SoC, but it doesn't run by default on mainline kernel, and you can also program it yourself, without too much trouble.
Armbian supports these boards quite well, including video decoding support.
Allwinner is also not that bad at releasing code/datasheets. They release a lot of code. The issue is that it is designed for old kernels (3.4, 3.10) so it's not directly usable/easily portable to newer kernels. But still it is helpful and community is actively working on mainlining the support for various SoC parts.
Orange PI PC (H3 soc) is quite usable as a desktop for web browsing and audio/video playback.
I'm glad to see H5, because it looks like performance wise it will be still better and I'm also optimistic about the open source software support in the future. It certainly is a very motivating board to develop for at the current price/performance level.
"Allwinner is also not that bad at releasing code/datasheets. They release a lot of code. The issue is that it is designed for old kernels (3.4, 3.10) so it's not directly usable/easily portable to newer kernels. But still it is helpful and community is actively working on mainlining the support for various SoC parts."
Allwinner does NOT cooperate with the linux-sunxi community. At all.
Video decoding acceleration does work on A10/A20/H3 with the legacy 3.4 kernel out of the box. I believe that you can even find some ready made SD card images. And you can track the mainlining effort at https://linux-sunxi.org/Sunxi-cedrus
"AllWinner is a GPL violator"
You are just cherry-picking statements and severely exaggerating them. Every major hardware vendor has its own skeletons in a closet. Maybe you can remember Linus Torvald's middle finger to NVIDIA and things like this. Allwinner is definitely not a saint, but is still far from the worst. If you want to vent out your hatred, then I can give you some better targets.
"Allwinner does NOT cooperate with the linux-sunxi community. At all."
This is not exactly true. They are at least providing the documentation and also their open source code drops. Some people (mainly the devboard manufacturers) have contacts with Allwinner.
Is this layout an output of some optimization algorithm that computationally finds the best layout without considering non-relevant constraints like human aesthetics? Or are we used to "perpendicular" layouts simply because assembly machines weren't able to rotate components like that?
Pick and place has always needed to rotate because the odds of the PCB part being in the same orientation as the supplied tape is extremely low especially for analog parts or RF parts. Even for "purely digital designs" (LOL, all circuits are analog) you never had tapes of 0.1 uF decoupling capacitors in vertical vs horizontal orientation, or four tapes of LEDs in various orientations (LEDs have polarity).
> Or are we used to "perpendicular" layouts simply because assembly machines weren't able to rotate components like that?
I used a small pick and place machine 15 years ago (Europlacer something or other). It was able to place components at any angle. You'd have an X,Y package centre, and then a theta rotation angle.
Programming it would not have been fun, but the placing is controlled by the programming and machine vision and fiducial markings.
I don't know, but if I were responsible for layout, that's the kind of thing I'd do. I think it looks great. I wonder if this design makes PNP more expensive.
Typically designers would turn a part to better align interfaces. e.g. if you have to chips which need to be connected you might rotate one to get the 'straighter' traces.
This looks like it might be to align the DDR better to the main processor but who knows.
Wave soldering is used for through hole, not surface mount, components.
With wave soldering you have a bucket of molten solder that is pushed over the lip of one edge of the bucket. This is the wave. The circuit board is transported over the wave, just touching it. Solder flows to the exposed copper, but not anything else (which is referred to as solder resist in this context - that blue colour is solder resist).
Surface mount would tend to use screen printed solder paste and then a hot oven to melt the paste.
Just a clarification here: you can in fact wave solder surface mount parts, and it's often done. It doesn't work for leadless parts or parts with pins under the package such as BGA and LGA but it can be used, with proper board design, for most other parts, even surprisingly fine-pitch ICs. The parts are glued to the PCB and then passed through the wave. The most common use is for passives, such as decoupling caps, on the bottom of a PCB.
It's a question of expectations. Me, I want a cheap, wifi-capable motion sensing camera on my LAN, behind a firewall, not on the public internet.
So I ordered the Orange Pi Lite and its camera module, altogether a smidgen less than $30 Canadian (a current model Raspberry Pi will set you back $50+ around here, and then another $10 or so for the camera module (or a clone of it) from China.
Not impressed initially. Not much documentation, so how do you know you even got it powered up right? No lights come on, no video signal comes out, nothing. Eventually hooked up a TTL USB/serial converter to the GND/TX/RX three-pin connector and hallelujah, it did boot and let me log in and set up wifi remote login. The only thing I found that booted was the Lite-specific Armbian distribution and yes, it uses a 3.4.x kernel, and I still haven't managed to get any HDMI output.
But on the plus side, "motion" was cinch to configure, works great with the camera in 800x600 mode (CPU temperature 43 degrees Celsius with no heat sink, board out in the open at room temperature) or 1600x1200 mode (CPU temperature about 48 degrees Celsius). That load also includes a script which periodically rsyncs the collected pictures to a server, and cleans up (I use /tmp in RAM disk to avoid SD card wear).
Happy? You bet. I'll probably order a couple more. Use this for direct internet facing stuff? No. Use this for general purpose computing where every feature has to work and the CPU performance is absolutely maximized? No. But for the specific application I want it for, peachy keen. At least it's been stable in two days of running and over a gigabyte of pictures taken and saved.
I've also got a Raspi and its camera module. All in all, the experience with the Raspi isn't any better, though the camera sure is, and now you can get an 8MP camera too (the OPi's camera is 2MP).
I don't know about the Orange Pi directly, but one of the other Allwinner boards I tried would only output on the HDMI if the display negotiated HDCP. So you had to hook it to a TV, not a computer monitor, to get the picture.
In general if you want something that just works, the Raspberry Pi is a much safer bet. These alternate boards always seem to have something stupid you have to fix before they work properly.
True, it's not a safe bet, but at the price it's a fun experiment. I've now concluded after further playing with mine that 1600x1200 mode effectively doesn't work (you get a picture, but it's mirrored horizontally and auto brightness/contrast doesn't work). Still at 800x600 good for the price.
I dread to think how long it took to lay that out, but I'm pretty impressed. A lesser person would have just given up and used a larger PCB, but they were clearly determined to fit everything in the same footprint as a Raspberry PI.
Is there a reason for the odd layout? Some pathalogical issue with utoplacement doing the best it can to fit components into a limited space? Trying to avoid sharp edges in the track for some weird capacitance reason? Or maybe it's deliberate to try and drive its users insane... anyone actually know?
45° rotation make sense when you want to avoid having half of your traces exit a dense chip towards the board edges, assuming (which often is the case) a rectangular board.
I guess in this particular case, the (many, and sensitive to total length and relative length with respect to each other) traces connecting CPU and RAM had been routed in isolation first. These chips seem to be 45° rotates against each other.
Then the group of CPU & RAM had been rotated too leave enough space for power/camera/HDMI, I'd guess.
It looks strange, but frankly there is no real reason (besides aesthetics) to favor any particular orientation.
I've worked with a PCB layout designer, and one comment he made is that it's far easier to do a 'by eye' check of, firstly, the virtual layout in CAD, and then the assembled board when things are arranged neatly or at 'nice angles'. Having done some PCB layout myself - mostly through-hole, although with a large number of parts - I never found circumstances in which odd angles made it easier to do the layout. However, I concede it might be for reasons of short traces or making traces certain lengths if required for timing reasons.
Yes they are cheap... but their hardware has a high fault-rate. Hardware support is there but the software support is crappy at best. Allwinners SoC's pretty much have zero support in the open source community. They use old kernels. You will be running old kernels and graphics drivers. Also... the old Orange Pi SoC got notoriously hot. 60-75 degress celcius. You needed an active cooler or very big passive one. Lets not forget the ridiculous patched kernel by Allwinner. They forgot to remove their "debug" code which basically allowed total control over devices shipped with the kernel; http://forum.armbian.com/index.php/topic/1108-security-alert...
I'd be very causcius about using this SBC. Sure it's fine for fiddling around. You're better of with ODroid.
All winner has had a terrible history of gold violations and Linux support. They'll release a kernel binary with support but not sources and not update things for ages.
Some person from linux-sunxi made it his life mission to crucify Allwinner because they (Allwinner) messed up with some Linux kernel tarballs. What you have been reading is the result of this campaign against Allwinner.
1. Allwinner used to distribute Linux kernel tarballs with several device drivers in binary-only (object) files. They were in the correct place and you could recompile the kernel. Those binary .o files would be used so that you could complete the compilation. Such an example is the Mali driver and others that Allwinner did not make an effort to get the rights to redistribute in source.
Obviously, this is a GPL violation.
So, how do you deal with this issue? Do you get Allwinner to release the source of the Mali GPU driver due to the GPL violation? :-). Some people wanted to play lawyers and would mess up ANY action unless Allwinner complied fully by releasing source code to things that they did not have a licence (to release source).
2. Allwinner released officially the source of the 3.4 kernel for a range of SoCs (A10 to A83, the H5 should be similar to one of the A?? SoCs): https://github.com/allwinner-zh/linux-3.4-sunxi
A few months ago, there was a discussion on LKML on how to deal with GPL violations. Linus and Greg said that being aggressive in pursuing the GPL violations really does not help. Here is an example where it did not help.
In both 1 and 2, there are a varying amount of blobs spread around kernel tarballs and even kernel git repositories, and Allwinner has been made aware of those being in violation with the GPL quite a numerous amount of time.
Has allwinner gone and resolved all of these issue in the meantime (which is only a brief timeperiod measured in, oh, i don't know, 3 years)? No. At best they did a few but only increased the number of blobs upon every new kernel release.
Stop your nonsense, besides it just being inane, it is quite perpendicular to the truth.
--libv (simosx's bestest friend in the whole world).
So this is the person I was talking about. Hey, libv!
First, libv does not get what is being said, for example, in https://lwn.net/Articles/698452/
The situation with Allwinner fits quite well with what Greg and Linus talk about.
Second, libv as a business person sucks bigly. He was being a PITA to Allwinner and, from what I deduced, would then propose to them to make the problem go away (develop himself the software) for quite some money.
Having been burnt several times buying 'cheap' SoC's like these and then spending hours trying to get them working due to crappy upstream support then I'd steer clear of this. If you value your time and don't want to get out SPI interfaces and the like to debug something then save your time and subsequently money, buy a Pi3.
Side note: One vendor (Pine64) even shipped binary images in a RAR format. I'm not sure why this was chosen, but makes you wonder how they got to that decision and if they spent much time working with 'proper' distro's for embedded, where nothing is shipped as a RAR but gz/bz/xz whatever
I'm really surprised the naming types for the Arm8 (64 bit) low cost boards didn't call them 'Tau' rather than 'Pi', and 'Orange Tau' or 'Dragon Tau' sounds reasonably identifiable to me and it would quickly become the defacto way of distinguishing between 64 bit machines and 32 bit machines.
I'm a little confused. Hopefully HN can teach me. At 1 GB isn't the 64-bit detrimental? I thought 64-bit addressing cost about 5-10% of performance, but didn't matter since the system has hundreds of more MB of RAM.
I guess this makes sure it runs on more modern operating systems. I thought that most still support 32-bit.
64 bits means bigger integers before overflow, wraparound or whatever. Big ints may be useful when working with big data. It also means double precision floating point will tend to be faster. That may be useful in signal processing applications.
All that said, mainly the board is 64b because popular recent versions of the ARM core are 64b. The Raspberry Pi 3 is also 64b but Raspbian Linux typically comes as 32b...or at least did last I looked.
32-bit refers to the memory addressing. There's nothing that says that a 32-bit processor has to have 32-bit instructions, 32-bit ALU, etc. And most 32-bit processors are perfectly capable of working with long-int/double types.
Assuming the processor is otherwise identical, 64-bit addressing on a SoC with 1 GB of RAM doesn't do anything except waste memory on an excessive address space.
I think that historically, n-bits refers to the architecture's word length and that may or may not match the size of the address bus for a particular processor. Likewise, historically, multiple smaller than word-length data structures were sometimes packed into single words. The mantissa and exponent of IEEE 754 kinda' sorta' do something like that if I squint real hard.
Not that bitpacking words is particularly execution efficient, but maybe the space savings is worth it. Probably the sort of thing that's worth benchmarking in an actual app. Likewise with memory usage; I mean 1GB may be more than enough for a particular application and minimizing the OS may be a useful tradeoff for saving halving reads on 64b or greater data structures.
Anyway, the intent of my comment was to provide an explanation not promote one dogma over another...I think the big reason the SoC is 64b is 64b seems to be a sweet spot in the ARM powered credit card sized computer market place right now. And if I were considering this board but 2GB RAM was a concern, I'd probably go with an AllWinner board with that much. For example a BananaPi: http://www.banana-pi.org/
Supposedly ARM64 is more efficient than ARM32 clock per clock (better IPC). I know Apple made a big deal about it when they switched. I think it's partially due to them ditching some backwards compatibility braindamage.
While really awesome on specs and price, downside of these boards is dev tools and community support. They are getting better at it and very fast, but living on the cutting edge is not pleasant.
That's the biggest problem with these boards, not just OrangePi, but most of of these SBCs. The ecosystem and development support leaves a lot to be desired. The community size is not comparable with what Raspbery Pi has and it shows.
I have the original BananaPi and unless you are willing to do a lot of Linux hacking, it is most often not worth the hassle over RasPi. E.g. in the case of this Orange Pi most people don't need the 64bit performance, moreover the board still has only 1GB of RAM, so the advantage of a 64bit CPU being able to access more RAM is not going to be used here.
Yes, Raspberry Pi is slower, doesn't have all the cool peripherals, but the ecosystem is much better. A fast CPU means little if you can't get a driver that you need working or a kernel hasn't been ported to your board ... Having to hunt stuff down on some Chinese forum is not fun.
The Orange Pi range are based on Allwinner SoCs which have poor Open Source drivers for the VPU (the bit of the SoC that actually plays video). There have been a number of attempts to improve this, and all so far have failed. All winner don't really seem to be that interested in working with Kodi devs to sort this, and apparently have a patchy history with open source licence compliance.
http://forum.kodi.tv/showthread.php?tid=238060
"Currently, the combination of the kernel driver and VA-API backend supports MPEG2 and MPEG4 decoding only. There is for the moment no support for encoding, and no support for H264, though we believe support for both aspects can be added within the architecture of the existing driver and VA-API backend."
The board layout looks strange. All those odd angles. It looks like someone copied partial layouts from other projects and crammed them into the available space. I wonder what board design program they use.
Can this be used for ZCash mining? (Never mind, ZCash is down 95% from the peak 9 days ago.[1])
There's useful insight into some of the SoC-based boards on Pete Scargill's IoT site chronicalling his gadget and MQTT-based work; it's well worth a browse...
How come there aren't any Raspberry Pi competitors using Intel Atom CPUs? There's plenty of cheap tablets running Windows 10 on Intel Atom on Aliexpress and similar, remove the screen and battery and it should be doable at an affordable price, no?
I first thought, oh noes I just got a RPi3, but then reading the specs I see it's not very different? USB2, 1GB RAM, A53, why would I (two weeks ago before ordering the Rpi) order this instead?
Gigabyte Ethernet for one, if you are using this in a project where Ethernet bandwidth is a problem, this would perform much better.
I actually want one of those RPi clones exactly because RPi performs so poor in I/O applications, since all external bandwidth is shared by one USB 2.0 HUB (including the Ethernet port, and more recently, Wi-Fi/Bluetooth). I use my RPi as a media server/torrent client, and it is severe limited in those situations.
As I understand, even adding a 1000M port to the RPi3 would not increase the network bandwidth. The limiting factor is bus and cpu. My RPi3 Model B maxes out from speedtest.net at around 91Mbps. From my iMac I get 180Mbps (throttled from my provider) not the Mac.
Yeah, on the Pi the ethernet is still hanging off the USB2 bus. That wouldn’t be too bad if the various ports had their own buses, but unfortunately everything is hanging off a single usb interface coming out of the core cpu, so although the raw bandwidth is there to make 1G ethernet potentially worthwhile - you can plug in a 1G USB device if you want to - but as soon as you actually want to do anything you get contention on the bus and your throughput drops like the proverbial rock.
No, it won't - because the ethernet on RPi is actually going over USB. The CPU doesn't have a built-in ethernet peripheral. So adding a gigabyte port would be pointless - the bottleneck would still be the USB bus.
The data rate over USB2 after accounting for overheads is a lot faster than 100Mbit, so it’s not entirely pointless - you would be able to serve cache files faster for instance. But as soon as you have anything else hitting that bus, your real world bandwidth is going to be < 100MBit.
Since 1G is more power hungry than 100MBit interfaces as well IIRC you can understand why the Pi people decided to stick with 100MBit.
Without good marketing and community support..this thing will be DOA like many other boards that tried to take on the RaspberryPi in the past few years.
I love it too. And because I love Raspberry Pi, I'd like to point out that Orange Pi are nothing to do with Raspberry Pi and are infringing on their trademarks. Raspberry Pi purchases fund their Foundation, which produces educational material for and liases with UK schools.
This is very interesting. the $79 price point is for the 2GB RAM model - and seems worthwhile with other accessories options provided.
The one concern I have with this board is that it ships in March 2017, which is getting very close to the next iteration of RPi4/Odroid C3, and that it opted for more LAN/WAN instead of adding more USB 2.0/3.0 Ports like the Odroid/RPI.
Many thanks for giving me something to heavily consider this next week for SBC projects though....
http://forum.kodi.tv/showthread.php?tid=238060
the current lubuntu image does not even exist.
http://www.orangepi.org/downloadresources/PiPlus2e/2016-06-0...