[Arm-netbook] Side-Topic: Liberating PocketCHIP

[John Luke Gibson]

On 5/8/17, Pablo <pablo at parobalth.org> wrote:
> On Sun, May 07, 2017 at 04:36:40PM +0100, Luke Kenneth Casson Leighton
> wrote:
>> On Sun, May 7, 2017 at 4:17 PM, Pablo <pablo at parobalth.org> wrote:
>>
>> > To flash your deblobbed image beware of the closed-source flashing tool
>> > for the Chrome browser and use the strange “Ubuntu virtual machine
>> > SDK solution”. I read somewhere that one NextThing developer flashes
>> > right from his Debian box but this way is not officially supported.
>>
>>  jaezuss this kind of thing pisses me off.  there is *NO NEED* for
>> proprietary tools with the A13 (R8), the A20 or any other allwinner
>> processor.
> I agree. Just to be sure I looked again if I can find the source of the
> Chrome browser extension.
> I only found this forum thread where "hippiehacker" searches for the source
> and gets no answer:
> https://bbs.nextthing.co/t/chip-flasher-on-github/5561/10
> So it seems I have been correct and it is proprietary.
>
>>fex-boot has been in sunxi-tools for at least FOUR YEARS
>> since i helped hno and others with the USB-sniffing of the FEL
>> protocol.
> What I called the strange "Ubuntu virtual machine SDK solution" is
> documented here:
> https://docs.getchip.com/chip.html#installing-c-h-i-p-sdk
> Basically they recommend to install a huge virtual machine image to
> create a "level" playing field for all users and then use a bunch of
> shell-scripts called CHIP-tools to flash images from within the virtual
> machine.
> CHIP-tools require sunxi-tools:
> https://github.com/NextThingCo/CHIP-tools
>
> So they use sunxi-tools but in a quite comlicated way.
> A documented and tested command-line solution for the major
> distributions would have been the way to go...
>
> Pablo
>
> _______________________________________________
> arm-netbook mailing list arm-netbook at lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netbook at files.phcomp.co.uk

Right now I'm looking at CHIP-buildroot.
I'm planning on patching out any blobs and also anything not CHIP
related (as we don't want a person to accidentally think the script
will give them a blobless cubieboard or anything).

I'm planning on posting the fork on notabug along with deblobbed forks
to any repositories the script fetches from and modifying the script
to pull from the blobless notabug repositories. So far I haven't found
any hex files in their uboot, so my hunch is that the wifi driver is
in the kernel and the chips won't need reflashing if that really truly
is the only blob. Thanks for the links about flashing. While I haven't
found any binary in uboot, I really don't like how often the source
comments mention code specifically aimed at accommodating blobs, so
even if their are no blobs I may still want to patch out some of the
files that check for the presence of microcode, etc... You know, to
make sure accidents don't happen.

I'm not a programmer by trade, so I don't know if I'm speaking above
my grade, but just looking at buildroot it looks like their is tons of
glitched/typo'ed code in conditional if statements that look like they
would never have any practical reason to run... Is this normal for
open source code xD

Like, the first file initiated by the main make file is
support/setlocalversion which looks to just check a whole bunch of
un-special variables which weren't set in the make script and had no
opportunity to be set by any other files I know of (on my system the
variables show as empty not having run anything from buildroot, but I
can't imagine head would be set to such a specific git command on
accident as the one it checks for). Then the if one of the conditions
were some how filled, then all it does is print weird strings like
this:

printf '%s%s' -g $head

Like this is the if statement:

if head=`git rev-parse --verify --short HEAD 2>/dev/null`

Mind you all this is printed to a variable in the make script called
BR2_Version_Full which does nothing in the make script but get printed
if a person asks the version, the script calls target-finalize or
legal-info-prepare (which it looks like it does unconditionally in
both cases). Like am I really that deep in over my head or does this
script really have a bug where if someone sets head to some weird
obscure git command it prints that very command in it's legal info?
Like how does that happen that way on accident? It looks like it might
serve some obscure purpose if it ran the command (which from I can
tell with bash, setting some $(shell x) might do that, however the
version string it should output doesn't seem very useful and just
contributes to that endemic problem of shell outputs being incredibly
hard to read for non-programmers, so I think I'll just delete the file
in our fork (obviously it serves no purpose if this bug hasn't been
noticed by now).

If I'm already making a critical error here, please tell me and I'll
reassess my use of the word trivial and computers xD

https://github.com/NextThingCo/CHIP-buildroot
(I'm talking about support/scripts/setlocalversion)