Failed platform. . .

if u can wait for a couple of months as

(a) the prices of new platforms made in china always drop like a stone after a month or so
(b) the imx6 platform doesnt formally come on stream for a couple of weeks

also the samsung quad core SOC is rumoured to be making a push in to cheap chinese manufacturers as well ..

Samsung like Freescale has a decent reputation of linux support


I'm happy with my mele (as headless media server) for a good time yet but if i wanted something to run a full fat GUI linux distro on then i would only consider a quadcore and i'd be pretty confident that certainly by year end i'd have a quadcore media stick type device in the bag for sunstancially less than $100 (excl postage and import VAT/duty) by year end

rgds

ian

Quote
Guillaume
So Long, and Thanks for All the Fish

Science fiction fan? Hope you did not miss the London Star Trek convention like I did ;-)

I'm very impressed with your Mele cluster. I hope it continues to work well for you. The Mele works quite well as a server. Glad to hear they are stable. But the A10 really needs netconsole, especially with that many devices. That way you could diagnose remotely if there is an issue and a failed reboot. Kernel upgrades are also an issue with no Debian support. Those are the kinds of things that I don't see getting resolved and one of the main reasons I pulled support for the platform. Those issues also have deterred me from using my Mele as a server.

I still prefer my Go Flex Net's for my servers. The SATA is better. The ethernet is faster and it does not steal resources. They can be remotely managed and the bootloader can be accessed remotely. Those things are essential in a server. My Go Flex's are hosting several personal web sites and email. They are serve as a MythTV backend and slave backend, and a MPD music server. They have been in that role now for almost two years with zero downtime.

It would be nice to have something faster for a server. The Mele was faster. But not fast enough to compensate for their poor ethernet performance compared to Kirkwood. My hopes for the A10 was as a MythTV frontend, and as a replacement Linux platform for my N800 tablet. But it can't serve either purpose, and it now looks like it never will. The battery life and lack of GPU acceleration kill it in the tablet dept. The lack of video acceleration kills it as a MythTV playback device. Even in Android it is marginal for that purpose.

Quote

It didn't last long to find a new project for gnexus ;)

Same project - just a broader focus. The problem with a10linux was it was locked to one device from one manufacturer.

That is why we hesitated to even post the site once it was completed. We already disliked needing to do work that Allwinner and/or the linux-sunxi guys should have already done. We had several discussions over that. We did not want to promote a manufacturer that refuses to give any support the open source community. But the domain was already registered and had previous visitors. So we decided to give it some time and see if the community would step up to overcome manufacturer resistance. The name of the site was, after all, the A10 Community. If somebody had offered free hosting, and at least one or two other developers or project leads from other sites had joined up, we would have kept it going. But that did not happen, and we did not want to become Allwinner's Linux software library and support service. The removal of linux-sunxi uboot support for all devices except Cubie's and Olimex sealed our decision to drop support:

from https://github.com/linux-sunxi/u-boot-sunxi/wiki:

Quote

Available board types are:

sun4i Generic A10
sun5i Generic A13
a13_olinuxino Olimex A13-OLinuXino (SPL)
cubieboard Cubieboard (SPL)
cubieboard_512 Cubieboard 512MB version (SPL)
mele_a1000 Mele A1000 (SPL)

Boards with (SPL) include SPL loader to boot directly from SD-card.

The only devices now supprted by them are Cubie's (Mele and Cubieboard) and Olimex. No support for other devices.

Generic A10/A13 has no SPL support. But also does not support NAND. It cannot boot other devices. Period.

The only way it will work is if you modify the code. How many users will attempt to do that?

I don't want to support people who pull NAND support, and then pull support for all devices except what they sell. I also don't want to support a SoC manufacturer that uses other people's code and then refuses to publish it.

The "highly modified u-boot" is 0 lines of code compared to the ICS code drop (lichee-dev-ICS branch), only a changed default environment. Could easily be replaced with a boot.scr script where this fancy logics better belongs.

Well.. there is some code. The "spl" version. This is is some version of uboot-allwinner but with all the history erased.

