New CHIP-SDK/CHIP-tools update


Hey folks,

In addition to Merry K[ernal]-mas, there’s another update afoot! Most of you seem to be using the Chrome web flasher, but those who err on the side of FOSS have been asking for a while about when the newer images would be available with the SDK, so here we go!

  • The CHIP-SDK and CHIP-tools have been updated to handle our new image format, both in terms of flashing and image creation.
  • Image caching was added to save on download time across image types.
  • A -h flag was added to for a help prompt that will now provide a quick explanation of all supported flashing flags, like No Limit, Reset, and Build #.
  • New images of every type [even Buildroot]!
  • PocketCHIP now flashable from terminal.

Be sure to run the new script before using the flashing tools to get all the appropriate dependencies set up.

Happy flashing!

– Ben

Smoothing SDK installation

Just in time to try out on these… oooh look… i brought a jumper cable into work with me… (lunch time testing i think).
Thanks @computermouth


Ended up with the following… during the make stage.

In file included from include/linux/compiler.h:54:0,
                 from include/linux/bitops.h:5,
                 from ./include/common.h:20:
include/linux/compiler-gcc.h:114:30: fatal error: linux/compiler-gcc6.h: No such file or directory
 #include gcc_header(__GNUC__)
compilation terminated.
In file included from include/linux/compiler.h:54:0,
                 from include/linux/bitops.h:5,
                 from ./include/common.h:20:
include/linux/compiler-gcc.h:114:30: fatal error: linux/compiler-gcc6.h: No such file or directory
 #include gcc_header(__GNUC__)
compilation terminated.
In file included from include/linux/compiler.h:54:0,
                 from include/linux/bitops.h:5,
                 from ./include/common.h:20:
include/linux/compiler-gcc.h:114:30: fatal error: linux/compiler-gcc6.h: No such file or directory
 #include gcc_header(__GNUC__)
make[3]: *** [include/] Error 1
make[3]: *** Waiting for unfinished jobs....
make[3]: *** [include/] Error 1
compilation terminated.
make[3]: *** [spl/include/] Error 1
make[2]: *** No rule to make target `include/config/auto.conf', needed by `include/config/uboot.release'.  Stop.
make[1]: *** [/home/administrator/buildroot/output/build/uboot-nextthing_chip-production-v1.2/.stamp_built] Error 2

From memory i got past this by using the buildroot key chain or something and not letting it download one.
I honestly cant remember as its been almost a month on this, but i do recall it was something i changed in make menuconfig for buildroot.

Is this using the latest buildroot version? i think possibly i resolved this by using the latest buildroot… one of the two above … cant recall which one.


If you git status in CHIP-Buildroot are you on branch chip/stable?

I do also remember this, but I thought it was resolved. Also, if this is from a previously cloned CHIP-Buildroot, you may need to sudo git clean -xfd to purge out all of the download and build cache. And then yes, I would check which toolchain is set in make nconfig. I believe we’re still recommending gcc4.9:

-> Type: External
-> Toolchain: Linaro ARM 2014.09


It was on my work PC, so i’ll have to check that one tomorrow as i’m home now and way to lazy to be using computers… programmer by day and … programmer by night… time for a night off.

But as for the cloned directory, i cleared out all old folders/files and did clean clones… normally i would do git pull but in this case i just did rm as wanted to be sure.,

Will update tomorrow at some stage
EDIT:… vpn’ned into work to check…

administrator@ntcchipflasher:~/buildroot$ git status
On branch chip/stable
Your branch is up-to-date with ‘origin/chip/stable’.
nothing to commit, working directory clean

i’ll need to re-download the default config for buildroot as was playing with it before hand, so to re-test need to be clean again… as in after posting my results i started to revert it to my working setup


Ok, keep me posted. I just built the chip/stable branch on my PC here and it all went fine. Buildroot is designed to be as self contained as possible, so differences in our hosts shouldn’t matter so much. But we’ll see.


Well i was able to get it to build with the following toolchain setup

Still slowly exploring, but now any time i re-clone/pull the git… it holds these settings (which i setup a few weeks ago on my old testing) … but never configured it today…

Removed the buildroot folder and re-cloned and same settings… Might build a clean VM later/tomorrow…


