MIPS Tempts Hackers With Raspbery Pi-like Dev Board

DeviceGuru (1136715) writes "In a bid to harness the energy and enthusiasm swirling around today's open, hackable single board computers, Imagination Technologies, licensor of the MIPS ISA, has unveiled the Creator C120 development board, the ISA's counter to ARM's popular Raspberry Pi and BeagleBone Black SBCs. The MIPS dev board is based on a 1.2GHz dual-core MIPS32 system-on-chip and has 1GB RAM and 8GB flash, and there's also an SD card slot for expansion. Ports include video, audio, Ethernet, both WiFi and Bluetooth 4.0, and a bunch more. OS images are already available for Debian 7, Gentoo, Yocto, and Arch Linux, and Android v4.4 is expected to be available soon. Perhaps the most interesting feature of the board is that there's no pricing listed yet, because the company is starting out by giving the boards away free to developers who submit the most interesting projects."

Comments

no price?

[Anonymous Coward]

The entire appeal of the raspberry pi was that it cost only $35. This new thing, you won't even tell us the price. If you need to ask, you can't afford it...

Re:no price?

[TheRaven64]

There's no price yet because they're giving away the first production run to people who are going to do interesting things with them. Unfortunately, this is a really bad time to do anything MIPS related (and I say this as someone who hacks on a MIPS IV compatible softcore and the LLVM MIPS back end). Imagination has just released the MIPS64r6 and MIPS32r6 specs. These are the biggest revisions to the MIPS ISA since MIPS III, which introduced 64-bit support. They've removed a load of legacy crap like the lwr and lwl instructions and the branch-likely instruction family and added things like compact (no delay slot) branch instructions, the requirement that hardware supports unaligned loads and stores (or, at least, that the OS traps and emulates them), and added much better support for PC-relative addressing. The result is a nice ISA, which is not backwards compatible with MIPS32r2 or MIPS64r2, the ISA that these boards use. Any investment in software for MIPS now is going to be wasted when products with the new ISA come out.

Re:no price?

[LoRdTAW]

It doesn't always have to boil down to price. This is the same argument over and over again from some maker/hacker types who want to turn platforms into religions.

The Raspberry Pi is a lackluster board with a crummy SoC and limited I/O and no FPU. Not to say that the Raspberry Pi is total crap, it does its intended job very well and there is a lot of community support. Plus where else can you buy a $35 board that runs Linux and X with HDMI USB and Audio?

But it falls flat in a few areas that is frustrating. First off it has *ONE* PWM output. Anyone looking to use this for motor control has to add an external PWM chip. Not a big deal but an annoying one. Next problem is there is the Ethernet is a USB-Ethernet chip on board, there is no hardware Ethernet NIC on the SoC which robs the CPU of cycles. Next up, and this is my gripe with many boards: no high speed interface. There is so much more these boards could do if we could attach an FPGA to them. Sure there is SPI but it simply isn't fast enough for certain things. The only board that can do this is the Beagle Bone which gives you an external bus interface but that disables the HDMI as the pins are shardes on the SoC. So its a trade off.

What I want to see in a dev board: dual core SoC w/FPU, 1GB RAM+, GPU, HDMI, SD card, SPI, I2C, 6-8 channels of 16 bit PWM, 8 channels of Analog 12bit-16bit, hardware 10/100 or gbit, 4xUSB host, *external bus interface not shared with I/O*. That's it. Just let me plug an FPGA daughter card that gives me the option to load bit files from the CPU and we are golden. Then we can do what ever crazy thing we want: more custom PWM (e.g. directly drive 3 phase bridges), quadrature encoders, faster ADC's, delta-sigma DAC's, high speed I/O, custom bus interfaces, etc. And make it cost $75. We are close to having a board like this, we just need the interest and the right SoC.

Re:no price?

[topham]

Sold it cheaper? Why?

The Rpi has an excellent price, it's low enough that price is not the deciding factor on using it.

Re:no price?

[TheRaven64]

Wouldn't it be just a matter of re-compiling your code though?

Assuming that your code doesn't do anything that is vaguely MIPS specific. If it is, then there is little benefit in using MIPS32r2 now - ARMv7 is likely to be closer than MIPS32r2 to MIPS32r6 in terms of compatibility with C (or higher-level language) source code compatibility.

I love MIPS and, that is the case in large part, because of its current instruction set. It seems like a bad idea to mess with the current instruction set and break backward compatibility. Why did they decide to do that?

Basically, because the MIPS ISA sucks as a compiler target. Delay slots are annoying and provide little benefit with modern microarchitectures. The only way to do PC-relative addressing is an ugly hack in the ABI, requiring that every call uses jalr with $t9 in the call, which means that you can't use bal for short calls. The lwl / lwr instructions for unaligned loads are just horrible and introduce nasty pipeline dependencies. The branch likely instructions are almost always misused, but as they're the only way of doing a branch without a delay slot there's often no alternative.

Re:Patent on this new feature

[TheRaven64]

No idea. I don't know if the instructions for computing PC-relative addresses in an ISA without an architectural PC are patentable. They also exist in RISC V (not sure which came first), so if they do then it's going to be a problem for Kriste et al. Nothing else in there is especially novel: like ARMv8, it's a nicely designed compilation target, but it doesn't do anything that's especially exciting.

I didn't look at the floating point stuff in much detail, so there may be something there, although the biggest changes in recent versions of the MIPS specs have been that they're more closely aligned with the IEEE floating point standards, so it's hard to imagine anything there.

The biggest difference between MIPS64r6 and ARMv8 is that the MIPS spec explicitly reserves some of the opcode space for vendor-specific extensions (we use this space, although our core predates the current spec - it's largely codifying existing opcode use). This allows, for example, Cavium to add custom instructions that are useful for network switches but not very useful for other things. ARMv8, in contrast, expects that any non-standard extensions are in the form of accelerator cores with a completely different ISA. This means that any code compiled for one ARMv8 core should run on any ARMv8 implementation, which is a big advantage. With MIPS, anything compiled for the core ISA should run everywhere, but people using custom variants (e.g. Cisco and Juniper, who use the Cavium parts in some of their products) will ship code that won't run on another vendors' chips.

Historically, this has been a problem for the MIPS ecosystem because each MIPS vendor has forked GCC and GNU binutils, hacked it up to support their extensions, but done so in a way that makes it impossible to merge the code upstream (because they've broken every other MIPS chip in the process) and left their customers with an ageing toolchain to deal with. I've been working with the Imagination guys to try to make sure that the code in LLVM is arranged in such a way that it's relatively easy to add vendor-specific extensions without breaking everything else.

Imagination doesn't currently have any 64-bit cores to license, but I expect that they will quite soon...