From patchwork Tue May 6 08:07:20 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christian Riesch X-Patchwork-Id: 346073 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 F15CD1402CF for ; Tue, 6 May 2014 18:13:18 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by theia.denx.de (Postfix) with ESMTP id 139FC4B9D7; Tue, 6 May 2014 10:13:17 +0200 (CEST) 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 eyjwSIryZxCj; Tue, 6 May 2014 10:13:16 +0200 (CEST) Received: from theia.denx.de (localhost [127.0.0.1]) by theia.denx.de (Postfix) with ESMTP id C1F264B9C1; Tue, 6 May 2014 10:13:14 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by theia.denx.de (Postfix) with ESMTP id B02114B9C1 for ; Tue, 6 May 2014 10:13:07 +0200 (CEST) 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 O38ghUXZVzPn for ; Tue, 6 May 2014 10:13:05 +0200 (CEST) X-Greylist: delayed 355 seconds by postgrey-1.27 at theia; Tue, 06 May 2014 10:13:01 CEST 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-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by theia.denx.de (Postfix) with ESMTPS id 265A94B9B4 for ; Tue, 6 May 2014 10:13:01 +0200 (CEST) Received: by mail-ee0-f44.google.com with SMTP id c41so6169948eek.3 for ; Tue, 06 May 2014 01:13:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mime-version:content-type :content-transfer-encoding:content-disposition; bh=rQxUXyNLFf8yTd0fOK1Tnl4BSv+wnziAGbvvWV07Kd8=; b=L1haaVFv8GsKNqifoWEd8uYyHyZVb0ZaQgKeK+kf7hFXAxDm4VtqbU9nDR+8DvQC8S xFUiQ7syjccYHTQtL4+Rr2y8JjhfIxtOsMfHaNhRgjrx/t/uWMoNE5FDa45Ay6Jxyv8b zIdZt0JNTS9vQxJKmqBSELW/ARa4qa0wFz45bhBsOZOo//YbqZkjdG910wBGPT/FBCVa g7iktbE4VF7TWFluTdfa4RYtHHYgLwKzcxZ2/ILGFqcguAfuttDpe4QxaqtU0M1OZKn1 miBb6CWXVGVqgjQBilLsb4GZDUEAwrixx04k2HLFLZSQuf/33mL7T+HhJtwC+vft3bR6 9e0w== X-Received: by 10.15.75.9 with SMTP id k9mr1436920eey.110.1399363626123; Tue, 06 May 2014 01:07:06 -0700 (PDT) Received: from CHRRIE10.omicron.at (vs162244.vserver.de. [62.75.162.244]) by mx.google.com with ESMTPSA id t4sm36338200eeb.29.2014.05.06.01.07.05 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 06 May 2014 01:07:05 -0700 (PDT) Date: Tue, 06 May 2014 10:07:20 +0200 From: Christian Riesch To: Tom Taylor , u-boot@lists.denx.de Message-ID: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Disposition: inline Cc: Tom Rini Subject: Re: [U-Boot] DA850EVM with USE_NAND config does not pad the AIS file 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 Tom, Thank you very much for your investigations :-) --On April 26, 2014 13:34 -0400 Tom Taylor wrote: > I'm a U-Boot newbie so please feel free to correct how I'm reporting this > issue.. > > I recently downloaded the 2014.04-rc3 snapshot to build U-Boot for my > custom DA850-based board. The only change was to add a new target > "dav850evm_nand" in boards.cfg with the added parameter "USE_NAND". > > The resulting AIS file was programmed into EVM-compatible NAND using > standard sfh_OMAP-L138 method. > > The board failed to boot, and stayed in a loop printing the SPL console > message repeatedly. > > After some debugging with CCS 5.5 and an XDS100v2, I found that incorrect > code was being loaded into the 0xc108000 RAM destination. The da850evm.h > file defines CONFIG_SYS_NAND_U_BOOT_OFFS as 0x28000, which corresponds to > an AIS offset of 0x8000 but the u-boot header did not appear there in the > AIS file. A search revealed that the Makefile catenated u-boot > immediately after the SPL without any padding. > > Further investigation revealed that the target Makefile needs > CONFIG_SPL_MAX_SIZE to be defined as 0x8000 in order for the padding to > be performed properly; however, this constant was apparently deleted > during a series of changes in April, 2013 to accommodate separate code > and BSS size limits for another target. In its place, > CONFIG_SPL_MAX_FOOTPRINT was defined as 32768. Unfortunately, the > da850evm Makefile does not refer to this constant. > > To solve the problem, I added the following 2 lines in my custom-modified > da850evm.h: ># define CONFIG_SPL_PAD_TO 0x8000 ># define CONFIG_SPL_MAX_SIZE 0x8000 > > although the first line may not be strictly required. Yes, CONFIG_SPL_PAD_TO is currently not used for the 'make u-boot.ais' target in the Makefile. Instead, the Makefile uses CONFIG_SPL_MAX_SIZE for padding the SPL, which is probably wrong. > This solved the > problem and allowed the board to boot. > > Doesn't this mean that other similar targets may be broken? I think yes. I think the right fix would be to change the Makefile to use CONFIG_SPL_PAD_TO instead of CONFIG_SPL_MAX_SIZE for the u-boot.ais target. And then check all ARM926EJS/Davinci configurations that use SPL: (extending Tom Rini's grep command from his email) $ git grep -l ARM926EJS include/configs/ | xargs grep -l DAVINCI | xargs grep -l _SPL_ include/configs/cam_enc_4xx.h include/configs/da830evm.h include/configs/da850evm.h include/configs/hawkboard.h include/configs/ipam390.h For the cam_enc_4xx CONFIG_SPL_PAD_TO is already defined, so it should work fine after fixing the Makefile. Heiko, any comments on this? Are you actually using the u-boot.ais target? da830evm and hawkboard did not use CONFIG_SPL_MAX_SIZE, so no need to fix them. da850evm: We should add CONFIG_SPL_PAD_TO as already suggested by you. ipam390.h: I think the #define CONFIG_SPL_MAX_SIZE 0x20000 should be removed or replaced by #define CONFIG_SPL_PAD_TO 0x20000. But actually the board has been added after the commits that replace CONFIG_SPL_MAX_SIZE by CONFIG_SPL_MAX_FOOTPRINT, so why didn't that issue come up when adding the board to mainline? Heiko, any comments? Are you using make u-boot.ais here or something else? Christian diff --git a/Makefile b/Makefile index ff38a43..869f442 100644 --- a/Makefile +++ b/Makefile @@ -890,7 +890,7 @@ MKIMAGEFLAGS_u-boot-spl.ais = -s -n $(if $(CONFIG_AIS_CONFIG_FILE), \ spl/u-boot-spl.ais: spl/u-boot-spl.bin FORCE $(call if_changed,mkimage) -OBJCOPYFLAGS_u-boot.ais = -I binary -O binary --pad-to=$(CONFIG_SPL_MAX_SIZE) +OBJCOPYFLAGS_u-boot.ais = -I binary -O binary --pad-to=$(CONFIG_SPL_PAD_TO) u-boot.ais: spl/u-boot-spl.ais u-boot.img FORCE $(call if_changed,pad_cat)