Hacker News new | past | comments | ask | show | jobs | submit login
XuanTie C906 based Allwinner RISC-V processor to power $12 Linux SBC's (cnx-software.com)
140 points by todsacerdoti on Nov 9, 2020 | hide | past | favorite | 77 comments



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.

1. https://github.com/riscv/riscv-v-spec/


06:34PM EDT - Q: plans to support RVV 1.0? A: 0.7.1 for now - when we designed, it was still at that level. We are following and working on that yes.

From https://www.anandtech.com/show/15991/hot-chips-2020-live-blo...

0.7.1 and 1.0 will not be compatible IIRC thus Linux distribution most likely will not support RVV on this.


It's not just vector, it's an incompatible version of bitmap too.

I presume "brave" was used ironically. It would be very unfortunate if it fractures the ISA but I'm optimistic that it will not.


As long as they use this version in their own products and update when RVV is finalized it should work out fine.


They made a point to note that V extension support is hidden behind a switch. If it is a problem, it can be turned off.

This is much better than not having support at all, particularly if you want to play with a recent draft, which should be what they implemented.


There was another recent core on here that supported vector extensions, was it similarly outdated?


AllWinner - I remember that their software support is horrible.

Support and documentation was non-existing last time I looked.

Has this changed recently? Is there mainline support for AllWinner now or is this still a copy/paste crapfest with branches and huge patchsets?


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.


Yes, the project is great and very useful.

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).


Aren't pine64 people primarily use allwinner stuff? AFAIK most of pine devices run mainline kernel.


The pinephone uses a 5 year old chip. This is because it takes ages for open source heroes to write all the software.


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].

[0]: https://linux-sunxi.org/Linux_mainlining_effort


Support and documentation was non-existing last time I looked.

Still better than Broadcom... at least you can find the (very long) datasheets for a lot of their SoCs.


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.


That's great news! I'd be glad to buy this one even to play with RISC-V asm, but still might do some home automation with it.


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.


What is the most advanced and performant processor which may be reasonably manufactured in a home garage?


The short answer is no for most definitions of a home garage.

Take a look at this fella: http://sam.zeloof.xyz/first-ic/

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.


Amazing, it takes so much work and tooling to make a simple, decades old IC. Modern processor fabrication is simply magic by comparison.


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...


Not long - Intel at least has its factories very standardised so they can recreate them anywhere they get sufficient subsidies.


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.

See https://warontherocks.com/2020/06/the-chip-wars-of-the-21st-... for some details about this.

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.


If by "processor" you're not restricting yourself to single-chip microprocessors, then probably something like this:

http://www.homebrewcpu.com/

...probably equivalent in performance to a minicomputer from the 70s.


I don't know the answer, but which particular limitations do you have in mind with the term "home garage"?

I.e.:

- space

- power and cooling capacity

- freshwater and wastewater capacity

- legality of storing / disposing of toxic materials

- proximity to a residential dwelling

- equipment cost

- amount of noise produced


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.


Using what for raw materials? Sand?


How to buy it? Tutorial?


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.

If you want to run RISC-V today, use QEMU: https://fedoraproject.org/wiki/Architectures/RISC-V/Installi...


I'm having a hard time imagining smartphone/tablet/smart TV with a CPU like this. I wonder what is Allwinner betting on?


Maybe government sponsorship as a hedge against ARM/Nvidia implications.


Quite likely there will be SBCs in a few months with that SoC. Likely in the first quarter of 2021.


The estimate for availability I've seen in the twitter thread is "within 2 month".


I love the form factor of a slot plugin module. Makes it easy to switch and replace, while not taking too much space.

Very Terminator'y :-)


Awesome. The rapid progress on cheap SBCs like that is good news. Will probably wait personally but excited anyway


Does anyone dare take a stab at estimating the power use of this thing?


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.


up tp 256MB RAM


For the price point they are going it's plenty enough. That's also enough to boot Linux distributions in headless mode.


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.


That is more than enough for many applications. How much RAM does your home router have?


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.


The GPU only supports 2D acceleration. 3D acceleration would have been a really nice addition.


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.


> One of the killer-features of RISC-V was being backdoor-free

I think you are confused. RISC-V is just an ISA, not a hardware design, so it can't have a backdoor or, on the other hand, be free of them.


It's a related idea.

With a closed ISA, the only manufacturers are closed-source and I can't verify the chip is secure under any circumstances.

With an open ISA, I may not be able to verify all designs are secure, but, I can verify that some are secure and choose one of those.


No, there is no relation.

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).


Funny that you mention that, since most backdoors found so far were in silicon from US companies, not the Chinese :-)


> Back to square one.

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?


Not sure how you would practically do that. You could thwart all that with a microcode layer anyway.

I think the closest you're going to get to "verifiably secure" is an FPGA based core.


> Not sure how you would practically do that.

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 agree that's the most practical solution.


> 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).


You can generally pretty easily see the bits of a mask rom as easily as you can see any other gates.


"I thought you were saying that the use of microcode would complicate verification of the hardware."

I do think that microcode opens up the possibility of subtle injections to follow code/hardware paths you might not easily predict.

A really good talk on reverse engineering an ISA implementation: https://youtu.be/KrksBdWcZgQ


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.


> It's an open source processor, right?

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.


Check out bunnie's talk on supply chain security:

https://www.bunniestudios.com/blog/?p=5519


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.


Thanks to Google you can now do this under some circumstances at the Skywater 130nm foundry

https://fossi-foundation.org/2020/06/30/skywater-pdk


Can you give an example of an chip with a hidden backdoor?


All the Intel CPUs with RDRAND, although I guess that's not exactly hidden anymore.


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.



He asked for a Hidden backdoor.

That chip is literally an explicit backdoor.


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.)


But now consumer can choose who will spy on them!




Applications are open for YC Winter 2023

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: