From patchwork Tue Jul 5 04:54:52 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Alexey Brodkin X-Patchwork-Id: 644465 X-Patchwork-Delegate: sbabic@denx.de 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 3rkBQP4zXbz9s9G for ; Tue, 5 Jul 2016 14:55:09 +1000 (AEST) Received: from localhost (localhost [127.0.0.1]) by theia.denx.de (Postfix) with ESMTP id 732AEA74E3; Tue, 5 Jul 2016 06:55:07 +0200 (CEST) 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 shaD6YTYOAqb; Tue, 5 Jul 2016 06:55:07 +0200 (CEST) Received: from theia.denx.de (localhost [127.0.0.1]) by theia.denx.de (Postfix) with ESMTP id 00C50A74D6; Tue, 5 Jul 2016 06:55:07 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by theia.denx.de (Postfix) with ESMTP id 93E41A74D6 for ; Tue, 5 Jul 2016 06:55:03 +0200 (CEST) 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 VmPQ92dbxznT for ; Tue, 5 Jul 2016 06:55:03 +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 smtprelay.synopsys.com (smtprelay.synopsys.com [198.182.47.9]) by theia.denx.de (Postfix) with ESMTPS id 07B8DA74D2 for ; Tue, 5 Jul 2016 06:55:00 +0200 (CEST) Received: from us02secmta2.synopsys.com (us02secmta2.synopsys.com [10.12.235.98]) by smtprelay.synopsys.com (Postfix) with ESMTP id 9DECE24E1705; Mon, 4 Jul 2016 21:54:57 -0700 (PDT) Received: from us02secmta2.internal.synopsys.com (us02secmta2.internal.synopsys.com [127.0.0.1]) by us02secmta2.internal.synopsys.com (Service) with ESMTP id 5D76655F13; Mon, 4 Jul 2016 21:54:57 -0700 (PDT) Received: from mailhost.synopsys.com (mailhost3.synopsys.com [10.12.238.238]) by us02secmta2.internal.synopsys.com (Service) with ESMTP id 1E96455F02; Mon, 4 Jul 2016 21:54:57 -0700 (PDT) Received: from mailhost.synopsys.com (localhost [127.0.0.1]) by mailhost.synopsys.com (Postfix) with ESMTP id 0260F50A; Mon, 4 Jul 2016 21:54:57 -0700 (PDT) Received: from US01WEHTC2.internal.synopsys.com (us01wehtc2-vip.internal.synopsys.com [10.12.239.238]) by mailhost.synopsys.com (Postfix) with ESMTP id C802D4DE; Mon, 4 Jul 2016 21:54:55 -0700 (PDT) Received: from DE02WEHTCB.internal.synopsys.com (10.225.19.94) by US01WEHTC2.internal.synopsys.com (10.12.239.237) with Microsoft SMTP Server (TLS) id 14.3.266.1; Mon, 4 Jul 2016 21:54:55 -0700 Received: from DE02WEMBXB.internal.synopsys.com ([fe80::95ce:118a:8321:a099]) by DE02WEHTCB.internal.synopsys.com ([::1]) with mapi id 14.03.0266.001; Tue, 5 Jul 2016 06:54:53 +0200 From: Alexey Brodkin To: "u-boot@lists.denx.de" Thread-Topic: Wandboard: u-boot.img is getting too large Thread-Index: AQHR1nldcnoVmJDe602YFeC2lxF3/Q== Date: Tue, 5 Jul 2016 04:54:52 +0000 Message-ID: <1467694422.3144.32.camel@synopsys.com> Accept-Language: en-US, ru-RU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.121.8.129] Content-ID: <5989E5DA7F53004FBC6B5B8F152E5116@internal.synopsys.com> MIME-Version: 1.0 Cc: "fabio.estevam@freescale.com" , "trini@konsulko.com" , "otavio@ossystems.com.br" Subject: [U-Boot] Wandboard: u-boot.img is getting too large X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.15 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" Hello, Recently I started to notice that u-boot.img built for Wandboard by some toolchains becomes so large that it basically overlaps with U-Boot environment area on SD-card. According to http://wiki.wandboard.org/index.php/Boot-process#sdcard_boot_data_layout Wandboard's SD-card layout is as follows: ------------------------------>8--------------------------- #  Offset (hex) (dec)   Description ------------------------------>8--------------------------- That might introduce incompatibility issues for those who used to modify default environment but given nobody noticed the problem in question it looks like there're not many of them. Any thoughts are more than welcome. -Alexey ========================================================== 1. 0x00000000 Reserved For MBR 2. 0x00000200 512 Secondary Image Table (optional) 3. 0x00000400 1024 uBoot Image (Starting From IVT) 4. 0x00060000 393216 start of uboot env (size:8k) 5. 0x00062000 end of uboot env 6. 0x00100000 1048576 Linux kernel start 7. 0x0076AC00 7777280 start of partition 1 ------------------------------>8--------------------------- So for U-Boot we have 383kB (392192 bytes). But in up to date U-Boot for Wandboard we build separately  a) SPL  b) u-boot.img which gives us a bit more detailed SD-card layout: ------------------------------>8--------------------------- #  Offset (hex) (dec)   Description ========================== ================================ 1. 0x00000000 Reserved For MBR 2. 0x00000200 512 Secondary Image Table (optional) 3. 0x00000400 1024 SPL 4. 0x00011400   70656 u-boot.img 5. 0x00060000 39 3216 start of uboot env (size:8k) 6. 0x00062000 end of uboot env ... ------------------------------ >8--------------------------- From that layout we may calculate amount of space reserved for u-boot.img. It's just 315kb (322560 bytes). Now if I build U-Boot with Sourcery CodeBench ARM 2014.05 produced u-boot.img is already more than we expected (323840 bytes instead of "< 322560"): ------------------------------>8--------------------------- ls -la u-boot.img  -rw-rw-r-- 1 user user 323840 Jul  5 07:38 u-boot.img ------------------------------>8--------------------------- Funny enough if I rebuild U-Boot with ARM toolchain available in my Fedora 23 distro u-boot.img becomes a little bit smaller: ------------------------------>8--------------------------- ls -la u-boot.img  -rw-rw-r-- 1 user user 322216 Jul  5 07:39 u-boot.img ------------------------------>8--------------------------- What's worse this problem might not affect people most of the time because what happens people would just copy u-boot.img on SD-card and live in happiness with it... well until somebody attempts to save environment in U-Boot with "saveenv" command which will simply overwrite the very end of u-boot.img. That will lead to unusable SD-card until user dd u-boot.img on SD-card again. I may foresee this issue in the future to become more visible once we add more features in U-Boot for Wandboard or just existing code base becomes bulkier and people will consistently get larger u-boot.img files produced. IMHO there's an obvious solution for all that - just move U-Boot's env for say another 300-400k above like that: ------------------------------>8--------------------------- diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h index 99f5c0c..e39583c 100644 --- a/include/configs/wandboard.h +++ b/include/configs/wandboard.h @@ -181,7 +181,7 @@  #define CONFIG_ENV_SIZE                        (8 * 1024)    #define CONFIG_ENV_IS_IN_MMC -#define CONFIG_ENV_OFFSET              (6 * 64 * 1024) +#define CONFIG_ENV_OFFSET              (2 * 6 * 64 * 1024)  #define CONFIG_SYS_MMC_ENV_DEV         0    #endif