[U-Boot] [PATCH v4] AT91SAM9*: Change kernel address in dataflash to match u-boot's size

Alexandre Belloni alexandre.belloni at piout.net
Sat Apr 21 23:19:03 CEST 2012


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


More information about the U-Boot mailing list