[Arm-netbook] Side-Topic: Liberating PocketCHIP

[John Luke Gibson]

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

Date: Sat, 29 Oct 2016 20:13:10 +0200
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 [...]"
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-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send la

[Bill Kontos]

Why is there an intel blob on the chip. I didn't know there was intel ip in
there.

Post by John Luke Gibson
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

Date: Sat, 29 Oct 2016 20:13:10 +0200
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 [...]"
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
https://github.com/linux-sunxi/u-boot-sunxi/search?q=blob
"# 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.
_______________________________________________
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook

[John Luke Gibson]

Post by Bill Kontos
Why is there an intel blob on the chip. I didn't know there was intel ip in
there.

Post by John Luke Gibson
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

Date: Sat, 29 Oct 2016 20:13:10 +0200
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 [...]"
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
https://github.com/linux-sunxi/u-boot-sunxi/search?q=blob
"# 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.
_______________________________________________
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook

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/fd2ad2582c7fb4a5fedff5ac19ca37d138df3963/drivers/net/wireless/ipw2x00/ipw2100.c

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.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netboo

[David Boddie]

Post by John Luke Gibson
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

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send l

[m***@gmail.com]

Post by John Luke Gibson
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.

Post by John Luke Gibson
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

Date: Sat, 29 Oct 2016 20:13:10 +0200
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 [...]"
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
https://github.com/linux-sunxi/u-boot-sunxi/search?q=blob
"# 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.

Post by John Luke Gibson
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.
_______________________________________________
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

Post by m***@gmail.com
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
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-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb

[John Luke Gibson]

Post by Luke Kenneth Casson Leighton
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

Post by m***@gmail.com
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
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.
_______________________________________________
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook

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.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large at

[Pablo]

Post by John Luke Gibson
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!

Post by John Luke Gibson
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
https://github.com/linux-sunxi/u-boot-sunxi/search?q=blob

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

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-ne

[Luke Kenneth Casson Leighton]

Post by Pablo
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.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Se

[Pablo]

Post by Luke Kenneth Casson Leighton

Post by Pablo
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.

Post by Luke Kenneth Casson Leighton
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-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachm

[John Luke Gibson]

Post by Pablo

Post by Luke Kenneth Casson Leighton

Post by Pablo
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
https://bbs.nextthing.co/t/chip-flasher-on-github/5561/10
So it seems I have been correct and it is proprietary.

Post by Luke Kenneth Casson Leighton
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
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.
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
_______________________________________________
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook

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)

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook

[Jeffrey Sites]

---
jasites

Post by John Luke Gibson

Post by Pablo

Post by Luke Kenneth Casson Leighton

Post by Pablo
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
https://bbs.nextthing.co/t/chip-flasher-on-github/5561/10
So it seems I have been correct and it is proprietary.

Post by Luke Kenneth Casson Leighton
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
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.
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
_______________________________________________
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook

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.

Post by John Luke Gibson
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
printf '%s%s' -g $head
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)
_______________________________________________
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netbook@

[Pablo]

Post by Jeffrey Sites

Post by John Luke Gibson
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

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcomp.

[Jeffrey Sites]

---
jasites

Post by Pablo

Post by Jeffrey Sites

Post by John Luke Gibson
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.

Post by Pablo
As a general purpose OS one of the libre distributions or Debian with
only the main repository seems the way to go.
Pablo
_______________________________________________
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send la

[John Luke Gibson]

Post by John Luke Gibson
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
printf '%s%s' -g $head
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-ER922AA-ABA-SR1834NX-NA660:~/Documents/Code/OperationDaBlob/chip-buildroot+subsidiaries/CHIP-buildroot$
if head='git rev-parse --verify --short HEAD 2>/dev/null'; then

Post by John Luke Gibson
echo $head;
else
echo "failed";
fi

