--- jasites
> On May 9, 2017, at 16:00, John Luke Gibson <eaterjo...@gmail.com> wrote: > >> On 5/8/17, Pablo <pa...@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 <pa...@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@lists.phcomp.co.uk >> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook >> Send large attachments to arm-netb...@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@lists.phcomp.co.uk > http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook > Send large attachments to arm-netb...@files.phcomp.co.uk _______________________________________________ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netb...@files.phcomp.co.uk
