Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP

[mike.v...@gmail.com]

2017-08-08 12:11 GMT+02:00 Pablo Rath :
> On Fri, Aug 04, 2017 at 10:17:22AM +0200, mike.v...@gmail.com wrote:
>> Well they've announced the CHIP to be more open and supported than
>> actually delivered.
>>
>> Now that is unfortunately common practice. And due to experiences in
>> the past, Poulsbo, Andriod, I already knew that they would not be able
>> to deliver that, especially at that price point. Hey they even
>> promised opensource 3d graphics if the crowdfunding was successful
>> enough, if I recall correctly.
>>
>> But that is just us. That might not, and probably is, be true for a
>> lot of their customers, like David. That's we're the evil lies I
>> think. Announcing a "libre" computer but fail to follow it through.
>> Yes there is open source software for you to use, yes there
>> schematics.
>
> Please correct me if I am wrong but I am pretty sure they did not
> announce a "libre" computer. They use the term "open source" and "very
> open source" on their kickstarter page. People in the "Open Source Camp"
> seem to be more inclined to accept a very open source system with
> proprietary wifi.

The term libre is somewhat new. The average joe knows about open
source these days. But if I drop the libre keyword they don't
understand.

And they did not get to "very open" in my opinion. But the level op
openness should be stated more clearly.

As it is the system for all functionality is tied to a 3.4 kernel and
fixed X11 version display stack. Or Android.

So for all the openness upgrading is neigh impossible. As is running a
generic Linux distribution.

So in my opinion opensource means that you can upgrade and the every
bit can be mainlined.

Firmware, however evil in it's own right, is independent on the OS
software stack and thus does not impair upgrading or switching OS
and/or OS versions. So hence the general acceptance I guess.

The MALI GPU requires a closed source driver dependent on the OS
stack. Thus locking you in place.

The Cedar VPU requires a closed source driver dependent on the OS
stack. Thus locking you in place. That situation, again no thanks to
NTC, is improving, albeit slowly.

Thankfully display drivers (That's not the GPU. So no 2d or 3d
acceleration!) are available or worked on. But no help from NTC.

So on paper nothing better than a Intel GMA500 (Poulsbo/PowerVR). E.g.
a Dell mini 1010 sold with Ubuntu, the trap I fell into, Three Ubuntu
iterations further and that was it for that Laptop.

When announcing an open source system. Companies should be very clear
on what they are selling.
Does it include firmware? (Acceptable ?)
Does it include closed source drivers? (That limits upgradablity and
usefull lifetime)
Do you provide a complete stack, Source, Compile chain, Documentation?
Do you provide schematics?
Do you provide a BoM?
Do you provide comprehensive component documentation free of NDA's?
etc.

Simply saying "we're selling an opensource system" is a farce. That's too broad.

>
> kind regards
> Pablo
>
>
> ___
> arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netb...@files.phcomp.co.uk

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

Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP

[Pablo Rath]

On Fri, Aug 04, 2017 at 10:17:22AM +0200, mike.v...@gmail.com wrote:
> Well they've announced the CHIP to be more open and supported than
> actually delivered.
> 
> Now that is unfortunately common practice. And due to experiences in
> the past, Poulsbo, Andriod, I already knew that they would not be able
> to deliver that, especially at that price point. Hey they even
> promised opensource 3d graphics if the crowdfunding was successful
> enough, if I recall correctly.
> 
> But that is just us. That might not, and probably is, be true for a
> lot of their customers, like David. That's we're the evil lies I
> think. Announcing a "libre" computer but fail to follow it through.
> Yes there is open source software for you to use, yes there
> schematics.

Please correct me if I am wrong but I am pretty sure they did not
announce a "libre" computer. They use the term "open source" and "very
open source" on their kickstarter page. People in the "Open Source Camp"
seem to be more inclined to accept a very open source system with
proprietary wifi.

kind regards
Pablo


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

Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP

[Luke Kenneth Casson Leighton]

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


On Thu, Aug 3, 2017 at 9:38 PM, Pablo Rath  wrote:
> On Fri, Jul 28, 2017 at 11:08:16AM -0400, do...@mail.com wrote:

>> I asked in to forums about how to solve this and it's been weeks without
>> any answer (I only ever got one, and that user told me not to side load
>> software (which I explained that I never did or even thought of)).
>
> I still don't get why you believe that ntc is evil. In my opinion they
> are not evil just because the configured PocketChip like you described.

 i concur.  they're a group of enterprising people who have utilised
one of the lowest-cost china SoCs with an extremely high libre
reputation, thanks to the sunxi community's work about five years ago.

> Please read my previous email on this list.
> Basically you put PocketChip into fel-mode and connect it with another
> computer. You can then use a "special" version of U-Boot via fel and
> boot an OS on USB or Debian Installer on USB.

 i've done this a lot.  it's my primary method of development and
debugging.  i upload the FEL sub-16k loader to initialise the SoC's
DDR3 RAM, then upload u-boot directly into the DDR3 RAM, then ask FEL
to *execute* u-boot directly in RAM.

 in the past i've even loaded an entire kernel *and initrd* into
memory over FEL - that takes a while but it can take less time than
having to insert and remove micro-sd cards (and rewrite them, and
mount them, and blah blah).

 you cannot expect companies to drop everything and help just you.
you're just one person: you're expected to work these things out for
yourself.

 now, if you were placing an order for ten THOUSAND *then* they might
be interested.

l.

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

Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP

[Pablo Rath]

On Fri, Jul 28, 2017 at 11:08:16AM -0400, do...@mail.com wrote:
> On Tue, 11 Jul 2017 12:10:21 +0200
> Pablo Rath  wrote:
> > On Fri, Jul 07, 2017 at 06:19:29PM -0400, David Niklas wrote:
> > > On Thu, 6 Jul 2017 13:21:56 +0200
> > > 
> > > Actually, my PC has a kernel fault   

...

> > > (It's a long story of ntc's evil
> > > doing),   
> > 
> > Why do you believe that ntc is evil?
> 
> When you boot a normal Linux computer you are presented with a plymouth
> boot screen and can hit escape to exit and see the boot messages.
> I pocketchip's case you are presented (serendipity), with a boot screen
> that somehow references a file listed in /home/chip (I forget the
> exact name, it starts with a period), that invokes feh on pocketchip's
> logo boot screen from which there is no escape. If you uninstall plymouth
> and delete the file that invokes feh in /home/chip you are just presented
> with a black screen.
> Once pocketchip finishes booting you cannot use Alt-F[0-9][0-9] to switch
> tty's, nor can you use Ctrl-Alt-F[0-9][0-9], so if the boot fails for any
> reason you are stuck with never being able to fix or diagnose it (though
> you might get the last few messages of some error, which you might have
> read in full if the screen was not black).
> I asked in to forums about how to solve this and it's been weeks without
> any answer (I only ever got one, and that user told me not to side load
> software (which I explained that I never did or even thought of)).

I still don't get why you believe that ntc is evil. In my opinion they
are not evil just because the configured PocketChip like you described.
Boot messages are small and scroll fast anyway so they would probably
don't help you much.

...

> > > I've found two faults that cannot be traced without a postmortem and
> > > I'm really sick of accidentally causing this thing to manifest said
> > > problems and then loosing all the work that I did in between my
> > > backup periods.  
> > 
> > How can you be sure it is a kernel bug and not another problem?
> 
> Can't, that's why I'm in this predicament. All I know is the last few
> messages that say that the kernel is not syncing with the rootfs (and I
> have not touched the partition table, or init, or those scripts and files
> (like fstab), which would alter the mounting process).
> 
> > Can you
> > give us some details. Did you ask on ntc's user forum or did you file a
> > bug report 
> 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...

