GR8

un-bagging Next Thing Co "chip pro" featuring a 'GR8' chip, some dude take'n a smoke break on streets of sf handed me one, so took it home and started hack'n on it as ya do, or thus far don't. these were set to release in "october" this is october, one year later. debian boot image for this is marked "deprecated", embedded arch version doesn't seem to have been rounded out.

https://docs.getchip.com/chip_pro.html#get-started-with-c-h-i-p-pro

http://flash.getchip.com/start

following cut and paste, doesn't exactly work, also you could just "su" the user in teh terminal to update group addition. in theory this would also work "sudo chromium --no-sandbox" however this assumes using ubuntu, we're using arch, so pause here to find windows machine.

So rtfm'd on Windows 10 machine, installed chrome app, installed driver, flashed with VU example, and now flasher can't re-enable FEL mode after running other tests. Also main product page says "dual mic's" however, these are apparently only i2s inputs, and the actual hardware required is on a optional dev board, so VU demo is probably totally useless in this case.

WHY IN TEH POST IRONIC SMALL BATCH INFINITY SCALE HARDWARE WORLD DOESN'T THIS COME WITH A PRE-INSTALLED IMAGE THAT DOES SOMETHING OUT OF THE BAG!?

will sleep on it before going nuclear...

came across this in bbs/forum threads: http://www.chip-community.org/index.php/Archlinuxarm_on_chip

#required packages for flashing
$ sudo pacman -S android-tools sunxi-tools

$ ./flash_arch.sh 
Loading SPL to the device
Uploading padded SPL to device memory
Uploading padded Uboot to device memory
Uploading Uboot flashing script image to device memory
Running Uboot with flashing script on device and waiting for fastboot
Flashing UBI image using fastboot
target reported max download size of 33554432 bytes
sending sparse 'UBI' 1/9 (30720 KB)...
OKAY [  2.968s]
writing 'UBI' 1/9...
FAILED (remote: error writing the image)
finished. total time: 3.062s
Flashing done, hopefully now the device will boot correctly to Arch
resuming boot...
OKAY [  0.000s]
finished. total time: 0.000s

The first few steps seem to work fine, then fails trying to write the entire UBI image. The shell script uses a "-u" flag which specifically does not erase the partition before writing, running without this flag did not seem to erase the partition first either.

I re-ran the entire procedure in the shell script manually, this time running a fastboot erase command on the UBI partition before the fastboot flash step which then successfully completed the UBI flashing. I used pre-compiled image from http://85.255.10.189/v0.4/ubi.img.sparse

$ sudo sunxi-fel spl sunxi-spl.bin
$ sudo sunxi-fel write 0x43000000 sunxi-spl-with-ecc.bin
$ sudo sunxi-fel write 0x4a000000 padded_uboot
$ sudo sunxi-fel write 0x43100000 uboot-script.img
$ sudo sunxi-fel exe 0x4a000000
$ sudo fastboot -i 0x1f3a devices
162542ca0b423627	fastboot

$ sudo fastboot -i 0x1f3a erase UBI
erasing 'UBI'...
OKAY [  2.814s]
finished. total time: 2.814s

$ sudo fastboot -i 0x1f3a -u flash UBI ubi.img.sparse
target reported max download size of 33554432 bytes
sending sparse 'UBI' 1/9 (30720 KB)...
OKAY [  2.905s]
writing 'UBI' 1/9...
OKAY [  3.935s]
sending sparse 'UBI' 2/9 (30720 KB)...
OKAY [  2.878s]
writing 'UBI' 2/9...
OKAY [ 17.116s]
sending sparse 'UBI' 3/9 (30720 KB)...
OKAY [  2.841s]
writing 'UBI' 3/9...
OKAY [ 17.118s]
sending sparse 'UBI' 4/9 (30720 KB)...
OKAY [  2.905s]
writing 'UBI' 4/9...
OKAY [ 17.117s]
sending sparse 'UBI' 5/9 (30720 KB)...
OKAY [  2.896s]
writing 'UBI' 5/9...
OKAY [ 17.119s]
sending sparse 'UBI' 6/9 (30720 KB)...
OKAY [  2.888s]
writing 'UBI' 6/9...
OKAY [ 17.121s]
sending sparse 'UBI' 7/9 (30720 KB)...
OKAY [  2.916s]
writing 'UBI' 7/9...
OKAY [ 17.120s]
sending sparse 'UBI' 8/9 (30720 KB)...
OKAY [  2.918s]
writing 'UBI' 8/9...
OKAY [ 17.128s]
sending sparse 'UBI' 9/9 (22528 KB)...
OKAY [  2.118s]
writing 'UBI' 9/9...
OKAY [ 10.770s]
finished. total time: 159.808s