Oh ok, so the difference here is that you’re actually building the toolchain from source inside of Buildroot, as opposed to downloading the prebuilt one from Linaro. It’s entirely fine to do it that way, it’s just that your builds will take a bit longer.


I normallly copy the chip config file over manually, I’ll double check it as well.

Im going to do the clean vm and rule out any weirdness, normally i wouldnt but in this case i just wanna be sure… but yea as soon as it uses the linaro one it fails on the gcc


Interesting, thanks for looking into this! I will also try on a fresh machine tomorrow.


Testing this now, make is currently running for buildroot… Clean VM… so shall know soon.

In the mean time a few suggestions.

1: use git clone --depth 1 where possible… will speed things up
2: git pull other repository if possible instead of using rm … "sunxi-tools"
3: use the dialog command to create a clean menu… example of mine
Never got time to finish it, but was so people could easily select from available versions
4: Use the offical buildroot repo, copy the required configs from the CHIP-buildroot … example in
5: Create a few dedicated bash scripts for the make commands… eg So you would run & Then

This time around it used the linaro 2014 version, so either way the part was resolved with the clean vm… going to put that down to murpheys law.

Well this time around it built with no issues So all good


Agreed on all fronts! The sunxi-tools removal was necessary as we’re actually switched to the upstream tools now, as opposed to our fork.

Dialog menus would be great. I took a look at your repo once before, and it’s super clean. Maybe for the next update I’ll draw some inspiration from it [with accreditation].

@zerotri’s actually doing a ton of work to migrate our stuff to using upstream Buildroot, but it’s still not ready for us to publicly promote yet.

Glad you’re up and running!


Im just glad it was the vm being the cause, so yay i dont need to find some random glitch or gemlin.

Dont worry about any credit, take anything from the git of mine. I just created quickly so it was hosted some where.

I just wish i had more time to complete it and to do my chip projects.


I finally had a chance to checkout this new firmware load. I had bought a PocketCHIP that I received mid last year (kickstarter reward). I then purchased a couple of spare CHIPs the end of last year and decided I would load the new PocketCHIP firmware on one of those and try it out in the PocketCHIP chassis. Things went fine and my problem with trying to connect to my WiFi after boot was fixed!

Previously my WiFi would only connect if I powered up or rebooted with it enabled. If I started with it off and then turned it on it would never connect. So then I’d have to reboot to get connected. So this is a nice improvement and one I thought worthwhile enough to go through the trouble of reloading all of the software that I had installed, which is probably going to take some trial and error as I didn’t make a list of all the things I’ve added or changed. :slight_smile:

So I decided I’d go through the hassle of loading the updated firmware on the original CHIP that came with my PocketCHIP. I assumed it would be quick since the firmware was already downloaded. I was wrong! It downloaded another image.

So, out of curiosity: What’s the difference? The original UBI file was named “chip-400000-4000-500.ubi.sparse” and the second download was named, “chip-400000-4000-680.ubi.sparse”. Can you explain the file name format and what the differences are?

Also kudos for getting the CLI flasher updated. That’s a very nice improvement in my book. I was one of those that hounded your support staff via email for images to flash with the CHIP-tools scripts.


I should mention, just in case anyone else is interested, that in order to get the CLI flasher to work I had to patch the “CHIP-tools/” script so that it looked for “fel” not “sunxi-fel”. I built “fel” from the “” repo. I suppose I could have renamed it as well. :slight_smile:


One is padded specifically for the Toshiba nand we circulate, the other is padded specifically for Hynix nand CHIPs.

This distinction is actually more involved than just the name of the binary. sunxi-fel is a newer version, re-running the CHIP-SDK setup script will build and install this binary.


Worked like a charm on the couple of CHIPs I tried it on and obviously I have both nand parts. My PocketCHIP gained some gigs! I made sure that the sunxi-tools repo was at the latest commit (branch “master”, commit #09cf8e3).


I am not able to flash the chip-pro using -f. Anyone succeeded ?


What do you mean by you cannot flash? Is there an error? If so, what’s the error? Is it something else?


update happens successfully, but after poweroff ( plugging off the usb cable), i am not getting /dev/ttyACM0 on my HOST