> Here are the post (hmm, seems that email notification of new replies is
> not working:
> https://bbs.nextthing.co/t/pocketchip-boots-to-black-screen/14643
> https://bbs.nextthing.co/t/kernel-panic-not-syncing/17525
> 

User "zwack" gave you good advice to use UART-serial connection.
Basically you connect your PocketChip with another computer and can read
boot messages there. You will even be able to interact with U-Boot
before booting.

...

> > > I'm in need of a way to boot PC without flashing the NAND I there a
> > > way to do this? So far my search results have been unsuccessful.  
> > 
> > 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?

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

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

___

Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP

[doark]

On Tue, 11 Jul 2017 12:10:21 +0200
Pablo Rath  wrote:
> On Fri, Jul 07, 2017 at 06:19:29PM -0400, David Niklas wrote:
> > On Thu, 6 Jul 2017 13:21:56 +0200
> > 
> > Actually, my PC has a kernel fault   
> 
> It took me a moment to guess that you abbreviate PocketChip as "PC". My
> mind went like: "What? Why is he talking about his Personal Computer
> now?" :)

The pocketchip community uses that abbreviation frequently, it confuses
me sometimes too.

> > (It's a long story of ntc's evil
> > doing),   
> 
> Why do you believe that ntc is evil?

When you boot a normal Linux computer you are presented with a plymouth
boot screen and can hit escape to exit and see the boot messages.
I pocketchip's case you are presented (serendipity), with a boot screen
that somehow references a file listed in /home/chip (I forget the
exact name, it starts with a period), that invokes feh on pocketchip's
logo boot screen from which there is no escape. If you uninstall plymouth
and delete the file that invokes feh in /home/chip you are just presented
with a black screen.
Once pocketchip finishes booting you cannot use Alt-F[0-9][0-9] to switch
tty's, nor can you use Ctrl-Alt-F[0-9][0-9], so if the boot fails for any
reason you are stuck with never being able to fix or diagnose it (though
you might get the last few messages of some error, which you might have
read in full if the screen was not black).
I asked in to forums about how to solve this and it's been weeks without
any answer (I only ever got one, and that user told me not to side load
software (which I explained that I never did or even thought of)).

> > and the Linux kernel claims that it is not tainted.
> > I don't know if that covers firmware, but at least there are no
> > modules that are non-free.  
> 
> I don't understand the paragraph above. Do you talk about mainline linux
> kernel, ntc's kernel fork for Chip, ... Can you please clarify?

The kernel is the default and it's name is:
4.4.13 ntc mlc

> > > > Best bet is to use libre-linux mainline and besides that just
> > > > attempt to deblob ntc's components by hand, which shouldn't be a
> > > > problem long term cause it doesn't look like they maintain any of
> > > > this stuff at all anyway and it's very likely the only blobs are
> > > > in the kernel anyway however not a sure one.  
> > > 
> > > I ditched all the custom NTC stuff and went for vanilla Debian. I
> > > have managed to install Debian Stretch (current Stable) on a USB
> > > stick using Debian Installer. I am using a self-compiled mainline
> > > U-Boot via sunxi-fel to circumvent the U-Boot version on NAND
> > > provided by the manufacturer which can not boot from USB.  
> > 
> > 
> > I've found two faults that cannot be traced without a postmortem and
> > I'm really sick of accidentally causing this thing to manifest said
> > problems and then loosing all the work that I did in between my
> > backup periods.  
> 
> How can you be sure it is a kernel bug and not another problem?

Can't, that's why I'm in this predicament. All I know is the last few
messages that say that the kernel is not syncing with the rootfs (and I
have not touched the partition table, or init, or those scripts and files
(like fstab), which would alter the mounting process).

> Can you
> give us some details. Did you ask on ntc's user forum or did you file a
> bug report 
2. Asked on the forum (I was a bit exasperated at the time since FLOSS
software is no good to me if I can't debug it).
Here are the post (hmm, seems that email notification of new replies is
not working:
https://bbs.nextthing.co/t/pocketchip-boots-to-black-screen/14643
https://bbs.nextthing.co/t/kernel-panic-not-syncing/17525

> Can't you improve you backup strategy - for example commit
> to an external git repo; or synchronize with another stable working
> computer?
3. Not really. I use pocketchip on-the-go and typically what I'm doing on
the go is offline and I'm physically separated from my other machines.

> > I'm in need of a way to boot PC without flashing the NAND I there a
> > way to do this? So far my search results have been unsuccessful.  
> 
> 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?

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

> 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

Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP

[Pablo Rath]

On Mon, Jul 10, 2017 at 06:34:39AM -0400, Jean Flamelle wrote:
> Actually learned about the
> deblob scripts seeing a script use them on the chrome kernel, so I was
> thinking about running deblob in a u-boot directory and seeing what
> happens.

My guess is that nothing useful is going to happen because there is a
deblob script tailored for every kernel release. I would be quite
surprised if it works on the source of a completely unrelated project. 
But I have been wrong before so go ahead if you want and tell us what
happens.

> > I ditched all the custom NTC stuff and went for vanilla Debian. I have
> > managed to install Debian Stretch (current Stable) on a USB stick
> > using Debian Installer. I am using a self-compiled mainline U-Boot via
> > sunxi-fel to
> > circumvent the U-Boot version on NAND provided by the manufacturer which
> > can not boot from USB.
> 
> I'm not sure if you mean version "of" NAND, but otherwise it sounds
> like your saying they hardcoded it not boot that way?
> Feature-not-a-bug?

I have to admit that I don't understand your first question probably
because I am not a native speaker. Is "of NAND" or "on NAND" a semantic
or a technical question?
I think NextThing forked U-Boot before USB boot went mainline. I
remember a forum thread where someone from NextThing wrote there are two
options; first to backport USB boot into NextThings U-Boot fork or
second to wait until certain features of NextThings U-Boot are
mainlined. So in my opinion feature-not-a-bug is not the case here.

> > I had some problems to boot the rootfs after completing installation and
> > solved it with help from the debian-arm mailing list (see this thread
> > for additional information:
> > https://lists.debian.org/debian-arm/2017/06/msg00027.html)
> > I am only using Debians main repos and connect to the Internet via
> > USB-OTG with the g_ether kernel module and a network bridge on my
> > desktop.
> 
> That whole thing sounds like it was painful to get operating.

I don't give up easily.
It was more like solving a puzzle where all parts fit once you have gotten them
out of several different boxes. I did not write a single line of code so
I am standing on the shoulders of giants (linux-sunxi community, debian
developers, U-Boot developers).
> 
> > I am running Chip headless via ssh and have not tested video and
> > sound yet. There may be some hidden quirks I am not yet aware of but so
> > far it looks good.
> 
> I would be very interested to know if GPIO functions okay like that.

Do you have an easy test to verify GPIO functions?

> kudos Pablo!

Thank you!

kind regards
Pablo

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

Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP

[Pablo Rath]

On Thu, Jul 06, 2017 at 06:01:42PM -0500, Isaac David wrote:
> 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-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP

[Jean Flamelle]

On 7/6/17, Pablo  wrote:
> This is a quite late reply to some Emails on this list from May. I took some
> time to research and test.
> John, do you still work on liberating Pocketchip?

Got distracted trying to install parabola on an asus c201 (nothing can
write a sane gpt header to emmc it seems). Actually learned about the
deblob scripts seeing a script use them on the chrome kernel, so I was
thinking about running deblob in a u-boot directory and seeing what
happens.

My understanding (which isn't too reliable) is that the universal in
universal bootloader is that u-boot handles some operations that would
normally be handled by linux, including passing microcode and handling
some firmware.

> Good news is that I managed to install Debian
> Stretch (current stable) with Debian Installer on a USB-stick. The CHIP
> OS based on Debian by NextThing is completely left alone.
> I plan to write a tutorial to document my approach and will put it on the
> Debian Wiki.

Yeah!

>> I knew about the wiki, then again I believe someone else was asking
>> about one earlier.
>
> Yes, it was me.

heh.. Sorry ,xD I didn't know the exact url by heart and never got
around to posting it on da list as a ref later.

> I ditched all the custom NTC stuff and went for vanilla Debian. I have
> managed to install Debian Stretch (current Stable) on a USB stick
> using Debian Installer. I am using a self-compiled mainline U-Boot via
> sunxi-fel to
> circumvent the U-Boot version on NAND provided by the manufacturer which
> can not boot from USB.

I'm not sure if you mean version "of" NAND, but otherwise it sounds
like your saying they hardcoded it not boot that way?
Feature-not-a-bug?

> I had some problems to boot the rootfs after completing installation and
> solved it with help from the debian-arm mailing list (see this thread
> for additional information:
> https://lists.debian.org/debian-arm/2017/06/msg00027.html)
> I am only using Debians main repos and connect to the Internet via
> USB-OTG with the g_ether kernel module and a network bridge on my
> desktop.

That whole thing sounds like it was painful to get operating.

> This is libre enough for me.
> I am running Chip headless via ssh and have not tested video and
> sound yet. There may be some hidden quirks I am not yet aware of but so
> far it looks good.

I would be very interested to know if GPIO functions okay like that.

kudos Pablo!

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

Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP

[Isaac David]

Pablo :

 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-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP

[Luke Kenneth Casson Leighton]

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


On Tue, May 30, 2017 at 8:29 PM, David Niklas  wrote:

> I'm shocked.

 yehh don't be - that's people for you.

> I've met so many nice people, like you, working on FLOSS projects...
> Just out of curiosity, did you ever consider developing a new version of
> samba that works right, just for fun and kicks?

 i did... but with so much mindshare invested, and how much effort it
takes (3 years to correctly implement the network neighbourhood for
example and that's *just one sub-system*) i figured i had better
things to do.

l.

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

Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP

[David Niklas]

On Tue, 30 May 2017 03:36:24 +0100
Luke Kenneth Casson Leighton  wrote:

> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
> 
> 
> On Mon, May 29, 2017 at 10:48 PM, David Niklas  wrote:
> 
> > I am just a tad confused.
> > 1. You started a reverse engineering project on NT domains.
> > 2. You presented your success to MS as a security problem.  
> 
>  and also a collaboration and interoperability opportunity (which
> worked extremely successfully).
> 
>  and it also galvanised them to do a proper documentation effort.
> basically there wasn't any.  at all.  the code had been organically
> develeped by engineers that were getting on for retirement age.  as
> they were the only ones left who understood the security implications,
> they began a rather urgent process called the "CIFS Initiative" to
> document the protocol so that their *own engineers could understand
> it*.
> 
>  frickin funny, really.
> 
> > 3. You were hired.
> > 4. Someone in MS complained.  
> 
>  some fuckwit in the brain-washed marketing department, yes.  what's
> hilarious is that microsoft's own employees - the ones with good
> reputations and standing - had to tell this particular specimen of
> brainwashed fuckwittery, "you _do_ realise what this one individual
> could do to our company if you ever pissed him off??"
> 
>  :)
> 
> 
> > So, the FLOSS folks never saw your work anyway?  
> 
>  they did and they resented it, very very badly.  the so-called
> leaders of the samba team *really* did not like the fact that i knew
> more than them about MSRPC, and that the work that i spearheaded
> increased the codebase of samba at the time by a whopping THIRTY
> PERCENT.
> 
>  so they engineereed a way to get me out.
> 
>  by 2003 someone in the FLOSS community tracked my work on Exchange
> 5.5 reverse-engineering, copied it, reimplemnted it, and did not tell
> anyone that i was the one who had done the reverse-engineering.
> 
>  20 years later samba is considered to be a failure.  samba 4 was
> something like 10 years in the making, and yet failed to deliver.
> companies that had held on to samba 3, which the samba developers
> STOPPED work on because they didn't understand it properly, were
> struggling to keep it up and running and were totally incensed when
> samba 4 was finally released and was even worse and even harder to
> configure.
> 
>  they pushed me out and FLOSS has suffered as a result, because the
> complexity is so high it's beyond their ability to cope.
> 
> l.

I'm shocked.
I've met so many nice people, like you, working on FLOSS projects...
Just out of curiosity, did you ever consider developing a new version of
samba that works right, just for fun and kicks?

Sincerely,
David

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

Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP

[doark]

On Tue, 30 May 2017 03:27:19 +0100
Luke Kenneth Casson Leighton  wrote:
> On Mon, May 29, 2017 at 10:37 PM, David Niklas  wrote:
> 
> > Prior to purchasing the Pocket CHIP I read their docs and kickstarter
> > page. See this (their kickstarter page says similar):
> > https://docs.getchip.com/chip.html#is-chip-open-source-where-are-the-docs
> > Are they flat out lying?  
> 
>  absolutely not.  absolutely everything (with the exception of MALI)
> has been available for the A13 core for... like... 4 years.
The wifi requires a binary blob according to this thread (unless I'm
remembering wrongly).

>  getting
> this through to people's thick skulls, thanks to the high
> noise-to-signal ratio, is getting frankly a little tiresome, i don't
> mind admitting.
> 
> l.

Well, when you say "opensource hardware" most people, including myself,
think "Oh, a completely opensource down to the last transistor
machine!!!"
When i first read the slashdot page on the C.H.I.P. I really thought that
that is what they meant... Same story with eoma. Which only makes sense,
since, taking spamassasin as an example, if you get an "opensource"
program you expect not only every line available for viewing but also the
docs and mass-check rules to be "opensource", which they are.

No offence intended luke, but when I see people trying to "Opensource"
something I am often times disappointed. I know that you and others work
very hard but it looks, to me, to be a half done job almost all the time
and I mean with software too, because it tends to lack tests to verify
it's functionality and docs to train the coming generations, myself
numbering among them.


Thanks,
David

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

Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP

[mike.v...@gmail.com]

2017-05-29 23:37 GMT+02:00 David Niklas :

> On Mon, 08 May 2017 09:59:50 +0100
> "mike.v...@gmail.com"  wrote:
> > 2017-05-08 3:34 GMT+02:00 :
>
> Sorry, I (foolishly) though that ARMv7 == A7 (i.e. a contraction).
>
Don't worry that is  common one.

>
> >
> > > 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.
> >
>
> Sorry, I thought the rest of it might be useful to look at.
>

It might be. That's why I suggested pastebin et al. Those are better for
public mailinglists than zipped files.


>
> 
> > > 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"
> Where is that quote from?
>

No ware. It was suggestion from me for them. That's what I would like to
see on all those sites selling this type of s*ht.

Be honest, be open. Don't façade the truth. It will come out and it will
bite you.

I don't believe the quote above would scare any potential buyer. The fact
they don't mention it while I know it is a reason I wouldn't buy from them.

It's like selling a car of which they have painted over rust and rewinded
the odo-meter. On first glance it looks terrific but when you find the
truth it will leave you angry and you'll go and tell everyone you know not
to buy from them.

So whenever I see a fancy site trying to sell a product of which I know the
limitations and they hide it: They become unreliable to me and I'll move
one and suggest to everyone that want's to listen to do the same.

Sadly that's the state of all vendors today. So everybody buy a crappy
painted over car with hardly any km/miles on it. ;-)
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP

[Luke Kenneth Casson Leighton]

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


On Mon, May 29, 2017 at 10:48 PM, David Niklas  wrote:

> I am just a tad confused.
> 1. You started a reverse engineering project on NT domains.
> 2. You presented your success to MS as a security problem.

 and also a collaboration and interoperability opportunity (which
worked extremely successfully).

 and it also galvanised them to do a proper documentation effort.
basically there wasn't any.  at all.  the code had been organically
develeped by engineers that were getting on for retirement age.  as
they were the only ones left who understood the security implications,
they began a rather urgent process called the "CIFS Initiative" to
document the protocol so that their *own engineers could understand
it*.

 frickin funny, really.

> 3. You were hired.
> 4. Someone in MS complained.

 some fuckwit in the brain-washed marketing department, yes.  what's
hilarious is that microsoft's own employees - the ones with good
reputations and standing - had to tell this particular specimen of
brainwashed fuckwittery, "you _do_ realise what this one individual
could do to our company if you ever pissed him off??"

 :)


> So, the FLOSS folks never saw your work anyway?

 they did and they resented it, very very badly.  the so-called
leaders of the samba team *really* did not like the fact that i knew
more than them about MSRPC, and that the work that i spearheaded
increased the codebase of samba at the time by a whopping THIRTY
PERCENT.

 so they engineereed a way to get me out.

 by 2003 someone in the FLOSS community tracked my work on Exchange
5.5 reverse-engineering, copied it, reimplemnted it, and did not tell
anyone that i was the one who had done the reverse-engineering.

 20 years later samba is considered to be a failure.  samba 4 was
something like 10 years in the making, and yet failed to deliver.
companies that had held on to samba 3, which the samba developers
STOPPED work on because they didn't understand it properly, were
struggling to keep it up and running and were totally incensed when
samba 4 was finally released and was even worse and even harder to
configure.

 they pushed me out and FLOSS has suffered as a result, because the
complexity is so high it's beyond their ability to cope.

l.

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

Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP

[Luke Kenneth Casson Leighton]

On Mon, May 29, 2017 at 10:37 PM, David Niklas  wrote:

> Prior to purchasing the Pocket CHIP I read their docs and kickstarter
> page. See this (their kickstarter page says similar):
> https://docs.getchip.com/chip.html#is-chip-open-source-where-are-the-docs
> Are they flat out lying?

 absolutely not.  absolutely everything (with the exception of MALI)
has been available for the A13 core for... like... 4 years.  getting
this through to people's thick skulls, thanks to the high
noise-to-signal ratio, is getting frankly a little tiresome, i don't
mind admitting.

l.

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

Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP

[David Niklas]

On Mon, 08 May 2017 09:59:50 +0100
"mike.v...@gmail.com"  wrote:
> 2017-05-08 3:34 GMT+02:00 :
> 
> > 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
> > "mike.v...@gmail.com"  wrote:  
> > >
> > > 2017-05-04 9:04 GMT+02:00 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.  
> > 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

Sorry, I (foolishly) though that ARMv7 == A7 (i.e. a contraction).

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

Sorry, I thought the rest of it might be useful to look at.


> > 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"
Where is that quote from?

> And state your involvement in freeing the hardware or not.
> 
> NTC website is just one big selling machine.
> 

Prior to purchasing the Pocket CHIP I read their docs and kickstarter
page. See this (their kickstarter page says similar):
https://docs.getchip.com/chip.html#is-chip-open-source-where-are-the-docs
Are they flat out lying?


Thanks,
David

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

Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP

[David Niklas]

On  Mon, 8 May 2017 16:38:22 +0100
Luke Kenneth Casson Leighton  wrote:
> On Mon, May 8, 2017 at 4:23 PM,   wrote:
> 
> > 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.

I am just a tad confused.
1. You started a reverse engineering project on NT domains.
2. You presented your success to MS as a security problem.
3. You were hired.
4. Someone in MS complained.

So, the FLOSS folks never saw your work anyway?

Thanks,
David

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

Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP

[John Luke Gibson]

On 5/12/17, Louis Pearson  wrote:
> I don't know if you know about this or not, but there is a community
> wiki at http://www.chip-community.org/index.php/Main_Page
> It has examples on using buildroot to flash images to chip
> http://www.chip-community.org/index.php/Flashing_Buildroot_Image_from_Ubuntu
>
> Again, I'm clueless :P I have just received some chip pro's and I am
> trying to make myself a neat little MP3 player with bluetooth audio
> support. Found the wiki up there through some searching. This is my
> first foray into working with embedded linux devices as well.

I knew about the wiki, then again I believe someone else was asking
about one earlier.
I'm still wrapping my head around these make scripts to make sure
nothing proprietary is hidden anywhere they don't theoretically need
to be.

Probably a good idea to use mainline libre-linux, but first want to
make a diff file comparing their fork with libre to make sure their
aren't any drivers which are libre that we might need (or any
bug-fixes). Unfortunately their aren't any overtly libre forks of
u-boot, however I don't know that their are necessarily any blobs in
mainline u-boot or ntc's fork. I looked into libreboot and their
support of arm is hazzy at best (one chromebook that it looks like two
people ported it over to completely on their own).

Best bet is to use libre-linux mainline and besides that just attempt
to deblob ntc's components by hand, which shouldn't be a problem long
term cause it doesn't look like they maintain any of this stuff at all
anyway and it's very likely the only blobs are in the kernel anyway
however not a sure one.

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

Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP

[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.
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP

[Stefan Monnier]

> Ah, interesting. Thank you for the correction and additional input.
> I would be glad to be wrong here as it makes things so much easier.
> My knowledge is quite vague in this area and comes mainly from
> NextThings user forum. For example consider the following threads:

If you want sound information, indeed, such forums tend to be pretty
hard to use.  The linux-sunxi website and mailing lists are a lot better
(and a lot more technical as a consequence).

You could start from http://linux-sunxi.org/NAND


Stefan


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

Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP

[Pablo]

On Wed, May 10, 2017 at 05:05:20PM +0200, mike.v...@gmail.com wrote:
> 2017-05-10 16:38 GMT+02:00 Luke Kenneth Casson Leighton :
> 
> > On Wed, May 10, 2017 at 3:23 PM, Pablo  wrote:
> >
> > > With any non-Chip-kernel you will lose NAND support.
> > > So you can either:
> > > a)patch your libre kernel
> > > or
> > > b) ignore NAND and use flash memory via usb port.
> > >
> > > For b) you will need mainline U-Boot because NextThings U-Boot fork
> > > supports NAND but not booting via usb.
> >
> >  this sounds weird / not quite right. the R8 (aka A13, aka the A10)
> > should be able to use the same sunxi 3.4.104+ kernel source as i've
> > been using for the A20, which has the (sunxi, libre) NAND driver in
> > it.  afaik they didn't change the NAND hardware from the A10/A20 to
> > the A13 to the R8 so this should be a non-issue.
> >
> >  also from what i gather there's been mainline support for the
> > (completely different, MTD-compatible) NAND driver for quite some
> > time, so again, should be a non-issue.
> >
Ah, interesting. Thank you for the correction and additional input.
I would be glad to be wrong here as it makes things so much easier.
My knowledge is quite vague in this area and comes mainly from
NextThings user forum. For example consider the following threads:
https://bbs.nextthing.co/t/is-it-possible-to-boot-from-a-usb-flash-drive/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*

> >  perhaps someone could ask on #linux-sunxi and/or their mailing list
> > for confirmation of the facts?
Sounds like a good idea. I can't do it because I lack the technical
details to ask the proper questions.
> 
> Wiki says "work in progress"
> 
> http://linux-sunxi.org/Mainlining_Effort
> http://linux-sunxi.org/NAND (Fun facts on supported NAND)
> http://linux-sunxi.org/MTD_Driver
> 
> https://groups.google.com/forum/#!searchin/linux-sunxi/mtd%7Csort:relevance
> 
> Boris has commit access so it's probably all there since 4.7
> 
> His work and derivatives did touch a lot of NAND/MTD drivers though.
> 
> Someone needs to crawl the linux kernel commits though or ask directly.

Thank you for the links and details. It is a lot of new information for
me. I am going to have a closer look in
the next couple of days. 
Maybe I will run some tests on my Chip. 

Pablo

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

Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP

[mike.v...@gmail.com]

2017-05-10 16:38 GMT+02:00 Luke Kenneth Casson Leighton :

> On Wed, May 10, 2017 at 3:23 PM, Pablo  wrote:
>
> > With any non-Chip-kernel you will lose NAND support.
> > So you can either:
> > a)patch your libre kernel
> > or
> > b) ignore NAND and use flash memory via usb port.
> >
> > For b) you will need mainline U-Boot because NextThings U-Boot fork
> > supports NAND but not booting via usb.
>
>  this sounds weird / not quite right. the R8 (aka A13, aka the A10)
> should be able to use the same sunxi 3.4.104+ kernel source as i've
> been using for the A20, which has the (sunxi, libre) NAND driver in
> it.  afaik they didn't change the NAND hardware from the A10/A20 to
> the A13 to the R8 so this should be a non-issue.
>
>  also from what i gather there's been mainline support for the
> (completely different, MTD-compatible) NAND driver for quite some
> time, so again, should be a non-issue.
>
>  perhaps someone could ask on #linux-sunxi and/or their mailing list
> for confirmation of the facts?

