[Arm-netbook] Side-Topic: Liberating PocketCHIP

[Jeffrey Sites]

---
jasites

> On May 9, 2017, at 16:00, John Luke Gibson <eaterjolly at gmail.com> wrote:
> 
>> 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).
> 

Would it make sense to just add a target for C.H.I.P. to libreCMC in this case?

I had been planning on doing that for a while but haven't had the time. 

> 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)
> 
> _______________________________________________
> 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