public inbox for u-boot@lists.denx.de
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox