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 v3] AT91SAM9*: Change kernel address in dataflash to match u-boot's size
Date: Wed, 29 Feb 2012 09:58:08 +0100	[thread overview]
Message-ID: <20120229085807.GA20362@piout.net> (raw)
In-Reply-To: <49F9F0AD-514C-4092-9764-DF100251A433@emagii.com>

On Wed, Feb 29, 2012 at 01:50:18AM +0100, Ulf Samuelsson wrote :
> > 
> >> 2. Std AT91bootstrap loads U-Boot from 0x8400
> >>    so your patch breaks 99% of all SAM9  boards.
> >> 
> > 
> > Those boards are broken anyway !
> 
> No they are not.
> The partitioning gives you some hint on where to store the kernel,
> but you can store the kernel at any suitable address.
> you lose some conveniance, but thats all.
> 
> Storing U-boot at any other address than 0x8400, means that AT91bootstrap
> must be modified, and there is significant disadvantages in having two possible u-boot locations.
> if you have an at91bootstrap binary, will this use the old or new location?
> I fail to see any benefit in moving, so that 
> 
> 
> 
> > As u-boot is bigger than the load size
> > of at91bootstrap (0x33900 by default). So, not changing means that you
> > are screwed after flashing a new u-boot
> 
> IIRC, The latest bootstrap with Kconfig has configurable size.
> Changing size is OK, changing location is not.
> 
> 

Doesn't that mean that you then have to recompile/reflash at91bootstrap
and so that the boards are broken using the latest ut-boot ? I couldn't
get my board working with the stock at91bootstrap because it cannot load
u-boot.

It has to be fixed or I don't see the point in keeping those configs.
If we don't want to change the location, and I can understand the
reasons why, then was my first patch ok ?

http://lists.denx.de/pipermail/u-boot/2012-January/114485.html

I'd like to see that fixed so that I could integrate it properly in
buildroot...

> 
> 
> >> If you want to grow U-Boot, then
> >> 
> >> bootstrap  0x00000000        ; 16 kB
> >> ubootenv   0x00004200        ; 16 kB    - Should be plenty
> >> uboot      0x00008400        ;
> >> kernel     0x00063000        ; Why waste space...
> >> 
> > 
> > What about the redundant env ? Why shouldn't we reorder u-boot and its
> > env ?
> 
> Because it adds problems without any benefits.
> When I looked the last time, the environment is only 8 pages,
> So you can fit a redundant environment anyway in 16 kB+}
> 



-- 
Alexandre Belloni

  reply	other threads:[~2012-02-29  8:58 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 [this message]
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
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=20120229085807.GA20362@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.