I have archived the a10linux branches of u-boot in my repository https://github.com/hno/uboot-allwinner if anyone is interested in viewing what there was.

If you are more interested in moving on then please read https://github.com/linux-sunxi/u-boot-sunxi/wiki for instructions how to add proper support for your board, or join #arm-netbook on freenode or the mailinglist at http://linux-sunxi.org/Mailing_list

It is quite funny to see both me and Alejandro being accused of doing this to promote Cubieboard and Olimex. Both of us do what we do in Linux & u-boot for Allwinner A1x for fun on our spare time. Neither of us have any commercial relation with either of them.

But I must say it's an odd time to abandon the ship. It's very interesting times ahead with many pieces falling into place just now.

hno finally joins our forum. . . Thank you for finally contributing. But it would be nice if you did so in a more productive way.


As I stated earlier - I never said it was "highly modified." So please stop misquoting me

Quote

It is quite funny to see both me and Alejandro being accused of doing this to promote Cubieboard and Olimex. Both of us do what we do in Linux & u-boot for Allwinner A1x for fun on our spare time. Neither of us have any commercial relation with either of them.

Then do something to prove it. Show you are working to put your code on Denx where it belongs. You have failed to aknowledge that Denx wrote 99.9% of your code, and that the vast majority of git commits come from there. Then add back default u-boot support for generic devices. . . Currently only devices sold by Cubie or Olimex are supported by your uboot.

I also fail to see how you can say Alejandro is doing it on "spare time" when the only time he is on IRC is when he's at work.
While you may not have a "commercial relation" you certainly cannot say that Tom Cubie, who wrote the majority of the A10 code in your u-boot, does not. You have actually contributed very little to the Allwinner uboot. You are just a maintainer. It is Denx who wrote the code, and Cubie who ported it to the A10. Cubie certainly has a commercial interest in Cubieboard. . .

One of the main reasons why I dropped support was both your and Alejandro's negative attitude toward me, this site, and a10linux.org. Alejandro was very negative about Jeff. He would not incorporate any of my kernel config suggestions even though many in the community want or need them. Your failure to at least aknowledge a10linux.org is what led to its demise.

Your negative post here certainly solidifies my assumptions about linux-sunxi. Absolutely no new features have been added to the Allwinner u-boot since Cubie ported it. The multi-boot uboot is something that many people wanted or needed. Although you say that it was only an environment change that is untrue. In order to be able to boot from NAND the drivers in Lichee must be included, and the MMC subsystem in Lichee-ICS must be enabled. NAND support is not part of your code. Lichee is the original Allwinner code released by Tom Cubie. If you only use my environment with your u-boot version you cannot boot from NAND. People who browse the git can see the changes vs. yours or lichee in sun4i.h. They are only minor changes. But they are needed changes that are not present in either the main branch or in lichee. I had merged lichee-ICS and MMC branches, and was working on PHY, SATA and USB support. But your negative attitude has stopped all that work.

Quote

please read https://github.com/linux-sunxi/u-boot-sunxi/wiki for instructions how to add proper support for your board, or join #arm-netbook on freenode or the mailinglist at http://linux-sunxi.org/Mailing_list

Support for other boards was already there. You already had all the resources to keep it there. You could have easily added support for other devices, or at least kept the existing support. But instead now you want to collect email addresses.
Thank you for your commercial. I think the people here already know where your uboot is located. . .

Showing 1 changed file with 233 additions and 53 deletions. Not just the environment either. . .

Also, I believe you are at least violating the spirit of the GPL by incorporating my code into your git without aknowledgement or permission.

I have no issues with you distributing it, but you should at least aknowledge the author of the branch in your wiki. Just like you have failed to show that Denx is the author of your code you have failed to state that you copied my code.

Quote
gnexus
Your negative post here certainly solidifies my assumptions about linux-sunxi. Absolutely no new features have been added to the Allwinner u-boot since Cubie ported it.

More accusations. Go and read the code.

