From mboxrd@z Thu Jan  1 00:00:00 1970
From: Alexandre Belloni <alexandre.belloni@piout.net>
Date: Sat, 21 Apr 2012 23:19:03 +0200
Subject: [U-Boot] [PATCH v4] AT91SAM9*: Change kernel address in
 dataflash to match u-boot's size
In-Reply-To: <4F8DFC1A.20209@emagii.com>
References: <4F4DF49B.3040907@emagii.com>
	<1333909023-6725-1-git-send-email-alexandre.belloni@piout.net>
	<20120408200641.76D21202B18@gemini.denx.de>
	<4F82835F.2030201@googlemail.com>
	<20120409081535.8EF77202A4D@gemini.denx.de>
	<4F8DFC1A.20209@emagii.com>
Message-ID: <20120421211903.GA14077@piout.net>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Hi,

On Wed, Apr 18, 2012 at 01:26:18AM +0200, Ulf Samuelsson wrote :
> While AT91bootstrap supports booting linux, this is real minimal support.
> Everything is hard-wired so for development it really sucks.
> It is really only useful for production work.
> I personally never used this capability.
> 
> This functionality is pretty new in AT91boostrap,
> and the Atmel (non) presence in the mailing list is an older problem.
> 
> While I no longer work for Atmel, I have a feeling that the problem
> is as follows:
> 
> Users are using the Atmel version of U-Boot, not mainstream.
> If not using the Atmel version, then they maybe using a build system
> like OpenEmbedded where u-boot is built as a part of the build process
> and people have very little incentive in modifying that part
> 
> There is very little incentive at Atmel to upgrade because
> 1. Patches provided by Atmel are ignored.
> 2. Patches are applied to mainline which keeps breaking the AT91 support.
> 3. All possible fixes to boot problem are rejected (discussion with
> Haavard).
> 4. It is considered more important to have a "clean" implementation,
> than a working implementation.
>     (Choice of NOR Flash Driver)
> 
> Atmel does not want to continuously spend effort on unbreaking other
> peoples work.
> 
> Problems are not fixed in the mainline due to problem (1).
> Instead the problems are fixed in the buildsystem and it is not considered
> worthwhile to submit such fixes to the mailinglist.
> 
> The action by the project to "solve" the problem by removing the
> boards from
> the MAKEALL scripts and also to remove BSPs is not encouraging.
> 
> There used to be a rule that patches should not break board support, but
> that rule seems to have gone down the drains.
> 
> The Atmel code is (IIRC) based on 0.3.4 so it is very old, so an
> update is really needed
> but before U-Boot becomes "developer-friendly", I doubt that will happen.
> If the project wants to have Atmel "on-board", then fixing problem
> (1) is key.
> 

Would it be possible to get a list of what is not working on mainline
but is working in ATMEL's version ? or at least some pointers.
It seems to be working well on my board. I'm really interested in
getting mainline working well.

I know there is not much interest in the AT91 boards now but I would
really like to see that issue fixed.

Regards,

-- 
Alexandre Belloni