Wiki says "work in progress"

http://linux-sunxi.org/Mainlining_Effort
http://linux-sunxi.org/NAND (Fun facts on supported NAND)
http://linux-sunxi.org/MTD_Driver

https://groups.google.com/forum/#!searchin/linux-sunxi/mtd%7Csort:relevance

Boris has commit access so it's probably all there since 4.7

His work and derivatives did touch a lot of NAND/MTD drivers though.

Someone needs to crawl the linux kernel commits though or ask directly.
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP

[Luke Kenneth Casson Leighton]

On Wed, May 10, 2017 at 3:23 PM, Pablo  wrote:

> With any non-Chip-kernel you will lose NAND support.
> So you can either:
> a)patch your libre kernel
> or
> b) ignore NAND and use flash memory via usb port.
>
> For b) you will need mainline U-Boot because NextThings U-Boot fork
> supports NAND but not booting via usb.

 this sounds weird / not quite right. the R8 (aka A13, aka the A10)
should be able to use the same sunxi 3.4.104+ kernel source as i've
been using for the A20, which has the (sunxi, libre) NAND driver in
it.  afaik they didn't change the NAND hardware from the A10/A20 to
the A13 to the R8 so this should be a non-issue.

 also from what i gather there's been mainline support for the
(completely different, MTD-compatible) NAND driver for quite some
time, so again, should be a non-issue.

 perhaps someone could ask on #linux-sunxi and/or their mailing list
