--- jasites
On May 9, 2017, at 16:00, John Luke Gibson eaterjolly@gmail.com wrote:
On 5/8/17, Pablo pablo@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@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-netbook@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-netbook@files.phcomp.co.uk