CHIP OS 4.4 Released [VGA, HDMI, and more!]


Hey C.H.I.P.sters, it’s upgrade time!

Here are some of the technical changes that we’ve made to the flasher and an explanation of the available operating system images. If you just want to use the flasher and aren’t concerned about what we’ve changed, simply head over to the site and follow the on-screen instructions.

New Technical Features:

Two --soon to be three-- new options are available on for C.H.I.P… As with the images that have been available since we shipped, you’ll have the option to flash a GUI, Headless, or Headless – No Fastboot image. Headless – No Fastboot v4.4 is currently just a placeholder, but will be coming online shortly.

For the uninitiated, the Headless – No Fastboot image is for computers that have problems flashing the other two images. This image uses a protocol that, while offering better compatibility across different hardware and operating systems, tends to be slower and limited in the size of the image that it can flash. Unless you’re having issues flashing, you don’t need to use Headless – No Fastboot.

The biggest changes in this release come from the Linux kernel upgrade to 4.4.11 and a U-Boot upgrade. Thanks to Maxime [@mripard], Boris, and Antione at Free Electrons, we now have a driver for faster NAND access and proper support for VGA and HDMI!

Those familiar with the web flasher will notice a new feature: downloadable image files! @howie implemented the change so that users can now choose to store the image on their local computer to speed up future flashing time, and save some bandwidth too.

Possible Issues:

We’ve changed the way that we build our kernel. Today’s 4.4 kernel will have a few new features (for example USB Gadget Ethernet), but it’s also possible that it may be missing some features that had been implemented in the 4.3 kernel. While we’ve done our best to reproduce the functionality we had in 4.3, there’s a possibility that one of the kernel’s thousands of previously included features could be missing. If you find that something isn’t working the way it used, give us a shoutout here, or an email at And keep in mind that you can always jump back to the 4.3 image, as those will remain available with the web flasher.

Our image building process has also changed, we’ve removed some of the work that your computer has to do when flashing with the CHIP-SDK tools. As such, the format of the images is different and is why the CHIP-tools will no longer be able to flash this newest image. Users should expect an update to CHIP-tools soon that will support flashing the new image format.

Going Forward:

If you’ve been keeping track, you may have noticed that this is the first update to the images themselves that we’ve posted since C.H.I.P.s launch in December. In the future, we plan to offer more frequent releases on a time-based schedule as opposed to feature releases. This way, community suggestions, bug reports, and new features can be sent out to everyone!

– Ben

No fastboot images not working



This is good news.

Will there also be tools to generate an image in the new format?

When will there be a new buildroot release?

Regards, Steve


@computermouth is there going to be a way to update the CHIP via apt-get?

I’m not ready to blast away everything I’ve done on my CHIP so far. If there is not a way, I totally understand and will start backing up the important files and power my CHIP down. That would at least get me to fix my wiring issue on my Onion DIP. :slight_smile:



Buildroot’s chip/next branch is pretty good, I’m just waiting on some more testing and code-review before we make it officially “stable”. However, that image won’t yet support HDMI/VGA, nor have kernel 4.4.

As far as new image generation goes, the reason we haven’t released anything in the past is because our image format is still going through rapid changes. As evidenced by what we’re talking about here today: the image format changed again. I’d rather not release something, than release something that’ll break in a few weeks. I’d love to get image creation into the hands of the community when it’s something I can confidently say will work and continue to work.

@xtacocorex, it’ll likely put you in a permanent kernel-panic after boot if you upgrade the kernel on an older image. I’m still working on figuring out why it’s happening, but between a different uboot, different uboot.scr, additional initramfs that wasn’t there before, etc. there’s a lot to look at. If you’ve got a project on your CHIP that you’re really attached to, I would either backup and flash the new image, or just stay on 4.3.

However, anyone reading that comment, don’t be afraid to apt-get update/upgrade/dist-upgrade. Our kernels are installed by version name, and thus, won’t be automatically updated to a different point release.

– Ben

Accessing filesystem from uboot?

Can we get change logs for the new images?


Thanks for the info Ben! I’ll back up and upgrade with the Flashing tool.


Can I suggest that you add a file version number to your file format? That way your new and future tools can be backward compatible to old files, and you can still change and improve them in the future. It would reduce the confusion and support problems in the future.

