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.