Am I negative? Did not intend to be negative, but maybe it is, not in the best mood after reading your earlier post calling my work on u-boot crap and seeing you abandon the ship.

Quote
gnexus
Support for other boards was already there. You already had all the resources to keep it there.

Nothing have been removed compared to Toms original release. What was there in SPL from start was kind of working Mele A1000 support, which for some unknown reason happens to work "by accident" on Mele v1.3 and some other devices, but far from all, not even Mele v1.6 or later. Most notably it was missing CPU voltage control and boots the CPU running serverely under voltage for the set clock frequency.

An unfortunate sideeffect of fixing this is the knowledge that there is no "single SPL that fits all". We always knew that there never was as it needs to match DRAM configuration closely, but now it's clearly shown.

Quote
gnexus
I also fail to see how you can say Alejandro is doing it on "spare time" when the only time he is on IRC is when he's at work. While you may not have a "commercial relation" you certainly cannot say that Tom Cubie, who wrote the majority of the A10 code in your u-boot, does not. You have actually contributed very little to the Allwinner uboot. You are just a maintainer. It is Denx who wrote the code, and Cubie who ported it to the A10. Cubie certainly has a commercial interest in Cubieboard. . .

Alejandro does some IRC from work, because he needs to be on IRC at work anyway. But that's all. All coding and most of his active IRC time is on his spare time.

Yes. Tom wrote most of the Allwinner u-boot code ouside the platform independent parts of mmc/nand/usb drivers, both in lichee-dev and lichee-dev-mmc. He did this as part of his day time job when he worked at Allwinner; lichee-dev for the Andoid folks, and lichee-dev-mmc to support Rhombus Tech but still paid by Allwinner. Tom have not contributed any code to u-boot or Linux after leaving Allwinner and starting cubieboard. But he continues to contribute where he can to making Linux on A10 a better experience.

Quote
gnexus
Then do something to prove it. Show you are working to put your code on Denx where it belongs.

There have always been a goal of upstreaming the Allwinner changes to mainline u-boot, and the changes are currently being prepared for submission, but I can not promise it can make it into the current u-boot merge window. There is still a lot to clean up, and some struff to prepare to get them in submittable form. But have some good help so it's not completely impossible.

Quote
gnexus
Showing 1 changed file with 233 additions and 53 deletions. Not just the environment either. . .

Sorry for not mentining needless whitespace changes and enabling some additional u-boot commands.

Quote
gnexus
Also, I believe you are at least violating the spirit of the GPL by incorporating my code into your git without aknowledgement or permission.

It's fully in the spirit of GPL. You gave the permission when publishing the changes under GPL. What is on those branches is your branches as published in a10linux git. No different from forking the repository. I by no way claim any authorship, nor have I touched any of the branch history, it's 100% preserved.

The branches are clearly named a10linux/... to acknowledge their origin. I haven not yet mentioned them in the wiki as I have little more to say about them than "from the now dead a10linux project", but feel free to add some suitable note, all you need to edit that page is a github account and a web browser.

I can speak only for myself, but I am deeply grateful for the that Henrik, Alejandro, and Tom Cubie have done regarding the A10 platform. Without their work none of this would be possible.

While we may each have separate projects and goals, I think everyone shares a desire to see the platform succeed. I think it would be wise to focus on the platform's success and be respectful of the fact that everyone is contributing their own personal time to this project.

Quote

Sorry for not mentining needless whitespace changes and enabling some additional u-boot commands.

You are conveniently omitting the main change, which is enabling MMC in the NAND version. There are also no "needless whitespace changes." The other lines are all the advanced environment scripting that enables easy booting from multiple devices. While you may think it "Could easily be replaced with a boot.scr script" there is no harm in having it there. There is plenty of room for it in the environment, and it benefits many users. The multi-boot uboot still supports boot.scr and uEnv scripts, and putting the multi-boot scripting into a boot.scr would prevent users from having their own script. The uboot.conf is also easier to use and configure for most users. End users should not need to compile a boot.scr, or even to create their own uEnv script just to boot with an initrd or from devices like SATA and USB.