Regards, Steve


EDIT: Google chrome reported the C.H.I.P. flasher plugin as version as 3.1.0

Tried on several computers/operating systems with not so great success. In all case I used a known-working USB cable.

Windows 7 64-bit (installed driver, rebooted)
4.4 GUI flash failed waiting for fastboot
4.4 Headless Mode flash failed wiating for fastboot
4.3 Headless Mode no fast boot succeeded
Note: this computer only has USB3 ports so I had to use a USB2 hub, also followed instructions on the flash failed dialog.

Debian Wheezy 64-bit
All options failed, even after following the instructions on the flash failed dialog

Ubuntu Xenial 64-bit
All options failed, even after following the instructions on the flash failed dialog

OS X Yosemite
4.4 GUI with fastboot succeeded.

This was all attempted with the same C.H.I.P unit.

It really doesn’t help that the tool does not give any useful errors messages, just “Flashing Failed” so I can’t offer any more useful debugging information.

Just got my C.H.I.P., Having Trouble Flashing (to 4.4), Help?

We sort of do, in that the file payloads themselves are downloaded from numbered directories indicating the build number. The problem is that we’re downloading 6 prepared files as opposed to a the previous 5 prepared files. Having a version indicator stored locally may prove good for cached images, but we’ll still need to functionality in the flashing scripts.

could you plop the following into a terminal on the Debian or Ubuntu machines?

echo -e 'SUBSYSTEM=="usb", ATTRS{idVendor}=="1f3a", ATTRS{idProduct}=="efe8", GROUP="plugdev", MODE="0660" SYMLINK+="usb-chip"
SUBSYSTEM=="usb", ATTRS{idVendor}=="18d1", ATTRS{idProduct}=="1010", GROUP="plugdev", MODE="0660" SYMLINK+="usb-chip-fastboot"
SUBSYSTEM=="usb", ATTRS{idVendor}=="1f3a", ATTRS{idProduct}=="1010", GROUP="plugdev", MODE="0660" SYMLINK+="usb-chip-fastboot"
SUBSYSTEM=="usb", ATTRS{idVendor}=="067b", ATTRS{idProduct}=="2303", GROUP="plugdev", MODE="0660" SYMLINK+="usb-serial-adapter"
' | sudo tee /etc/udev/rules.d/99-allwinner.rules

sudo udevadm control --reload-rules


Well then the problem is with your flashing scripts. They should refuse to download images “from the future”, with a nice helpful message as to the need for a flashing script upgrade. For images from the past, the scripts should do the flash the “old fashioned way” current when the images were created.

This is what is meant by backward compatible. It can be done and not doing it will create repeated support headaches from confused users.

Regards, Steve


Yuck, NTC must love support problems.

Now you want the world to change to use your scripts, rather than have the scripts adapt to the world. Why would these rules be needed? They weren’t before.

What about people using buildroot or a distro not using udev on the host? People using udev must change the udev rules on every new computer where they want to flash images. NTC using udev now causes Linux users the same problems as windows users with getting things set up before doing the flash.

Regards, Steve


The flashing scripts simply don’t download the newest image at all yet, is the point I was trying to get across. We will update them soon, and the interaction will be transparent to the user.

The CHIP-SDK has also always required udev rules.

– Ben


What are my options for flashing without Chrome? I don’t have Chrome, and prefer not to use it, for privacy reasons.


Well, there’s Chromium, but you may not like that either. Otherwise, you’d have to go the CHIP-tools route on Linux.


First try: failed (probably due to USB3 ports)
—switched to using USB2 hub—
Second try: failed (hung at 7%)
Third try: worked like a charm!


Are you on Windows? If so, which version? I believe this initial hiccup is a one-time thing. In the future, I’d expect flashing to just work on your machine.


I’m on OS X 10.11.05 / MacBook Air 13-inch, Mid 2013.
I just flashed a second CHIP, worked on the first try (using a USB2 hub).


I’d be fine with that, since I’ve got a Raspberry Pi as my home server. I’m assuming I just need to dig up a source package for CHIP-tools and compile it, right?


Here is some info on how to flash a chip from chip. Since the Pi is also debian, I would expect it to work: