The $9 CHIP Computer Reveals Its Open Source Details | Hacker News Reader

The $9 CHIP Computer Reveals Its Open Source Details

makezine.com

116 pointsdcschelt31 comments

Open articleView on HN

Olimex deconstructed that $9 computer story a while back.

https://olimex.wordpress.com/2015/06/05/how-to-get-in-the-ne...

TL;DR: It's going to be $39 after the Kickstarter.

For what it's worth, there's some debate about that. The creators have specifically said "C.H.I.P. will still be $9" -

https://www.kickstarter.com/projects/1598272670/chip-the-wor...

Of course, time will tell...

Well, seems they might make margin on accessory and postage etc, however, the math seems pretty clear -- they /can't/ sell it at $9 and break even, so there has to be a trick...

Personally, I'd rather give my money to guys like Olimex anyway -- a notch more expensive, however these guys are /spotless/ at making everything as open as they can, and in fact, they probably 'suffer' for it as many companies seem to use their (open) designs commercially...

I'm glad to have helped fund the kickstarter. It was advertised to come with a linux distro but at the time but they didn't have many details about that. Glad to see that they're becoming part of the mainline kernel. Developments like this are going to increase the popularity of linux and smaller computing devices.

Wow that's awesome that they want everything in the mainline Linux kernel. Here's hoping they pull it off!

If I understand, that would be their major advantage to Raspberry Pi? But is the graphics of CHIP comparable to the one on Raspberry Pi?

> But is the graphics of CHIP comparable to the one on Raspberry Pi?

