[Arm-netbook] Flashing the NAND

Aaron J. Seigo aseigo at kde.org
Mon Dec 9 14:27:02 GMT 2013


On Monday, December 9, 2013 09:28:13 you wrote:
> On Sun, 08 Dec 2013 02:34:12 +0100
> 
> "Aaron J. Seigo" <aseigo at kde.org> wrote:
> > On Saturday, December 7, 2013 03:19:50 Siarhei Siamashka wrote:
> > > PS. I'm a little bit surprised that Aaron immediately assumed that
> > > this weird behaviour is somehow the typical user experience, which
> > > needs to be documented on the wiki. I also hope that the other
> > 
> > Fair question.
> > 
> > It turns out that this “weird behaviour” has been run into by several
> > others previously.
> 
> I would have actually expected you to provide some link or other
> clear reference to support this statement.

.. and therein lies the crux of the matter. We (plural) ran into the issue, did some searching online, 
found some other reports of similar issues .. but there is no place to record / collate this information 
and so the knowledge we collected is not available to you unless we share it here after the fact on a 
mailing list where it will quickly get buried in archives for the next googler to stumble upon.

> > There have even been workaround put into use, as you noted.
> 
> What kind of workaround do you mean?

One that I was pointed to involved patching the mali blob .. fortunately we didn’t need to go to such 
lengths.

Given that none of this is documented in an easily findable location, people end up ‘researching’ via 
google and poking random people on irc, on this list or on various google groups. it doesn’t work 
well.

> > Now, where is that documented? It isn’t (unless you count google as
> > documentation ;)
> 
> Wait a second. Are you sending me to google now?

I’m making the point that when google is the best location for finding “documentation” on mailing 
list archives and random wikis with no canonical location for such information to be stored, then .. 
yes .. people end up sending each other to google.

> What makes me unhappy is that you really show no restraint. The first
> thing you do immediately after making an appearance is bashing your
> upstream (the kernel and drivers you use are from linux-sunxi, right?):
> 
>     http://thread.gmane.org/gmane.comp.hardware.netbook.arm/8451
>     http://thread.gmane.org/gmane.comp.hardware.netbook.arm/8459

What  makes me unhappy is that instead of asking  questions  of  me, you have jumped to the 
worst conclusion possible and then pissed all over me for it.

Siarhei, you are so wrong on your interpretation of the above it is not even funny.

My emails there were actually not aimed *at* linux-sunxi. The problem was this: one person told 
me “yep, we can flash the NAND”; awesome, right? Well, turns out they didn’t know how to exactly. 
More accurately they knew some of it and other parts they didn’t and some of the work was yet to 
be done and nowhere could either of us check on what was done and what wasn’t.

It involves bootloaders, kernel configurations, specific hardware (EOMA68) and vendor tooling. The 
sunxi kernel and drivers were really not an issue.

Yet, you decided in your mind that this must be what I was talking about, even though I never said 
that. As a result, you jumped all over me.

Now, I think that had you read carefully you would have noticed my referencing things like the 
rhombus tech site and that may have been a clue .. but I know that it is very easy to overlook such 
things.

Had you *asked* what my issue was with sunxi instead of going on the offensive, you would have 
found out the above without the drama.

Now, do you think that does your reputation any good? This community’s? sunxi’s?

I’m still reeling from surprise that someone appears and says “I’d like to put time and effort into 
some coordination efforts...” on this mailing list and the response is a general “fuck off” on #linux-
sunxi on irc. If you wonder why there are few people involved, look no further.

> You don't even bother to give us at least a few days to investigate
> the issue and help to resolve your problem.

Because the openGL problem was not the first issue we ran into that had ~no relevant 
documentation for, but which we had to mine people’s heads, mailing list archives and  forums for. 

You have constructed a narrative here that goes something like:

* Aaron ran into an opengl problem and couldn’t figure it out
* Aaron bitches about it on the mailing list the next day

My experience actually was:

* Several people working on this hardware were unable to bring up openGL
* Days were spent looking for documentation, none was forthcoming
* We were told to ask on the list
* The answer came from that same person, and the answer was links to random kernel trees and 
mailing list archives
* This was the Nth time this pattern repeated while working with All Winner SoCs in the EOMA68 
form factor, something we’ve been doing for nearly a year now
* Aaron accurately describes the situation above and suggests coordination meetings on irc so we 
might start to control the chaos

Now, do those two narratives look alike? No. Can I understand how you saw one storyline and I 
another? Yes! Here’s how:

	communication is broken in this community 
					+
	people expect the worst of each other

The latter point was told to me point blank by libv on irc Saturday night. Given this thread, I can 
completely understand why.

Maybe it is time to break the cycle?

> So is the opengles issue fully resolved now? I would like to know
> the details and whether any help or other actions are still needed
> from our side. Thanks.

It is currently working for us, though we do not know precisely what the fix was. This is not 
satisfactory, as you can no doubt imagine, but we will continue to look out for problems in future. I 
am not interested, however, in delving into technical matters in this thread which is about social 
issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.phcomp.co.uk/pipermail/arm-netbook/attachments/20131209/5284ed0c/attachment-0001.html>


More information about the arm-netbook mailing list