2. Is there even a complete spec for RISC-V?
3. At that level of paranoia, you're always going to probe deeper... Suppose someone inserted backdoors into your RISC-V core. Suppose the fab house has backdoors in the layout tools. Suppose an oversight committee got paid off...
not anything useful
> 2. Is there even a complete spec for RISC-V?
yes.
> 3. At that level of paranoia, you're always going > to probe deeper... Suppose someone inserted backdoors > into your RISC-V core. Suppose the fab house has > backdoors in the layout tools. Suppose an oversight > committee got paid off...
the damage that would be done to the reputation of any company stupid enough to allow backdoors to be slipped into their tools would be... they'd be finished. absolutely NOBODY would trust them EVER AGAIN - not their billion-dollar customers or the Military or the Intelligence Services that utilise their tools on a daily basis.
no - what you're suggesting is, far from being a plausible scenario, is in fact those companies WORST NIGHTMARE scenario because it's the day that they go out of business and probably have agents from all over the world queueing up to murder them! i love that film with john travolta, "this is incredible. i never seen anything like this. ya actually gotta get in line to whack this guy"....
It had, e.g., a big chunk of code bolted on that loaded a binary data file at boot time and configured the various peripherals. My suspicion is that that was the init code from an entirely different operating system completely that they'd just duct-taped onto the Linux kernel. Unwiring that was a problem.
The chip itself is pretty nice from the hackability perspective. It has a boot rom, like the processor in the Raspberry Pi, and is capable of loading the kernel from flash or an SD card, so you can build unbrickable hardware with it. (For years I ran my personal website off an A20-based TV set-top-box nailed to a plank.)
It's not entirely true about running entirely free code. Apart from the boot ROM, which I suspect you can change if you pay Allwinner enough money, it's got a Mali 400 GPU. There's some of an open source driver here: http://limadriver.org/ ...but I don't know how usable it is. If you want full acceleration I believe you need a blob.
It's still a four-year-old semi-obsolescent SoC, of course. Perfectly adequate for low-end work but compilation on it is for masochists. (I should know; I did.)
I've also used an A20 for compilation... briefly. And not much was compiled in the brief period ;)
As for the boot ROM blob, do you know if that is the 'boot0 and boot1' that Olimex apparently published the source code for?
I wonder if anyone's verified that the code in the boot room on this device really is what you get when you build the boot0 code? I wonder what sort of maliciousness you could fit in there if you tried...
no, the chances of them making a glaring and incompetent accidental mistake that compromises on security are far, far higher than them getting involved in deliberately adding malicious spying code into the device.
you have to remember that the A20 was designed along "unbrickable" lines, so that they could help out incompetent OEMs and ODMs who took it on themselves to "experiment" by making random changes to the design. any kind of DRM would be a serious impediment to that... so they didn't add any.
It had, e.g., a big chunk of code bolted on that
loaded a binary data file at boot time and
configured the various peripherals.
i don't know who you are but we probably both contributed at different times - i was the one who released the first linux and u-boot kernel source to the public via my server, and later on did a usb sniff of the USB-FEL traffic by putting LIVESUIT.EXE into qemu, configuring qemu to give it access to one of the USB ports and uploading an OS to one of my Computer Cards. that was enough for Henrik (hno) and others to complete the fex-boot program. i love doing that stuff.
anyway, upshot is: after a LOT of work by a LOT of people (including yourself it sounds like), the A20 is one of the few china processors that's fully libre reverse-engineered for its boot process, contains no DRM, and even the Video decode engine and 2D GPU are now reverse-engineered.
there aren't very many processors you can say that about - if you do know of any please tell me because i will need to make an in-depth evaluation.
ah! it's been so long, i've been so busy i couldn't remember who you were, out of curiosity had to look you up. yes. i remember. from successful experience of 10 years using wikis for note-taking in reverse-engineering projects, you insisted on posting unstructured information to a mailing list where it was then utterly impossible for anyone to find it (i don't mean me), help you with it (i don't mean me), collaborate with you on it (i don't mean me)
so... let's rewrite what you said to reflect it from your perspective.
> the project lead who has a lot of experience in > complex reverse-engineering, ongoing documentation, > information management and software libre, asked > me to respect certain rules... and i refused to do > so, causing his life and everybody's life to > become, um, "difficult"
you were causing me a significant amount of work by having to cut/paste things that you were writing to the list instead of putting them in the wiki and sending a link as i asked you to do, so that i was the one that was forced to clean up after you. not really very fair of you to do that to someone is it... but you blamed me for that? uhn??? how does that work??
so... yeah - that you left the list was a good thing because i was able to focus on what i was doing rather than having to clean up after you. sorry if you felt that that was unfair or "a run-in" or was "difficult", but it's real simple: when trying to find important information, if it's unstructured, it might as well not ever have been written. there's only so much that a google search can achieve. i trust that in the intervening years you've learned that by now.
http://elinux.org/Embedded_Open_Modular_Architecture/EOMA-68
https://www.crowdsupply.com/eoma68/micro-desktop/updates/pic...
since then i've been alerted to 2 more processors... but anyway the point is: out of all the ones on that list, the A20 is by far and above the most "ethical" one - irony that, given allwinner's background - that we can GAIN ACCESS to, that is also capable of running 1080p60 video so that people can go "ehhh.... yeahh okay, i could put up with that for a year whilst these guys figure out the next Computer Card".
now, there's been a lot of discussion and evaluation on various other forums including phoronix and reddit about RISC-V, i was going to do a separate update about it, but basically, RISC-V is not ready for prime-time.
or, more specifically, the people doing SoCs based around RISC-V haven't yet put something together that would match the minimum functional requirements of EOMA68. those requirements are quite modest, including 18-pin RGB/TTL @ 1366x768, SD/MMC, I2C, SPI, UART, PWM GPIO, EINT GPIO and 2 USB interfaces... but they still haven't actually managed that. the closest team that has is the lowRisc team.
now, on top of that, we need operating systems. it's no good trying to think you're going to raise $1m on crowdfunding selling 10,000 computers if the only OSes available are based on "linux from scratch" or "buildroot" for embedded computers. you need debian, you need android, you need chromeos, you need arch, parabola, gentoo - everybody needs to get on board.
once you become aware of these things you start to realise that RISC-V based SoCs and required OSes are at least 3 to 8 years out, so it would be much much better to start with something like MIPS64 for now.
if you know of a way to raise between $5m and $10m i can start that process NOW and have a chip ready in about 18 to 24 months. i've been through the process back in 2012 (google "Towards an FSF Endorseable Processor slashdot") so know what needs to get done.