From mboxrd@z Thu Jan 1 00:00:00 1970 From: Reinhard Meyer Date: Thu, 28 Oct 2010 08:23:24 +0200 Subject: [U-Boot] Most ARM CPU's have buggy clear_bss? In-Reply-To: <4CC91627.4040106@emk-elektronik.de> References: <20101027151203.GA5024@localhost> <4CC86B67.3000701@gmail.com> <4CC90F40.4020405@invitel.hu> <4CC91390.5000407@emk-elektronik.de> <4CC91572.6030308@denx.de> <4CC91627.4040106@emk-elektronik.de> Message-ID: <4CC916DC.7040606@emk-elektronik.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 28.10.2010 08:20, Reinhard Meyer wrote: > On 28.10.2010 08:17, Heiko Schocher wrote: >> Hello Reinhard, >> >> Reinhard Meyer wrote: >>> Dear Darius, >>>>> Now running in RAM - U-Boot at: 57fbe000 >>>>> NAND: raise: Signal # 8 caught >>>>> raise: Signal # 8 caught >>>>> raise: Signal # 8 caught >>>> This looks suspect to me. Seems to me some early init >>>> (pin setup? clocks?) is not OK. If you have early inits, >>>> you must do that now in board_early_init_f() (and you >>>> have to define CONFIG_BOARD_EARLY_INIT_F to enable this >>>> feature) >>> I got _exactly_ the same NAND messages when ARM relocation >>> was first used, because the timer.c did use static variables >>> which are not working _before relocation_. >>> Have a look at your timer implementation. >> >> Huh.. thought the elf relocation fixed this problem? > 2x Huh.. How would it? I moved the timer static vars into > global_data, THAT fixed the issue. OK, I should have mentioned, that those variables are values that are calculated _before_ relocation in timer_init and needed to have those values for any subsequent timer use before and after relocation... > > Reinhard