git rev-parse --verify --short HEAD 2>/dev/null
***@john-ER922AA-ABA-SR1834NX-NA660:~/Documents/Code/OperationDaBlob/chip-buildroot+subsidiaries/CHIP-buildroot$
#!/bin/bash
***@john-ER922AA-ABA-SR1834NX-NA660:~/Documents/Code/OperationDaBlob/chip-buildroot+subsidiaries/CHIP-buildroot$
# your code goes here
***@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

Post by John Luke Gibson
echo $head;
else
echo "failed";
fi

b52c25c
***@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.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large at

[John Luke Gibson]

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.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large att

[Philip Hands]

Post by John Luke Gibson

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_02_06_03

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.

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

Post by John Luke Gibson
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-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcomp.co.u

[Allan Mwenda]

Free Software Foundation Latin America Linux-Libre.

Post by Luke Kenneth Casson Leighton
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Wed, May 10, 2017 at 12:00 AM, John Luke Gibson

Post by John Luke Gibson
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.
_______________________________________________
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook

[Pablo]

Post by Allan Mwenda

Post by Luke Kenneth Casson Leighton

Post by Luke Kenneth Casson Leighton
On Wed, May 10, 2017 at 12:00 AM, John Luke Gibson
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.

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

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netbook@

[Luke Kenneth Casson Leighton]

Post by Pablo
With any non-Chip-kernel you will lose NAND support.
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.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@fil

[m***@gmail.com]

Post by Luke Kenneth Casson Leighton

Post by Pablo
With any non-Chip-kernel you will lose NAND support.
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.

[Pablo]

Post by m***@gmail.com

Post by Luke Kenneth Casson Leighton

Post by Pablo
With any non-Chip-kernel you will lose NAND support.
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/3090/15
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*

Post by m***@gmail.com

Post by Luke Kenneth Casson Leighton
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.

Post by m***@gmail.com
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

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcomp.co

[Stefan Monnier]

Post by 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

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


_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcomp.

[Louis Pearson]

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.

[John Luke Gibson]

Post by Louis Pearson
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.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook

[Pablo]

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.

Post by John Luke Gibson

Post by Louis Pearson
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_personal_HOWTO#My_config_file

...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_kernel_%28in_a_safe_way%29

Post by John Luke Gibson

Post by Louis Pearson
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.

Post by John Luke Gibson
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.

Post by John Luke Gibson
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

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.

[Isaac David]

Post by Pablo

Post by John Luke Gibson
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.
--
Isaac David
GPG: 38D33EF29A7691134357648733466E12EC7BA943
Tox:
0C730E0156E96E6193A1445D413557FF5F277BA969A4EA20AC9352889D3B390E77651E816F0C


_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.ph

[Pablo Rath]

Post by Isaac David

Post by Pablo
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

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook

[David Niklas]

On Thu, 6 Jul 2017 13:21:56 +0200

Post by Pablo
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>

Post by Pablo

Post by John Luke Gibson
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.

Post by Pablo

Post by John Luke Gibson
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


_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attac

[Pablo Rath]

Post by David Niklas
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?" :)

Post by David Niklas
(It's a long story of ntc's evil
doing),

Why do you believe that ntc is evil?

Post by David Niklas
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?

Post by David Niklas

Post by Pablo

Post by John Luke Gibson
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?

Post by David Niklas
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

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcomp

[d***@mail.com]

On Tue, 11 Jul 2017 12:10:21 +0200

Post by Pablo Rath

Post by David Niklas
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.

Post by Pablo Rath

Post by David Niklas
(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)).

Post by Pablo Rath

Post by David Niklas
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

Post by Pablo Rath

Post by David Niklas

Post by Pablo

Post by John Luke Gibson
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).

Post by Pablo Rath
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

Post by Pablo Rath
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.

Post by Pablo Rath

Post by David Niklas
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.

I thought chip could not boot via usb?

Post by Pablo Rath
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.

I think I could but then what? I know repetitively little about FEL mode
(though I'm willing to learn).

Post by Pablo Rath
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!).