for confirmation of the facts?

l.

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

Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP

[Pablo]

> >>On Wed, May 10, 2017 at 12:00 AM, John Luke Gibson
> >>eaterjo...@gmail.com> wrote:
> >> Right now I'm looking at CHIP-buildroot.
> >> I'm planning on patching out any blobs and also anything not CHIP
> >> related (as we don't want a person to accidentally think the script
> >> will give them a blobless cubieboard or anything).

> >On 10 May 2017 09:40:02 GMT+03:00, Luke Kenneth Casson Leighton 
> > wrote:
> > there's already a libre version of the linux kernel which has this
> >done already. look up the linux kernel that parabola uses.
> >
>On Wed, May 10, 2017 at 12:05:33PM +0300, Allan Mwenda wrote:
> Free Software Foundation Latin America Linux-Libre. 

Good idea! To use an already existing and "official" kernel will save
time, add credibility and transparency.

The link to the mentioned page of FSF Latin America is:
https://www.fsfla.org/ikiwiki/selibre/linux-libre/

With any non-Chip-kernel you will lose NAND support.
So you can either: 
a)patch your libre kernel 
or 
b) ignore NAND and use flash memory via usb port.

For b) you will need mainline U-Boot because NextThings U-Boot fork
supports NAND but not booting via usb.

