GR8 - Revision history

Ⅹ: /* debian */ avr packages net fix

2017-10-10T00:59:45Z

debian: avr packages net fix

← Older revision		Revision as of 17:59, 9 October 2017
Line 20:		Line 20:
	sudo apt-get install nginx		sudo apt-get install nginx
	</pre>		</pre>

			...also pip and gunicorn for apps

	Installing python generated another warning of inability to authenticate packages, also this ended up installing Python 2.7, so installed Python 3 as python3 package instead.		Installing python generated another warning of inability to authenticate packages, also this ended up installing Python 2.7, so installed Python 3 as python3 package instead.
Line 25:		Line 27:
	You should now get a default nginx page when trying to access ip of device via browser.		You should now get a default nginx page when trying to access ip of device via browser.

			adding support for avr deployment, avrdude, git
			<code>sudo apt-get install avrdude git</code>

			ran into an issue where apt-get install was failing, with errors about not being able to access internet resources. turned out wireless connection had died, restarted network services to restore connection.
			<code>sudo /etc/init.d/network-manager restart</code>

	== init ==		== init ==

核: +installs

2017-10-06T03:06:16Z

+installs

@@ Line 1: / Line 1: @@
 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.
@@ Line 4: / Line 33: @@
 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.

核: can haz root

2017-10-06T00:43:54Z

can haz root

Show changes

核 at 23:45, 5 October 2017

2017-10-05T23:45:03Z

← Older revision		Revision as of 16:45, 5 October 2017
Line 104:		Line 104:

	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.		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"

			<pre>
			$ 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!

			</pre>

			so once again this says it's ready to <s>work</s> 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.

核: $ ./flash_arch.sh

2017-10-05T23:07:37Z

$ ./flash_arch.sh

← Older revision		Revision as of 16:07, 5 October 2017
Line 12:		Line 12:

	will sleep on it before going nuclear...		will sleep on it before going nuclear...


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

			<pre>
			#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
			</pre>

			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

			<pre>
			$ 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
			</pre>

			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.

核: this is not yet a gadget

2017-10-04T07:37:05Z

this is not yet a gadget

New page

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...