Post by Pablo Rath
kind regards
Pablo

Thanks Pablo,
David
t

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@f

[Pablo Rath]

Post by d***@mail.com
On Tue, 11 Jul 2017 12:10:21 +0200

Post by Pablo Rath

Post by David Niklas
On Thu, 6 Jul 2017 13:21:56 +0200
Actually, my PC has a kernel fault

...

Post by d***@mail.com

Post by Pablo Rath

Post by David Niklas
(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.

...

Post by d***@mail.com

Post by Pablo Rath

Post by David Niklas
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).

Post by Pablo Rath
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).

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...

Post by d***@mail.com
Here are the post (hmm, seems that email notification of new replies is
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.

...

Post by d***@mail.com

Post by Pablo Rath

Post by David Niklas
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.

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?

Post by d***@mail.com

Post by Pablo Rath
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.

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.

Post by d***@mail.com

Post by Pablo Rath
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

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to ar

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

Post by Pablo Rath

Post by d***@mail.com
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.

Post by Pablo Rath
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.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@fil

[m***@gmail.com]

Post by Luke Kenneth Casson Leighton
---
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.

Post by Luke Kenneth Casson Leighton
l.
_______________________________________________
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm

[Pablo Rath]

Post by m***@gmail.com
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


_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachm

[m***@gmail.com]

Post by Pablo Rath

Post by m***@gmail.com
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.

Post by Pablo Rath
kind regards
Pablo
_______________________________________________
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachmen

[Luke Kenneth Casson Leighton]

Post by m***@gmail.com
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).

Post by m***@gmail.com
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.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netbo

[m***@gmail.com]

Post by Luke Kenneth Casson Leighton

Post by m***@gmail.com
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]

Post by Luke Kenneth Casson Leighton

Post by m***@gmail.com
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

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to ar

[Jean Flamelle]

Post by Pablo
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.

Post by Pablo
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!

Post by Pablo

Post by John Luke Gibson
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.

Post by Pablo
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?

Post by Pablo
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
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.

Post by Pablo
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!

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to ar

[Pablo Rath]

Post by Jean Flamelle
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.

Post by Jean Flamelle

Post by Pablo
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.

Post by Jean Flamelle

Post by Pablo
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
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).

Post by Jean Flamelle

Post by Pablo
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?

Post by Jean Flamelle
kudos Pablo!

Thank you!

kind regards
Pablo

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send larg

[Pablo Rath]

Post by Stefan Monnier
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 mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcomp

[d***@mail.com]

I apologize for DOS'ing the list, I can only get online about once a week.

On Thu, 4 May 2017 17:13:23 +0200

Post by m***@gmail.com

Post by John Luke Gibson
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.

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.

What? I own one of those and I'm almost certain that the CPU is an A7.
Let's boot the PocketCHIP up...
The processor is detected as an A7.
I'll attach the output, it would probably be interesting to see all of
it...
Done, it's compressed bzip2 since it's ~300KiB decompressed which is large
for an email.

<aside>
I'm not too clever with gpg yet, so please tell me if the compressed file
is also signed (I wanted to do that so that you could be certain that it
was not infected en-route like happens to MS .cab files far to
frequently (even though I don't have my key signed by anyone yet
\me grumble grumble)).
</aside>

Unless your saying that the WiFi has a built in ARM R8 (Why)? which would
really surprise me considering how large the processor chip is compared
with the WiFi chip.

Post by m***@gmail.com
If you look at
https://getchip.com/pages/chip
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.

<snip>

You're not giving us enough details. Who is Verhaegen? What did he burn
out on?
When I first considered purchasing a PocketCHiP I read about the GPU
not having 3D capabilities because of a binary blob. So, the CHIP folks
hired (I think it was an extended goal of the kickstarter campaign), a
kernel dev to add support to the Linux kernel for the GPU. I was going to
mention this on this list before, but it's been so active...

Sincerely,
David

[Luke Kenneth Casson Leighton]