Pablo 

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

Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP

[Pablo]

On Tue, May 09, 2017 at 05:06:17PM -0700, Jeffrey Sites wrote:
> 
> 
> > On May 9, 2017, at 16:00, John Luke Gibson  wrote:
> > 
> > Right now I'm looking at CHIP-buildroot.
> > I'm planning on patching out any blobs and also anything not CHIP
> > related (as we don't want a person to accidentally think the script
> > will give them a blobless cubieboard or anything).
> > 
> 
> Would it make sense to just add a target for C.H.I.P. to libreCMC in this 
> case?
> 
> I had been planning on doing that for a while but haven't had the time. 
> 
libreCMC seems an odd choice to me because C.H.I.P. does not have an
ethernet port. I think libreCMC for a C.H.I.P. will have a small
userbase. Do you have a special use case in mind?

As a general purpose OS one of the libre distributions or Debian with
only the main repository seems the way to go.

Pablo

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

Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP

[Philip Hands]

John Luke Gibson  writes:

> On 5/9/17, Benson Mitchell  wrote:
>> Seems like you're confusing back-quote (`) with single-quote ('), maybe?
>>
> I just want to say that alone makes for pretty terrible design within
> a fundamental language which an entire os can't run without.

When `` was first used I'm sure they were very pleased to have come up
with command substitution at all, so blaming them for introducing
readability issues is a bit harsh.  It's also possible that the
distinction between ` and ' was much more obvious when one was reading
the code off of a punched paper tape ;-)

$() has been in POSIX for at least 13 years:

  
http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_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.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP

[Allan Mwenda]

Free Software Foundation Latin America Linux-Libre. 

On 10 May 2017 09:40:02 GMT+03:00, Luke Kenneth Casson Leighton  
wrote:
>---
>crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>
>
>On Wed, May 10, 2017 at 12:00 AM, John Luke Gibson
> wrote:
>
>> Right now I'm looking at CHIP-buildroot.
>> I'm planning on patching out any blobs and also anything not CHIP
>> related (as we don't want a person to accidentally think the script
>> will give them a blobless cubieboard or anything).
>
> there's already a libre version of the linux kernel which has this
>done already. look up the linux kernel that parabola uses.
>
>l.
>
>___
>arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
>http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
>Send large attachments to arm-netb...@files.phcomp.co.uk

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP

[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  wrote:

> Right now I'm looking at CHIP-buildroot.
> I'm planning on patching out any blobs and also anything not CHIP
> related (as we don't want a person to accidentally think the script
> will give them a blobless cubieboard or anything).

 there's already a libre version of the linux kernel which has this
done already. look up the linux kernel that parabola uses.

l.

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

Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP

[John Luke Gibson]

On 5/9/17, Benson Mitchell  wrote:
> Seems like you're confusing back-quote (`) with single-quote ('), maybe?
>
I just want to say that alone makes for pretty terrible design within
a fundamental language which an entire os can't run without.

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

Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP

[John Luke Gibson]

On 5/9/17, Benson Mitchell  wrote:
> On May 9, 2017 7:02 PM, "John Luke Gibson"  wrote:
>
> Like, the first file initiated by the main make file is
> support/setlocalversion which looks to just check a whole bunch of
> un-special variables which weren't set in the make script and had no
> opportunity to be set by any other files I know of (on my system the
> variables show as empty not having run anything from buildroot, but I
> can't imagine head would be set to such a specific git command on
> accident as the one it checks for). Then the if one of the conditions
> were some how filled, then all it does is print weird strings like
> this:
>
> printf '%s%s' -g $head
>
> Like this is the if statement:
>
> if head=`git rev-parse --verify --short HEAD 2>/dev/null`
>
> That "=" is assignment, and those "`"s are output substitution. It tries
> executing that git command, storing the output in the shell variable head.
> If git succeeds (returns zero), the then clause is executed; if git fails
> (returns non-zero), the else clause (if present) is executed.
>
> Mind you all this is printed to a variable in the make script called
> BR2_Version_Full which does nothing in the make script but get printed
> if a person asks the version, the script calls target-finalize or
> legal-info-prepare (which it looks like it does unconditionally in
> both cases). Like am I really that deep in over my head
>
> Apparently, but that's how we learn, right? :)
>
> or does this
> script really have a bug where if someone sets head to some weird
> obscure git command it prints that very command in it's legal info?
>
> No.
>
> Like how does that happen that way on accident? It looks like it might
> serve some obscure purpose if it ran the command (which from I can
> tell with bash, setting some $(shell x) might do that,
>
> "$(foo)" and "`foo`" are essentially the same. They both run foo, and
> substitute the output.
>

I ran this in terminal and got this:

john@john-ER922AA-ABA-SR1834NX-NA660:~/Documents/Code/OperationDaBlob/chip-buildroot+subsidiaries/CHIP-buildroot$
if head='git rev-parse --verify --short HEAD 2>/dev/null'; then
> echo $head;
> else
> echo "failed";
> fi
git rev-parse --verify --short HEAD 2>/dev/null
john@john-ER922AA-ABA-SR1834NX-NA660:~/Documents/Code/OperationDaBlob/chip-buildroot+subsidiaries/CHIP-buildroot$
#!/bin/bash
john@john-ER922AA-ABA-SR1834NX-NA660:~/Documents/Code/OperationDaBlob/chip-buildroot+subsidiaries/CHIP-buildroot$
# your code goes here
john@john-ER922AA-ABA-SR1834NX-NA660:~/Documents/Code/OperationDaBlob/chip-buildroot+subsidiaries/CHIP-buildroot$
if head=$(git rev-parse --verify --short HEAD 2>/dev/null); then
> echo $head;
> else
> echo "failed";
> fi
b52c25c
john@john-ER922AA-ABA-SR1834NX-NA660:~/Documents/Code/OperationDaBlob/chip-buildroot+subsidiaries/CHIP-buildroot$

So I do believe I found a bug, but I mixed up bash script and make
script when posing $(shell x) as a solution which retains
functionality.

@Jeff, that would be a best if we were starting from scratch. The Chip
community has put a lot into documentation and tutorials, so it might
not be best to throw all that out for a new os. Debian's not bad.

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

Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP

[Jeffrey Sites]

---
jasites

> On May 9, 2017, at 16:00, John Luke Gibson  wrote:
> 
>> On 5/8/17, Pablo  wrote:
>> On Sun, May 07, 2017 at 04:36:40PM +0100, Luke Kenneth Casson Leighton
>> wrote:
>>> On Sun, May 7, 2017 at 4:17 PM, Pablo  wrote:
>>> 
 To flash your deblobbed image beware of the closed-source flashing tool
 for the Chrome browser and use the strange “Ubuntu virtual machine
 SDK solution”. I read somewhere that one NextThing developer flashes
 right from his Debian box but this way is not officially supported.
>>> 
>>> jaezuss this kind of thing pisses me off.  there is *NO NEED* for
>>> proprietary tools with the A13 (R8), the A20 or any other allwinner
>>> processor.
>> I agree. Just to be sure I looked again if I can find the source of the
>> Chrome browser extension.
>> I only found this forum thread where "hippiehacker" searches for the source
>> and gets no answer:
>> https://bbs.nextthing.co/t/chip-flasher-on-github/5561/10
>> So it seems I have been correct and it is proprietary.
>> 
>>> fex-boot has been in sunxi-tools for at least FOUR YEARS
>>> since i helped hno and others with the USB-sniffing of the FEL
>>> protocol.
>> What I called the strange "Ubuntu virtual machine SDK solution" is
>> documented here:
>> https://docs.getchip.com/chip.html#installing-c-h-i-p-sdk
>> Basically they recommend to install a huge virtual machine image to
>> create a "level" playing field for all users and then use a bunch of
>> shell-scripts called CHIP-tools to flash images from within the virtual
>> machine.
>> CHIP-tools require sunxi-tools:
>> https://github.com/NextThingCo/CHIP-tools
>> 
>> So they use sunxi-tools but in a quite comlicated way.
>> A documented and tested command-line solution for the major
>> distributions would have been the way to go...
>> 
>> Pablo
>> 
>> ___
>> arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
>> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
>> Send large attachments to arm-netb...@files.phcomp.co.uk
> 
> Right now I'm looking at CHIP-buildroot.
> I'm planning on patching out any blobs and also anything not CHIP
> related (as we don't want a person to accidentally think the script
> will give them a blobless cubieboard or anything).
> 

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

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

> I'm planning on posting the fork on notabug along with deblobbed forks
> to any repositories the script fetches from and modifying the script
> to pull from the blobless notabug repositories. So far I haven't found
> any hex files in their uboot, so my hunch is that the wifi driver is
> in the kernel and the chips won't need reflashing if that really truly
> is the only blob. Thanks for the links about flashing. While I haven't
> found any binary in uboot, I really don't like how often the source
> comments mention code specifically aimed at accommodating blobs, so
> even if their are no blobs I may still want to patch out some of the
> files that check for the presence of microcode, etc... You know, to
> make sure accidents don't happen.
> 
> I'm not a programmer by trade, so I don't know if I'm speaking above
> my grade, but just looking at buildroot it looks like their is tons of
> glitched/typo'ed code in conditional if statements that look like they
> would never have any practical reason to run... Is this normal for
> open source code xD
> 
> Like, the first file initiated by the main make file is
> support/setlocalversion which looks to just check a whole bunch of
> un-special variables which weren't set in the make script and had no
> opportunity to be set by any other files I know of (on my system the
> variables show as empty not having run anything from buildroot, but I
> can't imagine head would be set to such a specific git command on
> accident as the one it checks for). Then the if one of the conditions
> were some how filled, then all it does is print weird strings like
> this:
> 
> printf '%s%s' -g $head
> 
> Like this is the if statement:
> 
> if head=`git rev-parse --verify --short HEAD 2>/dev/null`
> 
> Mind you all this is printed to a variable in the make script called
> BR2_Version_Full which does nothing in the make script but get printed
> if a person asks the version, the script calls target-finalize or
> legal-info-prepare (which it looks like it does unconditionally in
> both cases). Like am I really that deep in over my head or does this
> script really have a bug where if someone sets head to some weird
> obscure git command it prints that very command in it's legal info?
> Like how does that happen that way on accident? It looks like it might
> serve some obscure purpose if it ran the command (which from I can
> tell with bash, setting some $(shell x) might do that, however the
> version string it should output 

Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP

[Benson Mitchell]

On May 9, 2017 7:02 PM, "John Luke Gibson"  wrote:

Like, the first file initiated by the main make file is
support/setlocalversion which looks to just check a whole bunch of
un-special variables which weren't set in the make script and had no
opportunity to be set by any other files I know of (on my system the
variables show as empty not having run anything from buildroot, but I
can't imagine head would be set to such a specific git command on
accident as the one it checks for). Then the if one of the conditions
were some how filled, then all it does is print weird strings like
this:

printf '%s%s' -g $head

Like this is the if statement:

if head=`git rev-parse --verify --short HEAD 2>/dev/null`

That "=" is assignment, and those "`"s are output substitution. It tries
executing that git command, storing the output in the shell variable head.
If git succeeds (returns zero), the then clause is executed; if git fails
(returns non-zero), the else clause (if present) is executed.

Mind you all this is printed to a variable in the make script called
BR2_Version_Full which does nothing in the make script but get printed
if a person asks the version, the script calls target-finalize or
legal-info-prepare (which it looks like it does unconditionally in
both cases). Like am I really that deep in over my head

Apparently, but that's how we learn, right? :)

or does this
script really have a bug where if someone sets head to some weird
obscure git command it prints that very command in it's legal info?

No.

Like how does that happen that way on accident? It looks like it might
serve some obscure purpose if it ran the command (which from I can
tell with bash, setting some $(shell x) might do that,

"$(foo)" and "`foo`" are essentially the same. They both run foo, and
substitute the output.
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP

[Pablo]

On Mon, May 08, 2017 at 10:36:28AM +0200, mike.v...@gmail.com wrote:
> 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-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP

[Pablo]

On Sun, May 07, 2017 at 04:36:40PM +0100, Luke Kenneth Casson Leighton wrote:
> On Sun, May 7, 2017 at 4:17 PM, Pablo  wrote:
> 
> > To flash your deblobbed image beware of the closed-source flashing tool for 
> > the Chrome browser and use the strange “Ubuntu virtual machine
> > SDK solution”. I read somewhere that one NextThing developer flashes
> > right from his Debian box but this way is not officially supported.
> 
>  jaezuss this kind of thing pisses me off.  there is *NO NEED* for
> proprietary tools with the A13 (R8), the A20 or any other allwinner
> processor.  
I agree. Just to be sure I looked again if I can find the source of the
Chrome browser extension.
I only found this forum thread where "hippiehacker" searches for the source
and gets no answer:
https://bbs.nextthing.co/t/chip-flasher-on-github/5561/10
So it seems I have been correct and it is proprietary.

>fex-boot has been in sunxi-tools for at least FOUR YEARS
> since i helped hno and others with the USB-sniffing of the FEL
> protocol.
What I called the strange "Ubuntu virtual machine SDK solution" is
documented here:
https://docs.getchip.com/chip.html#installing-c-h-i-p-sdk
Basically they recommend to install a huge virtual machine image to
create a "level" playing field for all users and then use a bunch of 
shell-scripts called CHIP-tools to flash images from within the virtual machine.
CHIP-tools require sunxi-tools:
https://github.com/NextThingCo/CHIP-tools

So they use sunxi-tools but in a quite comlicated way.
A documented and tested command-line solution for the major
distributions would have been the way to go...

Pablo

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

Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP

[Luke Kenneth Casson Leighton]

On Mon, May 8, 2017 at 4:23 PM,   wrote:

> 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-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP

[mike.v...@gmail.com]

Don't top post please

2017-05-08 17:23 GMT+02:00 :

>  Original Message 
> From: 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.


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

Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP

[ronwirring]

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

 Original Message 
From: Bill Kontos <vkontog...@gmail.com>
Apparently from: arm-netbook-boun...@lists.phcomp.co.uk
To: Linux on small ARM machines <arm-netbook@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.
> 
> On May 8, 2017 8:02 AM,  <do...@mail.com> wrote:
> > 
> > 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
> > "mike.v...@gmail.com" <mike.v...@gmail.com> wrote:
> > >
> > > 2017-05-04 9:04 GMT+02:00 John Luke Gibson <eaterjo...@gmail.com>:
> > >
> > > > Since it seems like a trivially simple task that for some reason no
> > > > one has taken up, I would like to take the opportunity to exercise a
> > > > learning experience and simultaneously benefit the community, by
> > > > liberating PocketCHIP by deblobbing the source and re-compiling.
> > > >
> > >
> > > The PocketCHIP is powered by their SoM:
> > > http://linux-sunxi.org/NextThingCo_CHIP
> > >
> > > That is apparently a Allwinner R8 pared with an external rtl8723bs
> > > Wifi/BT chip.
> > >
> > > The R8 is a rebranded A13.
> > 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.
> > 
> > 
> > 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)).
> > 
> > 
> > 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.
> > 
> > 
> > > 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.
> > 
> > 
> > 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
> > 
> > ___
> > arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
> > http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> > Send large attachments to arm-netb...@files.phcomp.co.uk
> 
>

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

Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP

[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.
On May 8, 2017 8:02 AM,  wrote:

> 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
> "mike.v...@gmail.com"  wrote:
> >
> > 2017-05-04 9:04 GMT+02:00 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.
> 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.
>
> 
> 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)).
> 
>
> 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.
>
>
> > 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.
> 
>
> 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
>
> ___
> arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netb...@files.phcomp.co.uk
>
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP

[Pablo]

> > 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-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP

[Luke Kenneth Casson Leighton]

On Mon, May 8, 2017 at 2:34 AM,   wrote:

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


> 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-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP

[John Luke Gibson]

On 5/4/17, Luke Kenneth Casson Leighton  wrote:
> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>
>
> On Thu, May 4, 2017 at 4:13 PM, mike.v...@gmail.com 
> wrote:
>
>> That is apparently a Allwinner R8 pared with an external rtl8723bs Wifi/BT
>> chip.
>>
>> The R8 is a rebranded A13.
>>
>> If you look at
>> https://getchip.com/pages/chip
>>
>> You'll see:
>> On the left image the RAM (Hynix) and Wifi+BT (Realtek) and Power module
>> (Allwinner AXP209)
>> On the right the SoC (R8/A13) and NAND (Samsung)
>>
>> The A13 does not need blob's to run anymore, the WiFi+BT chip does.
>> AFAIKT
>
>  so that'll be a definitive "No" for the Chip, not because of the
> processor but because one of the peripherals (the RTL8723bs) requires
> proprietary firmware.
>
>  if they sold a variant that did *not* have the RTL8723bs *then* they
> would be able to apply for RYF Certification... assuming that they
> didn't try to put MALI onto the OS sold with the product [or any other
> proprietary software].
>
>  they'd also need to create a totally separate product page or use
> some other method which ensured that "Grandma buying CHIP for little
> Tommie" did NOT get the wrong one.  that would mean that the
> [hypothetical RTL8723bs-less] CHIP would also need a totally different
> product name.
>
>  RYF Certification is really rather involved but makes sense when you
> consider all the angles.
>
> l.
>
> ___
> arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netb...@files.phcomp.co.uk

