All of lore.kernel.org
 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 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.