Post by d***@mail.com
You're not giving us enough details. Who is Verhaegen? What did he burn
out on?

http://libv.livejournal.com/

the fact that he's not under NDA has led to large corporations -
including ARM - to enact slander campaigns against him, and blackmail
campaigns against companies that fund him.

Post by d***@mail.com
When I first considered purchasing a PocketCHiP I read about the GPU
not having 3D capabilities because of a binary blob. So, the CHIP folks
hired (I think it was an extended goal of the kickstarter campaign), a
kernel dev to add support to the Linux kernel for the GPU.

it will have been for the "shim" that permits the proprietary
userspace library direct access to the MALI hardware.

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcomp.co

[Pablo]

Post by d***@mail.com

Post by m***@gmail.com
The R8 is a rebranded A13.

What? I own one of those and I'm almost certain that the CPU is an A7.
Let's boot the PocketCHIP up...
The processor is detected as an A7.
I'll attach the output, it would probably be interesting to see all of
it...
Done, it's compressed bzip2 since it's ~300KiB decompressed which is large
for an email.

You could have pasted the relevant parts right into your email.
This was the only relevant section I could find in your output:
cpu.1: cpuinfo
----- /proc/cpuinfo -----
processor : 0
model name : ARMv7 Processor rev 2 (v7l)

ARMv7 is the architecture. I did not find "A7" in a relevant context in
your output.

Have a look at:
https://bbs.nextthing.co/t/chip-engineering-programming-links-photos/270
'A13 Specifications Brief (Allwinner states R8 is a "1GHz A13 Compatible
SoC (System on Chip)"'

and:
http://linux-sunxi.org/Allwinner_SoC_Family
http://linux-sunxi.org/R8

Pablo

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.ph

[m***@gmail.com]

Post by d***@mail.com
I apologize for DOS'ing the list, I can only get online about once a week.
On Thu, 4 May 2017 17:13:23 +0200

Post by m***@gmail.com

Post by John Luke Gibson
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.

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.

What? I own one of those and I'm almost certain that the CPU is an A7.
Let's boot the PocketCHIP up...
The processor is detected as an A7.

It should be a Cortex-A8.
http://linux-sunxi.org/Allwinner_SoC_Family

The new chip GR8, which is specific SoC for NextThingCo, seems to be an "sun5i"
as well. Also a slightly modified A13 I guess.

The're seems to but mainline support for it. Icenowy Zheng has addid it I
think. But the'res no wiki page fo it.
http://linux-sunxi.org/Linux_mainlining_effort
http://linux-sunxi.org/GR8

Post by d***@mail.com
I'll attach the output, it would probably be interesting to see all of
it...
Done, it's compressed bzip2 since it's ~300KiB decompressed which is large
for an email.

Use pastebin or sorts. Or just cut out the specifica part.

Post by d***@mail.com
Unless your saying that the WiFi has a built in ARM R8 (Why)? which would
really surprise me considering how large the processor chip is compared
with the WiFi chip.

I'm not saying that at all.The SoC is indeed the biggest IC. And the WiFi
is on the other side of the PCB. A blue piece of PCB. next the NXP209. WiFi
chips are very small.
from https://getchip.com/pages/chip:
Loading Image...

Post by d***@mail.com
You're not giving us enough details. Who is Verhaegen? What did he burn
out on?
When I first considered purchasing a PocketCHiP I read about the GPU
not having 3D capabilities because of a binary blob. So, the CHIP folks
hired (I think it was an extended goal of the kickstarter campaign), a
kernel dev to add support to the Linux kernel for the GPU.

That did not happen. The're is no Opensource linux driver for MALI. NTC
hardly involves itself with the linux-sunxi community.

Their website is hardly obvious to the software needs of running their
hardware.

How hard can it be....

"To use our hardware you have two options: Our BSP which has closed source
drivers, but you have full utilization of the hardware. Or use the mainline
kernel with some restrictions"

