public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Albert ARIBAUD <albert.u.boot@aribaud.net>
To: u-boot@lists.denx.de
Subject: [U-Boot] memory corruption on nios2 due to overlap of gbl data and malloc
Date: Thu, 01 Mar 2012 22:57:51 +0100	[thread overview]
Message-ID: <4F4FF0DF.4080200@aribaud.net> (raw)
In-Reply-To: <CALButCK6quC_FOUEXW0yLMj0_1vq=qhGghZg6Vgx=NrKYzrhdg@mail.gmail.com>

Hi Graeme,

Le 29/02/2012 23:41, Graeme Russ a ?crit :
> Hi Mike,
>
> On Thu, Mar 1, 2012 at 9:29 AM, Mike Frysinger<vapier@gentoo.org>  wrote:
>> On Wednesday 29 February 2012 17:22:26 Graeme Russ wrote:
>>> On Thu, Mar 1, 2012 at 6:04 AM, Mike Frysinger wrote:
>>>> On Tuesday 28 February 2012 18:32:57 Graeme Russ wrote:
>>>>> And this is why I dislike the implementation - You have to do all sorts
>>>>> of weird calucations to put things in the right place when, in fact,
>>>>> the location of gd and bd in memory is totally irrelavent.
>>>>
>>>> right, that's why i minimized the pain for Blackfin users -- this is all
>>>> handled in the arch's config-pre.h header.  board porters only need to
>>>> declare the size of regions they care about (monitor and heap sizes).
>>>>
>>>>> Ow, ouch! - And that padding makes things more fun - The memory layout
>>>>> is
>>>>>
>>>>> U-Boot | gd | pad | bd | pad | heap
>>>>
>>>> fwiw, i documented the Blackfin memory layout:
>>>> http://docs.blackfin.uclinux.org/doku.php?id=bootloaders:u-boot:memory-la
>>>> yout
>>>
>>> I had a look at this and noticed that you statically allocate locations for
>>> gd and bd (CONFIG_SYS_GBL_DATA_ADDR, CONFIG_SYS_BD_INFO_ADDR)
>>>
>>> Considering that:
>>>
>>> a) the gd pointer is in a register (P3) and thus easily locatable by a
>>>     debugger, and;
>>> b) the bd pointer is in gd
>>>
>>> Is there any reason not to have gd and bd in BSS?
>>
>> in the Blackfin case, most likely not.  we don't do relocation, and the bss is
>> cleared long before board_init_f() gets called.  the only reason for allowing
>> the config to override would be if someone wanted to put gd/bd into on-chip L1
>> data, but i can't imagine this structure being performance critical enough to
>> warrant that.
>
> I thought as much - I moved gd/bd into BSS for x86 without really thinking
> about why everyone else calculates the location of these data structures
> around the stack and heap. The longer I think about it, the more I think
> that it was not a bad move and that maybe other arches can follow suit as
> part of standardising the init sequences

ARMs relocate and don't have a valid BSS until board_init_r() but 
require gd as early as board_init_f().

> Regards,
>
> Graeme

Amicalement,
-- 
Albert.

  parent reply	other threads:[~2012-03-01 21:57 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-20 23:24 [U-Boot] memory corruption on nios2 due to overlap of gbl data and malloc Alex Hornung
2012-02-28 22:29 ` Albert ARIBAUD
2012-02-28 22:39   ` Graeme Russ
2012-02-28 22:55     ` Albert ARIBAUD
2012-02-28 23:20       ` Graeme Russ
2012-02-28 23:24         ` Albert ARIBAUD
2012-02-28 23:32           ` Graeme Russ
2012-02-29 19:04             ` Mike Frysinger
2012-02-29 22:22               ` Graeme Russ
2012-02-29 22:29                 ` Mike Frysinger
2012-02-29 22:41                   ` Graeme Russ
2012-03-01  7:09                     ` [U-Boot] [PATCH] nios2: move gd and bd into BSS Thomas Chou
2012-03-01 17:17                       ` Mike Frysinger
2012-03-02  2:55                         ` [U-Boot] [PATCH v2] " Thomas Chou
2012-03-02  3:22                           ` Mike Frysinger
2012-03-01 21:57                     ` Albert ARIBAUD [this message]
2012-03-01 22:11                       ` [U-Boot] memory corruption on nios2 due to overlap of gbl data and malloc Graeme Russ

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=4F4FF0DF.4080200@aribaud.net \
    --to=albert.u.boot@aribaud.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