Hi all, I have an A20 based eoma68 card. I have now an image based on the Mer distribution that can boot and runs fine from the microSD card (following http://rhombus-tech.net/allwinner/a20/boot/ and http://www.gplsquared.com/eoma_boot/eoma_boot.html)
but the next necessary step is to flash a booting image to the internal NAND of the eoma68 (and in the end make an image that can be installed by default from the factory).
I understand there have been some progress (I see drivers for it in https://github.com/linux-sunxi/linux-sunxi/tree/wip/linux-sunxi-3.4/cubieboa... but nothing that looks like it shows up in /dev?)
I was wondering what is the procedure for it? did anybody managed to obtain a booting linux distribution from the nand? (seems a proprietary windows application is needed for the flashing?)
Cheers, Marco Martin
hi marco, welcome to the list, and thanks for agreeing to post these questions publicly so that others can help answer them, and more can benefit from everyone's replies.
On Thu, Dec 5, 2013 at 10:35 PM, Marco Martin notmart@gmail.com wrote:
Hi all, I have an A20 based eoma68 card. I have now an image based on the Mer distribution that can boot and runs fine from the microSD card (following http://rhombus-tech.net/allwinner/a20/boot/ and http://www.gplsquared.com/eoma_boot/eoma_boot.html)
but the next necessary step is to flash a booting image to the internal NAND of the eoma68 (and in the end make an image that can be installed by default from the factory).
ok. right. this was last discussed.... over 4-5 months ago, here on arm-netbooks, so i'm a little rusty as it's not in my immediate short-term memory.
I understand there have been some progress (I see drivers for it in https://github.com/linux-sunxi/linux-sunxi/tree/wip/linux-sunxi-3.4/cubieboa... but nothing that looks like it shows up in /dev?)
ok - the cubieboard2 3.4 kernel which you can likely find here: https://github.com/cubieboard2/linux-sunxi/tree/sunxi-3.4-cb2-dev or i *may* have a copy here: http://git.rhombus-tech.net/?p=linux.git - i believe almost certainly has libnand committed.
https://github.com/cubieboard2/linux-sunxi/tree/sunxi-3.4-cb2-dev/drivers/bl...
yep, there you go. that's what i recall using [over 4 months ago] and i remember it working correctly.
I was wondering what is the procedure for it? did anybody managed to obtain a booting linux distribution from the nand? (seems a proprietary windows application is needed for the flashing?)
the key critical procedure behind that proprietary tool - the fel booting - has long since been reverse-engineered and put into u-boot.
what *hasn't* yet been done is what allwinner did, which was to set up a small short non-OS-based "boot" system (which they split into two halves, boot0 and boot1, alongside some "apps" which go onto a DOS-formatted partition: these "apps" can be loaded at startup time by pressing keys - 1, 2 etc. etc). it's all horribly complicated yet amazingly the source code is actually available, it was accidentally included in the last allwinner-a20 3.3 SDK code-drop. they also compiled up u-boot with libnand attached to it, so that it could load the linux kernel from NAND.
so there are several pieces to the puzzle:
1) boot0 and boot1. the GPL-compliant source for this has been tracked down. it should be easy to find, let me know if you have any difficulties.
2) libnand-aware u-boot released by allwinner this, again, should be easy to find, on hno's github u-boot repo and in several other places. *quick search*... https://github.com/linux-sunxi/u-boot-sunxi/wiki - ah, there you go - lichee-a20-dev branch. that'll do.
3) libnand-aware sunxi 3.4 kernel. see above: that's at least one version that i know of which works (and i've tested on EOMA68-A20 CPU Cards).
4) allwinner's nand tools (equivalent to mtd-tools). https://github.com/linux-sunxi/sunxi-tools - you want nand-part. i recommend compiling this up natively (boot over fel or SD) - why waste time cross-compiling? you have a perfectly good OS and a fast enough processor with plenty of RAM!
once you have all those pieces you can then bootstrap up from:
a) a FEL boot b) to a MicroSD card c) use nand-part to create partitions d) write boot0 and boot1 directly to the 1st NAND partition (with dd) e) check it works (press 1 or 2 etc. etc.) f) repeat until success. g) put u-boot on as well h) repeat until success i) put OS files (linux kernel etc.) on the other NAND partitions j) repeat until success
at any point along this path, there is absolutely nothing to be concerned about if you screw up: you can always go back to FEL boot. so the whole system is basically "unbrickable".
i'd recommend using the proprietary GPL-violating versions of (d) and (g) first, in order to minimise the number of unknowns. in fact, what i'd recommend is that if you happen to already have android on the EOMA68-A20 card, to fire it up with adb (apt-get install android-tools) then take a copy of the entire /dev/system/nanda partition and anything else you can find (nandb for example), then play with that.
the alternative would be to hack the sunxi version of u-boot's SPL loader, to link in with libnand. what that would give you would be a free-software community alternative to boot0/boot1. given that the lichee-a20-dev version of u-boot already has libnand support this should not be too hard to achieve: the only thing to watch out for though is the extremely limited amount of space available for that first boot phase.
does anyone else have any other recommendations or strategies? henrik i know you've wanted to have proper sunxi nand support in u-boot for some time.
l.
On Friday 06 December 2013, luke.leighton wrote:
hi marco, welcome to the list, and thanks for agreeing to post these
thanks :)
https://github.com/cubieboard2/linux-sunxi/tree/sunxi-3.4-cb2-dev/drivers/ block/sun7i_nand
yep, there you go. that's what i recall using [over 4 months ago] and i remember it working correctly.
ok, so i have a small update on this already: the driver is there and is working in the sunxi-3.4 branch, i built all the pieces in the kernel and i now have from /dev/nanda to /dev/nandj nanda is the boot partition, nandd seems the ext4 root, nande a 512m vfat partition, nandh and nandi empty ext4 ones, nandj a 2gb vfat one. all the other seems to not be accessible
i suppose this layouthas to be maintained? (the space is very fragmented, doesn't let much storage space in the end
so there are several pieces to the puzzle:
- boot0 and boot1. the GPL-compliant source for this has been
tracked down. it should be easy to find, let me know if you have any difficulties.
is it in https://github.com/linux-sunxi/sunxi-tools ?
- libnand-aware u-boot released by allwinner this, again, should be
easy to find, on hno's github u-boot repo and in several other places. *quick search*... https://github.com/linux-sunxi/u-boot-sunxi/wiki - ah, there you go - lichee-a20-dev branch. that'll do.
- libnand-aware sunxi 3.4 kernel. see above: that's at least one
version that i know of which works (and i've tested on EOMA68-A20 CPU Cards).
yes, this seem to work..
will investigate on the other pieces of the puzzle
On Fri, Dec 6, 2013 at 9:10 AM, Marco Martin notmart@gmail.com wrote:
On Friday 06 December 2013, luke.leighton wrote:
hi marco, welcome to the list, and thanks for agreeing to post these
thanks :)
https://github.com/cubieboard2/linux-sunxi/tree/sunxi-3.4-cb2-dev/drivers/ block/sun7i_nand
yep, there you go. that's what i recall using [over 4 months ago] and i remember it working correctly.
ok, so i have a small update on this already: the driver is there and is working in the sunxi-3.4 branch, i built all the pieces in the kernel and i now have from /dev/nanda to /dev/nandj
awesome!
nanda is the boot partition, nandd seems the ext4 root, nande a 512m vfat partition, nandh and nandi empty ext4 ones, nandj a 2gb vfat one. all the other seems to not be accessible
i don't know what they're for.
i suppose this layouthas to be maintained?
not at all. the only critical one from what i gather is that the 1st partition has to start at a very specific offset (or, more specifically, the start of boot0 has to be at a hard-coded absolute location on the NAND). i recommend taking a dd of nanda then examine it with hexdump -C to see what's going on.
(the space is very fragmented, doesn't let much storage space in the end
so there are several pieces to the puzzle:
- boot0 and boot1. the GPL-compliant source for this has been
tracked down. it should be easy to find, let me know if you have any difficulties.
is it in https://github.com/linux-sunxi/sunxi-tools ?
those are tools (userspace applications). boot0 and boot1 are *very* early bootloaders, they're small enough to fit into the 1st level cache so that they can do things like set up the DDR3 timings so that it even becomes possible to do things like... y'know... use the memory? :)
here's a hint worth investigating to track the code down: https://github.com/hno/allwinner-boot/commits/lichee-a20-dev
henrik committed the A20 SDK to lichee-a20-dev so that would be a good place to start investigating. several others have copies as well i'm sure.
ahhhhh here we go: https://github.com/hno/allwinner-boot/tree/d29c34b7f221979724275b4861c50de3b...
that's the one.
- libnand-aware u-boot released by allwinner this, again, should be
easy to find, on hno's github u-boot repo and in several other places. *quick search*... https://github.com/linux-sunxi/u-boot-sunxi/wiki - ah, there you go - lichee-a20-dev branch. that'll do.
- libnand-aware sunxi 3.4 kernel. see above: that's at least one
version that i know of which works (and i've tested on EOMA68-A20 CPU Cards).
yes, this seem to work..
will investigate on the other pieces of the puzzle
let us know how you get on ok? also much of this stuff is current-knowledge in henrik (hno)'s head :) can i possibly recommend catching his attention on irc?
On Friday 06 December 2013, luke.leighton wrote:
On Fri, Dec 6, 2013 at 9:10 AM, Marco Martin notmart@gmail.com wrote:
On Friday 06 December 2013, luke.leighton wrote:
hi marco, welcome to the list, and thanks for agreeing to post these
thanks :)
https://github.com/cubieboard2/linux-sunxi/tree/sunxi-3.4-cb2-dev/drive rs/
block/sun7i_nand
yep, there you go. that's what i recall using [over 4 months ago]
and i remember it working correctly.
ok, so i have a small update on this already: the driver is there and is working in the sunxi-3.4 branch, i built all the pieces in the kernel and i now have from /dev/nanda to /dev/nandj
awesome!
nanda is the boot partition, nandd seems the ext4 root, nande a 512m vfat partition, nandh and nandi empty ext4 ones, nandj a 2gb vfat one. all the other seems to not be accessible
i don't know what they're for.
i suppose this layouthas to be maintained?
not at all. the only critical one from what i gather is that the 1st partition has to start at a very specific offset (or, more specifically, the start of boot0 has to be at a hard-coded absolute
ok, good news
henrik committed the A20 SDK to lichee-a20-dev so that would be a good place to start investigating. several others have copies as well i'm sure.
ahhhhh here we go: https://github.com/hno/allwinner-boot/tree/d29c34b7f221979724275b4861c50de 3bd5b47fb
that's the one.
ok.
I also found this on the wiki http://linux-sunxi.org/Installing_to_NAND_from_SD_card
does seem still reliable? (seems a bit old in this case "sun4i should be replaced with sun7i?) that tutorial i suppose maintains boot0 and boot1 from the default android image
On Fri, Dec 6, 2013 at 11:45 AM, Marco Martin notmart@gmail.com wrote:
I also found this on the wiki http://linux-sunxi.org/Installing_to_NAND_from_SD_card
yep that looks good.
does seem still reliable? (seems a bit old in this case "sun4i should be replaced with sun7i?) that tutorial i suppose maintains boot0 and boot1 from the default android image
that would appear to be the case. so as long as you don't overwrite the boot partition (or you take a dd if backup of it before-hand) you're good to go.
so those instructions would cover the latter steps of the strategy i outlined earlier.
l.
On Friday 06 December 2013, luke.leighton wrote:
On Fri, Dec 6, 2013 at 11:45 AM, Marco Martin notmart@gmail.com wrote:
I also found this on the wiki http://linux-sunxi.org/Installing_to_NAND_from_SD_card
yep that looks good.
does seem still reliable? (seems a bit old in this case "sun4i should be replaced with sun7i?) that tutorial i suppose maintains boot0 and boot1 from the default android image
that would appear to be the case. so as long as you don't overwrite the boot partition (or you take a dd if backup of it before-hand) you're good to go.
so those instructions would cover the latter steps of the strategy i outlined earlier.
soo, A small update on this, first things first, I have got the nand partitioned, a mer system copied on it (pretty much from the image i posted the other day) aaaand... (suspense)
...it works :D
other good news, is that heavy stuff like a full KDE Plasma session starts up waaaay faster than from the sd, so a full desktop session looks definitely usable, not super fast (as one can imagine) but usable :)
is still very hacky and I found quite some undocumented oddities (that yes, i will document). a quick list, so I don't forget is:
* the stock boot1 version on eoma expect a partition without a filesystem but just an initrd dd-ed on top of it, starting with "ANDROID!" (that's on /dev/nandc in the default layout, a different partitioning makes boot1 suicide, if i manage to get correctly boot1 rebuilt, removing it should be an easy patch)
* for u-boot i'm using the origin/lichee-dev branch. Unfortunately seems quite different from the sunxi branch, probably branched out quite a lot of time ago. It works but i had to modify a lot the default boot params in sun7i.h (what would be rocking i think is making it try to boot from sd and if fails then boot from nand, I wonder if is possible but this is for another day)
* boot0/boot1: i used the stock ones at first, https://github.com/hno/allwinner-boot seems to work, but *not* the last revision. While the older d29c34b revision seems to work (unfortunately many files don't seem to have gpl headers, is an issue that should be fixed) Newer revisions are very different and produce a boot.axf that doesn't start (on serial console complains about wrong elf magic or something like that) It has to be patched a bit to just even build.
That's enough for now... I think the sanest thing is now document all the steps: so where do you guys prefer it to be done?(linux-sunxi wiki? somewhere else?)
Then the first thing that i want to release is an image of the nand correctly partitioned with just boot stuff and the kernel in, so that can be used as the base to put any rootfs of any distribution on, and for people to experiment with
Then I'll publish iterations of what we want shipped on the Improv in the end, so as i go, who here has an eoma can test it very easily with just a simple dd.
Cheers, Marco Martin
On Tue, 10 Dec 2013 22:49:50 +0100 Marco Martin notmart@gmail.com wrote:
On Friday 06 December 2013, luke.leighton wrote:
On Fri, Dec 6, 2013 at 11:45 AM, Marco Martin notmart@gmail.com wrote:
I also found this on the wiki http://linux-sunxi.org/Installing_to_NAND_from_SD_card
yep that looks good.
does seem still reliable? (seems a bit old in this case "sun4i should be replaced with sun7i?) that tutorial i suppose maintains boot0 and boot1 from the default android image
that would appear to be the case. so as long as you don't overwrite the boot partition (or you take a dd if backup of it before-hand) you're good to go.
so those instructions would cover the latter steps of the strategy i outlined earlier.
soo, A small update on this, first things first, I have got the nand partitioned, a mer system copied on it (pretty much from the image i posted the other day) aaaand... (suspense)
...it works :D
other good news, is that heavy stuff like a full KDE Plasma session starts up waaaay faster than from the sd, so a full desktop session looks definitely usable, not super fast (as one can imagine) but usable :)
is still very hacky and I found quite some undocumented oddities (that yes, i will document). a quick list, so I don't forget is:
- the stock boot1 version on eoma expect a partition without a filesystem but
just an initrd dd-ed on top of it, starting with "ANDROID!" (that's on /dev/nandc in the default layout, a different partitioning makes boot1 suicide, if i manage to get correctly boot1 rebuilt, removing it should be an easy patch)
- for u-boot i'm using the origin/lichee-dev branch. Unfortunately seems quite
different from the sunxi branch, probably branched out quite a lot of time ago. It works but i had to modify a lot the default boot params in sun7i.h (what would be rocking i think is making it try to boot from sd and if fails then boot from nand, I wonder if is possible but this is for another day)
- boot0/boot1: i used the stock ones at first,
https://github.com/hno/allwinner-boot seems to work, but *not* the last revision. While the older d29c34b revision seems to work (unfortunately many files don't seem to have gpl headers, is an issue that should be fixed) Newer revisions are very different and produce a boot.axf that doesn't start (on serial console complains about wrong elf magic or something like that) It has to be patched a bit to just even build.
That's enough for now... I think the sanest thing is now document all the steps: so where do you guys prefer it to be done?(linux-sunxi wiki? somewhere else?)
Well, earlier in this thread somebody has already mentioned http://linux-sunxi.org/Installing_to_NAND_from_SD_card I guess, making it better is always welcome. You can also ask people on #linux-sunxi irc channel.
Then the first thing that i want to release is an image of the nand correctly partitioned with just boot stuff and the kernel in, so that can be used as the base to put any rootfs of any distribution on, and for people to experiment with
Then I'll publish iterations of what we want shipped on the Improv in the end, so as i go, who here has an eoma can test it very easily with just a simple dd.
Thanks for providing updates on your progress.
On Thursday, December 5, 2013 23:04:45 luke.leighton wrote:
hi marco, welcome to the list, and thanks for agreeing to post these questions publicly so that others can help answer them, and more can benefit from everyone's replies.
what surprises me is that all this apparent work has been done and yet:
* none of it is properly documented, resulting in “scavenger hunts” for anyone wanting to do most anything
* many of the default configurations of base pieces like the kernel are absolutely braindamaged -> include the nand drivers in the kernel tree but don’t build them by default? wherf?
* there are numerous gotchas (like that opengl demo program that you have to run first to get opengles started on the A20.. wtf?) that are quietly hidden away. they are on no roadmap, have no prioritization and nobody seems to work on them. (those three things are interrelated.)
i’m sure someone is running to send an email containing the words “volunteer effort”, “community” and what-not at this point. ;)
well, fact is that community based development does not need to be chaotic. if we wish to turn these efforts in something commercially viable as well as have a more thriving community, then we need to enable people more effectively.
this involves not only people/ projects on this mailing list, but the sunxi community and likely a few others as well.
do people on this list ever hold irc meetings? if so, when/where? if not, would people be open to having one with the goal of improving this situation?
On Friday 06 December 2013, Aaron J. Seigo wrote:
- there are numerous gotchas (like that opengl demo program that you have
to run first to get opengles started on the A20.. wtf?) that are quietly hidden away. they are on no roadmap, have no prioritization and nobody
about the opengl situation, a very strange thing happens: with this image http://www.gplsquared.com/eoma_boot/cubie_eoma_ubuntu_13_04_3d.bin.xz from http://www.gplsquared.com/eoma_boot/eoma_boot.html
that glark_es2 application works out of the box (the screenshot with that blue cat)
while on Mer, having built pretty much the same version of everything it needs that test app to be ran first (even the same glmark_es2 app)
anybody has any clue why?
Cheers, Marco Martin
On Fri, 6 Dec 2013 13:25:25 +0100 Marco Martin notmart@gmail.com wrote:
On Friday 06 December 2013, Aaron J. Seigo wrote:
- there are numerous gotchas (like that opengl demo program that you have
to run first to get opengles started on the A20.. wtf?) that are quietly hidden away. they are on no roadmap, have no prioritization and nobody
about the opengl situation, a very strange thing happens: with this image http://www.gplsquared.com/eoma_boot/cubie_eoma_ubuntu_13_04_3d.bin.xz from http://www.gplsquared.com/eoma_boot/eoma_boot.html
that glark_es2 application works out of the box (the screenshot with that blue cat)
Yes, the glark_es2 application is supposed to work fine out of the box. The other OpenGL ES applications are supposed to work correctly too.
while on Mer, having built pretty much the same version of everything it needs that test app to be ran first (even the same glmark_es2 app)
That's really weird. And I don't remember anybody ever observing anything like this before.
anybody has any clue why?
We currently have to deal with a proprietary userspace mali blob (version r3p0). This blob has a number of known bugs and glitches, which are more or less successfully workarounded for most of the people.
I guess that with your unusual hardware and your unusual linux distro, the chances of encountering something unusual are a bit higher than normal. If you have a complete SD card image where this problem can be easily reproduced, then I could try to debug it a bit.
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 "numerous gotchas" are going to be properly reported to the linux-sunxi developers. Patches are even more appreciated. IMHO that's the only practical way to improve the situation. But if somebody thinks that it is possible to achieve better results by "holding meetings" and "creating processes", then feel free to do so and prove me wrong :)
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. There have even been workaround put into use, as you noted. Now, where is that documented?
It isn’t (unless you count google as documentation ;) and so when people run into issues they are left with very little to go on. How much better if that information was captured somewhere for easy discovery and follow up.
"numerous gotchas" are going to be properly reported to the linux-sunxi developers.
Not all are relevant to linux-sunxi, those that we run into that are we will definitely communicate them to you.
Patches are even more appreciated. IMHO
Obviously. What I’m suggesting is something that has proven elsewhere to help increase the number of patches a project receives.
that's the only practical way to improve the situation. But if
Agreed; so one should do what one can to increase the odds of receiving such patches.
somebody thinks that it is possible to achieve better results by "holding meetings" and "creating processes", then feel free to do so and prove me wrong :)
You’ve been proven wrong countless times in countless projects that have been through these same sorts of issues. You can chose to learn from history or ignore it.
On Sun, 08 Dec 2013 02:34:12 +0100 "Aaron J. Seigo" aseigo@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.
There have even been workaround put into use, as you noted.
What kind of workaround do you mean?
Now, where is that documented? It isn’t (unless you count google as documentation ;)
Wait a second. Are you sending me to google now?
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
You don't even bother to give us at least a few days to investigate the issue and help to resolve your problem. The opengles issue has been first reported here:
http://irclog.whitequark.org/linux-sunxi/2013-12-05#5775192;
And now Marco Martin ("notmart" on irc) apparently made some progress:
http://thread.gmane.org/gmane.comp.hardware.netbook.arm/8466
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.
I understand that you have been semi-secretly developing your hardware for some time already and naturally might have had some difficulties with using linux-sunxi kernel and related software on it. But after finally going public, instantly venting out your frustration and spitting in the well you are drinking from does not look very civilized. I guess here is one more related rant from you:
https://plus.google.com/u/0/+AaronSeigo/posts/JDdvLDJESm5
So far I can see that it is you, who is having issues with poor communication in the processes of your own little project, but quite amusingly trying to blame this on someone else.
and so when people run into issues they are left with very little to go on. How much better if that information was captured somewhere for easy discovery and follow up.
"numerous gotchas" are going to be properly reported to the linux-sunxi developers.
Not all are relevant to linux-sunxi, those that we run into that are we will definitely communicate them to you.
Nice. Thanks.
Still if at least some of the gotchas are relevant to linux-sunxi (you are being a little bit ambiguous again), then your rant from the other day should have included the links to your bugreports right from the start. I expect no less from somebody who claims to be advocating good software development practices.
And by the way, I don't represent the whole linux-sunix community here (I'm only a minor contributor at best). So "communicate them to you" does not sound right and "communicate them to linux-sunxi people" is more appropriate.
on it. But after finally going public, instantly venting out your frustration and spitting in the well you are drinking from does not look very civilized. I guess here is one more related rant from you:
https://plus.google.com/u/0/+AaronSeigo/posts/JDdvLDJESm5
That is not what I class as a rant.
This below is what I call a rant:
So far I can see that it is you, who is having issues with poor communication
Siarhei Siamashka calm down, and look in the mirror first!
All our intentions are good and licenced to vent our frustrations at hardware and software not people.
On Mon, 9 Dec 2013 09:13:04 +0000 joem joem@martindale-electric.co.uk wrote:
on it. But after finally going public, instantly venting out your frustration and spitting in the well you are drinking from does not look very civilized. I guess here is one more related rant from you:
https://plus.google.com/u/0/+AaronSeigo/posts/JDdvLDJESm5That is not what I class as a rant.
Well, according to one of the definitions at https://www.vocabulary.com/dictionary/rant
"A rant is an argument that is fueled by passion, not shaped by facts."
The use of foul language in that G+ post indicates some sort of passion. But fine, let's consider it not a rant.
This below is what I call a rant:
So far I can see that it is you, who is having issues with poor communication
Then this is not a rant either. What exactly is wrong with this statement? Aaron himself admitted that the improvements of communication are needed. This was all your nice and friendly internal arm-netbook eoma68 talk about improving your software development processes.
Except that it also touched linux-sunxi wiki, linux-sunxi defconfigs and the mali400 graphics drivers support on sunxi hardware. And kinda implied that a poor job is also being done there.
Was there even any effort made to communicate with the linux-sunxi community? The kernel sources are available on github (and the Improv is already using them): https://github.com/linux-sunxi/linux-sunxi
The github page links to the linux-sunxi wiki: http://linux-sunxi.org/Linux
The linux-sunxi wiki has a link to the mailing list among other information: http://linux-sunxi.org/Mailing_list
For the OpenGL ES support in X11 on sunxi hardware, I have a project page here, which happens to list some contact information and describes the process of reporting issues: https://github.com/ssvb/xf86-video-fbturbo
Yes, the OpenGL ES issue has been successfully communicated via IRC. Nice job. Still Aaron described dealing with this particular issue using WTF word. Now I'm really curious what was my fault and how we can improve from this point?
Joem, if you have nothing really constructive to say, please just don't get in the way. And I actually have nothing more to add to this topic. What had to be said, had already been said. Cheers.
On Mon, Dec 9, 2013 at 11:41 AM, Siarhei Siamashka < siarhei.siamashka@gmail.com> wrote:
On Mon, 9 Dec 2013 09:13:04 +0000 joem joem@martindale-electric.co.uk wrote: The linux-sunxi wiki has a link to the mailing list among other information: http://linux-sunxi.org/Mailing_list
For the OpenGL ES support in X11 on sunxi hardware, I have a project page here, which happens to list some contact information and describes the process of reporting issues: https://github.com/ssvb/xf86-video-fbturbo
Right now OpenGL ES is working fine for me, i have a couple of ideas for trying to cause the problem again. Today i won't be able, but in the next days I'll do some experiments to see If the problem can be caused/fixed at will. at that point it can be documented (or fixed if there is anything to fix and wasn't just wrong procedure at some point)
Cheers, Marco Martin
On Mon, 9 Dec 2013 11:51:31 +0100 Marco Martin notmart@gmail.com wrote:
On Mon, Dec 9, 2013 at 11:41 AM, Siarhei Siamashka < siarhei.siamashka@gmail.com> wrote:
On Mon, 9 Dec 2013 09:13:04 +0000 joem joem@martindale-electric.co.uk wrote: The linux-sunxi wiki has a link to the mailing list among other information: http://linux-sunxi.org/Mailing_list
For the OpenGL ES support in X11 on sunxi hardware, I have a project page here, which happens to list some contact information and describes the process of reporting issues: https://github.com/ssvb/xf86-video-fbturbo
Right now OpenGL ES is working fine for me, i have a couple of ideas for trying to cause the problem again. Today i won't be able, but in the next days I'll do some experiments to see If the problem can be caused/fixed at will. at that point it can be documented (or fixed if there is anything to fix and wasn't just wrong procedure at some point)
Thanks. I'm definitely interested to know what was causing. Just to be sure that we can avoid it in the future. Also please report any other problems or oddities if you encounter them (preferably to the bugtracker, and not to this mailing list). Using irc is also fine for quick questions, but my presence may be limited at the usual office hours or in the middle night (European time).
It may seem that I have some prejudice against Mer, but have a look at this relatively recent bugreport for example: https://github.com/ssvb/xf86-video-fbturbo/issues/25 Nothing can be ruled out and it is difficult to make any assumptions about what could be possibly wrong in the user's system.
There is one more thing that may be relevant for you. The old r3p0 version of the mali blob can't fully utilize both pixel processors of the Mali400 MP2. So the performance is not optimal on Allwinner A20. It is possible to upgrade to a newer version r3p2-01rel2 of the blob to get better performance, but I was not very sure about it without a good justification (like somebody having a real use for OpenGL ES and able/willing to report bugs): http://thread.gmane.org/gmane.comp.hardware.netbook.arm.sunxi/4676 Also blobs are a temporary placeholder solution until we get free open source drivers. Investing extra efforts into getting blobs running may be counter productive at this moment.
On Wednesday 11 December 2013, you wrote:
at that point it can be documented (or fixed if there is anything to fix and wasn't just wrong procedure at some point)
Thanks. I'm definitely interested to know what was causing. Just to be sure that we can avoid it in the future. Also please report any other problems or oddities if you encounter them (preferably to the bugtracker, and not to this mailing list). Using irc is also fine for quick questions, but my presence may be limited at the usual office hours or in the middle night (European time).
It turns out the reason is the file /usr/lib/libGLESv2.so , link to /usr/lib/libGLESv2.so.2 was missing , and that caused gles apps to fail silently (without exiting for not having fount the proper library)
So, the kind of error it does is strange indeed, but is solved
Cheers, Marco Martin
That is not what I class as a rant.
Well, according to one of the definitions at https://www.vocabulary.com/dictionary/rant
"A rant is an argument that is fueled by passion, not shaped by facts."
Less girlie talk and more action me thinks.
If you are putting forward ideas that needs money to be spent or resources to be allocated, then just ask, and we are all ears.
I'm interested in getting touch working with EOMA if anyone has that working?
On Monday, December 9, 2013 12:41:59 Siarhei Siamashka wrote:
Except that it also touched linux-sunxi wiki, linux-sunxi defconfigs and the mali400 graphics drivers support on sunxi hardware. And kinda implied that a poor job is also being done there.
Let me clear that up so you don’t have to try and interpret implications:
The linux-sunxi wiki is not a problem in itself. Neither is elinux.org. Or rhombus-tech.com. However, to get anything meaning done with EOMA + AW SoC + Linux one needs to use pieces of all of them, and all are in varying states of detail and freshness.
The linux-sunxi kernel is not perfect. Mostly because it is starting from something that isn’t perfect and has few resources applied to it. So, the answer is: participate towards improvement.
Sadly, there are no documented means to do so other than things like “email $SOMEONE” and “get on IRC when people are there”. Even that has to be found out by asking people directly. I spent ~2am-5am my local time on Saturday on irc to work through one issue, which is an insane time to do so. I’ve asked where coordination happens, where bug reports are managed, about the structure of the wiki .. the answers I keep getting are unsatisfactory from the perspective of someone not already in the club.
mali400 graphics drivers: not your problem to deal with. They are a closed blob of horror. That can be quite frustrating, but *it is not your issue*.
Was there even any effort made to communicate with the linux-sunxi community?
Yes, there were. Why don’t you know? Because the communication methods available are not well ordered. That’s something I’d like to see improved.
For the OpenGL ES support in X11 on sunxi hardware, I have a project page here, which happens to list some contact information and describes the process of reporting issues: https://github.com/ssvb/xf86-video-fbturbo
Yep, and we are using stuff from there. That is actually one of the better documented things around, as it is mentioned here:
http://linux-sunxi.org/Binary_drivers http://linux-sunxi.org/Packages
I’d love to see that driver enhanced even further. We happen to have a developer with our company who has extensive experience with x.org and opengl development. The sad that is that right now the last thing I would suggest to them is to get involved because I really don’t want to expose them to the nature of this community as presented in this thread or on irc over the weekend. I have to wonder how many others have walked away due to that sort of interaction.
Yes, the OpenGL ES issue has been successfully communicated via IRC. Nice job. Still Aaron described dealing with this particular issue using WTF word. Now I'm really curious what was my fault and how we can improve from this point?
I’m a big boy and sometimes I use big boy language. If you’re going to get bent out of shape about three letters like “WTF”, this is going to be really difficult.
That said, the “WTF” is due to the binary blob that is the mali driver we have to work with today. You have very little to do with that, last time I checked. Why are you taking this so personally?
Joem, if you have nothing really constructive to say, please just don't get in the way.
If you want people involved, the best way to not accomplish that is to tell them to go away. joem’s input was measured, nice and obviously with the intent to improve things.
Your characterization of him “getting in the way” is pretty distasteful stuff. This appears to be the norm here, and you all need to decide whether you want to shift that norm in hopes of building a bigger, more vibrant community.
Go compare the reactions in this thread to what goes on in, say, the RPi community. Notice that RPi is pretty big? Those things are connected.
On Monday, December 9, 2013 09:28:13 you wrote:
On Sun, 08 Dec 2013 02:34:12 +0100
"Aaron J. Seigo" aseigo@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.
The communication problem not being resolved feels unsettling. Aaron J. Seigo recommends holding IRC meetings. Siarhei Siamashka bullies him. Luke, Joem and I defend Aaron Seigo. Siarhei Siamashka bullies Joem for definding Aaron Seigo. Aaron Seigo and Joem try defending themselves. The other members are silent. Are they bullied into silence?
Aaron Seigo is reluctant to invite newcomers to this mailing list. Other members may be too. Hence, Siarhei Siamashka won.
All forums need a policy of no bullying. Bullies are to be for warned once. If they bully again, be banned.
Siarhei Siamashka, consider this a warning. Learn how to give constructive criticism when appropriate.
Siarhei Siamashka, you owe Aaron and Joem an apology.
On Tuesday 10 December 2013, freebirds@fastmail.fm wrote:
The communication problem not being resolved feels unsettling. Aaron J. Seigo recommends holding IRC meetings. Siarhei Siamashka bullies him. Luke, Joem and I defend Aaron Seigo. Siarhei Siamashka bullies Joem for definding Aaron Seigo. Aaron Seigo and Joem try defending themselves. The other members are silent. Are they bullied into silence?
I just joined few days ago so I can't really tell, but there may be things that I see working in other communities that may be applicable here: a more clear roadmap done with periodic irc meetings as Aaron suggested would help.
Also, many communities have a code of conduct agreed upon. Disagreements are things that do happen, this is unavoidable (and healthy, even), what should be avoidable is disagreements degenerating in attacks or flamewars. To be able to say that somebody has crossed the line, is important that the line is clearly defined in the first place, would probably avoid some misunderstandings.
Just my 2 cents from someone that is still an outsider, so take it with a grain of salt :)
Cheers, Marco Martin
On Tue, 10 Dec 2013 10:37:52 -0800 freebirds@fastmail.fm wrote:
The communication problem not being resolved feels unsettling. Aaron J. Seigo recommends holding IRC meetings.
This all is perfectly fine and I don't have anything to say about how the EOMA-68 community should or should not organize itself. I think this should have been clear from the very start: http://thread.gmane.org/gmane.comp.hardware.netbook.arm/8462
Siarhei Siamashka bullies him. Luke, Joem and I defend Aaron Seigo. Siarhei Siamashka bullies Joem for definding Aaron Seigo. Aaron Seigo and Joem try defending themselves. The other members are silent. Are they bullied into silence?
Do you realize that our little dispute with Aaron Seigo has nothing to do with you, Joem and/or EOMA-68 community? Other than just happening in the arm-netbook mailing list. I'm sorry for exposing unrelated people to all this noise.
Aaron Seigo is reluctant to invite newcomers to this mailing list. Other members may be too. Hence, Siarhei Siamashka won.
All forums need a policy of no bullying. Bullies are to be for warned once. If they bully again, be banned.
Siarhei Siamashka, consider this a warning. Learn how to give constructive criticism when appropriate.
Now I hope that you see that your message was not appropriate. If not, then please re-read the whole thread again and try not to exaggerate/misinterpret things next time.
Siarhei Siamashka, you owe Aaron and Joem an apology.
If we happen to apologize to each other as the outcome of our dispute with Aaron, this is going to happen not because of your threats, but despite of them. Your participation is not doing any good.
On Wednesday, December 11, 2013 00:07:19 Siarhei Siamashka wrote:
Do you realize that our little dispute with Aaron Seigo has nothing to do with you, Joem and/or EOMA-68 community?
FWIW, I have never perceived this as a dispute. I didn’t even realize there was anything to even dispute until Siarhei and libv got rather upset on irc (while I wasn’t even there, btw). Having slowly come to an understanding of what their issues were, I have tried to clear them up.
Sadly, There has been no response to my emails from a couple days ago on this list, although Siarhei apparently had time to respond to Freebird’s email. That is disappointing, as I’d really rather resolve the issues than have people choose sides.
Siarhei: can you please acknowledge what I wrote on Monday? Thanks in advance.
Sent from my android device.
-----Original Message----- From: joem joem@martindale-electric.co.uk To: Linux on small ARM machines arm-netbook@lists.phcomp.co.uk Sent: Wed, 11 Dec 2013 9:51 AM Subject: Re: [Arm-netbook] Flashing the NAND
FWIW,
Stop playing with the trolls, take the money, make more EOMAs and put more MER into it :)
+1
FYI I located source for PCMCIA cases and thinking of ordering 100 cases for emergency projects. Not sure if that would be useful for anything at this moment.
_______________________________________________ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
On Wed, 11 Dec 2013 14:37:37 +0100 "Aaron J. Seigo" aseigo@kde.org wrote:
On Wednesday, December 11, 2013 00:07:19 Siarhei Siamashka wrote:
Do you realize that our little dispute with Aaron Seigo has nothing to do with you, Joem and/or EOMA-68 community?
FWIW, I have never perceived this as a dispute. I didn’t even realize there was anything to even dispute until Siarhei and libv got rather upset on irc (while I wasn’t even there, btw). Having slowly come to an understanding of what their issues were, I have tried to clear them up.
I just felt that your statement:
- there are numerous gotchas (like that opengl demo program that you
have to run first to get opengles started on the A20.. wtf?) that are quietly hidden away. they are on no roadmap, have no prioritization and nobody seems to work on them. (those three things are interrelated.)
was borderline rude (let's call it this way). Because the opengl issue, provided as an example, had absolutely nothing to do with being "hidden" or "nobody working on it". This all was happening at the very same time, when we were trying to identify the root cause of it together with Marco Martin, who reported the issue only about a day before.
Now it's understandable that the real work is being done by Marco Martin and you are just acting as a middleman. This clearly hinders communication and increases the chances of misunderstanding.
About my (over)reaction. The arm-netbook mailing list is not even the right place to report the issues like this (they are outside of the scope of EOMA-68). That felt like I was bad mouthed behind my back. Then instead of silently holding a grudge against you, I decided that it would be much better to request for explanations and clear all misunderstandings.
Another somewhat unexpected thing is how little people from around here know about linux-sunxi. I can't find any posts from you, joem or freebirds in the linux-sunxi mailing list. Yet linux-sunxi is providing *software* support for Allwinner SoCs (unless you are using the Android SDK from Allwinner). The *hardware* projects and the companies working on them, such as RhombusTech, OLIMEX, CubieTech and the others all depend on linux-sunxi. Ignoring the linux-sunxi existence is just asking for communication troubles. Where do you get your kernel sources for Allwinner hardware? Are the EOMA-68 people assuming that all this work is somehow being magically done by elves while nobody is looking?
Now it became clear that the people around here are likely under the influence of Luke Kenneth Casson Leighton, who boycotts linux-sunxi mostly because of the use of google groups and github services. This issue has been identified and, I believe, already addressed (see the replies from "mnemoc" to "lkcl"): http://irclog.whitequark.org/linux-sunxi/2013-12-09 In particular this reply: "<mnemoc> there are real technical reasons against google groups, as there are technical reasons to want mirrors of our repos outside github.com".
So is everyone going to be happy now? This would be great.
Sadly, There has been no response to my emails from a couple days ago on this list, although Siarhei apparently had time to respond to Freebird’s email. That is disappointing, as I’d really rather resolve the issues than have people choose sides.
Siarhei: can you please acknowledge what I wrote on Monday? Thanks in advance.
In fact I don't have that much free time to waste on this mostly pointless discussion anymore :(
Sadly your mails are long and verbose. And I feel like replying to all of them would do nothing good other than backing you into a corner (because you still don't seem to have a coherent story due to missing or misinterpreting bits of information here and there).
To sum it up: it is very likely that you had good intentions, yet you made me unhappy. However that's not a big deal and I can live with that.
I'll only reply to this part, because I think it is relevant:
That said, the “WTF” is due to the binary blob that is the mali driver we have to work with today. You have very little to do with that, last time I checked. Why are you taking this so personally?
We can't blame the binary blob for all the problems. My take on this is that xf86-video-fbturbo has to work at least as good as xf86-video-mali. If *anything* happens to work worse, that's *my* problem without doubt. And I want bugs to be reported to me, just to see whether anything can be done.
On Friday, December 13, 2013 03:23:35 Siarhei Siamashka wrote:
Because the opengl issue, provided as an example, had absolutely nothing to do with being "hidden" or "nobody working on it”.
a) look at the mailing list i sent it to b) point me to the roadmap showing what work is scheduled c) given the progress in the last year, it’s evident very little manpower is on this set of issues d) i’m mostly concerned with upstream interactions; again: not everything is about you or linux-sunxi
Now, evidently you are working on integration of the drivers. So *somebody* is working on it. That’s great to know, and I was wrong in saying “nobody”.
The issue that is obviously there is that what work is being done is very opaque to anyone not you or the 2-3 other people deeply involved. Other people I talked to who also use A10/A20 devices similarly had no idea what was up.
That communication and documentation barrier is what I want to see addressed. It’d be much nicer to improve the situation than throw spears at each other.
Instead of getting pissy about "nobody", step back and think why that is: maybe it’s because the visibility of work being done is very low. Your users are unable to see through the "fog of war” to gain perspective on what *is* happening . Then think about how to improve that.
Because then, instead of arguing with me, you’d be able to solve this issue for every single person who comes along in the future. I’d go so far as to suggest that by doing so you’ll have more people who come along in the future as well.
This all was happening at the very same time, when we were trying to identify the root cause of it together with Marco Martin, who reported the issue only about a day before.
I’ll belabour the point: where is the bug tracker, task list, etc. we can consult to know this?
Now it's understandable that the real work is being done by Marco Martin and you are just acting as a middleman.
Not really, but it’s also irrelevant.
About my (over)reaction. The arm-netbook mailing list is not even the right place to report the issues like this (they are outside of the scope of EOMA-68).
I agree; however, there is so much overlap and the barriers between the various projects that ought to work together well are large enough that knowing who, where and when to communicate is utterly unclear. That can be improved on, but we can’t fault people for hitting the “wrong” communication channel when there is utterly unclear lines.
That felt like I was bad mouthed behind my back.
Not only did you read that incorrectly, but you then lashed out instead of asking questions to gain information that would have cleared it up. That is not cool.
Then instead of silently holding a grudge against you, I decided that it would be much better to request for explanations and clear all misunderstandings.
By being aggressive and accusing me of various things? Look, I appreciate that you didn’t just sit on it. That indeed would have been worse. Perhaps instead of responding as you did, you could have asked me what was meant by things instead of going off and *rampantly* misinterpreting things I wrote on G+ (e.g.) that had *nothing* *at* *all* to do with you or linux-sunxi. Better yet, let’s try and put together the communication and documentation infrastructure to prevent such problems in future.
My instinctive reaction is “this community is very volatile and puts very little value on coordination and communication ... I should be looking for a different SoC family to work with.”
That’s the kind of reaction a lot of people will have which limits participation and growth. This is not unique to linux-sunxi, it’s common to many open projects with similar attributes.
Another somewhat unexpected thing is how little people from around here know about linux-sunxi. I can't find any posts from you, joem or freebirds in the linux-sunxi mailing list. Yet linux-sunxi is providing *software* support for Allwinner SoCs (unless you are using the Android SDK from Allwinner). The *hardware* projects and the companies working on them, such as RhombusTech, OLIMEX, CubieTech and the others all depend on linux-sunxi. Ignoring the linux-sunxi existence is just asking for communication troubles. Where do you get your kernel sources for Allwinner hardware? Are the EOMA-68 people assuming that all this work is somehow being magically done by elves while nobody is looking?
This is exactly why I want to have some coordination meetings in January. I’m glad we’re seeing the same issues now :)
Now it became clear that the people around here are likely under the
Not really; it’s more like:
* lkcl talks to people and reaches out beyond his borders * the lack of documentation and scatter shot of information sources makes it very difficult to connect with the most effective sources
Perhaps instead of blaming lkcl et al you could instead ask yourself why linux-sunxi isn’t more visible or providing a set of resources that are useful enough to people that they gravitate towards that source.
So is everyone going to be happy now? This would be great.
We’ll get there :)
Sadly, There has been no response to my emails from a couple days ago on this list, although Siarhei apparently had time to respond to Freebird’s email. That is disappointing, as I’d really rather resolve the issues than have people choose sides.
Siarhei: can you please acknowledge what I wrote on Monday? Thanks in advance.
In fact I don't have that much free time to waste on this mostly pointless discussion anymore :(
It’s not pointless to figure out the sources of the challenges you outlined above and figure out how to address them.
I'll only reply to this part, because I think it is relevant:
That said, the “WTF” is due to the binary blob that is the mali driver we have to work with today. You have very little to do with that, last time I checked. Why are you taking this so personally?
We can't blame the binary blob for all the problems.My take on this is that xf86-video-fbturbo has to work at least as good as xf86-video-mali.
.. and I wasn’t referencing fbturbo. You are reading things as if they are about you when they aren’t.
If *anything* happens to work worse, that's *my* problem without doubt. And I want bugs to be reported to me, just to see whether anything can be done.
That’s completely fair; where is your bug tracker at?
My instinctive reaction is “this community is very volatile and puts very little value on coordination and communication ... I should be looking for a different SoC family to work with.”
Firstly Aaron, don't let unproductive trolls drag you into a decision making process. Over the years, I have learned you can choose to ignore their comments. Absolutely nothing they can do about it :) :) Eventually they go away and do some work and come back with more productive comments.
For every quality post by a person such as yourself, you will find up to 200 troll posts and rants snipping at you. It is not economic to respond to these trolls and rants. Its just a fact of life, trolls exist, just ignore them, all of us do, there is *nothing* they can say or do which will dent your reputation here :)
2nd, we all here because we all looked hard and find Allwinner chip price and level of cooperation as a complete package, optimal.
If switching to alternative SoC, cooperation may be higher but SoC price higher, or price may be lower but cooperation with open source world low. Either way, open source products made with alternative SoCs liable to become irrelevant to market.
This an opportunity for one of us to get rich, spend $1m buy ARM license, and found RealWinner Corporation (TM) which will be first company to make ARM chip with *SINGLE* header file that describes *ALL* hardware registers and *ALL* bit fields.
So when RealWinner Corporation (TM) make the second chip, it takes mere hours and days with new header file to port all previous work to it.
Sounds simple plan, and it really is that simple.
I do it all day with PIC chips. Sadly Microchip don't make big SoCs to run Linux properly yet.
If they or ReallWinner Corporation (TM) made this first true ARM SoC with single header file, they will *COMPLETELY* sweep aside *ALL* other chip vendors as the open source hoards descend on this chip and port absolutely everything to this new chip with the single header file.
On Tue, 2013-12-10 at 10:37 -0800, freebirds@fastmail.fm wrote:
<girlie_shrieky_voice>
The communication problem not being resolved feels unsettling. Aaron J. Seigo recommends holding IRC meetings. Siarhei Siamashka bullies him. Luke, Joem and I defend Aaron Seigo. Siarhei Siamashka bullies Joem for definding Aaron Seigo. Aaron Seigo and Joem try defending themselves. The other members are silent. Are they bullied into silence?
</girlie_shrieky_voice>
In any case it is 100% wrong :)
What I said was if you have hardware / software that needs building and/or resources that need allocating, let us know and we'll see what can get done.
There is too much work to be getting on with, so send requests and summaries in short form.
On Fri, Dec 6, 2013 at 11:57 AM, Aaron J. Seigo aseigo@kde.org wrote:
On Thursday, December 5, 2013 23:04:45 luke.leighton wrote:
hi marco, welcome to the list, and thanks for agreeing to post these questions publicly so that others can help answer them, and more can benefit from everyone's replies.
what surprises me is that all this apparent work has been done and yet:
it hasn't. everyone else who has sold sunxi-related product has used the default GPL-violating binaries supplied by allwinner (and has typically used the proprietary w32 tools to load them up).
do people on this list ever hold irc meetings?
no. there's no "leaders", only "peers". out of those peers, they do the work they feel motivated to do, in their own available time, and, on irc, they are available online at times that are convenient to them. i'm including the sunxi community in that assessment as well.
l.
On Friday, December 6, 2013 12:44:42 luke.leighton wrote:
On Fri, Dec 6, 2013 at 11:57 AM, Aaron J. Seigo aseigo@kde.org wrote:
On Thursday, December 5, 2013 23:04:45 luke.leighton wrote:
hi marco, welcome to the list, and thanks for agreeing to post these questions publicly so that others can help answer them, and more can benefit from everyone's replies.
what surprises me is that all this apparent work has been done and yet:
it hasn't. everyone else who has sold sunxi-related product has used the default GPL-violating binaries supplied by allwinner (and has typically used the proprietary w32 tools to load them up).
ignore boot0/boot1 and sum up everything from “booting from sd card”, “flashing nand”, “building a kernel that actually does useful things like see nand partitions”, “getting opengl to work”, etc.
yes, the hardware companies are making this harder than necessary, but when we get to say things like "also much of this stuff is current-knowledge in $PERSON's head”, point people to N different wikis all in different states of usefulness and we still have to dive into source code to re-discover what others may or may not have done .. that’s *insanity*
knowledge is being generated and then *thrown away*. that’s good enough for tinkerers and hobbyists who want to learn a little something but it is not good enough for building either a dynamic Free software community nor a business environment around.
do people on this list ever hold irc meetings?
no. there's no "leaders", only “peers”.
i didn’t ask if there were leaders (whatever you might mean by that). i asked if there were meetings. peers meet, too, and can do so of their own volition.
and pls don’t confuse “coordination” with “leadership” or “coordinator” with “leader”. they are not necessarily the same thing.
out of those peers, they do the work they feel motivated to do, in their own available time, and, on irc, they are available online at times that are convenient to them.
this is true of every single other tech community i have ever been a part of. those communities (at least the successful onese) have all managed to coordinate meetings on a regular basis in which we coordinate and plan, thus preventing things like knowledge loss.
i'm including the sunxi community in that assessment as well.
yes, seems that way indeed.
which brings us to the last question i posed:
"would people be open to having one with the goal of improving this situation?”
you can’t answer for everyone, but you can answer for yourself.
On Fri, Dec 6, 2013 at 1:20 PM, Aaron J. Seigo aseigo@kde.org wrote:
On Friday, December 6, 2013 12:44:42 luke.leighton wrote:
knowledge is being generated and then *thrown away*.
not when i'm doing it. i document everything as i'm going along, because i've done this a number of times. it does however begin to try my patience to have to follow up pretty much every single message to arm-netbooks with "could you please put that on the wiki". approximately every 20th time i've written that i've sent a message asking people to do that for themselves. those people with experience in the use of wikis (and their beneift) follow that request.
"would people be open to having one with the goal of improving this situation?”
yes!
On Friday, December 6, 2013 14:55:43 luke.leighton wrote:
On Fri, Dec 6, 2013 at 1:20 PM, Aaron J. Seigo aseigo@kde.org wrote:
On Friday, December 6, 2013 12:44:42 luke.leighton wrote:
knowledge is being generated and then *thrown away*.
not when i'm doing it. i document everything as i'm going along, because i've done this a number of times. it does however begin to
I know you try to do this, but it isn’t producing results useful to others.
try my patience to have to follow up pretty much every single message to arm-netbooks with "could you please put that on the wiki”.
That’s because the wiki is not useful. If it were, people would be using it.
In part this is because there is no “the wiki”: there is the wiki on rhombus- tech.net which starts with "Welcome to Rhombus Tech, a CIC company”, there is elinux.org which a wonderful maze of relevant and not-relevant information and there is the linux-sunxi.org wiki.
We should discuss all this during the future irc meeting, starting by defining what our needs are as a group, what our expectations are, cataloging our current assets and then creating process that may work for us to move us forward.
"would people be open to having one with the goal of improving this situation?”
yes!
ok, cool. for you, evenings (UTC) and weekends work better than daytime, correct? i’m thinking of something in early January to get this started ...
replies brief, fell off bicycle, damaged shoulder.
On Fri, Dec 6, 2013 at 5:30 PM, Aaron J. Seigo aseigo@kde.org wrote:
On Friday, December 6, 2013 14:55:43 luke.leighton wrote:
On Fri, Dec 6, 2013 at 1:20 PM, Aaron J. Seigo aseigo@kde.org wrote:
On Friday, December 6, 2013 12:44:42 luke.leighton wrote:
knowledge is being generated and then *thrown away*.
not when i'm doing it. i document everything as i'm going along, because i've done this a number of times. it does however begin to
I know you try to do this, but it isn’t producing results useful to others.
notes needed. info good. not enough collaboration. too early.
try my patience to have to follow up pretty much every single message to arm-netbooks with "could you please put that on the wiki”.
That’s because the wiki is not useful. If it were, people would be using it.
no product. beyond most people to be honest. i'm motivated, but not paid. others: no motivation, nor any pay. result: no long-term contributions! lots of people help along the way though. really really grateful.
In part this is because there is no “the wiki”: there is the wiki on rhombus- tech.net which starts with "Welcome to Rhombus Tech, a CIC company”, there is elinux.org which a wonderful maze of relevant and not-relevant information and there is the linux-sunxi.org wiki.
sunxi went off did their own thing.
We should discuss all this during the future irc meeting, starting by defining what our needs are as a group, what our expectations are, cataloging our current assets and then creating process that may work for us to move us forward.
good idea. you're good at that. i have a different style.
"would people be open to having one with the goal of improving this situation?”
yes!
ok, cool. for you, evenings (UTC) and weekends work better than daytime, correct?
yes.
i’m thinking of something in early January to get this started ...
great.
-- Aaron J. Seigo
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
luke.leighton <luke.leighton <at> gmail.com> writes:
Hey list,
(attempt two, I don't think my client was setup properly the first time)
replies brief, fell off bicycle, damaged shoulder.
Poor you, always having bad luck. I do hope you get well soon!
On Fri, Dec 6, 2013 at 5:30 PM, Aaron J. Seigo <aseigo <at> kde.org> wrote:
On Friday, December 6, 2013 14:55:43 luke.leighton wrote:
On Fri, Dec 6, 2013 at 1:20 PM, Aaron J. Seigo <aseigo <at> kde.org> wrote:
On Friday, December 6, 2013 12:44:42 luke.leighton wrote:
knowledge is being generated and then *thrown away*.
not when i'm doing it. i document everything as i'm going along, because i've done this a number of times. it does however begin to
I know you try to do this, but it isn’t producing results useful to others.
notes needed. info good. not enough collaboration. too early.
try my patience to have to follow up pretty much every single message to arm-netbooks with "could you please put that on the wiki”.
That’s because the wiki is not useful. If it were, people would be using it.
no product. beyond most people to be honest. i'm motivated, but not paid. others: no motivation, nor any pay. result: no long-term contributions! lots of people help along the way though. really really grateful.
In part this is because there is no “the wiki”: there is the wiki on
rhombus-
tech.net which starts with "Welcome to Rhombus Tech, a CIC company”,
there is
elinux.org which a wonderful maze of relevant and not-relevant
information and
there is the linux-sunxi.org wiki.
sunxi went off did their own thing.
I know you are a little bitter about this, but let me say clearly, I think you are doing a great thing with EOMA86 and appreciate everything you have done so far!
When I joined linux-sunxi (via the arm-netbook IRC channel) it was on a follow up from the XBMC A10 thread. I was very interested in the A10 as it could potentially be a Free (libre) mediacenter. I initially even got a Pivos with AMLogic but sold that since in favor of the A10. My first A10 device was a tablet I gotten that had the A10 by chance, hence my looking into the sunxi community. While true, at this point the split already happened I feel that this only as evolution.
Linux-sunxi focuses only on the SoC, Rhombus/Eoma around the eoma specifically. What will happen if EOMA uses an AMLogic for the next iteration (or rockchip). The A10 would have been let to rot a little. Now there's a community around it. Sunxi seems to focus mostly on the olimex and cubietech boards these days (as they gave dev boards to devs) and whatever tablet of the week pops by.
So while I've heard the splitting of the two communities didn't maybe go the prettiest of ways, it's healthy that it did.
More cooperation is only good and on that note, I wonder if EOMA et al will be at FOSDEM 2014?
Oliver
We should discuss all this during the future irc meeting, starting by
defining
what our needs are as a group, what our expectations are, cataloging our current assets and then creating process that may work for us to move us forward.
good idea. you're good at that. i have a different style.
"would people be open to having one with the goal of improving this situation?”
yes!
ok, cool. for you, evenings (UTC) and weekends work better than daytime, correct?
yes.
i’m thinking of something in early January to get this started ...
great.
-- Aaron J. Seigo
arm-netbook mailing list arm-netbook <at> lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook <at> files.phcomp.co.uk
arm-netbook mailing list arm-netbook <at> lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook <at> files.phcomp.co.uk
fre 2013-12-06 klockan 20:52 +0000 skrev luke.leighton:
sunxi went off did their own thing.
linux-sunxi spun off because very little of it is EOMA relevant and felt inappropriate for the context. Further rhombus-tech is not a community.
There is also a number of other reasons why, and we have talked about that before. Not the right place to discuss that here. But the creation of linux-sunxi was inevitable at the time.
Regards Henrik
On Fri, 06 Dec 2013 18:30:10 +0100 "Aaron J. Seigo" aseigo@kde.org wrote:
On Friday, December 6, 2013 14:55:43 luke.leighton wrote:
On Fri, Dec 6, 2013 at 1:20 PM, Aaron J. Seigo aseigo@kde.org wrote:
On Friday, December 6, 2013 12:44:42 luke.leighton wrote:
knowledge is being generated and then *thrown away*.
not when i'm doing it. i document everything as i'm going along, because i've done this a number of times. it does however begin to
I know you try to do this, but it isn’t producing results useful to others.
try my patience to have to follow up pretty much every single message to arm-netbooks with "could you please put that on the wiki”.
That’s because the wiki is not useful. If it were, people would be using it.
In part this is because there is no “the wiki”: there is the wiki on rhombus- tech.net which starts with "Welcome to Rhombus Tech, a CIC company”, there is elinux.org which a wonderful maze of relevant and not-relevant information and there is the linux-sunxi.org wiki.
We should discuss all this during the future irc meeting, starting by defining what our needs are as a group, what our expectations are, cataloging our current assets and then creating process that may work for us to move us forward.
"would people be open to having one with the goal of improving this situation?”
yes!
ok, cool. for you, evenings (UTC) and weekends work better than daytime, correct? i’m thinking of something in early January to get this started ...
Just a question to avoid any possible misunderstanding. Are you trying to organize and manage only the Rhombus / EOMA / Mer people? Or is it a larger scale ambition?
Because if it's related to EOMA and arm-netbook list only, then it's really your own business.
But if you also include linux-sunxi.org in your plans, then I propose to first learn a bit more about this community. It just looks like you literally appear from nowhere, have only incomplete preliminary information and already trying to enforce your own rules on the others. Not everyone is going to appreciate this.
On Sat, Dec 7, 2013 at 12:42 AM, Siarhei Siamashka siarhei.siamashka@gmail.com wrote:
On Fri, 06 Dec 2013 18:30:10 +0100 "Aaron J. Seigo" aseigo@kde.org wrote:
ok, cool. for you, evenings (UTC) and weekends work better than daytime, correct? i’m thinking of something in early January to get this started ...
Just a question to avoid any possible misunderstanding. Are you trying to organize and manage only the Rhombus / EOMA / Mer people? Or is it a larger scale ambition?
siarhei, i'm the maintainer and instigator of the arm-netbooks project, and the creator of the EOMA standards. i invited aaron here because he has a significant amount of both business and software libre project management. he's also QiMod's first main client. we've been talking for over a year now however it's only been appropriate for him to surface from private discussions once the decision was made to bring Improv out. so there's been a lot going on in the background.
regarding your questions: i have a completely different kind of leadership style from aaron. my style is one that comes from experience in "leading by technical example" software libre project management, over the past 15 years. so that means less structure, continuous availability (response to mailing list questions within minutes or hours), more hands-off and inviting people, within certain guidelines, to basically do whatever they want.
with the samba tng project, that worked extremely well. the nature of the project meant that some highly gifted and highly self-motivated individuals joined - elrond, matthew chapman, jean-francois micouleau to name a few - and contributed significantly based on the infrastructure that i'd put in place.
again, until it was hijacked, that approach worked extremely well with the pyjamas project. i took over "by default" - after luke howard had abandoned it - and several highly-motivated extremely competent and independent people again began to contribute, loved what was being done: i set the rules, and people followed them happily (until some idiot decided he didn't like them, encouraged others to hijack the domain, and now the project's cohesion and reputation has been destroyed).
with the xanadux project (the HTC smartphone reverse-engineering one), that was different: there were no "leaders" there, only peers. we kept in touch every day (pretty much without fail) over several years, coordinated via #htc-linux on freenode, and assembled a vast amount of information on the xda-developers wiki which is still relevant and useful for those devices we reverse-engineered, even today.
this project however is, i have to say, radically different. the key difference is that like many of the other seriously-heavy-duty technical projects i've been involved in i'm pretty much literally *the* only person with the skillset and motivation to get - let alone keep - things going, and this time it involves not just writing software but designing the hardware as well. i don't know anyone else who would, after making the mistake of not putting easy access to JTAG on a board that had *zero* software on it, and having no UART either to do debug printout messages, persist blind for *four weeks* in compiling up an entire linux OS stack *including* u-boot. with no debug output methods of any kind. it was only the persistence and patience i learned from the xanadux project that kept me going at it until i suceeded.
so that's a short version of some of my background. all the relevant bits of experience, none of which is helping to attract people to help out on a day-to-day basis because the skillsets required are too high, and the goals likewise. remember: the project also involves fixing some of the GPL-violations and respecting software freedom. that means that i also have to respect software freedom and software libre principles... *including* doing things like staying away from github and groups.google.com because they're non-free proprietary services. [yes i'm aware i have to stop using gmail, but i have over 45,000 messages stored on it, which makes it an immense task that i'm delaying].
now we have a client who is extremely skilled with people, believes not only in the project but also in the EOMA68 standard *and* respects and understands why software freedom is important, *and* has a successful business that is critically dependent on software libre and its principles. those principles extend out in a multitude of not-immediately-obvious ways, including how he and his associates interact with people, and, typically, they are so impressed and grateful at the [often unpaid initial] help provided that they soon become extremely loyal clients.
so given the critical phase we're at right now, where we're transitioning from 100% proven prototype to first serious production run, i need all the help that aaron's offering, and more. and, given that there's nobody else really responsible for this project except me (because of the high technical bar at the moment), then, as terry pratchett says: "i'm the man, and i've got the vote" :)
so that's some of the background. coming back to your question, let's cover it from the different angles you've raised.
1) as far as the rhombus tech side is concerned, it's fine. i need all the help i can get!
2) for the sunxi-community, i cannot speak for them because i was not invited to participate in that initiative, and they're running on non-free proprietary infrastructure so i cannot, in good conscience, participate directly in their community even if they asked me to and also say that i uphold the very founding principles which i have as good as vowed to honour. so until they fix that, i am forced to either communicate privately and solely with individuals in that community, post on this list and hope that they notice, or use #linux-sunxi freenode irc.
3) as far as EOMA68 (and the other EOMA standards) are concerned, i am its creator and guardian. nobody - EVER - will be permitted to represent the EOMA standards. i've already had to bring one or two people to task for misrepresentation bordering on fraud that could, by their mistakes, bring the standard into disrepute as well as open themselves up to mis-selling and consequent lawsuits (in their own 3rd party wholly-independent businesses)
NOBODY else will be given the authority to represent or speak authoritatively on the EOMA standards. i may at some point review that, including setting up a strict charter for the development of future standards and the custodianship of the existing ones at the time: we will have to see, but i first have to find people who can be trusted, and who are far-sighted enough, to do that. it's actually amazingly hard to design decent mass-volume-targetted standards, and i've yet to encounter anyone else - in the entire world (this is not a joke) - who is capable of doing that.
along the way, i will be happy to take input, contributions and considerations into account into the EOMA standards, but, ultimately, i am their guardian: once i make a decision and once a standard reaches a critical point, it's final, and that is the non-negotiable end of the matter.
so does that rather long answer help explain matters, siarhei?
l.
On Fri, Dec 6, 2013, at 04:42 PM, Siarhei Siamashka wrote: "It just looks like you literally appear from nowhere, have only incomplete preliminary information and already trying to enforce your own rules on the others. Not everyone is going to appreciate this. . . ."But if somebody thinks that it is possible to achieve better results by "holding meetings" and "creating processes", then feel free to do so and prove me wrong :)"
I disagree that Aaron J. Seigo is "trying to enforce his own rules on the others." I appreciate Aaron Seigo making recommendations including starting IRC meetings. Meetings are democratic. If Aaron Seigo intended to dictate, he wouldn't ask for feedback to hold the first meeting in January. Regarding "literally appearing from no where" we need to welcome newcomers. Newcomers don't need to wait in the background for an extensive period of time before speaking up. Newcomers are to be encouraged to participate. If they have enough chutzpah to make recommendations based on "incomplete preliminary information", it is a way for all of us to learn, act and become involved. I thank Aaron Seigo for his time, efforts, motivation and speed that he is getting involved.
Luke, I hope your shoulder heals quickly.
Happy Holidays everyone.
On Saturday, December 7, 2013 07:43:08 freebirds@fastmail.fm wrote:
the others." I appreciate Aaron Seigo making recommendations including starting IRC meetings. Meetings are democratic. If Aaron Seigo intended to dictate, he wouldn't ask for feedback to hold the first meeting in January.
Precisely. The only reason I’d like to see coordination and communication is so that I can participate in meaningful ways with everyone else. I would have been far happier with someone else stepping up and suggesting this as it means I wouldn’t have to spend time on it :)
Regarding "literally appearing from no where" we need to
Given how opaque this community is, it should be of no surprise that there are probably many people that others can not see. If the EOMA68 / sunxi / arm- netbook communities were better organized, you all would’ve noticed me a lot sooner.
On Sun, Dec 8, 2013 at 1:37 AM, Aaron J. Seigo aseigo@kde.org wrote:
Given how opaque this community is, it should be of no surprise that there are probably many people that others can not see.
aaron: there are very few active key players because the knowledge/skill level is just too high. this should not be a big surprise, given that we're still in the phase of "pre-lots-of-feature-boards".
so we have, in effect, just me and maybe at any one time one or two part-time people helping out on a percentage basis that's in the low single digits on average, and over 350 lurkers who really _really_ want this project to succeed but right now really don't have anything to contribute other than lots of encouragement.
once Improv's out, that entirely changes. this and many other forums will, after that, go completely nuts.
l.
On Sunday, December 8, 2013 10:37:33 luke.leighton wrote:
On Sun, Dec 8, 2013 at 1:37 AM, Aaron J. Seigo aseigo@kde.org wrote:
Given how opaque this community is, it should be of no surprise that there are probably many people that others can not see.
aaron: there are very few active key players because the knowledge/skill level is just too high. this should not be a big surprise, given that we're still in the phase of "pre-lots-of-feature-boards".
It’s much simpler than that:
a) I have been around for, what, a year now? b) most people were completely unaware of that c) either i’m an outlier datapoint or there are more people like me
i’m betting on “more people like me”.
it has nothing to do with few active key players, ergo [...]
the connection is actually probably reversed: there are few key players because the interaction structures in place support and encourage opaque interactions.
if you and others wish to grow this space beyond having a few key active players, then we need to get onside with:
* supportive interactions * an approachable documentation strategy for clarity and knowledge retention
getting there requires communication, not releases of hardware products. because if that *were* the case, the plethora of other arm boards out there right now would have resolved issues seen on this list. it’s not like eoma68 is the only hardware group represented on this list. it’s just the most vocal / discussed.
Aaron J. Seigo <aseigo <at> kde.org> writes:
On Saturday, December 7, 2013 07:43:08 freebirds <at> fastmail.fm wrote:
the others." I appreciate Aaron Seigo making recommendations including starting IRC meetings. Meetings are democratic. If Aaron Seigo intended to dictate, he wouldn't ask for feedback to hold the first meeting in January.
Precisely. The only reason I’d like to see coordination and communication is so that I can participate in meaningful ways with everyone else. I would have been far happier with someone else stepping up and suggesting this as it
means
I wouldn’t have to spend time on it :)
In addition to that (and the discussion on #linux-sunxi) it should be said, that linux-sunxi is doing pretty 'ok'. While some may disagree with how it formed (and who was and was not invited, really? everybody is invited.). Sure we'd love to have more people write code or write documentation, but only so many man-hours available by volunteers.
Now we should also make it clear, there's clearly two 'camps' here. And while there should be, they are disjunctive right now, let me explain.
We have 2 projects here that should be collaborating. Rhombus-tech which does great work on the hardware side of things and Linux-sunxi which worries about the software side (of only Allwinner SoC's). Nice and clear separated and makes sense. If the next EOMA86 will be using AMLogic, then no problem, the community won't 'shift' but the EOMA community will also start talking to the AMLogic community. Anyway, I'm sure this doesn't need more explaining as it's quite obvious.
What is going on right now however, is that rhombus-tech appears to also take on the 'software-side' of things, rhombus git, no to little collaboration etc. But why you may ask? Because while G-mail is 'ok' to use but dev@linux-sunxi.org is 'verboten' to CC on patches/discussions? Because reading mails from linux-sunxi@google-groups.com is 'verboten'? A little far fetched and hypocritical if you ask me, but don't worry, we are in the slow transition of migrating away from google-groups, but as moving away from gmail takes time, at least give linux-sunxi the benefit of the doubt that also they are working on moving away from google-groups.
As for not using github because the webfrontend is closed (git clone git://github.com/linux-sunxi/linux-sunxi.git talks to the git server which probably is vanilla isn't it? So cloning, puhsing, syncing can all be done without touching proprietary code but don't worry, there is now also gitorious.org/linux-sunxi which IS open source. But even here, we hopefully have git.linux-sunxi.org setup soon too. This whole manhours and what to spend them on, actually writing code, or take time to setup things up.
Regarding "literally appearing from no where" we need to
Given how opaque this community is, it should be of no surprise that there
are
probably many people that others can not see. If the EOMA68 / sunxi / arm- netbook communities were better organized, you all would’ve noticed me a lot sooner.
Here also, without repeating myself too much, the sunxi community is doing pretty well, albeit short on man-power.
So there you have it. And again, nobody is excluded, nobody was deliberately not invited. Evolution at work if anything. And everybody is welcome, always.
Oliver
On Saturday, December 7, 2013 02:42:57 Siarhei Siamashka wrote:
Just a question to avoid any possible misunderstanding. Are you trying to organize and manage only the Rhombus / EOMA / Mer people?
I’m not trying to manage anyone. I simply would appreciate the opportunity to engage with others in creating a more transparent and vibrant community that has more of the attributes are important prerequisites to building both community and business interests.
Your response does fascinate me: Can you explain to me how you go from “can we have a meeting” (which is what I asked for) to hearing “I want to manage you”?
Or is it a larger scale ambition?
Here’s a really important thing to know about me: I’ll tell you what I’m thinking. You don’t have to guess. You don’t have to run around trying to figure it out. You get what you see. If I had larger scale ambitions (wtf that means), you’d know it because I’d say it, straight-up.
You can ask people who have worked with me in the past.
Because if it's related to EOMA and arm-netbook list only, then it's really your own business.
/me looks at the name of the mailing list he posted this to
But if you also include linux-sunxi.org in your plans, then I propose to first learn a bit more about this community.
I have no preconceived plans. If linux-sunxi people wish to participate in building a more productive community, awesome. If not, that’s fine, too.
Your statement here is actually built on the obviously absurd premise that I could just beckon the linux-sunxi.org community and somehow they’d be beholden to that. That isn’t how things work, and you evidently know that. What makes you think I don’t, too? :)
It just looks like you literally appear from nowhere, have only incomplete preliminary information and already trying to enforce your own rules on the others.
As I wrote in another email in this thread, the fact you didn’t now about me until now is a symptom of the opaque and structureless nature of this community.
Not everyone is going to appreciate this.
Good thing that’s not what I’m doing then, I suppose.
As I wrote in another email in this thread, the fact you didn’t now about me until now is a symptom of the opaque and structureless nature of this community.
there's people continuously joining, aaron, even now, and they don't necessarily all read every message. example: i still don't know if david and christopher are aware that there's been a second [announced] change to the EOMA68 specification. i had to contact you off-list in order to prompt them of a mistake they'd made by not reading the spec (wrong I2C address for the EEPROM).
l.
Sent from my iPhone
On Dec 8, 2013, at 4:30 AM, "luke.leighton" luke.leighton@gmail.com wrote:
As I wrote in another email in this thread, the fact you didn’t now about me until now is a symptom of the opaque and structureless nature of this community.
there's people continuously joining, aaron, even now, and they don't necessarily all read every message. example: i still don't know if david and christopher are aware that there's been a second [announced] change to the EOMA68 specification. i had to contact you off-list in order to prompt them of a mistake they'd made by not reading the spec (wrong I2C address for the EEPROM).
If you're referring to the change from address 0x50 to something else. Then yes, the address is 0x54.
l.
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
On Sun, Dec 8, 2013 at 4:42 PM, Christopher Thomas christopher@firemothindustries.com wrote:
Sent from my iPhone
On Dec 8, 2013, at 4:30 AM, "luke.leighton" luke.leighton@gmail.com wrote:
As I wrote in another email in this thread, the fact you didn’t now about me until now is a symptom of the opaque and structureless nature of this community.
there's people continuously joining, aaron, even now, and they don't necessarily all read every message. example: i still don't know if david and christopher are aware that there's been a second [announced] change to the EOMA68 specification. i had to contact you off-list in order to prompt them of a mistake they'd made by not reading the spec (wrong I2C address for the EEPROM).
If you're referring to the change from address 0x50 to something else.
there was no change from address 0x50 to something else. the address has always been 0x51. there was at one point some repetition of the (industry-wide) confusion over what constitutes an "address" in I2C, however that was cleared up. even without that clarification, the address has always been 0x51.
Then yes, the address is 0x54.
0x51. as listed in the specification, and as shown on the example schematic:
http://elinux.org/Embedded_Open_Modular_Architecture/EOMA-68#Requirements_fo...
as you were designing the schematics in private as a proprietary product - without the possibility of peer review - may i recommend that you double-check the Improv schematics, chris?
also, the second change that was made, after joe kindly investigated and brought it to my attention, was made on the 10th november, after some considerable discussion and a number of requests for clarification:
http://elinux.org/index.php?title=Embedded_Open_Modular_Architecture%2FEOMA-...
i did not hear from you chris, so i assumed that you were watching the list and had seen that modification to the standard, and that Improv Daughter Boards have taken that change into account?
i've been thinking that it may be appropriate to have a separate list (low-traffic by now) for EOMA68 (and other standards), just in case people are not properly paying attention at this critical phase before the standard is declared final. it already is... sort-of - but things like the RGB pinout change are ruled by "reality", where "reality" is defined by "what the very first CPU Card in the series is actually capable of".
l.
+++ Aaron J. Seigo [2013-12-06 18:30 +0100]:
On Friday, December 6, 2013 14:55:43 luke.leighton wrote:
On Fri, Dec 6, 2013 at 1:20 PM, Aaron J. Seigo aseigo@kde.org wrote:
On Friday, December 6, 2013 12:44:42 luke.leighton wrote:
knowledge is being generated and then *thrown away*.
not when i'm doing it. i document everything as i'm going along, because i've done this a number of times. it does however begin to
I know you try to do this, but it isn’t producing results useful to others.
Luke's docs have been (very) useful to me.
try my patience to have to follow up pretty much every single message to arm-netbooks with "could you please put that on the wiki”.
That’s because the wiki is not useful. If it were, people would be using it.
I'm using it. (read only so far as I've not contruibtued anything useful yet). I do agree that it's not well-strucutured and stuff is out of date, but that's pretty-much true the world over in wikis, unless $someone spends a _lot_ of time updating and merging and splitting to keep things relevant and well-organised.
In part this is because there is no “the wiki”: there is the wiki on rhombus- tech.net which starts with "Welcome to Rhombus Tech, a CIC company”, there is elinux.org which a wonderful maze of relevant and not-relevant information and there is the linux-sunxi.org wiki.
We should discuss all this during the future irc meeting, starting by defining what our needs are as a group, what our expectations are, cataloging our current assets and then creating process that may work for us to move us forward.
Yep, Some agreement of what should be where would defo be helpful and there is clearly a lot that could be done to make things easier to find without having to know an insider first (or where to look in this list).
I think IRC meetings would be useful. We could clearly lower the barrier of entry a lot, but to some degree that's more to do with getting support in the right places (e.g into mailine and distros) so things work as they should without needing to know a pile of magic runes, than about documenting all those magic runes..
"would people be open to having one with the goal of improving this situation?”
yes!
me too, anytime 11-3am european times works for me.
ok, cool. for you, evenings (UTC) and weekends work better than daytime, correct? i’m thinking of something in early January to get this started ...
In general weekends daytime is no use for me, but I'm not important round here, so worry about people who are :-)
Wookey
On Wednesday, December 11, 2013 14:21:03 Wookey wrote:
I think IRC meetings would be useful. We could clearly lower the barrier of entry a lot, but to some degree that's more to do with getting support in the right places (e.g into mailine and distros) so things work as they should without needing to know a pile of magic runes, than about documenting all those magic runes..
agreed; working on getting those things in place and making sure the results of those efforts are accessible to others is the reason for coordination.
as for days / times, i’ll put up a doodle for people to fill in closer to january so we can figure out some useful timings for as many people as possible.
fre 2013-12-06 klockan 14:20 +0100 skrev Aaron J. Seigo:
"would people be open to having one with the goal of improving this situation?”
one as in meetings?
Ofcourse. Just takes one who is interested in coordinating and calling for it, at a time that works for the right people.. (if possible).
Regards Henrik
On Thursday, December 12, 2013 22:31:57 Henrik Nordström wrote:
fre 2013-12-06 klockan 14:20 +0100 skrev Aaron J. Seigo:
"would people be open to having one with the goal of improving this situation?”
one as in meetings?
Ofcourse. Just takes one who is interested in coordinating and calling for it, at a time that works for the right people.. (if possible).
great :)
i was/am interesting in coordinating it, and plan to do so in january. see you there :)
tor 2013-12-05 klockan 23:04 +0000 skrev luke.leighton:
the key critical procedure behind that proprietary tool - the fel booting - has long since been reverse-engineered and put into u-boot.
Yes...
what *hasn't* yet been done is what allwinner did, which was to set up a small short non-OS-based "boot" system (which they split into two halves, boot0 and boot1, alongside some "apps" which go onto a DOS-formatted partition: these "apps" can be loaded at startup time by pressing keys - 1, 2 etc. etc). it's all horribly complicated yet amazingly the source code is actually available, it was accidentally included in the last allwinner-a20 3.3 SDK code-drop. they also compiled up u-boot with libnand attached to it, so that it could load the linux kernel from NAND.
Actually that to is done, just not polished up for general consumtion yet. We do have an u-boot SPL version that can boot directly from NAND. This version of u-boot is tailored for UBI usage, not AW libnand. But it is entirely possible to short-circuit by using only the SPL from this version cross-polinated with libnand u-boot if you want AW "libnand" format on the NAND.
Writing to the boot area is still a little bit rusty, but there do exists a Linux driver for it.
so there are several pieces to the puzzle:
- boot0 and boot1. the GPL-compliant source for this has been
tracked down. it should be easy to find, let me know if you have any difficulties.
But boot0/boot1 is not really needed, we have u-boot that fills that function pretty well with much less platform unique code.
- libnand-aware u-boot released by allwinner this, again, should be
easy to find, on hno's github u-boot repo and in several other places. *quick search*... https://github.com/linux-sunxi/u-boot-sunxi/wiki - ah, there you go - lichee-a20-dev branch. that'll do.
Yes..
a) a FEL boot b) to a MicroSD card c) use nand-part to create partitions d) write boot0 and boot1 directly to the 1st NAND partition (with dd)
Not quite... boot0 & boot1 resides outside of the NAND logical block partitions.
You need the nand boot area driver to write to this area of the NAND. The code is all there in libnand, just not exposed in Linux or u-boot.
does anyone else have any other recommendations or strategies? henrik i know you've wanted to have proper sunxi nand support in u-boot for some time.
Yes, but ran into a number of problems..
a) Out of time with other projects eating all my time at the moment (most of the past year). But hope to get that sorted out a bit.
b) There is no "the AW libnand". There exists at least three incompatible versions of "AW libnand".
c) none of the libnand versions can be supported to any reasonable level by the community as none of the people who work on that code is seen in the free software world at all.
d) AW libnand is ~15K lines of undocumented code (with some confusing chineese or chineese english comments) implementing a undocumented NAND FTL layer which is potentially patent infringing like most all other FTL implementations. Vere many unknowns.
The community try to fix up some things as we go, but it's slow with this FTL layer being a separate beast unique to sunxi and barely touched with a long pole by anyone else.
Looking at the other viable path, Using Linux MTD. This is slowed by slightly different parameters
a) As above.
b) NAND controller documentation is a bit sparse.. I think I have reversed most of it, but still feels as if I am missing something obvious.
c) The existing Linux MTD driver for sunxi needs some more work and incompatible format changes.
d) libnand and MTD is mutually exclusive. Only booting a kernel with one will likely wipe the NAND entirely if the other had been used previously. Both libnand and several ot the MTD based alternatives automatically format their storage area.
e) Linux MTD is serisouly patent hindered which hinders innovations in the area making general Linux NAND support progress very slow. So it's quite understandable if most people want an custom NAND FTL layer instead and use the NAND as a block device. Because of patents Linux can not have a generic NAND FTL layer.
Either way I would say it's a fairly high priority to get the existing boot block NAND driver polished up and committed to our common linux-sunxi tree. This would allow a full open toolchain for installing current libnand based systems while MTD support continues evolving.
Kernel sunxi MTD & boot driver: https://github.com/yuq/sunxi-nfc-mtd u-boot sunxi MTD driver: https://github.com/yuq/u-boot-sunxi/tree/mtd
Note: MTD driver is still in early stages and do have some noticeable shortcomings. Don't use it for any data that you care for.
Regards Henrik
arm-netbook@lists.phcomp.co.uk
-
Aaron J. Seigo -
Christopher Thomas -
freebirds＠fastmail.fm -
Henrik Nordström -
joem -
luke.leighton -
Marco Martin -
neal＠pengpod.com -
Olliver Schinagl -
Olliver Schinagl -
Siarhei Siamashka -
Wookey