From patchwork Tue Jan 29 15:16:21 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Luca Ellero X-Patchwork-Id: 216570 X-Patchwork-Delegate: trini@ti.com Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from theia.denx.de (theia.denx.de [85.214.87.163]) by ozlabs.org (Postfix) with ESMTP id D8F1B2C0097 for ; Wed, 30 Jan 2013 02:12:55 +1100 (EST) Received: from localhost (localhost [127.0.0.1]) by theia.denx.de (Postfix) with ESMTP id 9B2F24A170; Tue, 29 Jan 2013 16:12:53 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at theia.denx.de Received: from theia.denx.de ([127.0.0.1]) by localhost (theia.denx.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6PLk5phC4RG; Tue, 29 Jan 2013 16:12:53 +0100 (CET) Received: from theia.denx.de (localhost [127.0.0.1]) by theia.denx.de (Postfix) with ESMTP id C10F34A14B; Tue, 29 Jan 2013 16:12:51 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by theia.denx.de (Postfix) with ESMTP id 52DF44A14B for ; Tue, 29 Jan 2013 16:12:46 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at theia.denx.de Received: from theia.denx.de ([127.0.0.1]) by localhost (theia.denx.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdVgqFMC7jS8 for ; Tue, 29 Jan 2013 16:12:35 +0100 (CET) X-policyd-weight: NOT_IN_SBL_XBL_SPAMHAUS=-1.5 NOT_IN_SPAMCOP=-1.5 NOT_IN_BL_NJABL=-1.5 (only DNSBL check requested) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) by theia.denx.de (Postfix) with ESMTPS id 8A9584A140 for ; Tue, 29 Jan 2013 16:12:32 +0100 (CET) Received: by mail-wi0-f175.google.com with SMTP id hq12so2078097wib.14 for ; Tue, 29 Jan 2013 07:12:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=EAl2RY2YhVH38RfVpb9zRY5MWdkFt+HOq66JfMP3eK0=; b=yGWNaaj9/AmbH5uVwsWdFXRKgAxddRyx5Rx0USchgyAqm9gSoNLHBHvQHCuRCNLdnZ ae5I35EI1MKjF5hVdYnF6iROTeeIr2BvAESeOtYfVdtX4Q3bPkJq3OXL8xN1Knv69eKI MTSE/0ypEyRFAyQxz9HBYkVmPqDl1zB2rE+86Hq/OP2Zz0A2P97JNXTYJkh6gxT2QmTB X/PtJ7ZX7IGI57FifgfM+GHATM4HLr//MSmWGidDe/3y0rzahLzb56+TFtNjre0vGVn7 oeGJF7HbWTv1oClZWWCQIpMmU8cIdun9+uWVSn+yUQtzl0azbs3pA9Erp6lt2FiweByP 8HzA== X-Received: by 10.195.13.200 with SMTP id fa8mr3121078wjd.15.1359472351623; Tue, 29 Jan 2013 07:12:31 -0800 (PST) Received: from [172.16.17.45] (host253-241-static.223-195-b.business.telecomitalia.it. [195.223.241.253]) by mx.google.com with ESMTPS id s8sm3494499wif.9.2013.01.29.07.12.30 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Jan 2013 07:12:30 -0800 (PST) Message-ID: <5107E7C5.9050400@gmail.com> Date: Tue, 29 Jan 2013 16:16:21 +0100 From: Luca Ellero User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Wolfgang Denk References: <51077D26.5020808@denx.de> <51078BFD.60906@gmail.com> <20130129094827.C94C82005AB@gemini.denx.de> In-Reply-To: <20130129094827.C94C82005AB@gemini.denx.de> Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] CONFIG_SYS_TEXT_BASE and relocaddr X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.11 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: u-boot-bounces@lists.denx.de Errors-To: u-boot-bounces@lists.denx.de Dear Wolfgang, On 29/01/2013 10.48, Wolfgang Denk wrote: > Dear Luca Ellero, > > In message <51078BFD.60906@gmail.com> you wrote: >> >> in U-Boot version 2012.10 I used to skip "relocate_code" setting >> CONFIG_SYS_TEXT_BASE to relocaddr (obtained from bdinfo command). >> This since some hardware is able to configure SDRAM and load U-Boot >> directly to SDRAM, so relocation is useless and time consuming. > > You are wrong. relocation is not useless, even in your case. there > are quite a number of configuration options that will put stuff above > the U-Boot image, directly at the end of RAM (things like protected > RAM, shared frame buffer, shared log buffer, etc.). In these cases, > the relocation address may even be dynamic (i. e. depending on > settings of environment variables, and thus unknown at compile time). > >> Now I'm using latest git version and this isn't working anymore. >> Can someone explain me way? And what is the suggested way to skip >> relocation now. > > Don't. Got your point ;-) Thanks I'm asking that since I'm digging on ARM SDRAM configuration and found a bug on getting top of SDRAM (where u-boot will be relocated). On ARM architectures top of SDRAM will always be: CONFIG_SYS_SDRAM_BASE + gd->ram_size anyway this can be wrong since SDRAM can be composed by more that one bank in not-contiguous address space. (CONFIG_SYS_SDRAM_BASE + gd->ram_size) can land to not existent SDRAM addresses and can be very dangerous since it can potentially corrupt real SDRAM (in most cases SDRAM is aliased so writing to some not-existent address can write to real address). My proposed patch is something like this: --------------------------------------------------------- if (n banks > 2) and they are not contiguous, relocate u-boot at the end of 2nd bank even if there are more than 2 banks. Please suggest me if this is the right way to follow or suggest me some more appropriate way to correct this bug Thanks again Regards Luca Ellero diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c index cfe32cc..7525caf 100644 --- a/arch/arm/lib/board.c +++ b/arch/arm/lib/board.c @@ -333,7 +333,18 @@ void board_init_f(ulong bootflag) gd->ram_size -= CONFIG_SYS_MEM_TOP_HIDE; #endif +#if defined(PHYS_SDRAM_2) && defined(PHYS_SDRAM_2_SIZE) + if ( CONFIG_NR_DRAM_BANKS > 1 && + (PHYS_SDRAM_1 + PHYS_SDRAM_1_SIZE) != PHYS_SDRAM_2 ) + addr = PHYS_SDRAM_2 + PHYS_SDRAM_2_SIZE; + else + addr = CONFIG_SYS_SDRAM_BASE + gd->ram_size; +#else addr = CONFIG_SYS_SDRAM_BASE + gd->ram_size; +#endif + --------------------------------------------------------- I know that some arch use more than 2 banks but implementing all macros checks to PHYS_SDRAM_* leads to some macro hell. So the point here is: