Since it seems like a trivially simple task that for some reason no one has taken up, I would like to take the opportunity to exercise a learning experience and simultaneously benefit the community, by liberating PocketCHIP by deblobbing the source and re-compiling.
Browsing the archives to see if this had been talked about before, I find it very incredibly humourous I got name dropped on the mailing list by Parobath:
Date: Sat, 29 Oct 2016 20:13:10 +0200 From: Parobalth parobalth@gmail.com To: arm-netbook@lists.phcomp.co.uk Subject: closed-source BootROM and RYF certification User-Agent: Mutt/1.5.23 (2014-03-12)
At the forum of NextThing Chip is a thread about Chip and a possible RYF certification. I wrote there that I think that is unlikely to happen and linked to https://www.crowdsupply.com/eoma68/micro-desktop/updates/fsf-ryf-background. Then someone else mentioned that a closed-source BootROM is used for Chip. Another guy with username "eaterjolly" wrote about this BootROM: "The same type of SOC is used for the EOMA croud project which is vying for ryf-endorsement quite openly [...]"
You can find the forum thread here: https://bbs.nextthing.co/t/ntc-thoughts-on-ryf-endorsement/4490
Because they use Discourse to power their forum which relies heavily on JavaScript I also attach a Pdf version of the forum post.
I wonder if the mentioned statements are correct and how it relates to the RYF certification of the EOMA68-A20 Libre Tea card.
kind regards Paro
Like reading that URL, I was like? didn't I start that thread? then I re-read the post and noticed I was quoted in the email xD I didn't participate in the list back then, cause I was afraid my ignorance would be spurred, of course I know that not to be true in hindsight. Feels a bit melodramatic being name dropped on a linux mailing list, usually you only see legends get mentioned by name when they aren't around xD
Anywhoo, I more or less just wanted to start this thread because I wanted to know if any one could point out anything that would need be removed besides the wifi firmware. I searched the sunix-uboot repository on github for the word blob and got a few interesting hits for the code in the folder binman:
https://github.com/linux-sunxi/u-boot-sunxi/search?q=blob
Particularly in files mentioning the devil:
"# Entry-type module for Intel Chip Microcode binary blob"
I suppose this is just another aspect of mainlining, meant to be parsed out once it's discovered that there are no such blobs in the kernel, but personally I'd feel more comfortable with a script removing these sections of the code altogether.
If I had been actually reading the list digests back when I could have posted more accurate information in that thread rather than just guessing. Well, I suppose I can do so now.
How humorous it is though too that I've run into the same 40k file limit? Small tiny things suggesting the work of the vicissitudes of fate, much like deja vu in the matrix.
Why is there an intel blob on the chip. I didn't know there was intel ip in there.
On Thu, May 4, 2017 at 10:04 AM, John Luke Gibson eaterjolly@gmail.com wrote:
Since it seems like a trivially simple task that for some reason no one has taken up, I would like to take the opportunity to exercise a learning experience and simultaneously benefit the community, by liberating PocketCHIP by deblobbing the source and re-compiling.
Browsing the archives to see if this had been talked about before, I find it very incredibly humourous I got name dropped on the mailing list by Parobath:
Date: Sat, 29 Oct 2016 20:13:10 +0200 From: Parobalth parobalth@gmail.com To: arm-netbook@lists.phcomp.co.uk Subject: closed-source BootROM and RYF certification User-Agent: Mutt/1.5.23 (2014-03-12)
At the forum of NextThing Chip is a thread about Chip and a possible RYF certification. I wrote there that I think that is unlikely to happen and linked to https://www.crowdsupply.com/
eoma68/micro-desktop/updates/fsf-ryf-background.
Then someone else mentioned that a closed-source BootROM is used for
Chip.
Another guy with username "eaterjolly" wrote about this BootROM: "The
same type of SOC is
used for the EOMA croud project which is vying for ryf-endorsement quite openly [...]"
You can find the forum thread here: https://bbs.nextthing.co/t/ntc-thoughts-on-ryf-endorsement/4490
Because they use Discourse to power their forum which relies heavily on JavaScript I also attach a Pdf version of the forum post.
I wonder if the mentioned statements are correct and how it relates to the RYF certification of the EOMA68-A20 Libre Tea card.
kind regards Paro
Like reading that URL, I was like? didn't I start that thread? then I re-read the post and noticed I was quoted in the email xD I didn't participate in the list back then, cause I was afraid my ignorance would be spurred, of course I know that not to be true in hindsight. Feels a bit melodramatic being name dropped on a linux mailing list, usually you only see legends get mentioned by name when they aren't around xD
Anywhoo, I more or less just wanted to start this thread because I wanted to know if any one could point out anything that would need be removed besides the wifi firmware. I searched the sunix-uboot repository on github for the word blob and got a few interesting hits for the code in the folder binman:
https://github.com/linux-sunxi/u-boot-sunxi/search?q=blob
Particularly in files mentioning the devil:
"# Entry-type module for Intel Chip Microcode binary blob"
I suppose this is just another aspect of mainlining, meant to be parsed out once it's discovered that there are no such blobs in the kernel, but personally I'd feel more comfortable with a script removing these sections of the code altogether.
If I had been actually reading the list digests back when I could have posted more accurate information in that thread rather than just guessing. Well, I suppose I can do so now.
How humorous it is though too that I've run into the same 40k file limit? Small tiny things suggesting the work of the vicissitudes of fate, much like deja vu in the matrix.
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
On 5/4/17, Bill Kontos vkontogpls@gmail.com wrote:
Why is there an intel blob on the chip. I didn't know there was intel ip in there.
On Thu, May 4, 2017 at 10:04 AM, John Luke Gibson eaterjolly@gmail.com wrote:
Since it seems like a trivially simple task that for some reason no one has taken up, I would like to take the opportunity to exercise a learning experience and simultaneously benefit the community, by liberating PocketCHIP by deblobbing the source and re-compiling.
Browsing the archives to see if this had been talked about before, I find it very incredibly humourous I got name dropped on the mailing list by Parobath:
Date: Sat, 29 Oct 2016 20:13:10 +0200 From: Parobalth parobalth@gmail.com To: arm-netbook@lists.phcomp.co.uk Subject: closed-source BootROM and RYF certification User-Agent: Mutt/1.5.23 (2014-03-12)
At the forum of NextThing Chip is a thread about Chip and a possible RYF certification. I wrote there that I think that is unlikely to happen and linked to https://www.crowdsupply.com/
eoma68/micro-desktop/updates/fsf-ryf-background.
Then someone else mentioned that a closed-source BootROM is used for
Chip.
Another guy with username "eaterjolly" wrote about this BootROM: "The
same type of SOC is
used for the EOMA croud project which is vying for ryf-endorsement quite openly [...]"
You can find the forum thread here: https://bbs.nextthing.co/t/ntc-thoughts-on-ryf-endorsement/4490
Because they use Discourse to power their forum which relies heavily on JavaScript I also attach a Pdf version of the forum post.
I wonder if the mentioned statements are correct and how it relates to the RYF certification of the EOMA68-A20 Libre Tea card.
kind regards Paro
Like reading that URL, I was like? didn't I start that thread? then I re-read the post and noticed I was quoted in the email xD I didn't participate in the list back then, cause I was afraid my ignorance would be spurred, of course I know that not to be true in hindsight. Feels a bit melodramatic being name dropped on a linux mailing list, usually you only see legends get mentioned by name when they aren't around xD
Anywhoo, I more or less just wanted to start this thread because I wanted to know if any one could point out anything that would need be removed besides the wifi firmware. I searched the sunix-uboot repository on github for the word blob and got a few interesting hits for the code in the folder binman:
https://github.com/linux-sunxi/u-boot-sunxi/search?q=blob
Particularly in files mentioning the devil:
"# Entry-type module for Intel Chip Microcode binary blob"
I suppose this is just another aspect of mainlining, meant to be parsed out once it's discovered that there are no such blobs in the kernel, but personally I'd feel more comfortable with a script removing these sections of the code altogether.
If I had been actually reading the list digests back when I could have posted more accurate information in that thread rather than just guessing. Well, I suppose I can do so now.
How humorous it is though too that I've run into the same 40k file limit? Small tiny things suggesting the work of the vicissitudes of fate, much like deja vu in the matrix.
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
Well to clarify, I haven't actually found a blob in uboot yet, rather I found parts of the code which refer to blobs interestingly.
So far I found this pile of blobs in their kernel that the readme says they are legally no allowed to distribute, lovely:
https://github.com/NextThingCo/CHIP-linux/tree/chip/stable/firmware
But also on the wifi, I don't know, but this file certainly looks like the source code of a wireless driver:
https://github.com/NextThingCo/CHIP-linux/blob/fd2ad2582c7fb4a5fedff5ac19ca3...
Gosh, I feel like this is just more mainline stuff that would be parsed out, because there must be more than a hundred drivers with everything from intel to yamaha.
On Thu May 4 12:05:48 BST 2017, John Luke Gibson wrote:
Gosh, I feel like this is just more mainline stuff that would be parsed out, because there must be more than a hundred drivers with everything from intel to yamaha.
Yes, you need to look at the configuration file for the kernel to find out what's included. There's a file in the vendor's Buildroot repository (https://github.com/NextThingCo/CHIP-buildroot) that seems to be what you're looking for:
https://github.com/NextThingCo/CHIP- buildroot/blob/chip/stable/board/nextthing/pocketchip/linux.config
David
2017-05-04 9:04 GMT+02:00 John Luke Gibson eaterjolly@gmail.com:
Since it seems like a trivially simple task that for some reason no one has taken up, I would like to take the opportunity to exercise a learning experience and simultaneously benefit the community, by liberating PocketCHIP by deblobbing the source and re-compiling.
The PocketCHIP is powered by their SoM: http://linux-sunxi.org/NextThingCo_CHIP
That is apparently a Allwinner R8 pared with an external rtl8723bs Wifi/BT chip.
The R8 is a rebranded A13.
If you look at https://getchip.com/pages/chip
You'll see: On the left image the RAM (Hynix) and Wifi+BT (Realtek) and Power module (Allwinner AXP209) On the right the SoC (R8/A13) and NAND (Samsung)
The A13 does not need blob's to run anymore, the WiFi+BT chip does. AFAIKT
Display output needs some checking in Linux and U-boot mainline. But most should be available or somewhat easily hacked in.
GPU needs a BLOB which does not work on mainline AFAIKT. Luc Verhaegen did get quite far before he burned out.
But looking at the SUNXI wiki the CHIP products could need some TLC.
The PocketCHIP does not have it's own page there and probably needs a DT overlay. I doubt that runtime can autosense the hardware on that.
Browsing the archives to see if this had been talked about before, I find it very incredibly humourous I got name dropped on the mailing list by Parobath:
Date: Sat, 29 Oct 2016 20:13:10 +0200 From: Parobalth parobalth@gmail.com To: arm-netbook@lists.phcomp.co.uk Subject: closed-source BootROM and RYF certification User-Agent: Mutt/1.5.23 (2014-03-12)
At the forum of NextThing Chip is a thread about Chip and a possible RYF certification. I wrote there that I think that is unlikely to happen and linked to https://www.crowdsupply.com/
eoma68/micro-desktop/updates/fsf-ryf-background.
Then someone else mentioned that a closed-source BootROM is used for
Chip.
Another guy with username "eaterjolly" wrote about this BootROM: "The
same type of SOC is
used for the EOMA croud project which is vying for ryf-endorsement quite openly [...]"
You can find the forum thread here: https://bbs.nextthing.co/t/ntc-thoughts-on-ryf-endorsement/4490
Because they use Discourse to power their forum which relies heavily on JavaScript I also attach a Pdf version of the forum post.
I wonder if the mentioned statements are correct and how it relates to the RYF certification of the EOMA68-A20 Libre Tea card.
kind regards Paro
Like reading that URL, I was like? didn't I start that thread? then I re-read the post and noticed I was quoted in the email xD I didn't participate in the list back then, cause I was afraid my ignorance would be spurred, of course I know that not to be true in hindsight. Feels a bit melodramatic being name dropped on a linux mailing list, usually you only see legends get mentioned by name when they aren't around xD
Anywhoo, I more or less just wanted to start this thread because I wanted to know if any one could point out anything that would need be removed besides the wifi firmware. I searched the sunix-uboot repository on github for the word blob and got a few interesting hits for the code in the folder binman:
https://github.com/linux-sunxi/u-boot-sunxi/search?q=blob
Particularly in files mentioning the devil:
"# Entry-type module for Intel Chip Microcode binary blob"
That contains a full copy of U-Boot, not the Linux kernel, and thus initialization for all type of hardware. Most of which requires microcode of firmware to work.
I suppose this is just another aspect of mainlining, meant to be parsed out once it's discovered that there are no such blobs in the kernel, but personally I'd feel more comfortable with a script removing these sections of the code altogether.
If I had been actually reading the list digests back when I could have posted more accurate information in that thread rather than just guessing. Well, I suppose I can do so now.
How humorous it is though too that I've run into the same 40k file limit? Small tiny things suggesting the work of the vicissitudes of fate, much like deja vu in the matrix.
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
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Thu, May 4, 2017 at 4:13 PM, mike.valk@gmail.com mike.valk@gmail.com wrote:
That is apparently a Allwinner R8 pared with an external rtl8723bs Wifi/BT chip.
The R8 is a rebranded A13.
If you look at https://getchip.com/pages/chip
You'll see: On the left image the RAM (Hynix) and Wifi+BT (Realtek) and Power module (Allwinner AXP209) On the right the SoC (R8/A13) and NAND (Samsung)
The A13 does not need blob's to run anymore, the WiFi+BT chip does. AFAIKT
so that'll be a definitive "No" for the Chip, not because of the processor but because one of the peripherals (the RTL8723bs) requires proprietary firmware.
if they sold a variant that did *not* have the RTL8723bs *then* they would be able to apply for RYF Certification... assuming that they didn't try to put MALI onto the OS sold with the product [or any other proprietary software].
they'd also need to create a totally separate product page or use some other method which ensured that "Grandma buying CHIP for little Tommie" did NOT get the wrong one. that would mean that the [hypothetical RTL8723bs-less] CHIP would also need a totally different product name.
RYF Certification is really rather involved but makes sense when you consider all the angles.
l.
On 5/4/17, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Thu, May 4, 2017 at 4:13 PM, mike.valk@gmail.com mike.valk@gmail.com wrote:
That is apparently a Allwinner R8 pared with an external rtl8723bs Wifi/BT chip.
The R8 is a rebranded A13.
If you look at https://getchip.com/pages/chip
You'll see: On the left image the RAM (Hynix) and Wifi+BT (Realtek) and Power module (Allwinner AXP209) On the right the SoC (R8/A13) and NAND (Samsung)
The A13 does not need blob's to run anymore, the WiFi+BT chip does. AFAIKT
so that'll be a definitive "No" for the Chip, not because of the processor but because one of the peripherals (the RTL8723bs) requires proprietary firmware.
if they sold a variant that did *not* have the RTL8723bs *then* they would be able to apply for RYF Certification... assuming that they didn't try to put MALI onto the OS sold with the product [or any other proprietary software].
they'd also need to create a totally separate product page or use some other method which ensured that "Grandma buying CHIP for little Tommie" did NOT get the wrong one. that would mean that the [hypothetical RTL8723bs-less] CHIP would also need a totally different product name.
RYF Certification is really rather involved but makes sense when you consider all the angles.
l.
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
Yeah, I kind of given up on ntc since they refused to make any comment. I'm more thinking for my purposes, since I already have a few and they have a full usb port on the board free when in pocket-CHIP I figured I could just use a dongle.
On Thu, May 04, 2017 at 03:04:12AM -0400, John Luke Gibson wrote:
Since it seems like a trivially simple task that for some reason no one has taken up, I would like to take the opportunity to exercise a learning experience and simultaneously benefit the community, by liberating PocketCHIP by deblobbing the source and re-compiling.
I think we could argue about the definition of a "trivially simple task" and if it applies to this case. I own a NextThing Chip and I am interested in running it blob-free. Please document your efforts and keep me/us updated!
Anywhoo, I more or less just wanted to start this thread because I wanted to know if any one could point out anything that would need be removed besides the wifi firmware. I searched the sunix-uboot repository on github for the word blob and got a few interesting hits for the code in the folder binman:
As far as I know NextThing uses a custom U-boot fork which can be found here: https://github.com/NextThingCo/CHIP-u-boot
Kernel source used on Chip is here: https://github.com/NextThingCo/CHIP-linux/releases
I believe that NextThing uses free NAND-drivers developed by Free Electrons which shall be mainlined someday. Keep in mind that there are two types of NAND used and that NextThing provides different images for these NAND-types.
Basically you have to patch out the support for the non-free wifi module and make sure your dongle works properly. You also have to patch out the support for the Mali gpu. I have not heard about any other blobs.
It is bothersome that NextThing is quite opaque in their communication about blobs. You will have to look right at the source to understand what exactly is going on.
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.
Good luck and Happy Hacking!
Pablo
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. 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.
l.
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
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).
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)
On May 9, 2017 7:02 PM, "John Luke Gibson" eaterjolly@gmail.com wrote:
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`
That "=" is assignment, and those "`"s are output substitution. It tries executing that git command, storing the output in the shell variable head. If git succeeds (returns zero), the then clause is executed; if git fails (returns non-zero), the else clause (if present) is executed.
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
Apparently, but that's how we learn, right? :)
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?
No.
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,
"$(foo)" and "`foo`" are essentially the same. They both run foo, and substitute the output.
On 5/9/17, Benson Mitchell benson.mitchell+arm-netbook@gmail.com wrote:
On May 9, 2017 7:02 PM, "John Luke Gibson" eaterjolly@gmail.com wrote:
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`
That "=" is assignment, and those "`"s are output substitution. It tries executing that git command, storing the output in the shell variable head. If git succeeds (returns zero), the then clause is executed; if git fails (returns non-zero), the else clause (if present) is executed.
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
Apparently, but that's how we learn, right? :)
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?
No.
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,
"$(foo)" and "`foo`" are essentially the same. They both run foo, and substitute the output.
I ran this in terminal and got this:
john@john-ER922AA-ABA-SR1834NX-NA660:~/Documents/Code/OperationDaBlob/chip-buildroot+subsidiaries/CHIP-buildroot$ if head='git rev-parse --verify --short HEAD 2>/dev/null'; then
echo $head; else echo "failed"; fi
git rev-parse --verify --short HEAD 2>/dev/null john@john-ER922AA-ABA-SR1834NX-NA660:~/Documents/Code/OperationDaBlob/chip-buildroot+subsidiaries/CHIP-buildroot$ #!/bin/bash john@john-ER922AA-ABA-SR1834NX-NA660:~/Documents/Code/OperationDaBlob/chip-buildroot+subsidiaries/CHIP-buildroot$ # your code goes here john@john-ER922AA-ABA-SR1834NX-NA660:~/Documents/Code/OperationDaBlob/chip-buildroot+subsidiaries/CHIP-buildroot$ if head=$(git rev-parse --verify --short HEAD 2>/dev/null); then
echo $head; else echo "failed"; fi
b52c25c john@john-ER922AA-ABA-SR1834NX-NA660:~/Documents/Code/OperationDaBlob/chip-buildroot+subsidiaries/CHIP-buildroot$
So I do believe I found a bug, but I mixed up bash script and make script when posing $(shell x) as a solution which retains functionality.
@Jeff, that would be a best if we were starting from scratch. The Chip community has put a lot into documentation and tutorials, so it might not be best to throw all that out for a new os. Debian's not bad.
On 5/9/17, Benson Mitchell benson.mitchell+arm-netbook@gmail.com wrote:
Seems like you're confusing back-quote (`) with single-quote ('), maybe?
I just want to say that alone makes for pretty terrible design within a fundamental language which an entire os can't run without.
John Luke Gibson eaterjolly@gmail.com writes:
On 5/9/17, Benson Mitchell benson.mitchell+arm-netbook@gmail.com wrote:
Seems like you're confusing back-quote (`) with single-quote ('), maybe?
I just want to say that alone makes for pretty terrible design within a fundamental language which an entire os can't run without.
When `` was first used I'm sure they were very pleased to have come up with command substitution at all, so blaming them for introducing readability issues is a bit harsh. It's also possible that the distinction between ` and ' was much more obvious when one was reading the code off of a punched paper tape ;-)
$() has been in POSIX for at least 13 years:
http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag...
but I suspect that it was in 1003.2 in 1997, but cannot find a reference.
It is certainly a shame when one sees new scripts being written with ``, but that's what one gets when people are learning by example, and there is too little curation of the examples to weed out the archaic usage.
Cheers, Phil.
--- 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
On Tue, May 09, 2017 at 05:06:17PM -0700, Jeffrey Sites wrote:
On May 9, 2017, at 16:00, John Luke Gibson eaterjolly@gmail.com wrote:
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.
libreCMC seems an odd choice to me because C.H.I.P. does not have an ethernet port. I think libreCMC for a C.H.I.P. will have a small userbase. Do you have a special use case in mind?
As a general purpose OS one of the libre distributions or Debian with only the main repository seems the way to go.
Pablo
--- jasites
On May 10, 2017, at 07:02, Pablo pablo@parobalth.org wrote:
On Tue, May 09, 2017 at 05:06:17PM -0700, Jeffrey Sites wrote:
On May 9, 2017, at 16:00, John Luke Gibson eaterjolly@gmail.com wrote:
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.
libreCMC seems an odd choice to me because C.H.I.P. does not have an ethernet port. I think libreCMC for a C.H.I.P. will have a small userbase. Do you have a special use case in mind?
For using libreCMC as a base/framework for a lightweight embedded distribution without systemd, Linux-Libre kernel, uclib, and omitting router centric packages, using a ath9k_htc or USB->Ethernet dongle makes perfect sense for a small physical footprint for a server providing services like DHCP, HTTPS, or similar.
Since there is already support for other sunxi devices, and NTC uses buildroot as their Debian alternative, it seemed worthwhile to me. Obviously depends on use case or intended purpose.
As a general purpose OS one of the libre distributions or Debian with only the main repository seems 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
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Wed, May 10, 2017 at 12:00 AM, John Luke Gibson eaterjolly@gmail.com wrote:
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).
there's already a libre version of the linux kernel which has this done already. look up the linux kernel that parabola uses.
l.
Free Software Foundation Latin America Linux-Libre.
On 10 May 2017 09:40:02 GMT+03:00, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Wed, May 10, 2017 at 12:00 AM, John Luke Gibson eaterjolly@gmail.com wrote:
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).
there's already a libre version of the linux kernel which has this done already. look up the linux kernel that parabola uses.
l.
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
On Wed, May 10, 2017 at 12:00 AM, John Luke Gibson eaterjolly@gmail.com> wrote: 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).
On 10 May 2017 09:40:02 GMT+03:00, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote: there's already a libre version of the linux kernel which has this done already. look up the linux kernel that parabola uses.
On Wed, May 10, 2017 at 12:05:33PM +0300, Allan Mwenda wrote: Free Software Foundation Latin America Linux-Libre.
Good idea! To use an already existing and "official" kernel will save time, add credibility and transparency.
The link to the mentioned page of FSF Latin America is: https://www.fsfla.org/ikiwiki/selibre/linux-libre/
With any non-Chip-kernel you will lose NAND support. So you can either: a)patch your libre kernel or b) ignore NAND and use flash memory via usb port.
For b) you will need mainline U-Boot because NextThings U-Boot fork supports NAND but not booting via usb.
Pablo
On Wed, May 10, 2017 at 3:23 PM, Pablo pablo@parobalth.org wrote:
With any non-Chip-kernel you will lose NAND support. So you can either: a)patch your libre kernel or b) ignore NAND and use flash memory via usb port.
For b) you will need mainline U-Boot because NextThings U-Boot fork supports NAND but not booting via usb.
this sounds weird / not quite right. the R8 (aka A13, aka the A10) should be able to use the same sunxi 3.4.104+ kernel source as i've been using for the A20, which has the (sunxi, libre) NAND driver in it. afaik they didn't change the NAND hardware from the A10/A20 to the A13 to the R8 so this should be a non-issue.
also from what i gather there's been mainline support for the (completely different, MTD-compatible) NAND driver for quite some time, so again, should be a non-issue.
perhaps someone could ask on #linux-sunxi and/or their mailing list for confirmation of the facts?
l.
2017-05-10 16:38 GMT+02:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
On Wed, May 10, 2017 at 3:23 PM, Pablo pablo@parobalth.org wrote:
With any non-Chip-kernel you will lose NAND support. So you can either: a)patch your libre kernel or b) ignore NAND and use flash memory via usb port.
For b) you will need mainline U-Boot because NextThings U-Boot fork supports NAND but not booting via usb.
this sounds weird / not quite right. the R8 (aka A13, aka the A10) should be able to use the same sunxi 3.4.104+ kernel source as i've been using for the A20, which has the (sunxi, libre) NAND driver in it. afaik they didn't change the NAND hardware from the A10/A20 to the A13 to the R8 so this should be a non-issue.
also from what i gather there's been mainline support for the (completely different, MTD-compatible) NAND driver for quite some time, so again, should be a non-issue.
perhaps someone could ask on #linux-sunxi and/or their mailing list for confirmation of the facts?
Wiki says "work in progress"
http://linux-sunxi.org/Mainlining_Effort http://linux-sunxi.org/NAND (Fun facts on supported NAND) http://linux-sunxi.org/MTD_Driver
https://groups.google.com/forum/#!searchin/linux-sunxi/mtd%7Csort:relevance
Boris has commit access so it's probably all there since 4.7
His work and derivatives did touch a lot of NAND/MTD drivers though.
Someone needs to crawl the linux kernel commits though or ask directly.
On Wed, May 10, 2017 at 05:05:20PM +0200, mike.valk@gmail.com wrote:
2017-05-10 16:38 GMT+02:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
On Wed, May 10, 2017 at 3:23 PM, Pablo pablo@parobalth.org wrote:
With any non-Chip-kernel you will lose NAND support. So you can either: a)patch your libre kernel or b) ignore NAND and use flash memory via usb port.
For b) you will need mainline U-Boot because NextThings U-Boot fork supports NAND but not booting via usb.
this sounds weird / not quite right. the R8 (aka A13, aka the A10) should be able to use the same sunxi 3.4.104+ kernel source as i've been using for the A20, which has the (sunxi, libre) NAND driver in it. afaik they didn't change the NAND hardware from the A10/A20 to the A13 to the R8 so this should be a non-issue.
also from what i gather there's been mainline support for the (completely different, MTD-compatible) NAND driver for quite some time, so again, should be a non-issue.
Ah, interesting. Thank you for the correction and additional input. I would be glad to be wrong here as it makes things so much easier. My knowledge is quite vague in this area and comes mainly from NextThings user forum. For example consider the following threads: https://bbs.nextthing.co/t/is-it-possible-to-boot-from-a-usb-flash-drive/309... https://bbs.nextthing.co/t/can-i-run-multiple-os-on-boot/11196/5 https://bbs.nextthing.co/t/why-c-h-i-p-has-its-own-kernel-fork/1603 https://bbs.nextthing.co/t/install-kernel-via-apt-get/2467/7 https://bbs.nextthing.co/t/ntc-improving-nand-on-linux/10526
It is quite hard to distinguish between facts, guesses and outdated information. A well maintained wiki would help to complement the user forum... *sigh*
perhaps someone could ask on #linux-sunxi and/or their mailing list for confirmation of the facts?
Sounds like a good idea. I can't do it because I lack the technical details to ask the proper questions.
Wiki says "work in progress"
http://linux-sunxi.org/Mainlining_Effort http://linux-sunxi.org/NAND (Fun facts on supported NAND) http://linux-sunxi.org/MTD_Driver
https://groups.google.com/forum/#!searchin/linux-sunxi/mtd%7Csort:relevance
Boris has commit access so it's probably all there since 4.7
His work and derivatives did touch a lot of NAND/MTD drivers though.
Someone needs to crawl the linux kernel commits though or ask directly.
Thank you for the links and details. It is a lot of new information for me. I am going to have a closer look in the next couple of days. Maybe I will run some tests on my Chip.
Pablo
Ah, interesting. Thank you for the correction and additional input. I would be glad to be wrong here as it makes things so much easier. My knowledge is quite vague in this area and comes mainly from NextThings user forum. For example consider the following threads:
If you want sound information, indeed, such forums tend to be pretty hard to use. The linux-sunxi website and mailing lists are a lot better (and a lot more technical as a consequence).
You could start from http://linux-sunxi.org/NAND
Stefan
I don't know if you know about this or not, but there is a community wiki at http://www.chip-community.org/index.php/Main_Page It has examples on using buildroot to flash images to chip http://www.chip-community.org/index.php/Flashing_Buildroot_Image_from_Ubuntu
Again, I'm clueless :P I have just received some chip pro's and I am trying to make myself a neat little MP3 player with bluetooth audio support. Found the wiki up there through some searching. This is my first foray into working with embedded linux devices as well.
On 5/12/17, Louis Pearson desttinghimgame@gmail.com wrote:
I don't know if you know about this or not, but there is a community wiki at http://www.chip-community.org/index.php/Main_Page It has examples on using buildroot to flash images to chip http://www.chip-community.org/index.php/Flashing_Buildroot_Image_from_Ubuntu
Again, I'm clueless :P I have just received some chip pro's and I am trying to make myself a neat little MP3 player with bluetooth audio support. Found the wiki up there through some searching. This is my first foray into working with embedded linux devices as well.
I knew about the wiki, then again I believe someone else was asking about one earlier. I'm still wrapping my head around these make scripts to make sure nothing proprietary is hidden anywhere they don't theoretically need to be.
Probably a good idea to use mainline libre-linux, but first want to make a diff file comparing their fork with libre to make sure their aren't any drivers which are libre that we might need (or any bug-fixes). Unfortunately their aren't any overtly libre forks of u-boot, however I don't know that their are necessarily any blobs in mainline u-boot or ntc's fork. I looked into libreboot and their support of arm is hazzy at best (one chromebook that it looks like two people ported it over to completely on their own).
Best bet is to use libre-linux mainline and besides that just attempt to deblob ntc's components by hand, which shouldn't be a problem long term cause it doesn't look like they maintain any of this stuff at all anyway and it's very likely the only blobs are in the kernel anyway however not a sure one.
This is a quite late reply to some Emails on this list from May. I took some time to research and test. John, do you still work on liberating Pocketchip?
Good news is that I managed to install Debian Stretch (current stable) with Debian Installer on a USB-stick. The CHIP OS based on Debian by NextThing is completely left alone. I plan to write a tutorial to document my approach and will put it on the Debian Wiki.
On Sat, May 13, 2017 at 01:13:39AM -0400, John Luke Gibson wrote:
On 5/12/17, Louis Pearson desttinghimgame@gmail.com wrote:
I don't know if you know about this or not, but there is a community wiki at http://www.chip-community.org/index.php/Main_Page It has examples on using buildroot to flash images to chip http://www.chip-community.org/index.php/Flashing_Buildroot_Image_from_Ubuntu
I knew about the community wiki. In my opinion Chip has a great, friendly and helpful community. I am not going to blame the community - especially because I have not yet found the time to contribute to the community wiki. My critique was directed at the manufacturer NextThing Co.
John mentioned that he will have a look at the kernel first and later at U-boot. I have found some additional documents. To replace the existing kernel there is no need to reflash. A very good tutorial can be found here: http://www.raspibo.org/wiki/index.php/Compile_the_Linux_kernel_for_Chip:_my_...
...and also a way to test a new kernel in a save way. Keep your USB-to-serial-cable ready in case things go wrong: http://www.raspibo.org/wiki/index.php/Chip9%24_U-Boot:_how_to_test_a_new_ker...
Found the wiki up there through some searching. This is my first foray into working with embedded linux devices as well.
I knew about the wiki, then again I believe someone else was asking about one earlier.
Yes, it was me.
I'm still wrapping my head around these make scripts to make sure nothing proprietary is hidden anywhere they don't theoretically need to be. Probably a good idea to use mainline libre-linux, but first want to make a diff file comparing their fork with libre to make sure their aren't any drivers which are libre that we might need (or any bug-fixes).
There is a deblob script used by Parabola Linux to liberate a mainline kernel. It is used to create a libre-linux kernel from mainline.
Best bet is to use libre-linux mainline and besides that just attempt to deblob ntc's components by hand, which shouldn't be a problem long term cause it doesn't look like they maintain any of this stuff at all anyway and it's very likely the only blobs are in the kernel anyway however not a sure one.
I ditched all the custom NTC stuff and went for vanilla Debian. I have managed to install Debian Stretch (current Stable) on a USB stick using Debian Installer. I am using a self-compiled mainline U-Boot via sunxi-fel to circumvent the U-Boot version on NAND provided by the manufacturer which can not boot from USB. I had some problems to boot the rootfs after completing installation and solved it with help from the debian-arm mailing list (see this thread for additional information: https://lists.debian.org/debian-arm/2017/06/msg00027.html) I am only using Debians main repos and connect to the Internet via USB-OTG with the g_ether kernel module and a network bridge on my desktop. This is libre enough for me. I am running Chip headless via ssh and have not tested video and sound yet. There may be some hidden quirks I am not yet aware of but so far it looks good.
kind regards Pablo
Pablo pablo@parobalth.org:
Probably a good idea to use mainline libre-linux, but first want to make a diff file comparing their fork with libre to make sure their aren't any drivers which are libre that we might need (or any bug-fixes).
There is a deblob script used by Parabola Linux to liberate a mainline kernel. It is used to create a libre-linux kernel from mainline.
just chiming in to clarify that Parabola actually uses Linux-libre as provided by the FSFLA. they're the ones maintaining and running the deblob script and we just grab their pre-cleaned sources. needless to say, nothing prevents you or us from applying the script to linux mainline ourselves.
i'm not familiar with Debian, but i've heard a number of times that their kernel (and rest of the system indeed) is also equally clean by default.
On Thu, Jul 06, 2017 at 06:01:42PM -0500, Isaac David wrote:
Pablo pablo@parobalth.org:
There is a deblob script used by Parabola Linux to liberate a mainline kernel. It is used to create a libre-linux kernel from mainline.
just chiming in to clarify that Parabola actually uses Linux-libre as provided by the FSFLA. they're the ones maintaining and running the deblob script and we just grab their pre-cleaned sources. needless to say, nothing prevents you or us from applying the script to linux mainline ourselves.
Thank you for correcting my error and giving proper credit to the FSFLA. I even visited the homepage of FSFLA a few weeks ago and took a look at the deblop script but did not get that Parabola uses the pre-cleaned sources provided by the FSFLA.
kind regards Pablo
On Thu, 6 Jul 2017 13:21:56 +0200 pablo@parobalth.org wrote:
This is a quite late reply to some Emails on this list from May. I took some time to research and test. John, do you still work on liberating Pocketchip?
Good news is that I managed to install Debian Stretch (current stable) with Debian Installer on a USB-stick. The CHIP OS based on Debian by NextThing is completely left alone. I plan to write a tutorial to document my approach and will put it on the Debian Wiki.
Please pass us a link when you do so.
<snip>
On Sat, May 13, 2017 at 01:13:39AM -0400, John Luke Gibson wrote:
I'm still wrapping my head around these make scripts to make sure nothing proprietary is hidden anywhere they don't theoretically need to be. Probably a good idea to use mainline libre-linux, but first want to make a diff file comparing their fork with libre to make sure their aren't any drivers which are libre that we might need (or any bug-fixes).
There is a deblob script used by Parabola Linux to liberate a mainline kernel. It is used to create a libre-linux kernel from mainline.
Actually, my PC has a kernel fault (It's a long story of ntc's evil doing), and the Linux kernel claims that it is not tainted. I don't know if that covers firmware, but at least there are no modules that are non-free.
Best bet is to use libre-linux mainline and besides that just attempt to deblob ntc's components by hand, which shouldn't be a problem long term cause it doesn't look like they maintain any of this stuff at all anyway and it's very likely the only blobs are in the kernel anyway however not a sure one.
I ditched all the custom NTC stuff and went for vanilla Debian. I have managed to install Debian Stretch (current Stable) on a USB stick using Debian Installer. I am using a self-compiled mainline U-Boot via sunxi-fel to circumvent the U-Boot version on NAND provided by the manufacturer which can not boot from USB.
<snip>
I've found two faults that cannot be traced without a postmortem and I'm really sick of accidentally causing this thing to manifest said problems and then loosing all the work that I did in between my backup periods. I'm in need of a way to boot PC without flashing the NAND I there a way to do this? So far my search results have been unsuccessful.
Thanks, David
On Fri, Jul 07, 2017 at 06:19:29PM -0400, David Niklas wrote:
On Thu, 6 Jul 2017 13:21:56 +0200
Actually, my PC has a kernel fault
It took me a moment to guess that you abbreviate PocketChip as "PC". My mind went like: "What? Why is he talking about his Personal Computer now?" :)
(It's a long story of ntc's evil doing),
Why do you believe that ntc is evil?
and the Linux kernel claims that it is not tainted. I don't know if that covers firmware, but at least there are no modules that are non-free.
I don't understand the paragraph above. Do you talk about mainline linux kernel, ntc's kernel fork for Chip, ... Can you please clarify?
Best bet is to use libre-linux mainline and besides that just attempt to deblob ntc's components by hand, which shouldn't be a problem long term cause it doesn't look like they maintain any of this stuff at all anyway and it's very likely the only blobs are in the kernel anyway however not a sure one.
I ditched all the custom NTC stuff and went for vanilla Debian. I have managed to install Debian Stretch (current Stable) on a USB stick using Debian Installer. I am using a self-compiled mainline U-Boot via sunxi-fel to circumvent the U-Boot version on NAND provided by the manufacturer which can not boot from USB.
<snip>
I've found two faults that cannot be traced without a postmortem and I'm really sick of accidentally causing this thing to manifest said problems and then loosing all the work that I did in between my backup periods.
How can you be sure it is a kernel bug and not another problem? Can you give us some details. Did you ask on ntc's user forum or did you file a bug report Can't you improve you backup strategy - for example commit to an external git repo; or synchronize with another stable working computer?
I'm in need of a way to boot PC without flashing the NAND I there a way to do this? So far my search results have been unsuccessful.
1. Well, you can take your Chip out of the housing and install the distro of you choice on a USB-stick and use it as a regular Chip.
2. Can you get PocketChip into fel-mode without taking it out of the enclosure? Ntc's documentation claims it is not possible but there is a forum thread about a reboot option into fel-mode. I have no PoketChip and leave it up to you to research the answers to this questions.
Another point is if the distro of you choice on a USB-stick will support PocketChips hardware (e.g. Keyboard, LCD-Screen) out of the box. Do you have a serial-to-usb-cable to interact with PocketChip?
kind regards Pablo
On Tue, 11 Jul 2017 12:10:21 +0200 Pablo Rath pablo@parobalth.org wrote:
On Fri, Jul 07, 2017 at 06:19:29PM -0400, David Niklas wrote:
On Thu, 6 Jul 2017 13:21:56 +0200
Actually, my PC has a kernel fault
It took me a moment to guess that you abbreviate PocketChip as "PC". My mind went like: "What? Why is he talking about his Personal Computer now?" :)
The pocketchip community uses that abbreviation frequently, it confuses me sometimes too.
(It's a long story of ntc's evil doing),
Why do you believe that ntc is evil?
When you boot a normal Linux computer you are presented with a plymouth boot screen and can hit escape to exit and see the boot messages. I pocketchip's case you are presented (serendipity), with a boot screen that somehow references a file listed in /home/chip (I forget the exact name, it starts with a period), that invokes feh on pocketchip's logo boot screen from which there is no escape. If you uninstall plymouth and delete the file that invokes feh in /home/chip you are just presented with a black screen. Once pocketchip finishes booting you cannot use Alt-F[0-9][0-9] to switch tty's, nor can you use Ctrl-Alt-F[0-9][0-9], so if the boot fails for any reason you are stuck with never being able to fix or diagnose it (though you might get the last few messages of some error, which you might have read in full if the screen was not black). I asked in to forums about how to solve this and it's been weeks without any answer (I only ever got one, and that user told me not to side load software (which I explained that I never did or even thought of)).
and the Linux kernel claims that it is not tainted. I don't know if that covers firmware, but at least there are no modules that are non-free.
I don't understand the paragraph above. Do you talk about mainline linux kernel, ntc's kernel fork for Chip, ... Can you please clarify?
The kernel is the default and it's name is: 4.4.13 ntc mlc
Best bet is to use libre-linux mainline and besides that just attempt to deblob ntc's components by hand, which shouldn't be a problem long term cause it doesn't look like they maintain any of this stuff at all anyway and it's very likely the only blobs are in the kernel anyway however not a sure one.
I ditched all the custom NTC stuff and went for vanilla Debian. I have managed to install Debian Stretch (current Stable) on a USB stick using Debian Installer. I am using a self-compiled mainline U-Boot via sunxi-fel to circumvent the U-Boot version on NAND provided by the manufacturer which can not boot from USB.
<snip>
I've found two faults that cannot be traced without a postmortem and I'm really sick of accidentally causing this thing to manifest said problems and then loosing all the work that I did in between my backup periods.
How can you be sure it is a kernel bug and not another problem?
Can't, that's why I'm in this predicament. All I know is the last few messages that say that the kernel is not syncing with the rootfs (and I have not touched the partition table, or init, or those scripts and files (like fstab), which would alter the mounting process).
Can you give us some details. Did you ask on ntc's user forum or did you file a bug report
2. Asked on the forum (I was a bit exasperated at the time since FLOSS software is no good to me if I can't debug it). Here are the post (hmm, seems that email notification of new replies is not working: https://bbs.nextthing.co/t/pocketchip-boots-to-black-screen/14643 https://bbs.nextthing.co/t/kernel-panic-not-syncing/17525
Can't you improve you backup strategy - for example commit to an external git repo; or synchronize with another stable working computer?
3. Not really. I use pocketchip on-the-go and typically what I'm doing on the go is offline and I'm physically separated from my other machines.
I'm in need of a way to boot PC without flashing the NAND I there a way to do this? So far my search results have been unsuccessful.
- Well, you can take your Chip out of the housing and install the
distro of you choice on a USB-stick and use it as a regular Chip.
I thought chip could not boot via usb?
- Can you get PocketChip into fel-mode without taking it out of the
enclosure? Ntc's documentation claims it is not possible but there is a forum thread about a reboot option into fel-mode. I have no PoketChip and leave it up to you to research the answers to this questions.
I think I could but then what? I know repetitively little about FEL mode (though I'm willing to learn).
Another point is if the distro of you choice on a USB-stick will support PocketChips hardware (e.g. Keyboard, LCD-Screen) out of the box. Do you have a serial-to-usb-cable to interact with PocketChip?
I don't think so. But it's confusing when people write things like that because USB stands for Universal *Serial* Bus (so USB is a serial cable and no conversion is needed!).
kind regards Pablo
Thanks Pablo, David t
On Fri, Jul 28, 2017 at 11:08:16AM -0400, doark@mail.com wrote:
On Tue, 11 Jul 2017 12:10:21 +0200 Pablo Rath pablo@parobalth.org wrote:
On Fri, Jul 07, 2017 at 06:19:29PM -0400, David Niklas wrote:
On Thu, 6 Jul 2017 13:21:56 +0200
Actually, my PC has a kernel fault
...
(It's a long story of ntc's evil doing),
Why do you believe that ntc is evil?
When you boot a normal Linux computer you are presented with a plymouth boot screen and can hit escape to exit and see the boot messages. I pocketchip's case you are presented (serendipity), with a boot screen that somehow references a file listed in /home/chip (I forget the exact name, it starts with a period), that invokes feh on pocketchip's logo boot screen from which there is no escape. If you uninstall plymouth and delete the file that invokes feh in /home/chip you are just presented with a black screen. Once pocketchip finishes booting you cannot use Alt-F[0-9][0-9] to switch tty's, nor can you use Ctrl-Alt-F[0-9][0-9], so if the boot fails for any reason you are stuck with never being able to fix or diagnose it (though you might get the last few messages of some error, which you might have read in full if the screen was not black). I asked in to forums about how to solve this and it's been weeks without any answer (I only ever got one, and that user told me not to side load software (which I explained that I never did or even thought of)).
I still don't get why you believe that ntc is evil. In my opinion they are not evil just because the configured PocketChip like you described. Boot messages are small and scroll fast anyway so they would probably don't help you much.
...
I've found two faults that cannot be traced without a postmortem and I'm really sick of accidentally causing this thing to manifest said problems and then loosing all the work that I did in between my backup periods.
How can you be sure it is a kernel bug and not another problem?
Can't, that's why I'm in this predicament. All I know is the last few messages that say that the kernel is not syncing with the rootfs (and I have not touched the partition table, or init, or those scripts and files (like fstab), which would alter the mounting process).
Can you give us some details. Did you ask on ntc's user forum or did you file a bug report
- Asked on the forum (I was a bit exasperated at the time since FLOSS
software is no good to me if I can't debug it).
I know it sucks to have an obscure computer problem you can not immediately solve but you should not put the blame on FLOSS. It can be a bug, a wrong config, something you did...
Here are the post (hmm, seems that email notification of new replies is not working: https://bbs.nextthing.co/t/pocketchip-boots-to-black-screen/14643 https://bbs.nextthing.co/t/kernel-panic-not-syncing/17525
User "zwack" gave you good advice to use UART-serial connection. Basically you connect your PocketChip with another computer and can read boot messages there. You will even be able to interact with U-Boot before booting.
...
I'm in need of a way to boot PC without flashing the NAND I there a way to do this? So far my search results have been unsuccessful.
- Well, you can take your Chip out of the housing and install the
distro of you choice on a USB-stick and use it as a regular Chip.
I thought chip could not boot via usb?
It is possible altough currently a bit quirky. Have you read my previous email on this list and the linked thread on debian-arm mailing list?
- Can you get PocketChip into fel-mode without taking it out of the
enclosure? Ntc's documentation claims it is not possible but there is a forum thread about a reboot option into fel-mode. I have no PoketChip and leave it up to you to research the answers to this questions.
I think I could but then what? I know repetitively little about FEL mode (though I'm willing to learn).
Please read my previous email on this list. Basically you put PocketChip into fel-mode and connect it with another computer. You can then use a "special" version of U-Boot via fel and boot an OS on USB or Debian Installer on USB.
Another point is if the distro of you choice on a USB-stick will support PocketChips hardware (e.g. Keyboard, LCD-Screen) out of the box. Do you have a serial-to-usb-cable to interact with PocketChip?
I don't think so. But it's confusing when people write things like that because USB stands for Universal *Serial* Bus (so USB is a serial cable and no conversion is needed!).
I meant a USB TTL Serial cable (USB to serial converter cables) providing a connection between USB and serial UART interfaces. You should get one as it seems necessary to debug your problems.
kind regards Pablo
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Thu, Aug 3, 2017 at 9:38 PM, Pablo Rath pablo@parobalth.org wrote:
On Fri, Jul 28, 2017 at 11:08:16AM -0400, doark@mail.com wrote:
I asked in to forums about how to solve this and it's been weeks without any answer (I only ever got one, and that user told me not to side load software (which I explained that I never did or even thought of)).
I still don't get why you believe that ntc is evil. In my opinion they are not evil just because the configured PocketChip like you described.
i concur. they're a group of enterprising people who have utilised one of the lowest-cost china SoCs with an extremely high libre reputation, thanks to the sunxi community's work about five years ago.
Please read my previous email on this list. Basically you put PocketChip into fel-mode and connect it with another computer. You can then use a "special" version of U-Boot via fel and boot an OS on USB or Debian Installer on USB.
i've done this a lot. it's my primary method of development and debugging. i upload the FEL sub-16k loader to initialise the SoC's DDR3 RAM, then upload u-boot directly into the DDR3 RAM, then ask FEL to *execute* u-boot directly in RAM.
in the past i've even loaded an entire kernel *and initrd* into memory over FEL - that takes a while but it can take less time than having to insert and remove micro-sd cards (and rewrite them, and mount them, and blah blah).
you cannot expect companies to drop everything and help just you. you're just one person: you're expected to work these things out for yourself.
now, if you were placing an order for ten THOUSAND *then* they might be interested.
l.
2017-08-04 8:17 GMT+02:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
you cannot expect companies to drop everything and help just you. you're just one person: you're expected to work these things out for yourself.
now, if you were placing an order for ten THOUSAND *then* they might be interested.
Well they've announced the CHIP to be more open and supported than actually delivered.
Now that is unfortunately common practice. And due to experiences in the past, Poulsbo, Andriod, I already knew that they would not be able to deliver that, especially at that price point. Hey they even promised opensource 3d graphics if the crowdfunding was successful enough, if I recall correctly.
But that is just us. That might not, and probably is, be true for a lot of their customers, like David. That's we're the evil lies I think. Announcing a "libre" computer but fail to follow it through. Yes there is open source software for you to use, yes there schematics.
But from what I've learned, a lot of it here on the list and from you Luke. That's not enough.
There needs to be a reproducible process and clearly state what is open and what is not.
l.
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
On Fri, Aug 04, 2017 at 10:17:22AM +0200, mike.valk@gmail.com wrote:
Well they've announced the CHIP to be more open and supported than actually delivered.
Now that is unfortunately common practice. And due to experiences in the past, Poulsbo, Andriod, I already knew that they would not be able to deliver that, especially at that price point. Hey they even promised opensource 3d graphics if the crowdfunding was successful enough, if I recall correctly.
But that is just us. That might not, and probably is, be true for a lot of their customers, like David. That's we're the evil lies I think. Announcing a "libre" computer but fail to follow it through. Yes there is open source software for you to use, yes there schematics.
Please correct me if I am wrong but I am pretty sure they did not announce a "libre" computer. They use the term "open source" and "very open source" on their kickstarter page. People in the "Open Source Camp" seem to be more inclined to accept a very open source system with proprietary wifi.
kind regards Pablo
2017-08-08 12:11 GMT+02:00 Pablo Rath pablo@parobalth.org:
On Fri, Aug 04, 2017 at 10:17:22AM +0200, mike.valk@gmail.com wrote:
Well they've announced the CHIP to be more open and supported than actually delivered.
Now that is unfortunately common practice. And due to experiences in the past, Poulsbo, Andriod, I already knew that they would not be able to deliver that, especially at that price point. Hey they even promised opensource 3d graphics if the crowdfunding was successful enough, if I recall correctly.
But that is just us. That might not, and probably is, be true for a lot of their customers, like David. That's we're the evil lies I think. Announcing a "libre" computer but fail to follow it through. Yes there is open source software for you to use, yes there schematics.
Please correct me if I am wrong but I am pretty sure they did not announce a "libre" computer. They use the term "open source" and "very open source" on their kickstarter page. People in the "Open Source Camp" seem to be more inclined to accept a very open source system with proprietary wifi.
The term libre is somewhat new. The average joe knows about open source these days. But if I drop the libre keyword they don't understand.
And they did not get to "very open" in my opinion. But the level op openness should be stated more clearly.
As it is the system for all functionality is tied to a 3.4 kernel and fixed X11 version display stack. Or Android.
So for all the openness upgrading is neigh impossible. As is running a generic Linux distribution.
So in my opinion opensource means that you can upgrade and the every bit can be mainlined.
Firmware, however evil in it's own right, is independent on the OS software stack and thus does not impair upgrading or switching OS and/or OS versions. So hence the general acceptance I guess.
The MALI GPU requires a closed source driver dependent on the OS stack. Thus locking you in place.
The Cedar VPU requires a closed source driver dependent on the OS stack. Thus locking you in place. That situation, again no thanks to NTC, is improving, albeit slowly.
Thankfully display drivers (That's not the GPU. So no 2d or 3d acceleration!) are available or worked on. But no help from NTC.
So on paper nothing better than a Intel GMA500 (Poulsbo/PowerVR). E.g. a Dell mini 1010 sold with Ubuntu, the trap I fell into, Three Ubuntu iterations further and that was it for that Laptop.
When announcing an open source system. Companies should be very clear on what they are selling. Does it include firmware? (Acceptable ?) Does it include closed source drivers? (That limits upgradablity and usefull lifetime) Do you provide a complete stack, Source, Compile chain, Documentation? Do you provide schematics? Do you provide a BoM? Do you provide comprehensive component documentation free of NDA's? etc.
Simply saying "we're selling an opensource system" is a farce. That's too broad.
kind regards 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
On Tue, Aug 8, 2017 at 2:57 PM, mike.valk@gmail.com mike.valk@gmail.com wrote:
The Cedar VPU requires a closed source driver dependent
you mean a criminally-infringing library which has at the very least stolen copyright code from ffmpeg confirmed (not a "closed source" driver).
on the OS stack. Thus locking you in place. That situation, again no thanks to NTC, is improving, albeit slowly.
libcedrus has been around and working for a long, long time on the A13 / R8 / GR8 (all the same SoC). it also works on the A20 and i had full 1080p video playback fully operational back in august 2016. so i know it's a fully libre video stack.
l.
2017-08-08 16:28 GMT+02:00 Luke Kenneth Casson Leighton lkcl@lkcl.net:
On Tue, Aug 8, 2017 at 2:57 PM, mike.valk@gmail.com mike.valk@gmail.com wrote:
The Cedar VPU requires a closed source driver dependent
you mean a criminally-infringing library which has at the very least stolen copyright code from ffmpeg confirmed (not a "closed source" driver).
:-) yep that one! And the driver source, while constructed out of gpl software, was never released. And thus still closed software. Illegal, gpl violating, but closed. Their attempt to rectify was to create a open source stub driver and a closed source userspace part, consisting of obfuscated FFMPEG code. [1]
Luc Verhagen, et al. explained and barked loudly at Allwinner on what they had to do to rectify. But I guess the IP owner of cedarx is not AllWinner. And their vendor, the IP owner, the original infringer, did not give them permission to rectify properly. Or something else. [1]
on the OS stack. Thus locking you in place. That situation, again no thanks to NTC, is improving, albeit slowly.
libcedrus has been around and working for a long, long time on the A13 / R8 / GR8 (all the same SoC). it also works on the A20 and i had full 1080p video playback fully operational back in august 2016. so i know it's a fully libre video stack.
sunxi-vdpau is open source but it is a hack. An unsafe one! [3] sunxi-cedrus is not ready for primetime last time I checked. V4L is slow to accept the needed changes.[2]
[1] http://linux-sunxi.org/CedarX [2] http://linux-sunxi.org/Cedrus [3] http://linux-sunxi.org/Cedrus/libvdpau-sunxi
On 7/6/17, Pablo pablo@parobalth.org wrote:
This is a quite late reply to some Emails on this list from May. I took some time to research and test. John, do you still work on liberating Pocketchip?
Got distracted trying to install parabola on an asus c201 (nothing can write a sane gpt header to emmc it seems). Actually learned about the deblob scripts seeing a script use them on the chrome kernel, so I was thinking about running deblob in a u-boot directory and seeing what happens.
My understanding (which isn't too reliable) is that the universal in universal bootloader is that u-boot handles some operations that would normally be handled by linux, including passing microcode and handling some firmware.
Good news is that I managed to install Debian Stretch (current stable) with Debian Installer on a USB-stick. The CHIP OS based on Debian by NextThing is completely left alone. I plan to write a tutorial to document my approach and will put it on the Debian Wiki.
Yeah!
I knew about the wiki, then again I believe someone else was asking about one earlier.
Yes, it was me.
heh.. Sorry ,xD I didn't know the exact url by heart and never got around to posting it on da list as a ref later.
I ditched all the custom NTC stuff and went for vanilla Debian. I have managed to install Debian Stretch (current Stable) on a USB stick using Debian Installer. I am using a self-compiled mainline U-Boot via sunxi-fel to circumvent the U-Boot version on NAND provided by the manufacturer which can not boot from USB.
I'm not sure if you mean version "of" NAND, but otherwise it sounds like your saying they hardcoded it not boot that way? Feature-not-a-bug?
I had some problems to boot the rootfs after completing installation and solved it with help from the debian-arm mailing list (see this thread for additional information: https://lists.debian.org/debian-arm/2017/06/msg00027.html) I am only using Debians main repos and connect to the Internet via USB-OTG with the g_ether kernel module and a network bridge on my desktop.
That whole thing sounds like it was painful to get operating.
This is libre enough for me. I am running Chip headless via ssh and have not tested video and sound yet. There may be some hidden quirks I am not yet aware of but so far it looks good.
I would be very interested to know if GPIO functions okay like that.
kudos Pablo!
On Mon, Jul 10, 2017 at 06:34:39AM -0400, Jean Flamelle wrote:
Actually learned about the deblob scripts seeing a script use them on the chrome kernel, so I was thinking about running deblob in a u-boot directory and seeing what happens.
My guess is that nothing useful is going to happen because there is a deblob script tailored for every kernel release. I would be quite surprised if it works on the source of a completely unrelated project. But I have been wrong before so go ahead if you want and tell us what happens.
I ditched all the custom NTC stuff and went for vanilla Debian. I have managed to install Debian Stretch (current Stable) on a USB stick using Debian Installer. I am using a self-compiled mainline U-Boot via sunxi-fel to circumvent the U-Boot version on NAND provided by the manufacturer which can not boot from USB.
I'm not sure if you mean version "of" NAND, but otherwise it sounds like your saying they hardcoded it not boot that way? Feature-not-a-bug?
I have to admit that I don't understand your first question probably because I am not a native speaker. Is "of NAND" or "on NAND" a semantic or a technical question? I think NextThing forked U-Boot before USB boot went mainline. I remember a forum thread where someone from NextThing wrote there are two options; first to backport USB boot into NextThings U-Boot fork or second to wait until certain features of NextThings U-Boot are mainlined. So in my opinion feature-not-a-bug is not the case here.
I had some problems to boot the rootfs after completing installation and solved it with help from the debian-arm mailing list (see this thread for additional information: https://lists.debian.org/debian-arm/2017/06/msg00027.html) I am only using Debians main repos and connect to the Internet via USB-OTG with the g_ether kernel module and a network bridge on my desktop.
That whole thing sounds like it was painful to get operating.
I don't give up easily. It was more like solving a puzzle where all parts fit once you have gotten them out of several different boxes. I did not write a single line of code so I am standing on the shoulders of giants (linux-sunxi community, debian developers, U-Boot developers).
I am running Chip headless via ssh and have not tested video and sound yet. There may be some hidden quirks I am not yet aware of but so far it looks good.
I would be very interested to know if GPIO functions okay like that.
Do you have an easy test to verify GPIO functions?
kudos Pablo!
Thank you!
kind regards Pablo
On Thu, May 11, 2017 at 04:48:28PM -0400, Stefan Monnier wrote:
If you want sound information, indeed, such forums tend to be pretty hard to use. The linux-sunxi website and mailing lists are a lot better (and a lot more technical as a consequence).
Thank you for the recommendations, Stefan. I am now subscribed to the linux-sunxi mailing list.
Pablo
arm-netbook@lists.phcomp.co.uk
-
Allan Mwenda -
Benson Mitchell -
Bill Kontos -
David Boddie -
David Niklas -
doark＠mail.com
-
Isaac David -
Jean Flamelle -
Jeffrey Sites -
John Luke Gibson
-
Louis Pearson -
Luke Kenneth Casson Leighton -
mike.valk＠gmail.com -
Pablo -
Pablo Rath
-
Philip Hands -
Stefan Monnier