All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexandre Belloni <alexandre.belloni@piout.net>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v4] AT91SAM9*: Change kernel address in dataflash to match u-boot's size
Date: Sat, 21 Apr 2012 23:19:03 +0200	[thread overview]
Message-ID: <20120421211903.GA14077@piout.net> (raw)
In-Reply-To: <4F8DFC1A.20209@emagii.com>

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

  reply	other threads:[~2012-04-21 21:19 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-29 21:37 [U-Boot] [PATCH v2] Change kernel address in dataflash to match u-boot's size Alexandre Belloni
2012-02-18 15:13 ` Albert ARIBAUD
2012-02-18 16:21   ` Albert ARIBAUD
2012-02-20 10:40     ` Alexandre Belloni
2012-02-20 10:46       ` Albert ARIBAUD
2012-02-20 12:48         ` [U-Boot] [PATCH] AT91SAM9*: " Alexandre Belloni
2012-02-20 13:00           ` Albert ARIBAUD
2012-02-20 16:40             ` [U-Boot] [PATCH v3] " Alexandre Belloni
2012-02-27 15:25               ` Ulf Samuelsson
2012-02-28 22:57                 ` Alexandre Belloni
2012-02-29  0:50                   ` Ulf Samuelsson
2012-02-29  8:58                     ` Alexandre Belloni
2012-02-29  9:49                       ` Ulf Samuelsson
2012-04-08 18:17                         ` [U-Boot] [PATCH v4] " Alexandre Belloni
2012-04-08 20:06                           ` Wolfgang Denk
2012-04-09  6:36                             ` Andreas Bießmann
2012-04-09  8:15                               ` Wolfgang Denk
2012-04-17 23:26                                 ` Ulf Samuelsson
2012-04-21 21:19                                   ` Alexandre Belloni [this message]
2012-02-20 12:51         ` [U-Boot] [PATCH v2] " Alexandre Belloni

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120421211903.GA14077@piout.net \
    --to=alexandre.belloni@piout.net \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.