From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Tue, 20 Jan 2015 08:07:47 +0100 Subject: [U-Boot] [PATCH] board_f: save "malloc_base" from zeroing in case of CONFIG_SYS_MALLOC_F_LEN In-Reply-To: <1421690103-29091-1-git-send-email-abrodkin@synopsys.com> References: <1421690103-29091-1-git-send-email-abrodkin@synopsys.com> Message-ID: <20150120080747.07f168b7@lilith> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hello Alexey, On Mon, 19 Jan 2015 20:55:03 +0300, Alexey Brodkin wrote: > In case of CONFIG_SYS_MALLOC_F_LEN "malloc_base" is used for early > start-up code and is set very early, typically in "start.S" or "crt1.S". There is no "crt1.S" in U-Boot. Did you mean "crt0.S"? > In current implementation in case of CONFIG_SYS_GENERIC_GLOBAL_DATA all > global data gets zeroed on "board_init_f" entry. But by that time > "malloc_base" could have been set already, which means it will be zeroed > and subsequent C-code will be executed improperly (if executed at all - > if there's no memory mapped to 0 or it is read-only then on some arches > there will be an exception and others will quetly die). > > To work-around described situation we just need to make sure > "malloc_base" is saved prior zeroing global data and recovered > afterwards. Keeping data from being zeroed etc is usually done through GD. Could malloc_base be placed there instead of creating a specific exemption for it? Amicalement, -- Albert.