$ sudo fastboot -i 0x1f3a continue
resuming boot...
OKAY [  0.000s]
finished. total time: 0.000s

this all seemed to work, and in theory the chip is now loaded with Arch and has booted into it. I can't seem to verify this as the USB connection does not resolve to a valid serial port and the chip just seems to get very hot to the touch at this point. restarting the chip enumerates as a USB device with no specific interface, although it seems to run at a reasonable temperature now.

ARRRRRRRRRR FARTS!, that was not teh distro you're looking for

all of that probably would have worked if this was a "c.h.i.p." however, this is a "c.h.i.p. pro" which has half the ram and 1/8th of storage. i had a suspicion as there was a vague reference to expanding a file system to 4GB. so maybe if some settings were twerked and it was compiled from source, maybe.

so here's another random find https://docs.getchip.com/chip_pro.html#bluetooth-is-not-working-on-c-h-i-p-pro-debian-based-pro-image

this describes a process of installing some things from git, and downloading a tar file, which comes a bit awkwardly from mega. this process seems to work ok on a arch based host machine with modification for pre-requisites to be installed using pacman not apt-get "sudo pacman -S sunxi-tools uboot-tools"

$ sudo ./chip-update-firmware.sh -L img/
== Local directory 'img/' selected ==
== preparing images ==
== Local/cached probe files located ==
== Staging for NAND probe ==
Image Name:   detect NAND
Created:      Thu Oct  5 16:22:11 2017
Image Type:   ARM Linux Script (uncompressed)
Data Size:    97 Bytes = 0.09 KiB = 0.00 MiB
Load Address: 00000000
Entry Point:  00000000
Contents:
   Image 0: 89 Bytes = 0.09 KiB = 0.00 MiB
waiting for fel...OK
waiting for fel......OK
NAND detected:
nand_erasesize=40000
nand_oobsize=100
nand_writesize=1000
== Cached UBI located ==
Image Name:   flash server
Created:      Thu Oct  5 16:22:22 2017
Image Type:   ARM Linux Script (uncompressed)
Data Size:    1784 Bytes = 1.74 KiB = 0.00 MiB
Load Address: 00000000
Entry Point:  00000000
Contents:
   Image 0: 1776 Bytes = 1.73 KiB = 0.00 MiB
waiting for fel...OK
waiting for fastboot..............OK
target reported max download size of 33554432 bytes
sending sparse 'UBI' 1/11 (32512 KB)...
OKAY [  2.480s]
writing 'UBI' 1/11...
OKAY [ 16.448s]
sending sparse 'UBI' 2/11 (32512 KB)...
OKAY [  2.530s]
writing 'UBI' 2/11...
OKAY [ 18.064s]
sending sparse 'UBI' 3/11 (32512 KB)...
OKAY [  2.637s]
writing 'UBI' 3/11...
OKAY [ 18.070s]
sending sparse 'UBI' 4/11 (32512 KB)...
OKAY [  2.503s]
writing 'UBI' 4/11...
OKAY [ 18.071s]
sending sparse 'UBI' 5/11 (32512 KB)...
OKAY [  2.536s]
writing 'UBI' 5/11...
OKAY [ 18.071s]
sending sparse 'UBI' 6/11 (32512 KB)...
OKAY [  2.511s]
writing 'UBI' 6/11...
OKAY [ 18.074s]
sending sparse 'UBI' 7/11 (32512 KB)...
OKAY [  2.523s]
writing 'UBI' 7/11...
OKAY [ 18.075s]
sending sparse 'UBI' 8/11 (32512 KB)...
OKAY [  2.535s]
writing 'UBI' 8/11...
OKAY [ 18.082s]
writing 'UBI' 9/11...
OKAY [ 18.070s]
sending sparse 'UBI' 10/11 (32512 KB)...
OKAY [  2.534s]
writing 'UBI' 10/11...
OKAY [ 17.821s]
sending sparse 'UBI' 11/11 (2560 KB)...
OKAY [  0.205s]
writing 'UBI' 11/11...
OKAY [  1.321s]
finished. total time: 205.692s
resuming boot...
OKAY [  0.000s]
finished. total time: 0.000s


FLASH VERIFICATION COMPLETE.


   #  #  #
  #########
###       ###
  # {#}   #
###  '%######
  #       #
###       ###
  ########
   #  #  #


CHIP is ready to roll!

so once again this says it's ready to work roll, however still you can't tell anything from the usb connection or a blinky led even. connected to a USB/UART serial interface, and jack shit on power up.