Quote

No different from forking the repository.

It is different in that it does not show the fork. That is my only objection. Pulling it all into your own git is not the proper way to do a fork. It should be in a separate project on your github, at minimum, if the fork is not shown.

I have always aknowledged your work, but you continue to belittle mine. That type of behaviour is what kills Linux projects.

Quote
Henrik Nordström
there is no "single SPL that fits all"

That is quite depressing to hear. I thought about that quite a while. I find it quite difficult to believe that every different device needs a custom uboot version. All A10 devices use the same SoC. The device customizations should be done in script bin. I'm fairly certain that no other manufacturer has multiple uboot versions for the same SoC.

I'm sorry, but that information thus means I can't anymore support the use of the SPL. To support it's use would either mean that I have to release a specific SD image for each device, or put in a disclaimer saying that my software releases may not work reliably. Neither choice is acceptable to me. Thus, regretfully, I'm terminating my support for booting from MMC.

Glad to know that we can boot reliably using the NAND uboot, and that it is fully GPL'd.

Its a real shame that whoever was working on this project got better and simply rm -rf'ed all the data instead of hosting it somewhere like source forge. If all FOSS projects where given just 4 months to thrive almost none of them would exist - everything can't be an instant success.

~Jeff

Well, I registered the domain. I did the images, etc. and the most of the forum posts. Angus adapted the web pages from the posts here at Jeff's forum. Kevin hosted the site and started the github. It was Kevin that deleted everything. He was drunk and pissed about a lot of things at the time, with good reason. That, however, was not reason enough to delete all my work. . .

It makes me really hesitant do do more unless I have full control of the server I am uploading to, or at least am using a reputable site like SourceForge or GitHub. I should have done my own github for the u-boot, but I was just too busy. The git tree was not easily adapted from uboot-allwinner. So Kevin took control. BTW, hno, the git issues are why the SPL tree had to be deleted and then pushed again without your commits. It was not possible to use it as is because it was the origin.

Quote

I am deeply grateful for the that Henrik, Alejandro, and Tom Cubie have done regarding the A10 platform.

So am I. I never wanted to do anything to fracture the community. My only objective has been to move the platform forward. My hope was to get more developers on board. Unfortunately, Alejandro was not happy with my kernel config changes. I also knew from the start that Henrik would object to my uboot changes. I would have much preferred to have had all my work, tutorials, etc. incorporated into linux-sunxi, along with maybe linking Jeff's forum with that site. Would have been much easier and better.

Quote
gnexus
That is quite depressing to hear. I thought about that quite a while. I find it quite difficult to believe that every different device needs a custom uboot version. All A10 devices use the same SoC. The device customizations should be done in script bin. I'm fairly certain that no other manufacturer has multiple uboot versions for the same SoC.

The issue is not the SoC, the issue is the wiring of the board and type of DRAM populated on the board.

When SPL starts absolutely nothing of the board is configured. Pretty much the first thing SPL does is configuring the DRAM controller with the right settings for the board and type of DRAM used so the memory can be accessed.

If you are familiar with script.bin then this is equivalent the dram_para & target sections of script.bin, with fully populated parameters.

As there is no memory available before the DRAM controller is configured it's not possible to read & parse script.bin to find these values. It need to be configured in the boot loader. Same applies on images written to nand, the bootloader (boot0 & boot1) need to be prepared for the board. Some of this is done when the image is composed, and current versions of livesuit can optionally do part of the board configuration section when flashing the device.

Quote
Henrik
Same applies on images written to nand, the bootloader (boot0 & boot1) need to be prepared for the board.

Thus, by booting from NAND using the existing boot0 & boot already supplied with the device, we automatically overcome all the SPL issues. By simply avoiding booting using uboot installed to MMC only one NAND uboot version needs to be used.

It is simply not practical for me to build multiple Linux SD images to cater to each and every device. Therefore I must stand by my prior comments. I will no longer support booting from MMC. I'll let others carry that flag from now on.