The CHIP uses an Allwinner R8 SoC, which uses a Mali400 GPU (source: http://www.cnx-software.com/2015/06/07/allwinner-r8-module-d...). RPi uses a VideoCore IV GPU.

While there is no open source driver for Mali400 available, it has been partially reverse-engineered (lima). For the VideoCore IV there is an open source driver available, but the SoC on the RPi is special in the sense that when booting the VideoCore IV is the core to start, which later in the boot process starts the ARM core(s). On the VideoCore IV there runs a proprietary OS (probably RTOS) that is based on ThreadX. So most things the open source driver does are simply calls to this RTOS via a mailbox.

Nevertheless the RPI developers market the VideoCore IV GPU as the most open embedded GPU available. Indeed it is the only one, where an official open source driver is available and thus it is more friendly towards bare-metal programmers that want to write their own OS. On the other hand, the RTOS running on the VideoCore IV is a large blob in an instruction set that has not yet been deciphered.

Thanks! So RPi is still more "open source" than CHIP?

And how big is that whole binary blob running on VideoCore IV?

Good thing there is:

https://github.com/hermanhermitage/videocoreiv

First: What I wrote it only for the GPU, since you only asked about that part. I wrote nothing about the other parts of the SoC or Raspbian, though there are lots of things to say, for example:

No public documentation (without NDA) is available for the USB controller of the RPi (there is still an open source driver in the Linux kernel for it that is based on this non-public datasheets) made by Broadcom. I personally consider the action that the Linux developers also include drivers based on secret datasheets into the kernel as a violation of the spirit of open source, but I digress.

Also the Raspbian developers (from the Raspberry Pi foundation) include proprietary software into Raspbian, say, Mathematica. While probably useful, this surely isn't open source.

So there are more criteria on which to judge a SoC than whether it is open source, say, whether there are complete and free datasheets (no NDA) available or whether the SoC is also available in small amounts for hackers (Broadcom is said to be very compicated in this area). Or how much open-source the de-facto standard GNU/Linux distribution (since this is what you'll probably want to use) for the SoC is.

TLDR: Openness or open-sourceness is much more complicated.

Thanks again! Actually I asked about the size of the whole blob you mentioned to get some idea how hard would it be to disassemble it fully. What do you think?

The blob for the default VideoCore IV blob in the version from yesterday (commit 369d99df38de4c33b648ac864dd42e185461b477) has a size of 2708.504 kB:

https://github.com/raspberrypi/firmware/blob/369d99df38de4c3...

All the blobs are in https://github.com/raspberrypi/firmware/tree/master/boot and carry the name start.*\.elf .

There are four versions of this firmware blob that can be used:

start.elf: the default version

start_cd.elf: a minimal version of the firmware that must be used if you set the GPU memory below some threshold, and only supports few features.

start_x.elf: an extended version of the firmware blob which included some extra free codecs (source: https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=1933...).

start_db.elf: A version of start_x.elf with additional debug assertions (source: https://github.com/raspberrypi/firmware/issues/408).

The VideoCore IV is pretty well understood, and there are some hacky C compilers for it. I have, e.g., a simple boot monitor for it:

http://cowlark.com/cgi-bin/fossil.cgi/piface/doc/stable/doc/...

It's a bootcode.bin which runs a simple shell via a serial terminal which allows you to do things like up and download data, examine memory, etc. No ARM code involved anywhere! It doesn't initialise the SDRAM yet (although I think I know how).

Right now it's built using a hacky port of the Amsterdam Compiler Kit, which generates lousy code. I've tried porting both gcc and LLVM and ran into a brick wall --- they're both vile. I'm hopefully going to have a go with libfirm soon, which looks more tractable. However, Volker Barthelmann's non-open-source vbcc has experimental (and apparently very good) VC4 support: http://www.compilers.de/vbcc.html

Where did you/they get the information on the VC4 instruction set from? According to some sources about reverse-engineering VC4 which I could recover if I wanted to, finding out the instruction set that the blob uses was a serious problem at least in the past.

I realise now I forgot to reference my source; I didn't do any of the reverse engineering myself:

https://github.com/hermanhermitage/videocoreiv

I believe it was figured out from a combination of analysis of the blob, examining the patents (which contain quite a lot of information), trial-and-error, and careful examination of the fragments of VC4 source released by Broadcom (their big source release a year or so back contained quite a lot). I know that at least one person wrote a program which would run arbitrary instructions on the Pi and analyse the state of the registers afterwards, which is a neat trick.

The VC4 is a really nice processor, BTW. Dual core, lots of registers, efficient instruction packing, 64x64x8bit vector unit, integrated single-precision FPU using the integer registers (no double-precision, alas), 1kB on-chip lookup table... but, bizarrely, no adc or sbc instructions, so 64-bit arithmetic is hard. Very weird.

That's not quite accurate anymore - there's an open-source OpenGL ES driver for the Pi that isn't just a wrapper around the binary blob on the VPU. However, you still need the proprietary blob in order to boot the Pi and actually enable the display outputs, and for accelerated video decoding. (Oh, and it has an interesting license that forbids you from using it on non-Raspberry Pi hardware.) On the Allwinner chips, it's the other way around - you can boot them, enable the display outputs and do modesetting and I think even hardware video decoding with open-source code, but OpenGL ES requires a proprietary blob. Though I think the Allwinner 2D graphics overlay hardware is fully documented, which may be enough for some applications.

> That's not quite accurate anymore - there's an open-source OpenGL ES driver for the Pi that isn't just a wrapper around the binary blob on the VPU.

Where can I find it?

See http://dri.freedesktop.org/wiki/VC4/ I think - not quite sure where the latest version lives these days.

>> Oh, and it has an interesting license that forbids you from using it on non-Raspberry Pi hardware.

Does that mean you can't use the Pi as a dev board for the SoC and then build a product based on that? Or I suppose you'd license the video driver when you go to buy the SoC for production?

It does, but chances are Broadcom won't sell you the SoC either so it matters less than you think. I expect it's mostly just aimed at anyone who attempts to re-purpose existing hardware based on the same Broadcom SoC.

Allwinner SoCs also have a 2D graphics accelerator which can speed up things like text and line drawing and scrolling.

An embedded shop released u-boot source. I never thought I'd see the day - this is great news.

Most embedded shops release u-boot source, just not in a very usable state, eg. based on old versions, zip package instead of version control, not following any of the development practices or internal organization of the original project... Same thing with the kernel. Excited to see mainline support!

Source: working in embedded, trying to fix how we release exactly these things.

I think the first time I started pushing for real version control and semi-reproducible builds in embedded device development was in 1991, when I was working on medical diagnostic devices. I really can not believe that in 2015 there are still places the still don't adhere to simple practises like that...many places unfortunately.

I mean it's like wearing pants. It's fine if you do not want to wear pants at home but once you're at work and doing something in a professional context it seems like a reasonable minimum bar to expect everyone to live up to.

Haha, the pants is a great example, thanks! If I may, I'll use that example internally, hopefully to good (and hilarious) effect!

Kind of amusing that the article explains how to set up the development environment using VirtualBox. I doubt many Linux kernel hackers use or want to use VirtualBox. At least, many ones working with mainline.

I'd imagine a lot of kernel developers use virtualisation during development so that they can still boot their machine (though they probably aren't running Macs).

Not ARM developers; my workstation reboots every few months, my ARM boards every few minutes :-) That is, unless you have a qemu port for the SoC in question.

That's also why my host /sbin/reboot is "echo Wrong terminal, you idiot"

Haha I generally try to colour my terminals differently to get around this same issue.

I think he was referring to VirtualBox in particular - its kernel modules are endless sources of problems. KVM has its modules in mainline, so it's a more popular choice for kernel development.

Awesome! I would have funded the campaign had I known this information at the time.

Reply on news.ycombinator.com