Banana Pi BPI-M64 board was launched with Allwinner A64 processor, but a few days ago, I noticed the board got an option for Allwinner R18. Both processors are likely very similar since they are pin-to-pin compatible, and Pine64 was first seen with Allwinner R18, so I did not really feel it was newsworthy. But today, Google announced Google Cloud IoT Core cloud service working with a few app partners such as Helium and Losant, as well as several device partners including ARM, Marvell, Microchip, Mongoose OS, NXP… and Allwinner, having just announced the release of an Allwinner R18 SDK with libraries supporting Google Cloud IoT Core.
Let’s go through the board specifications first which are exactly the same as for the original BPI-M64 board, except for the processor:
- SoC – Allwinner R18 quad core ARM Cortex A53 processor with Mali-400MP2 GPU
- System Memory – 2GB DDR3
- Storage – 8GB eMMC flash (16, 32 and 64GB options), micro SD slot up to 256 GB
- Video Output / Display interface – HDMI 1.4 up to 4K resolution @ 30 Hz, MIPI DSI interface
- Audio – HDMI, 3.5 mm headphone jack, built-in microphone
- Connectivity – Gigabit Ethernet + 802.11 b/g/n WiFi & Bluetooth 4.0 (AP6212)
- USB – 2x USB 2.0 host ports, 1x micro USB OTG port
- Camera – MIPI CSI interface (which I guess you support parallel cameras via some kind of bridge)
- Security – Hardware security enables ARM TrustZone, Digital Rights Management (DRM), information encryption/decryption, secure boot, secure JTAG and secure efuse
- Expansion – 40-pin Raspberry Pi 2 somewhat-compatible header
- Debugging – 3-pin UART header
- Misc – IR receiver; U-boot, reset and power buttons;
- Power – 5V via power barrel; 3.7V Lithium battery header; AXP803 PMIC
So from hardware perspective, there’s no advantage of getting the board with the new R18 processor. But the SDKs are somehow different, and based on Allwinner’s press release, only R18 processor gets Google Cloud IoT Core support.
Some of the key benefits of Cloud IoT Core include:
- End-to-end security – Enable end-to-end security using certificate-based authentication and TLS; devices running Android Things or ones supporting the Cloud IoT Core security requirements can deliver full stack security.
- Out-of-box data Insights – Use downstream analytic systems by integrating with Google Big Data Analytics and ML services.
- Serverless infrastructure: Scale instantly without limits using horizontal scaling on Google’s serverless platform.
- Role-level data control – Apply IAM roles to devices to control access to devices and data.
- Automatic device deployment – Use REST APIs to automatically manage the registration, deployment and operation of devices at scale.
Both Foxconn/SinoVoIP and Pine64 can offer Allwinner R18 platforms compatible with Google Cloud IoT Core via their Banana Pi BPI-M64 and Pine A64+ boards respectively.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
Oh my… what a weird mind set behind this all (absolutely identical SoCs with different names and different chipid that are only allowed to run this or that ‘SDK’ based on this ID — when will Allwinner realize that this is plain stupid?)
BTW: You forgot to mention that Xunlong can produce an ‘OPi CloudIoT’ (‘OPi Win’ with A64 replaced by R18) and same with FriendlyELEC’s NanoPi A64. At least now we know why hardware vendors still rely on these uninteresting chips in 2017 and release new boards with them.
@tkaiser
About Xunlong and FriendlyELEC making R18 boards that’ true they could do that easily, but Allwinner PR only mentioned Foxconn and Pine64. I’ve asked TL Lim about Pine64 with R18, but he has not replied yet.
@cnxsoft
I forgot Olimex before, they also have finalized A64 designs where nothing has to be changed except of the SoC. At least now we also know why Allwinner is about to release a new kernel 4.4 BSP variant (Google must have had a laugh when Allwinner was telling them that all they have is either kernel 3.4.39 or 3.10.65)
cnxsoft:
You miss a R in the title…
BTW: I was wrong above, it’s not about chipid but a different bit as can be seen here:
http://forum.linksprite.com/index.php?/topic/4516-lm-sensors-no-worky/#entry12084
Allwinner’s A83T and H8 are as similar (identical) as A64 and R18 we’re talking here about but H8 was only ‘allowed’ to run Android 4.4 while A83T (different business unit) supported ‘even’ 5.1 (and the above check should ensure that H8 users could not enjoy an Android version exceeding 4.4). In case Allwinner implements something similar now with A64 and R18 (the ‘ic check’ above) to limit ‘SDKs’ to specific SoC variants all you need is dd to replace parts of a blob.
@tkaiser
The only explanation I can think of is that Allwinner charges different prices for the same SoC depending on the level of software support. If we consider that A64 = R18, A64 might be cheaper because it’s using a standard SDK for tablets and TV boxes, while R18 might be more expensive, as the company’s software workload is higher for the latter, and overall market volume is likely lower.
@cnxsoft
The idea to pay for Allwinner’s ‘software’ hurts! I hope someone at Allwinner takes eg. a Pine64 and then runs their latest own Android 6.0 on it and compares it to community’s (ayufan’s) Android 7.1. And I hope the same person then starts to think about what’s wrong with the way they’re doing software.
@tkaiser
Possibly one more reason to use Allwinner R18 over A64: Long term support.
I got the following answer about Pine64 R18:
I implemented Amazon’s IOT core on the A64 months ago, there was nothing special about it. The only slightly unusual bit is that you need to use the secure keystore to hold the device’s private key. I seriously doubt if Google’s IOT core is significantly different than Amazon’s.
The management at Allwinner does not know how to organize a SOC company. The people running Allwinner are clearly chip heads and they organize like a chip person views the world. News to Allwinner — organizing that way is an utter disaster for software development. You are institutionalizing “port and forget”. Chip head managers don’t get this since chips are basically make the mask, ship, let marketing worry, move onto the next chip. Allwinner’s organization makes perfect sense to a chip person, but this is not how software works.
Allwinner has done an even crazier scheme of creating competing business units. Yet another disaster the US semiconductor companies tried and failed with. For sure make separate marketing groups — but do not assign independent chip designers and software people to these divisions. Can’t you see that they will stop sharing information since you have them competing against each other?
US chip companies spent decades learning that this was the wrong model and now most have changed.
Allwinner act like a company whose main market is dying and are licencing their IP in several different markets in a attempt to survive. Hence multiple SoC with bits added or removed. IMHO thats why they are so thread bare with software support, like Orange Pi they just make things software support is not priced in, maybe like CNX says for upport you pay extra?
Nanopi cost more but their is some software support. Mind you I know Nanopi don’t just sell to makers they sell to industry too, don’t know about Orange Pi.
This is why sane people should stay away from Allwinner type xPi “community” vendors and just go along the flow with those very available, very hackable, very supported, very cheap and best price/performance Amlogic/ RK devices that clearly are more than Android Boxes, 32/64bit.
The only exception is CHIP. But they chose to invest in professional help and thus are doing well now.
Repair jobs and excuses can’t help. This isn’t about those old Maytag commercials.
Is it not simply a material die shrink which you could argue is a good enough reason for Allwinner to move name A64 -> R18 ? Lower power, heat and better stability at higher clock speeds etc .. plus a few fixes and slightly updated cores .. sounds fair enough to me if that’s the case
Nope, both R18 and A64 are 40nm (and the same chips BTW and R18 even appeared before A64 ‘in the wild’ — see above 😉 ). Allwinner’s 28nm offerings are A80 and A83T (the latter also known as H8, R58 and something with V) and soon H6 and A63.
In short, probably Jon Smirl view about Allwinner is the right one.
According to the book they recently sent with the Banana Pi R40 gift, the Rxx series is for “smart hardware”, in contrast to “consumer electronics”, “home entertainment”, “automotive applications” and “industrial applications”.
This all seem like business units, and that’s fine, except that they seem to be overlapping themselves. Many SoC’s appears to be really the same over units, with different names, so clearly, this units are not only about chips, there is also software and support involved.
It is a strategy, like shooting in all directions, maybe you hit an absent-minded duck.
Or, maybe you shoot yourself on the foot…
We should start a Kickstarter campaign buying out allwinner 😛
After all we all know how to do it better 😀
@itchy n scratchy
Allwinner is worth over a billion dollars in the stock market. That’s going to be a huge Kickstarter.
@Jon Smirl
Hmm, so each business unit has their own SDK, processor name, and target products. I wonder how software resources are shared between units since there is so much in common.
@cnxsoft
The R group is releasing a different SDK for the R18. They are not using the A64 one. That strongly suggests to me two sets of software people. A single software group would have simply added the R18 extras into the A64 SDK.
You want a centralized Linux and Android group. Then inside that group you develop specialists. For example the DMA person, the UART person, the Ethernet person, etc. That person is responsible for driver support over all of the CPUs Allwinner makes. They become experts on this piece of the SOC. The output of this group is a single SDK that supports all Allwinner processors. Like what mainline Linux is doing for Allwinner SOC currently. Not the single CPU kernels that AW keeps releasing.
Then you can give this central software group two instructions:
1) Add a new SOC to the existing base. Each specialist will extend their existing driver to add support for the new SOC. Not cut and paste then edit to make a new driver! That happens with separate groups.
2) Add support for a new kernel or Android release. Everyone in the group works together to bring all of the SOC support up to this new release. This is not that hard now since each expert in their niche will know exactly what the issues are.
The central group allows these vertical specialists to exist. Having the chip groups do it results in a lot of copy/paste/edit (which we see in spades) and many bugs because the work is having to be done by generalist assigned to the group. When the programmers belong to the hardware groups Allwinner is creating “port and forget” specialists.
One example of this in Android. Only a chip specific porting group would go in and edit the h.264 enc/dec support in android/frameworks/av for each chip creating a different version of that directory for each SOC. A central group would have used the OpenMax framework sitting in front of them and made OMX plugins for each SOC.
Consider that last example. If you edit android/frameworks/av and make it specific to an SOC, that code can never be checked back into mainline Android since it breaks every other SOC in the tree. Those edits were clearly done by a software group that had to worry about a single SOC and did not care about breaking all of the others. That decision has institutionalized “port and forget” now in Allwinner Android because the way they are adding h.264 support the trees can never coexist.
And why, why, why can’t AW maintain a public git tree with their Linux and Android code in it? Why are we stuck with these 8GB zip files of the trees. AW uses git and lets OEMs close to them access it, but they won’t make it public. The explanation for they give me is that they have secret Google code in their git. Fine, so only put the the non-secret pieces on a public server. News to Allwinner — that AOSP you are starting from is on a public server at Google! So I regularly have to get an 8GB drop out of China’s awful Internet, and then diff it with the public Google tree to find out what Allwinner changed! There are zero Google secrets in these code drops.
Google is probably giving AW access to unreleased Android. Of course that should be kept secret. But when you publish the AW git tree you don’t have to publish every branch. Just publish the released branches. If you don’t expose a branch in the public server, I can’t get to it. Gosh, even super secretive Qualcomm’s Android git trees are public.
I really, really wish I could get Allwinner to support a public git tree. I have been asking them to do this for years without success. Hundreds of other people also ask them to do this. I believe the problem is that their legal department is confused about their contracts with Google. The legal depart is not differentiating Google’s released code and unreleased code and insisting that all access to Google code be protected by NDA. I have specifically been told by AW reps that the Google contract prevents them from making a public git tree. They are simply confused about this. The contract says UNRELEASED code has to stay under NDA, not the released stuff. Allwinner is making me sign NDAs that say I won’t release Android 5 AOSP source code. That is just messed up.
A public git tree would be so valuable to them if they’d just do it. The way Android works AW public tree will only contain AW’s delta changes to AOSP not all of AOSP. When you fetch the tree all of the 8GB of core AOSP will download from Google’s very fast public servers. Then only the deltas for AW’s changes will come from China or wherever they host.
Once there is a public AW tree, all of the colorful PI vendors can then base of from it. Say the Orange PI people. The orange PI people’s git server will only contain an Android manifest file and the specific changes Orange PI has made. When you use Google repo tool to access it, repo will first fetch the correct AOSP base from Google’s hugely fast servers, then apply the Allwinner changes from their servers, and then apply the Orange PI changes. All automatically.
Now consider a critical bug patch from Google. Google patches it in the AOSP servers. You type ‘repo sync’ wait five minutes and that critical patch is now in your local code. Compile and push out to your devices. Sometimes there is a merge conflict but those are usually easy to fix.
Note the tremendous difference the public git server makes. Did Allwinner or Orange PI needs to lift a finger for me to get that security patch? No! In the current model Google patches AOSP, and then almost zero AW customers end up with the security patch. That is because AW’s code distribution is messed up since the public git server is missing.
I can do the ‘repo sync’ right now with super secretive Qualcomm’s Android, why can’t I do it with Allwinner’s?
The last step in this process… Both AW and Orange PI have public git servers hosting their changes to Linux and Android.
There should be a constant only going effort to empty out those delta servers by getting their code checked into mainline AOSP and Linux. In a perfect world those servers would be quickly emptied after each new SOC is released.
Once the code ends up in mainline it can truly be in maintenance mode.
@Jon Smirl
Wow. So you mean the R and A team may have different kernel tree within the company, and they just share drivers by copy/paste with each SDK evolving its own way? So some kernel bugs may be fixed in R-series kernel, but still there in A-series? If that’s the case that’s really crazy. I would expect the low level part like the kernel to be shared across business units, and higher level or “added value” software handled independently by each unit.
The A64 team made the A64 SDK and shipped it. Management then disbanded the A64 team and sent the various people out to work on new unreleased chips implementing SDKs for them inside the A division. That is classic “port and forget”. The A64 SDK is never going to get much in updates because no one is assigned to work on it any more.
The R division has a completely different set of programmers. That’s because the R and A divisions compete at the General Manager level. Those GM’s bonuses are set on how well their division perform. So the R division programmers will pick up the A64 SDK add what is needed for the R18 and ship it. They will not bother merging back with the A64 people since their group is not compensated for doing that. After the R18 SDK ships that team will be broken up and moved to other projects in the R division. “Port and forget” strikes again!
This awful management style was practiced by most of the US semiconductor industry in the 1990’s. Most have discovered that it was a really bad way to do things and have reorganized.
This management style occurs when chip people end up in top management at these SOC companies. They treat everything like a chip and software is definitely not a chip. But these “chip heads” don’t know much about software so they can’t see how bad this organization design is for long term support. You can’t blame the “chip heads” for acting this way, it is the only area they have worked in. What they are doing is the correct model for making chips.
Now I don’t have detailed internal org charts for Allwinner. But I used to work for US companies that had this exact management structure before realizing how messed up it was. Only after a couple of very expensive failed launches of new chips because the software supporting them didn’t work did management change.
@Jon Smirl
I really hope someone at Allwinner has the balls to translate your points into Chinese for Allwinner’s management without altering contents so they might get the idea why they will fail especially in their new ‘R business’.
I believe with their traditional markets the awful ‘port and forget’ style seemed to work well for them. Their only customers were hardware vendors living the same ‘company culture’: Once the cheap tablet or OTT box is out it’s already forgot, zero support, zero updates, let’s move on to the next piece of hardware before customer takes notice and sell them something new instead. No one ever cared about kernel version or security flaws (quite the opposite, the average Android user of these cheap gadgets moronically asks first whether horrible security vulnerabilities are available to ‘root my device’) and their direct customers (hardware vendors) were happy with Allwinner doing the software work.
The ‘R use cases’ are somewhat different and I really had a laugh reading about ‘End-to-end security’ above in combination with Allwinner’s great kernel offers (currently still either 3.4.39 or 3.10.65, some rumours say they work on a new kernel 4.4 based BSP variant maybe due to some buttkicks by Google while still not understanding what ‘mainlining’ means).
Where did you see an R18 SDK? At github.com/tinalinux there’s nothing.
The BPI people have it, they have not managed to get it onto a public server yet. They are going to put it up, I think they are just fighting with the stupid 8GB file.
As you can tell I have worked in chip companies behaving like this. That’s where the term “chip head” for a division manager who is excellent at chips and who knows nothing about software comes from. I didn’t make it up.
I just gave Allwinner about $50M worth of advice. My ex-employer lost way more than that learning those lessons.
To be fair, this is not only a Allwinner problem, 90% of us all have that deficit in our Android phones, tablets, etc, no matter what the Soc maker is.
This is beginning to hurt Google, so I guess this “business model” (mentality?) will change with time.
And, thanks Jon Smirl for the very fine lecture!
Tkaiser:
I think Chinese management can read English very well… 😉
There are signs that Allwinner is starting to see how the strategy I described works. Consider the A13 and then the R8. When the A13 first came out it was their flagship chip. Of course they did “port and forget” on it and dropped the software. But someone had the smarts to see that flagship chips can be repurposed as a low end model with very little expenditure. So this smart person launched the R8 taking advantage of the free R&D from the A13. If you happen to own fabs this strategy can really pay off since your flagship chips can only be built in the new fabs and these old models can keep the old fabs doing something better than tearing them down. The strategy works even better if you plan on doing it from the beginning and you make the software maintainable. Sometimes you even get a surprise and that repurposed flagship sells like hot cakes by being useful in an unexpected market. Then you can do a die shrink on it and move it into a newer fab which will increase your yield and margins.
They will also quickly learn that their automotive chips are going nowhere without a minimum ten year longevity guarantee.
@JotaMG
There are two factors messing with Google and Android. The first factor is vendors doing “port and forget” like Allwinner does. That one can be fixed.
The second factor is much more worrisome. Some companies (like Qualcomm) are purposely trying to create churn in the phone market in order to generate revenue. Places like Qualcomm are trying to stack things so that you have to buy a new phone every two years so they will get another huge patent royalty check (as high as $10/phone). Qualcomm has been “encouraging” this churn by refusing to update drivers for chips more than two years old. This behavior is partially behind all of these new lawsuits against Qualcomm.
This churn is likely to continue for a long time and it will probably be artificially enhanced by manipulating the cell standards to create 5G, 6G, 7G, 8G, etc. Turning off the cell towers for the previous generation forces you to buy a new phone whether or not you care in the least bit about the later cell technology.
See how Qualcomm (who has a big hand in cell standards) can manipulate this? 6G doesn’t have to be better than 5G, just different. Since it is different all of those patents on 5G can be replaced with new patents on 6G. And then when their cell carrier buddies turn off 5G, we’ll all be buying new, highly patented (with big royalty) cell phones. Carrier buddies go along with this because they are making margins on the phone sales too.
I come from China, I support you!
So when did ‘the BPI people’ deliver? Where’s what they put on a public server? Where’s their try to behave nicelyl in terms of ‘open source’?
Anyway, we don’t need to wait for those guys any more. Allwinner vomited a huge pile of code in a single commit in the meantime. See yourself what’s different: https://github.com/tinalinux/linux-3.10/compare/r18-v0.9 😉