Imagination Launches A MIPS Development Board

[BSDude]

Says the guy who is a mindless fanatic fanboy of BSD. An OS heavily infested with blobs and binary firmware like a dead cow full of maggots.

Ahhh yes, Endman! Keep on mindlesly trollin' you dimwit but ask yourself this, why is there a linux-libre project around?!

[0xBADCODE]

NVIDIA released a tiny bit of code but most of the work was done by the Nouveau guys in the first place. The GPU in newer Tegra's is a derivative of their desktop GPUs. There are open source drivers for Qualcomm's Adreno GPUs, ARM's Mali GPUs and Broadcom's VideoCore IV GPU.

Blobs should be hated period whether in the embedded world or not. Most open source OS developers and users should be killing blobs on sight and are. They are unwelcome. They are a total headache and create a variety of different issues that hinder use, maintenance and development.

I do not welcome blobs at all. However, there're different kinds of them. Some could be tolerated. Some are unconditionally fatal and I can consider them as showstopper. This depends on system architecture and what exactly blob does and what it can potentially do should it be unfriendly/misbehaving/backdoored. Say, I would not mind HDD firmware too much because it lacks network connectivity and while its theoretically possible it can try to hack system by returning WRONG data, potentially giving own executable code, in practice it is hard to predict all use cases and meaningfully hack arbitrary system this way. And if its concern, its possible to put integrity checks. OTOH other firmwares, most notably ME/EC can potentially get network access and perform quite complex actions, potentially allowing arbitrary remote attacks, including those targeted on particular OS/system. Needless to say this is completely unwelcome. Furthermore, Supermicro has been already caught on backdoored ME firmware. Generally, BLOB == UNTRUSTED CODE for me.

As for drivers:
1) I do not care about qualcomm. Their architecture is cellular modem centric. Cell modem runs multi-megabyte cosed source firmware which keeps full control over whole SoC, it even boots Linux on UI and therefore it makes it a very little sense to get rid of binary GPU driver on such arch. It runs huge BLOB in background and you can't get rid of it. OTOH it can perfoorm ton of unwanted actiity, be it sending your coordinates via RRLP without user confirmation (hardcore spyware IMO) or just pwn system in arbitrary way. Potentially via over-the-air requests. This is one of cases I consider it completely fatal and would never deal with any Qualcomm SoC at all for myself or security-sensitive applications. IMO SoC design where cell modem CPU haves unrestricted system access is not trustworthy at all. Sometimes it can be funny to learn system architectures. And at least in some Qualcomm SoCs meant for phones, cell modem CPU is the king of the hill of the whole system who boots first and then starts up secondary UI CPU which meant to display you that fancy UI and Linux but it is *secondary* CPU. I consider such system arch to be backdoor on its own.

2) Pi... well, it haves awkward system architecture. Some GPU blobs without sources. FAT32 (I dislike it it and prefer not to use it, considering it legacy crap), weak CPU with outdated arch and other weird shit. Its cheap but its weirdest ARM system I ever seen at all. It's GPU with some small CPU rather than anything else. And it's not like if I got ton of GPU intensive tasks for small hardware. But Pi suxx at everything else. Slow at computation and execution, sucking when it comes to networking, no even real Ethernet (lame USB <-> Ethernet converter does not counts as proper Ethernet, this crap can be added to any system with USB via cheap adapters, but it tends to work poorly and Pi is not exception). Weak CPU with poor I/O and no distro got packages built for that arch. So while GPU driver could be here, it's not like if it is too much fun about it due to the fact rest of hardware in Pi just total crap.

3) Mali. Well, its here but opensource driver is incomplete and author seems to have strange views. Then Mali GPU architecture seems to be really outdated compared to desktop GPUs, i.e. they not even got unified shaders, keeping separate execution units for vertex and fragment shaders IIRC. This reminds me stone age of desktop GPUs (AMD got unified shaders at least at HD4000 or even earlier, for example) and means it is highly unlikelly to see things like computation acceleration (OpenCL, etc). Even opensource driver can't do much if underlying hardware is crap. Last but not least ARM proven to be proprietary f...ks who are unwilling to publish documentation/sources. Probably they afraid their consumers would understood Mali architecture is a really old outdated crap.