And state your involvement in freeing the hardware or not.

NTC website is just one big selling machine.

Post by d***@mail.com
I was going to
mention this on this list before, but it's been so active...
Sincerely,
David
_______________________________________________
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook

[Pablo]

Post by m***@gmail.com
Their website is hardly obvious to the software needs of running their
hardware.
How hard can it be....
"To use our hardware you have two options: Our BSP which has closed source
drivers, but you have full utilization of the hardware. Or use the mainline
kernel with some restrictions"
And state your involvement in freeing the hardware or not.
NTC website is just one big selling machine.

Thank you Mike! The above statement quite nicely sums up my thoughts on this topic.

Pablo

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook

[Bill Kontos]

Verhaegen is one of those selected individuals who had the luxury of
getting all the shit of the world thrown at their face for trying to do the
right thing. He was one of the leaders in pushing amd into mainlining gpu
drivers( which they have been successful to and keep working on) and got
shit for that. He attempted to reverse engineer the arm mali drivers( look
up lima driver) and he succeeded to some extend, then he run out of money
becaue nobody was willing to help him and arm has put significant effort
into destroying his life. The nda a company has to sign for getting the
mali drivers requires 0 interaction with his work, therefor no company can
hire him now.

Post by d***@mail.com
I apologize for DOS'ing the list, I can only get online about once a week.
On Thu, 4 May 2017 17:13:23 +0200

Post by m***@gmail.com

Post by John Luke Gibson
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.

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.

What? I own one of those and I'm almost certain that the CPU is an A7.
Let's boot the PocketCHIP up...
The processor is detected as an A7.
I'll attach the output, it would probably be interesting to see all of
it...
Done, it's compressed bzip2 since it's ~300KiB decompressed which is large
for an email.
<aside>
I'm not too clever with gpg yet, so please tell me if the compressed file
is also signed (I wanted to do that so that you could be certain that it
was not infected en-route like happens to MS .cab files far to
frequently (even though I don't have my key signed by anyone yet
\me grumble grumble)).
</aside>
Unless your saying that the WiFi has a built in ARM R8 (Why)? which would
really surprise me considering how large the processor chip is compared
with the WiFi chip.

Post by m***@gmail.com
If you look at
https://getchip.com/pages/chip
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.

<snip>
You're not giving us enough details. Who is Verhaegen? What did he burn
out on?
When I first considered purchasing a PocketCHiP I read about the GPU
not having 3D capabilities because of a binary blob. So, the CHIP folks
hired (I think it was an extended goal of the kickstarter campaign), a
kernel dev to add support to the Linux kernel for the GPU. I was going to
mention this on this list before, but it's been so active...
Sincerely,
David
_______________________________________________
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook

[r***@Safe-mail.net]

Is it common to do something like this against a person?

-------- Original Message --------
From: Bill Kontos <***@gmail.com>
Apparently from: arm-netbook-***@lists.phcomp.co.uk
To: Linux on small ARM machines <arm-***@lists.phcomp.co.uk>
Subject: Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP
Date: Mon, 8 May 2017 12:14:50 +0300

Verhaegen is one of those selected individuals who had the luxury of getting all the shit of the world thrown at their face for trying to do the right thing. He was one of the leaders in pushing amd into mainlining gpu drivers( which they have been successful to and keep working on) and got shit for that. He attempted to reverse engineer the arm mali drivers( look up lima driver) and he succeeded to some extend, then he run out of money becaue nobody was willing to help him and arm has put significant effort into destroying his life. The nda a company has to sign for getting the mali drivers requires 0 interaction with his work, therefor no company can hire him now.

Post by d***@mail.com
I apologize for DOS'ing the list, I can only get online about once a week.
On Thu, 4 May 2017 17:13:23 +0200

Post by m***@gmail.com

Post by John Luke Gibson
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.

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.

