From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Thu, 01 Mar 2012 22:57:51 +0100 Subject: [U-Boot] memory corruption on nios2 due to overlap of gbl data and malloc In-Reply-To: References: <4F42D61C.6080201@alexhornung.com> <201202291404.26773.vapier@gentoo.org> <201202291729.46616.vapier@gentoo.org> Message-ID: <4F4FF0DF.4080200@aribaud.net> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 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.