From patchwork Tue May 6 11:30:25 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christian Riesch X-Patchwork-Id: 346136 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 A33A4141337 for ; Tue, 6 May 2014 21:30:31 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by theia.denx.de (Postfix) with ESMTP id E6BFD4B7D6; Tue, 6 May 2014 13:30:27 +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 65QOOp2loMjy; Tue, 6 May 2014 13:30:27 +0200 (CEST) Received: from theia.denx.de (localhost [127.0.0.1]) by theia.denx.de (Postfix) with ESMTP id B09E74B7CB; Tue, 6 May 2014 13:30:25 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by theia.denx.de (Postfix) with ESMTP id 11EBA4B7CB for ; Tue, 6 May 2014 13:30:19 +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 J8ai8AYdLNgQ for ; Tue, 6 May 2014 13:30:16 +0200 (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-f43.google.com (mail-ee0-f43.google.com [74.125.83.43]) by theia.denx.de (Postfix) with ESMTPS id 7AE604B7C8 for ; Tue, 6 May 2014 13:30:12 +0200 (CEST) Received: by mail-ee0-f43.google.com with SMTP id d17so1643657eek.2 for ; Tue, 06 May 2014 04:30:12 -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=uyfyNfUtzbjyIBuWgqfuXxQGO0LtEGpgn9Q18NYnxRQo6YaMRLtqX+7W+JR/FhdWs5 kYYxCpQWDkn/xbHkF5ZzyEwoFS7qSGxX4NYoSqECtxnhoxuO4yKSl9f71pBZ2Pfprfi3 WXMQ1U7Gx1lFC6t7puHKe0SgFzl8hWgZIxx4ojkGOhsh2N9INMAwLMGoFoA2ams3YgZW hiNu+gvD0Wbv73b/rFO22VEeU8d7NBcRMmLVUS78wEC/SHRza+zaoOlBwSZW6hKqNPpZ Ro4NBiEh2The3ZKQqfiKxlioSU0XxSGqqN7/9FTk9Db0+B5sAe6m0xhlGHNGtrHknYwM XnCg== X-Received: by 10.14.122.196 with SMTP id t44mr9450147eeh.61.1399375812241; Tue, 06 May 2014 04:30:12 -0700 (PDT) Received: from CHRRIE10.omicron.at (vs162244.vserver.de. [62.75.162.244]) by mx.google.com with ESMTPSA id p9sm26743967eeg.32.2014.05.06.04.30.10 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 06 May 2014 04:30:11 -0700 (PDT) Date: Tue, 06 May 2014 13:30:25 +0200 From: Christian Riesch To: Tom Taylor , u-boot@lists.denx.de Message-ID: <1175F677D729FCC42037B0B8@[172.22.2.41]> 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)