What? I own one of those and I'm almost certain that the CPU is an A7.
Let's boot the PocketCHIP up...
The processor is detected as an A7.
I'll attach the output, it would probably be interesting to see all of
it...
Done, it's compressed bzip2 since it's ~300KiB decompressed which is large
for an email.
<aside>
I'm not too clever with gpg yet, so please tell me if the compressed file
is also signed (I wanted to do that so that you could be certain that it
was not infected en-route like happens to MS .cab files far to
frequently (even though I don't have my key signed by anyone yet
\me grumble grumble)).
</aside>
Unless your saying that the WiFi has a built in ARM R8 (Why)? which would
really surprise me considering how large the processor chip is compared
with the WiFi chip.

Post by m***@gmail.com
If you look at
https://getchip.com/pages/chip
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.

<snip>
You're not giving us enough details. Who is Verhaegen? What did he burn
out on?
When I first considered purchasing a PocketCHiP I read about the GPU
not having 3D capabilities because of a binary blob. So, the CHIP folks
hired (I think it was an extended goal of the kickstarter campaign), a
kernel dev to add support to the Linux kernel for the GPU. I was going to
mention this on this list before, but it's been so active...
Sincerely,
David
_______________________________________________
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcomp.

[m***@gmail.com]

Don't top post please

Post by r***@Safe-mail.net
-------- Original Message --------

Post by Bill Kontos
Verhaegen is one of those selected individuals who had the luxury of

getting all the shit of the world thrown at their face for trying to do the
right thing. He was one of the leaders in pushing amd into mainlining gpu
drivers( which they have been successful to and keep working on) and got
shit for that. He attempted to reverse engineer the arm mali drivers( look
up lima driver) and he succeeded to some extend, then he run out of money
becaue nobody was willing to help him and arm has put significant effort
into destroying his life. The nda a company has to sign for getting the
mali drivers requires 0 interaction with his work, therefor no company can
hire him now.

"Is it common to do something like this against a person?"

No but not uncommon as well. Luc pressed were it hurts and Luc has a
somewhat unfiltered personalty. Manager etc. usually have filtered
personalities.

Managers also usually people with little technical insight and need to rely
in information from others, the lack of information makes for easier
decision making is the though here. And usually those that talk smooth are
easier to listen to than those with an sound opinion, those are usually
spoken loudly and don't concur with the mainstream thoughts.

ARM was afraid of lawsuits for infringement and loss of income by the
details Luc might unveil on his RE quest.

This is how politics and business works.

[Luke Kenneth Casson Leighton]

Post by r***@Safe-mail.net
Is it common to do something like this against a person?

in the unethical business world? of course it is! mostly you don't
get to hear about it, but software libre developers are different.
they're not beholden to anyone, they're not corporate slaves, they're
not controlled and they are entitled to speak their mind.

consequently they get attacked. especially if some fucker deems that
their "profit" is threatened.

for example: there was some discussion back in 1999 as to whether
microsoft would ever take out a contract on my life, when i was doing
the reverse-engineering of NT domains. consequently i decided that
the research that i was doing had best be presented responsibly to
them as "security vulnerabilities", presented PRIVATELY to them (as a
responsible security researcher does) and only later disclosing them
if they didn't fix the problems in a reasonable timeframe.

and that's why ISS hired me. the strategy that i deployed worked.
one microsoft employee actually called ISS up asking them to fire me.
ISS declined, pointing out that i was quite likely to get very pissed
off, and would they prefer me inside pissing out or outside pissing
in? they're absolutely right: i would have worked really really hard
to release one devastating public zero-day security vulnerability -
with full exploit code - every few days for several months, if they'd
fucked with me.

luc verhaegen unfortunately did not deploy this type of strategy
(muddying the P.R. waters by leveraging the "responsible security
disclosure" track). if he had, then he could reasonably claim that
ARM (and other unethical companies) are being highly irresponsible in
trying to attack him. the technology and security press would
absolutely go to town on them (as we know has been done in the past
when other independent security researchers get attacked).

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attach