Yeah, I kind of given up on ntc since they refused to make any comment.
I'm more thinking for my purposes, since I already have a few and they
have a full usb port on the board free when in pocket-CHIP I figured I
could just use a dongle.

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

Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP

[Luke Kenneth Casson Leighton]

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


On Thu, May 4, 2017 at 4:13 PM, mike.v...@gmail.com  wrote:

> That is apparently a Allwinner R8 pared with an external rtl8723bs Wifi/BT
> chip.
>
> The R8 is a rebranded A13.
>
> If you look at
> https://getchip.com/pages/chip
>
> You'll see:
> On the left image the RAM (Hynix) and Wifi+BT (Realtek) and Power module
> (Allwinner AXP209)
> On the right the SoC (R8/A13) and NAND (Samsung)
>
> The A13 does not need blob's to run anymore, the WiFi+BT chip does.  AFAIKT

 so that'll be a definitive "No" for the Chip, not because of the
processor but because one of the peripherals (the RTL8723bs) requires
proprietary firmware.

 if they sold a variant that did *not* have the RTL8723bs *then* they
would be able to apply for RYF Certification... assuming that they
didn't try to put MALI onto the OS sold with the product [or any other
proprietary software].

 they'd also need to create a totally separate product page or use
some other method which ensured that "Grandma buying CHIP for little
Tommie" did NOT get the wrong one.  that would mean that the
[hypothetical RTL8723bs-less] CHIP would also need a totally different
product name.

 RYF Certification is really rather involved but makes sense when you
