public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Aneesh V <aneesh@ti.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] Skipping relocation RAM to RAM, esp. on i.MX6?
Date: Tue, 07 Feb 2012 12:49:10 +0530	[thread overview]
Message-ID: <4F30D06E.8060200@ti.com> (raw)
In-Reply-To: <CALButCJFFrCnqtpcjDjaj8wnUX2NsC5GGfPrDwAq3NHceibyiQ@mail.gmail.com>

On Tuesday 07 February 2012 04:11 AM, Graeme Russ wrote:
> Hi Wolfgang,
>
> On Tue, Feb 7, 2012 at 9:27 AM, Wolfgang Denk<wd@denx.de>  wrote:
>> Dear Albert ARIBAUD,
>>
>> In message<4F304463.1050901@aribaud.net>  you wrote:
>>>
>>>> In my experience, the offset is consistent on a given platform so once
>>>> you do the dance once to figure out where it'll be placed you can just
>>>> start off debugging post-relocation.
>>>
>>> That's for a given platform *and* a given U-Boot build, since the U-Boot>
>>
>> ...and for a given set of configured options and environment settings.
>>
>> Change the size of the PRAM area, or change the resolution of your
>> graphics controller (and thus the size of the frame buffer), or change
>
> The graphics controller memory may not be in main memory - It could be
> in the PCI address space, in which case it may not affect the relocation
> address
>
>> the size of the log buffer, or ...
>>
>> There is a _plenty_ of reasons why the relocation address may change,
>> even for a given binary image and a given piece of hardware.
>
> Note that x86's E820 address map tells the kernel which physical pages of
> memory are reserved for system use - Paging takes care of defragmenting
> the physical address space to provide the kernel and user mode code a
> virtual linear address space. Technically, U-Boot does not need to be
> relocated for x86 at all, even if we want to keep it in RAM - We just tell
> the kernel that the physical address space that U-Boot resides in is
> reserved
>
> There are a lot of other arches besides PPC ;) And a lot of boards which
> will be shipped with an extremely static configuration (lots of consumer
> devices like set-top boxes etc only have one physical configuration)

I agree. Even on some platforms that are not fully static (such as having
variants with different memory sizes) the minimum available memory is
more than enough to allocate big enough partitions for each need at
U-Boot level. And my guess (or rather speculation) is that platforms
that do not have any real dynamic needs are in the majority. I sincerely 
believe that platforms should be allowed to enable/disable
relocation based on their needs.

br,
Aneesh

  reply	other threads:[~2012-02-07  7:19 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-03  7:25 [U-Boot] Skipping relocation RAM to RAM, esp. on i.MX6? Dirk Behme
2012-02-03  8:51 ` Stefano Babic
2012-02-03 10:18   ` Dirk Behme
2012-02-03 11:00     ` Stefano Babic
2012-02-03 11:19       ` Mike Frysinger
2012-02-04  8:38       ` [U-Boot] i.MX5/6 U-Boot: Cache enabling (was: Re: Skipping relocation RAM to RAM, esp. on i.MX6?) Dirk Behme
2012-02-04  9:18         ` [U-Boot] i.MX5/6 U-Boot: Cache enabling Aneesh V
2012-02-04 10:18         ` [U-Boot] i.MX5/6 U-Boot: Cache enabling (was: Re: Skipping relocation RAM to RAM, esp. on i.MX6?) Marek Vasut
2012-02-08 13:37           ` [U-Boot] i.MX5/6 U-Boot: Cache enabling Dirk Behme
2012-02-09  7:06             ` Marek Vasut
2012-02-04  9:15 ` [U-Boot] Skipping relocation RAM to RAM, esp. on i.MX6? Aneesh V
2012-02-04 11:00   ` Albert ARIBAUD
2012-02-04 11:14     ` Aneesh V
2012-02-04 11:37       ` Albert ARIBAUD
2012-02-06 14:34     ` Tom Rini
2012-02-06 21:21       ` Albert ARIBAUD
2012-02-06 22:27         ` Wolfgang Denk
2012-02-06 22:41           ` Graeme Russ
2012-02-07  7:19             ` Aneesh V [this message]
2012-02-07 23:26               ` Wolfgang Denk
2012-02-08  6:43                 ` Aneesh V
2012-02-08 13:58                   ` Wolfgang Denk
2012-02-08 14:48                     ` Aneesh V
2012-02-08 16:23                       ` Wolfgang Denk
2012-02-09  6:01                         ` Aneesh V
2012-02-09 11:44                           ` Wolfgang Denk
2012-02-09 13:43                             ` Aneesh V
2012-02-05  6:19   ` Simon Glass
2012-02-06 14:19     ` Aneesh V

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=4F30D06E.8060200@ti.com \
    --to=aneesh@ti.com \
    --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