From patchwork Thu Jul 24 05:27:07 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Chris Packham X-Patchwork-Id: 373119 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 0263F1401DE for ; Thu, 24 Jul 2014 15:27:36 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by theia.denx.de (Postfix) with ESMTP id A4048A76D1; Thu, 24 Jul 2014 07:27:35 +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 XyPnf2ErCFiJ; Thu, 24 Jul 2014 07:27:35 +0200 (CEST) Received: from theia.denx.de (localhost [127.0.0.1]) by theia.denx.de (Postfix) with ESMTP id 093EEA76DF; Thu, 24 Jul 2014 07:27:33 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by theia.denx.de (Postfix) with ESMTP id 6E6AEA76DF for ; Thu, 24 Jul 2014 07:27:28 +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 JTcFhco6clZw for ; Thu, 24 Jul 2014 07:27:25 +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-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) by theia.denx.de (Postfix) with ESMTPS id DAEC6A76D1 for ; Thu, 24 Jul 2014 07:27:20 +0200 (CEST) Received: by mail-pa0-f52.google.com with SMTP id bj1so3176769pad.11 for ; Wed, 23 Jul 2014 22:27:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=Wo21umfqVBDpJNszF8hU7coAN6v+uSVe4uLb9pOOzDk=; b=VfXF8/ktPqy0SC8gsixcSjFsqXTXQA+LV/PgawPLsI3vhdGCgFsy58USQEHGmNCGWP sbiDK4xPFYBqG1ih6jymNYuWS1QhasP+gn0M4r+vTsdDjFyZLf1DXNZe3qwUn0yIhJxj adhNg1jjupW2GZLSOJ7XVagPoa4IYAGooy3aYSVzw7XS4ia2gwcCfR/ujTlLaX6NdSqm n3E4ZYbs14zuyfvGpR3zocXoRSPExvTFH9dHjvQx8b2TK8XKkNrhqXUfBklnSSJLrWOf Hy4O61zjxQ5x8s2ePbRr0mmDb/InYvwHP6KlvEMf5AaUVrQxwN5JzceFDEOYrr9Ay2dx bS3A== X-Received: by 10.66.249.71 with SMTP id ys7mr7505754pac.112.1406179638190; Wed, 23 Jul 2014 22:27:18 -0700 (PDT) Received: from chrisp3-dl.ws.atlnz.lc (2-163-36-202-static.alliedtelesis.co.nz. [202.36.163.2]) by mx.google.com with ESMTPSA id yb4sm4230301pbb.9.2014.07.23.22.27.16 for (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Jul 2014 22:27:17 -0700 (PDT) From: Chris Packham To: sjg@chromium.org Date: Thu, 24 Jul 2014 17:27:07 +1200 Message-Id: <1406179627-9496-1-git-send-email-judge.packham@gmail.com> X-Mailer: git-send-email 1.7.9.5 In-Reply-To: References: Cc: trini@ti.com, u-boot@lists.denx.de, Chris Packham Subject: [U-Boot] [PATCH] Makefile: use u-boot.map for binary_size_check 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: , MIME-Version: 1.0 Sender: u-boot-bounces@lists.denx.de Errors-To: u-boot-bounces@lists.denx.de u-boot.map is generated automatically by the compiler and more importantly can handle addresses >4GB. --- On Thu, Jul 24, 2014 at 5:14 PM, Chris Packham wrote: > Hi Simon, > > On Wed, Jul 23, 2014 at 10:27 PM, Simon Glass wrote: >> On 22 July 2014 18:08, Chris Packham wrote: >>> file_size was being calculated using back-ticks but map_size uses >>> $(shell ...). Update the file_size calculation to use $(shell ...). >>> >>> Signed-off-by: Chris Packham >> >> Acked-by: Simon Glass >> >> But you might want to look at this. >> >> http://patchwork.ozlabs.org/patch/371936/ >> > > Thanks. I've re-submitted a version with Jeroen's change included and > it seems a v2 of his patch is imminent too. Either way I'm not fussed. > > But this has highlighted another issue I'm experiencing related to > this code. Originally I thought it was because I was doing something a > bit weird with a custom u-boot.lds but actually the problem is my > u-boot is setup so that it finishes exactly at the end of a 32bit > address space so _image_binary_end is just off the end of it which > screws up the size calculation. > > $ grep _image_binary_end u-boot.map > 0x0000000100000000 _image_binary_end = . > > $ grep _image_binary_end System.map > 00000000 A _image_binary_end > > $ make binary_size_check > ... > System.map shows a binary size of -4294180864 > but u-boot.bin shows 786432 > make: *** [binary_size_check] Error 1 > > I think it should be possible to change binary_size_check to use > u-boot.map instead of System.map but would that be OK for all > architectures? Something like this works for me but maybe there is a way to get nm to handle addresses >4GB. Makefile | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index b98a80a..3ed02a4 100644 --- a/Makefile +++ b/Makefile @@ -785,14 +785,15 @@ u-boot.hex u-boot.srec: u-boot FORCE OBJCOPYFLAGS_u-boot.bin := -O binary -binary_size_check: u-boot.bin System.map FORCE +binary_size_check: u-boot.bin FORCE @file_size=$(shell wc -c u-boot.bin | awk '{print $$1}') ; \ - map_size=$(shell cat System.map | \ + map_size=$(shell cat u-boot.map | \ awk '/_image_copy_start/ {start = $$1} /_image_binary_end/ {end = $$1} END {if (start != "" && end != "") print "ibase=16; " toupper(end) " - " toupper(start)}' \ + | sed 's/0X//g' \ | bc); \ if [ "" != "$$map_size" ]; then \ if test $$map_size -ne $$file_size; then \ - echo "System.map shows a binary size of $$map_size" >&2 ; \ + echo "u-boot.map shows a binary size of $$map_size" >&2 ; \ echo " but u-boot.bin shows $$file_size" >&2 ; \ exit 1; \ fi \