consider all the angles.

l.

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

Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP

[mike.v...@gmail.com]

2017-05-04 9:04 GMT+02:00 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.


>
> Browsing the archives to see if this had been talked about before, I
> find it very incredibly humourous I got name dropped on the mailing
> list by Parobath:
>
> > Date: Sat, 29 Oct 2016 20:13:10 +0200
> > From: Parobalth 
> > To: arm-netbook@lists.phcomp.co.uk
> > Subject: closed-source BootROM and RYF certification
> > User-Agent: Mutt/1.5.23 (2014-03-12)
> >
> > At the forum of NextThing Chip is a thread about Chip and a
> > possible RYF certification. I wrote there that I think that is unlikely
> > to happen and linked to https://www.crowdsupply.com/
> eoma68/micro-desktop/updates/fsf-ryf-background.
> > Then someone else mentioned that a closed-source BootROM is used for
> Chip.
> > Another guy with username "eaterjolly" wrote about this BootROM: "The
> same type of SOC is
> > used for the EOMA croud project which is vying for ryf-endorsement quite
> > openly [...]"
> >
> > You can find the forum thread here:
> > https://bbs.nextthing.co/t/ntc-thoughts-on-ryf-endorsement/4490
> >
> > Because they use Discourse to power their forum which relies heavily on
> > JavaScript I also attach a Pdf version of the forum post.
> >
> > I wonder if the mentioned statements are correct and how it relates to
> > the RYF certification of the EOMA68-A20 Libre Tea card.
> >
> > kind regards
> > Paro
>
> Like reading that URL, I was like? didn't I start that thread? then I
> re-read the post and noticed I was quoted in the email xD I didn't
> participate in the list back then, cause I was afraid my ignorance
> would be spurred, of course I know that not to be true in hindsight.
> Feels a bit melodramatic being name dropped on a linux mailing list,
> usually you only see legends get mentioned by name when they aren't
> around xD
>
> Anywhoo, I more or less just wanted to start this thread because I
> wanted to know if any one could point out anything that would need be
> removed besides the wifi firmware. I searched the sunix-uboot
> repository on github for the word blob and got a few interesting hits
> for the code in the folder binman:
>
> https://github.com/linux-sunxi/u-boot-sunxi/search?q=blob
>
> Particularly in files mentioning the devil:
>
> "# Entry-type module for Intel Chip Microcode binary blob"
>