From what I understand, Nvidia is the only GPU vendor around who got more or less decent GPU in their SoC (i.e. basically based on decent and modern designs used on desktops) and bothered to help get opensource drivers on wheels. Drastic difference from their sucking desktop policy, should I tell. The prob? Ok, Tegra is expensive and not widespread. If you can get Allwinner at $5 per 1000 ICs ... well, Nvidia simply does not haves any comparable offers. As the result, systems based on Tegra are expensive and so not widespread. So smaller community, hard to obtain and so on. As you can see, so far there is no perfect solution at all and TBH, graphics is my absolute least favorite thing when it comes to embedded world. Proprietary drivers + awkward/outdated GPUs? Well, it stinks.

[Ibidem]

So, I found out about this previously by accident (looking at the eLinux wiki, I found a list of SBCs that mentioned the MIPS Creator CI20).
Main page is here: http://elinux.org/MIPS_Creator_CI20
There are other websites related to it, but that seems to be the one where most info goes.

I've read through some of the specs and the list associated with it, and this is what I picked up:
-kernel graphics driver: besides the alleged 'support' of a (presumably proprietary) driver, someone's ported the iMX.6 kernel driver. I'm not sure if that's framebuffer or KMS, but there's a reference to a 'simple hack to get DRM going' in one of the patches that's available.
-board ships with Wheezy, apparently with a custom init script to get wireless/bluetooth working and proprietary X drivers.
-files here: http://elinux.org/CI20_Tech_Stuff#Files
-allegedly 'open source' board design (we all know that's far too vague to mean much of anything)
But if someone swapped in a JZ7470 for the JZ7480, it would be vastly prefereable...
-peripherals:
2x USB (one of which is duplexed with a USB micro "OTG" port, but the upstream Linux driver doesn't support usb client mode yet)
1x BT/wireless bgn card (IW8103)
1x 10/100 ethernet (Davicom DM9000C)
HDMI
4-pin audio: stereo out, mic in
IR in
1x SD card reader (second available via expansion...)
8 GB ROM
1 GB RAM (8-bit DDR3)
4-pin UART
EJTAG
expansion connector (layout-compatible with RPi).

This is a 90mm X 95mm board with a dual-core 1.2 Ghz mipsel(32) CPU.

-the wireless/bt card is a rebranded Broadcom SDIO one, with a chipset supported by mainline but needing an extra driver (patch available on one of the lists)
-kernel source: https://github.com/MIPS/CI20_linux

So it's USB-poor compared to the RPi B+, but roughly doubles the Beaglebone Black specs.
It's the only generic SBC I've seen with builtin wifi (there are some Atheros router SBCs with builtin wireless, but pathetic flash/ram and no display.)

Oh, the biggest detail: Cost TBD.
They were saying "if it's popular, we may sell it at a reasonable price"; judging by the fact that their website fell over within a couple hours and they had far more than the 1000 applications that they were going to pick, I'd be surprised if they didn't.

[curaga]

Yet another board with poor ethernet. I read on another site (can't remember which) that while the ethernet on this one is not connected via USB, it's using a slow 8-bit bus, and so cannot reach full 100Mbps. The cpu usage implications of that bus remain to be seen.

[chithanh]

About the price, I am mildly optimistic that it will not be much above the bare tablet mobos that you can buy individually. After all, the JZ4780 was designed for use in low-cost tablets.

Compared to the Raspberry Pi, at least the Ethernet does not share bandwidth with the other USB ports. 1 GB RAM is twice as much as on the Pi (but still on the low side), and I expect the internal NAND flash to be faster than the Pi's SD interface so in total a much better performing system. Aside from the graphics, which is a big unknown of course.

It could be possible to use the proprietary Android PowerVR drivers along with Jolla's Hybris (Bionic) compatibility layer, in that case the performance might actually be quite ok.