Brave of them to do support for the vector extension, given that it hasn't been ratified / officially standardised yet[1]. It's still a work-in-progress. The final version of the vector extension may have small (or enormous!) incompatibilities, so you might be tied to one of their toolchains to use it properly, rather than something upstream.
Basically yes it's as you describe, but I want to add that the https://linux-sunxi.org/ project has been doing brilliant work for AllWinner's ARM chips.
AllWinner parts are not bad if, and only if, the features you need are already clearly supported. Don’t invest in an AllWinner-based design expecting to implement key SoC features later. If it doesn’t work right now, there’s no guarantee it will ever be supported.
That said, upstream support for AllWinner parts has come a long way and continues to improve. I wouldn’t mind using them in certain projects.
However, anyone who absolutely needs good documentation and SoC support needs to stick with a vendor that emphasizes openness and good documentation. NXP i.MX is the safe choice.
I wish the HW companies either document their devices or pay someone who understands software to work on it instead just releasing nearly working prototypes and then continuing to another project abandoning HW with old kernels.
I got burned by AllWinner once and will not buy devices using them unless I have a very good reason. :)
IIRC Allwinner has already sent some patches related to RISC-V to kernel and also suggestions to SBI specification. So far the beginning is good. Remember that they are using IP from Alibaba. Alibaba might as well work on upstreaming, etc. efforts for this (speculation).
To me this being AllWinner, because of linux-sunxi, looked like Good News.
They're not going to be unnecessarily reinventing wheels, which should mean we're already half there in these new chips being well-supported by mainline kernel[0].
With the exception of Raspberry Pi, you can’t really purchase Broadcom SoCs for your own products anyway. Not unless you are a large vendor with high quantities, in which case they’d be happy to support your project.
Never build a product around chips you can’t access anyway. Using the Broadcom Raspberry Pi modules is a great option if, and only if, the features you need are already well supported and documented.
Not unless you are a large vendor with high quantities, in which case they’d be happy to support your project.
Have to chuckle at this one. I worked for a large company that actually got support from Broadcom for a newer part family (StrataGX). The support was dismal. You'd ask an FAE questions, they'd shrug, if you pressed hard enough (and got your executive team in the loop) you'd get an "answer" from the factory which was usually a pile of badly commented Verilog excerpts under NDA. Thanks but no thanks.
Oh and that one time we did get sample code it was a dump of someone's development directory, including project files for another company (you're probably have one of their machines in your office right now). That was fun.
I have the same bad experience with Broadcom's technical support. I worked on a project based around StrataXGS Tomahawk and some other chip I can't remember right now. One of those chipsets would randomly lock itself and stop switching traffic somewhere about 5-6 minutes after rebooting. It took us ONE WHOLE FREAKING YEAR of debugging on our side and nagging them to make them figure out that they forgot to tell us that some specific PCI-E clock settings must be set in THEIR OWN DRIVER. It was paid support. Imagine the horrors of dev team whose product gets delayed one year and now imagine their faces after Broadcom provided the solution.
Also, their requests to plug in "logic analyzer" on the PCI-E bus between host CPU and their chipset in finished product where everything was using BGA soldered parts - yeah...
I believe the only reason everything they share with you is under NDA so you don't go and publicly tell how bad they really are. They are like Boeing to me, but I yet have to see their MAX-like mistake.
Anyone know anything about Tina OS, or have contacts at Allwinner who might know about it? This article says it is based on Debian but other pages on the web say it is based on OpenWrt.
The page has a short video goes over some of the tools and materials that went in to making a small amplifier chip.
I don't have any experience with making integrated circuits but just from the looks of it, scaling it up to make an entire processor seems a little far fetched.
If you're in it for the fun of having a small project you can pretty easily make your own PCB and solder microchips onto it in almost any home garage.
If by any chance all modern processor manufacturers simply cease to exist at the same time (e.g. WWIII happen and those manufacturers are marked as strategic target and destroyed), I wonder how long it would take for us to get back to the same level of tech. 10 years? 20 years?
Good question... No idea about the same level, I reckon it would be decently quick (5 years maybe? less than a decade imo) if the right people are alive.
If not, there's still knowledge of older, but decent processes like 130nm/90nm, which should be doable pretty fast...
Who holds the secrets/documentation to the chip designs themselves? I reckon without the right experts, it would be very hard. Plus, Intel uses equipment from third parties, too.
It's like the Saturn V - the documentation/blueprints/etc was massive, secret, spread all over, making it basically impossible to recreate the rocket just by "following instructions", replacement stuff would have to be recreated from scratch.
Chip fabrication has traditionally been a US strategic technology supported by US government investment in return for making sure there are complete supply chains available in the US or friendly nations (specifically Japan and Taiwan).
The US has tightly controlled the export of advanced processes, which is why even TSMC isn't allowed to manufacture in China with processes below 22nm.
I believe (Chinese based company) SIMC has a new 8nm process they developed themselves, but people have doubts about the yield.
What's more we are constantly building new plants and processes. This isn't like the Saturn V where the plans were mothballed.
Sure, if you killed all semi-conductor engineers, and everyone at Intel and TSMC and Samsung I'm sure there would be problems. But realistically chip manufacture is one of the things I'd feel more confident about being able to recover.
Looking at the links others posted, I'd just go the scavenger route... it would be easier to build stuff around any processor instead of making your own.
It's simply amazing how bleeding edge modern fabrication is.
I don't think anything is available yet. Last we heard AllWinner's order was still being processed by TSMC, rumoured to be 50 million units over the next three years. It would take months for them to be packaged, the SBC to be finalized, assembly, QA etc. And of course AllWinner aren't making these for SBCs, they're making them for their lineup of crappy no brand sub-$100 phones/tablets/smart TVs/etc so the bulk of the chips will end up in those.
At the moment all that's available to order is the HiFive Unmatched, with delivery in "Q4" (this year hopefully!). RIOSLab SBCs (https://rioslab.org/) should be coming next year.
My intuition, very unreliable, tells me it's going to be somewhere between rpi1 and rpi3 in performance, while having lower or similar power usage as rpi1.
256MB is a boat load of memory for embedded use. Only when you start adding pointless layers of abstraction and bloated frameworks on top of an OS does 256MB become an issue.
If you want a "desktop" experience then buy a pi4.
Eh, it's a bit on the low side. Comparing a BeagleBone Black (512MB) with an Omega Onion2+ (256MB), I found that 256MB is almost not quite enough for anything other than the smallest applications.
One of the killer-features of RISC-V was being backdoor-free, but it appears that chinese companies will produce most of the chips. Back to square one.
This is a pipe dream, but having self-managed local foundries (à la hackerspace) would be awesome to ensure that RISC-V stays secured, decentralised and competitive.
You are conflating the ISA with its hardware designs. I'm not an expert, but imagine an ISA being like a C library API, in that case the hardware would be the APIs implementation.
It's worth pointing out that fabless design companies build upon reference designs (whether ARM or RISC V) created by other companies (eg, ARM Holdings or SiFive), and both these kinds of businesses and are distinct from semiconductor fabrication companies like Taiwan's TSMC.
Although fabless design companies like Allwinner and fabrication companies like SMIC both exist in China, there is accessible pathways to China-free chips, especially if you're willing to pay the premium for TSMC's high end manufacturing.
Chip-making is material-intensive and needs to be done at a large capital-intensive scale in order to be competitive with other mercantilist states.
You can't have a manufacturing-hostile environment here in this country and expect to be able to buy phones that are owned by you instead of President Xi and just on loan to you.
Remember the fight over clipper chips? We've rearranged the electronics industry so that everything has a clipper chip, it's just outsourced and you can't see the details.
(I say this like all of y'all reading this aren't younger than 35 and _remember_ the clipper chip).
It's an open source processor, right? (Not just the RISC-V instruction-set, but the specific chip.) Could the chip be compared against that design to check for backdoors?
The idea would be to somehow scan the design of the chip, presumably using an electron microscope as progre said, and compare it against the design's netlist. This isn't something I know much about, so perhaps it's not at all practical, but at least in principle this should be possible for chips with open designs.
> You could thwart all that with a microcode layer anyway.
I don't see that the particular techniques used in the design, such as microcode, would matter. The question is whether the published netlist matches the one on your chip.
> I think the closest you're going to get to "verifiably secure" is an FPGA based core.
> I don't see that the particular techniques used in the design, such as microcode, would matter. The question is whether the published netlist matches the one on your chip.
You're missing the fact that microcode lies between the hardware and the user-supplied machine code. Thus hardware+microcode is what has to be verified.
This is a risc chip, it's unlikely there's any microcode at all - I know of no RISC-V chip that has microcode.
What there will be is a 0-stage boot ROM -it's not microcode, just RISC-V code -essentially the code that knows how to get from the first instruction after reset up to and including the loading of u-boot (or whatever) - if you're interested in how open a system is ask to see that code, and all the code that runs in m-mode (probably u-boot-spl and opensbi both of which are open source)
There's typically plenty of preboot code that is executed before the the architectural reset vector. Also, complex RISC cores will generally have a distinction between architectural instructions and micro instructions, sometimes using a mask ROM for the translation.
I see what you're saying now, that the microcode would also need to be published and studied, and it would also be necessary to ensure the delivered microcode matched the published microcode. I thought you were saying that the use of microcode would complicate verification of the hardware.
If it's open hardware, I presume they'll publish the microcode.
You need a way to scan the microcode as well, which you can't practically do physically (e.g. even with an x-ray scanner), at least when not some kind of circuit ROM.
So you need to scan the microcode; this demands care I think. Whatever you are reading could be reporting itself incorrectly, if you were to read it through software (that is itself influenced by the microcode). One solution would be to have a hardware module, a verified function that dumps the microcode and cannot be significantly influenced by the microcode itself.
Another issue could be program obfuscation, where you hide behavior inside your program. Since microcode is quite small, I guess the risk is also small.
As a curiosity, as far as I know Cryptographic theory at this point hasn't proved whether efficient white-box obfuscation is possible! (specially for the case of obfuscating cryptographic keys), but there are some proposed methods that generate very large obfuscated programs, and there are several manual techniques (by experienced programmers) that make it difficult to decode to figure out function (we don't know if this could be generalized and automated).
Agreed, this is an issue with complexity more generally, but microcode seems like a particularly important case.
As far as I can tell from the software world though, it's pretty rare for anyone to try this kind of thing. When their software is Free and Open Source, some companies put telemetry in there (e.g. Visual Studio Code), but it's very rare for there to be anything this malicious hidden away in publicly viewable code.
The Linux world has collectively agreed to trust SELinux, for instance, despite that it originates from the NSA.
The term open source was used in the article, but did they mean that in an accurate sense, or was it just empty marketing? Also, I can't find the source after a short search.
> Could the chip be compared against that design to check for backdoors?
Don't know, but I'm sure much expertise, man-hours and expensive equipment would be necessary. Maybe prohibitively so.
Is this chip open hardware? I didn't see that in the article but maybe you have other sources... In that case, you would still need is a electron scanning microscope and a known good reference to verify with.
Do you have any documentation that a back door has been found? I'm aware Ted Ts'o and others were worried of the possibility of backdoors in RDRAND, but I wasn't aware of any being confirmed. Also, the Wikipedia article for RDRAND really needs to be updated if a back door has been confirmed.
On a side note, there was a workaround found for the backdoor: since it was using DH key agreement without digital signatures, both sides could use proxies that each generated a secret w, raised the outgoing DH public key to the power of w, and raised the incoming DH public key to the same power w. Alice's public key is g^x, where x is known to the government but is otherwise locked away deep in tamper-resistant hardware in the Clipper chip. Alice's proxy raises her (g^x)^w mod p = g^(xw) mod p before it hits the wire. Likewise, Bob's proxy raises (g^y)^v mod p = g^(y v) mod p. Alice's proxy raises Bob's seen public key to her secret exponent g^(y * v)^w mod p = g^(y * v * w) mod p before sending it to her clipper chip, and the tamper-resistant hardware calculates g^(y * v * w) ^ x mod p = g^(x * y * w * v) mod p. Bob's clipper chip likewise is given 9^(x * w)^v mod p and calculates g^(x * w)^v^y mod p = g^(x * y * w * v) mod p. Both chips calculate the same shared secret Skipkack key to encrypt the keystream. A government wiretapper knows x and y and sees g^(xw) and g^(yv), but can't calculate g^(xywv) unless they can compute discrete logarithms mod p. As a bonus, they'd get perfect forward secrecy whereas fixed DH public keys don't provide forward secrecy.
Authentication worked by the phone displaying a hash of the session key, and the two users were expected to read the key hash to each other and recognize each other's voices. If they were being MitM'd, they wouldn't have identical session keys. Alice and Bob's authentication procedure would then still work just fine, since they'd still have identical session keys.
If the government were wiretapping Alice, they'd of course detect the tampering because they'd be getting garbage data/failed checksums, but otherwise, the tampering would be undetectable, and Alice and Bob get hardware-accelerated 80-bit Skipjack encryption of their data stream, back when 56-bit DES was generally considered reasonably safe and 80-bit symmetric keys were considered sufficient for data classified SECRET and below.
(Or maybe the tampering could be detected when the wiretappers went to look up Alice's fixed DH public key and couldn't find it in their escrow database... I forget if the escrow worked by having a database or if the chip encrypted the DH secret key with a master key and transmitted it at the start of every session. In any case, the whole thing wasn't that well thought out. It's also possible the DH exchange was signed using a malleable signature scheme using the same prime as DH, allowing Alice to raise the DH public key to a known-only-to-Alice power and calculate the power needed to raise the signature in order to still get a valid signature on the modified DH public key. Clearly, I forget the exact details.)
1. https://github.com/riscv/riscv-v-spec/