That contains a full copy of U-Boot, not the Linux kernel, and thus
initialization for all type of hardware. Most of which requires microcode
of firmware to work.


>
> I suppose this is just another aspect of mainlining, meant to be
> parsed out once it's discovered that there are no such blobs in the
> kernel, but personally I'd feel more comfortable with a script
> removing these sections of the code altogether.
>
> If I had been actually reading the list digests back when I could have
> posted more accurate information in that thread rather than just
> guessing. Well, I suppose I can do so now.
>
> How humorous it is though too that I've run into the same 40k file
> limit? Small tiny things suggesting the work of the vicissitudes of
> fate, much like deja vu in the matrix.
>
> ___
> arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netb...@files.phcomp.co.uk
___
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk

Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP

[David Boddie]

On Thu May 4 12:05:48 BST 2017, John Luke Gibson wrote:

> Gosh, I feel like this is just more mainline stuff that would be
> parsed out, because there must be more than a hundred drivers with
> everything from intel to yamaha.

Yes, you need to look at the configuration file for the kernel to find out
what's included. There's a file in the vendor's Buildroot repository
(https://github.com/NextThingCo/CHIP-buildroot) that seems to be what you're
looking for:

https://github.com/NextThingCo/CHIP-
buildroot/blob/chip/stable/board/nextthing/pocketchip/linux.config

David

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

Re: [Arm-netbook] Side-Topic: Liberating PocketCHIP

[John Luke Gibson]

On 5/4/17, Bill Kontos  wrote:
> Why is there an intel blob on the chip. I didn't know there was intel ip in
> there.
>
> On Thu, May 4, 2017 at 10:04 AM, John Luke Gibson 
> wrote:
>
>> Since it seems like a trivially simple task that for some reason no
>> one has taken up, I would like to take the opportunity to exercise a
>> learning experience and simultaneously benefit the community, by
>> liberating PocketCHIP by deblobbing the source and re-compiling.
>>
>> Browsing the archives to see if this had been talked about before, I
>> find it very incredibly humourous I got name dropped on the mailing
>> list by Parobath:
>>
>> > Date: Sat, 29 Oct 2016 20:13:10 +0200
>> > From: Parobalth 
>> > To: arm-netbook@lists.phcomp.co.uk
>> > Subject: closed-source BootROM and RYF certification
>> > User-Agent: Mutt/1.5.23 (2014-03-12)
>> >
>> > At the forum of NextThing Chip is a thread about Chip and a
>> > possible RYF certification. I wrote there that I think that is unlikely
>> > to happen and linked to https://www.crowdsupply.com/
>> eoma68/micro-desktop/updates/fsf-ryf-background.
>> > Then someone else mentioned that a closed-source BootROM is used for
>> Chip.
>> > Another guy with username "eaterjolly" wrote about this BootROM: "The
>> same type of SOC is
>> > used for the EOMA croud project which is vying for ryf-endorsement
>> > quite
>> > openly [...]"
>> >
>> > You can find the forum thread here:
>> > https://bbs.nextthing.co/t/ntc-thoughts-on-ryf-endorsement/4490
>> >
>> > Because they use Discourse to power their forum which relies heavily on
>> > JavaScript I also attach a Pdf version of the forum post.
>> >
>> > I wonder if the mentioned statements are correct and how it relates to
>> > the RYF certification of the EOMA68-A20 Libre Tea card.
>> >
>> > kind regards
>> > Paro
>>
>> Like reading that URL, I was like? didn't I start that thread? then I
>> re-read the post and noticed I was quoted in the email xD I didn't
>> participate in the list back then, cause I was afraid my ignorance
>> would be spurred, of course I know that not to be true in hindsight.
>> Feels a bit melodramatic being name dropped on a linux mailing list,
>> usually you only see legends get mentioned by name when they aren't
>> around xD
>>
>> Anywhoo, I more or less just wanted to start this thread because I
>> wanted to know if any one could point out anything that would need be
>> removed besides the wifi firmware. I searched the sunix-uboot
>> repository on github for the word blob and got a few interesting hits
>> for the code in the folder binman:
>>
>> https://github.com/linux-sunxi/u-boot-sunxi/search?q=blob
>>
>> Particularly in files mentioning the devil:
>>
>> "# Entry-type module for Intel Chip Microcode binary blob"
>>
>> I suppose this is just another aspect of mainlining, meant to be
>> parsed out once it's discovered that there are no such blobs in the
>> kernel, but personally I'd feel more comfortable with a script
>> removing these sections of the code altogether.
>>
>> If I had been actually reading the list digests back when I could have
>> posted more accurate information in that thread rather than just
>> guessing. Well, I suppose I can do so now.
>>
>> How humorous it is though too that I've run into the same 40k file
>> limit? Small tiny things suggesting the work of the vicissitudes of
>> fate, much like deja vu in the matrix.
>>
>> ___
>> arm-netbook mailing list arm-netbook@lists.phcomp.co.uk
>> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
>> Send large attachments to arm-netb...@files.phcomp.co.uk
>

Well to clarify, I haven't actually found a blob in uboot yet, rather
I found parts of the code which refer to blobs interestingly.

So far I found this pile of blobs in their kernel that the readme says
they are legally no allowed to distribute, lovely:

https://github.com/NextThingCo/CHIP-linux/tree/chip/stable/firmware

But also on the wifi, I don't know, but this file certainly looks like
the source code of a wireless driver:

https://github.com/NextThingCo/CHIP-linux/blob/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-netbook@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb...@files.phcomp.co.uk