From patchwork Sun Mar 26 22:38:33 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Heiko Stuebner X-Patchwork-Id: 743585 X-Patchwork-Delegate: sjg@chromium.org Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.denx.de (dione.denx.de [81.169.180.215]) by ozlabs.org (Postfix) with ESMTP id 3vrsWp2w7Lz9s2s for ; Mon, 27 Mar 2017 09:38:45 +1100 (AEDT) Received: by lists.denx.de (Postfix, from userid 105) id C258AC21BE6; Sun, 26 Mar 2017 22:38:41 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on lists.denx.de X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=unavailable autolearn_force=no version=3.4.0 Received: from lists.denx.de (localhost [IPv6:::1]) by lists.denx.de (Postfix) with ESMTP id 1741AC21BE6; Sun, 26 Mar 2017 22:38:38 +0000 (UTC) Received: by lists.denx.de (Postfix, from userid 105) id 48733C21BE6; Sun, 26 Mar 2017 22:38:36 +0000 (UTC) Received: from gloria.sntech.de (gloria.sntech.de [95.129.55.99]) by lists.denx.de (Postfix) with ESMTPS id 1E0AFC21BE5 for ; Sun, 26 Mar 2017 22:38:35 +0000 (UTC) Received: from p5b127b1d.dip0.t-ipconnect.de ([91.18.123.29] helo=phil.localnet) by gloria.sntech.de with esmtpsa (TLS1.1:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1csGny-0002lF-4L; Mon, 27 Mar 2017 00:38:34 +0200 From: Heiko Stuebner To: Simon Glass , Tom Rini Date: Mon, 27 Mar 2017 00:38:33 +0200 Message-ID: <13311000.Ut1nIK35EQ@phil> User-Agent: KMail/5.2.3 (Linux/4.9.0-2-amd64; KDE/5.28.0; x86_64; ; ) In-Reply-To: References: <20170323234134.10325-1-heiko@sntech.de> <7607266.99lxGRV2jP@phil> MIME-Version: 1.0 Cc: U-Boot Mailing List Subject: Re: [U-Boot] [PATCH 2/3] rockchip: rk3188: Add Radxa Rock board X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.18 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" Am Sonntag, 26. März 2017, 15:28:44 CEST schrieb Simon Glass: > Hi Heiko, > > On 26 March 2017 at 15:00, Heiko Stuebner wrote: > > Am Sonntag, 26. März 2017, 22:52:16 CEST schrieb Heiko Stuebner: > >> Am Sonntag, 26. März 2017, 22:41:35 CEST schrieb Heiko Stuebner: > >> > Am Sonntag, 26. März 2017, 22:13:08 CEST schrieb Heiko Stuebner: > >> > > Am Sonntag, 26. März 2017, 14:00:51 CEST schrieb Simon Glass: > >> > > > Hi Heiko, > >> > > > > >> > > > On 26 March 2017 at 13:59, Simon Glass wrote: > >> > > > > Hi Heiko, > >> > > > > > >> > > > > On 26 March 2017 at 13:06, Heiko Stuebner wrote: > >> > > > >> Hi Simon, > >> > > > >> > >> > > > >> Am Samstag, 25. März 2017, 20:39:08 CEST schrieb Simon Glass: > >> > > > >>> On 23 March 2017 at 17:41, Heiko Stuebner wrote: > >> > > > >>> > The Rock is a RK3188 based single board computer by Radxa. > >> > > > >>> > Currently it still relies on the proprietary DDR init and > >> > > > >>> > cannot use the generic SPL, but at least is able to boot > >> > > > >>> > a linux kernel and system up to a regular login prompt. > >> > > > >>> > > >> > > > >>> > Signed-off-by: Heiko Stuebner > >> > > > >>> > Reviewed-by: Simon Glass > >> > > > >>> > Tested-by: Kever Yang > >> > > > >>> > --- > >> > > > >>> > arch/arm/dts/Makefile | 1 + > >> > > > >>> > arch/arm/dts/rk3188-radxarock.dts | 382 ++++++++++++++++++++++++++++++++++ > >> > > > >>> > arch/arm/mach-rockchip/rk3188/Kconfig | 11 + > >> > > > >>> > board/radxa/rock/Kconfig | 15 ++ > >> > > > >>> > board/radxa/rock/MAINTAINERS | 6 + > >> > > > >>> > board/radxa/rock/Makefile | 7 + > >> > > > >>> > board/radxa/rock/rock.c | 7 + > >> > > > >>> > configs/rock_defconfig | 58 ++++++ > >> > > > >>> > include/configs/rock.h | 30 +++ > >> > > > >>> > 9 files changed, 517 insertions(+) > >> > > > >>> > create mode 100644 arch/arm/dts/rk3188-radxarock.dts > >> > > > >>> > create mode 100644 board/radxa/rock/Kconfig > >> > > > >>> > create mode 100644 board/radxa/rock/MAINTAINERS > >> > > > >>> > create mode 100644 board/radxa/rock/Makefile > >> > > > >>> > create mode 100644 board/radxa/rock/rock.c > >> > > > >>> > create mode 100644 configs/rock_defconfig > >> > > > >>> > create mode 100644 include/configs/rock.h > >> > > > >>> > >> > > > >>> I am still having trouble applying this patch. I get build errors: > >> > > > >>> > >> > > > >>> arm: + rock > >> > > > >>> +arch/arm/Makefile:22: CONFIG_CPU_V7 -march=armv7-a > >> > > > >>> +make[2]: *** No rule to make target 'dts/dt.dtb', needed by > >> > > > >>> 'tpl/u-boot-tpl.dtb'. Stop. > >> > > > >>> +make[1]: *** [tpl/u-boot-tpl.bin] Error 2 > >> > > > >>> +make: *** [sub-make] Error 2 > >> > > > >>> 0 0 1 /1 rock > >> > > > >>> > >> > > > >>> Also there seems to be a duplicate config: > >> > > > >>> > >> > > > >>> arm: + rock > >> > > > >>> +In file included from include/configs/rock.h:11:0, > >> > > > >>> + from include/config.h:5, > >> > > > >>> + from include/common.h:21, > >> > > > >>> + from arch/arm/lib/asm-offsets.c:15: > >> > > > >>> + #define CONFIG_SYS_THUMB_BUILD > >> > > > >>> + ^ > >> > > > >>> + from lib/asm-offsets.c:15: > >> > > > >>> +In file included from include/linux/kconfig.h:4:0, > >> > > > >>> + from :0: > >> > > > >>> +include/generated/autoconf.h:10:0: note: this is the location of the > >> > > > >>> previous definition > >> > > > >>> + #define CONFIG_SYS_THUMB_BUILD 1 > >> > > > >> > >> > > > >> looks like this got run over by another Kconfig migration on march-18. > >> > > > >> New patches (migration + rock board) coming up shortly. > >> > > > > > >> > > > > Thanks - what toolchain are you using to test this? > >> > > > > >> > > > Also I am still getting this error: > >> > > > > >> > > > buildman rock$ > >> > > > boards.cfg is up to date. Nothing to do. > >> > > > Building current source for 1 boards (1 thread, 8 jobs per thread) > >> > > > arm: + rock > >> > > > +make[2]: *** No rule to make target 'dts/dt.dtb', needed by > >> > > > 'tpl/u-boot-tpl.dtb'. Stop. > >> > > > +make[1]: *** [tpl/u-boot-tpl.bin] Error 2 > >> > > > +make: *** [sub-make] Error 2 > >> > > > 0 0 1 /1 rock > >> > > > >> > > that is really strange. > >> > > > >> > > I'm building with the armhf cross-compiler from Debian testing, which is > >> > > > >> > > arm-linux-gnueabihf-gcc (Debian 6.3.0-5) 6.3.0 20170124 > >> > > > >> > > My git history also is up-to-date it seems: > >> > > 14ef0b180b rockchip: rk3188: Add Radxa Rock board > >> > > d0348986cc rockchip: rk3188: follow THUMB_BUILD Kconfig migration > >> > > 3bffe88d68 rockchip: video: Split out HDMI controller code > >> > > a188a5a35c rockchip: i2c: Add compatibles for Rockchip Cortex-A9 socs > >> > > 903fae5666 rockchip: rk3188: Setup the armclk in spl > >> > > 7957cc4bd0 rockchip: clk: rk3188: Allow configuration of the armclk > >> > > > >> > > with 3bffe88d68 being your current head and my build commands being > >> > > > >> > > make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- clean > >> > > make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- rock_defconfig > >> > > make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- > >> > > >> > that also works with a "make mrproper" before everything else. > >> > > >> > > >> > > Strangely the tpl shouldn't require a dtb at all, as it needs to use > >> > > OF_PLATDATA. Am I missing some config option somewhere? > >> > > >> > I also did play around a bit with buildman just now: > >> > > >> > At first I forgot the "$" after rock, so build everything with rock in the > >> > name and the radxarock failed because the somewhat old 4.9 toolchain > >> > used seems to produce a TPL image that is over the size constraints. > >> > I.e. 1020 bytes on 4.9 vs. 792 bytes on 6.3.0 . > >> > > >> > When I drop the SPL_MAX_SIZE from rk3188_common.h for the TPL build > >> > tools/buildman/buildman -P rock > >> > builds 14 boards and finishes sucessfully including the radxarock. > >> > > >> > > >> > Now when I try buildman -P rock$ I seem to also get the error about the > >> > missing dts/dt.dtb , which does not occur in my regular builds and also > >> > not when building the bigger number of boards. I guess I need to figure > >> > out what is different in that case. > >> > >> sorry for spamming, but > >> > >> also when entering .bm-work/rock where buildman failed and doing just my > >> > >> make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- > >> > >> in that directory created by buildman, produces perfectly fine images. > >> (buildman does create the .config, so I'm just finishing the build, buildman > >> failed at for unknown reasons) > > > > and a > > tools/buildman/buildman -PVv -T1 -j1 rock$ > > > > also finishes sucessfully, so it looks like that is more some sort of build > > concurrency issue, with the platdata not being created in time for some > > reason. > > Yes I think that is right. I will see if I can fix that. > > Re the toolchain, if I pull in this patch then I will likely cause a > build breakable on common toolchains. What do you think is the best > option? Can the TPL be shrunk a little with gcc 4.9? I've added Tom for comments, executive summary: - rk3188-tpl is size limited to 1020 bytes - gcc 6.3 produces a rk3188-tpl of 792 bytes - gcc 4.9 makes it 1020 bytes - buildman seems to always use gcc-4.9 - rk3188 board does not compile with buildman Isn't holding on to a pretty old compiler for everything somewhat strange? ;-) I think the recent memset change in commit c67c8c604b6c ("board_init.c: Always use memset()") did hurt us the most sizewise, as we're now using the libgeneric memset which is quite a bit bigger than the naive fallback that existed in board_init.c before. Reverting and using the naive memset again brings us down to 952 bytes again even on gcc-4.9 . I guess I could just remove the TPL_LIBGENERIC option again and provide a similarly small/naive memset in the rk3188 tpl board? ################ Or maybe just check if the size limit in u-boot-spl.lds is actually correct. In our example gcc-4.9 produces a 1020bytes result and the SPL_SIZE_LIMIT is set to (0x400 - 0x4) = 1020, so of course doing does look somewhat correct. But of course that rides way to much on the edge when every additional byte will break the build. Heiko diff --git a/arch/arm/cpu/u-boot-spl.lds b/arch/arm/cpu/u-boot-spl.lds index 068163b73a..c9643efd96 100644 --- a/arch/arm/cpu/u-boot-spl.lds +++ b/arch/arm/cpu/u-boot-spl.lds @@ -72,7 +72,7 @@ SECTIONS } #if defined(CONFIG_SPL_MAX_SIZE) -ASSERT(__image_copy_end - __image_copy_start < (CONFIG_SPL_MAX_SIZE), \ +ASSERT(__image_copy_end - __image_copy_start <= (CONFIG_SPL_MAX_SIZE), \ "SPL image too big"); #endif