From owner-freebsd-arm@FreeBSD.ORG Sun Apr 26 10:11:07 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 413223A4; Sun, 26 Apr 2015 10:11:07 +0000 (UTC) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BBC7411DA; Sun, 26 Apr 2015 10:11:06 +0000 (UTC) Received: from th-04.cs.huji.ac.il ([132.65.80.125]) by kabab.cs.huji.ac.il with esmtp id 1YmJWZ-000LDj-MB; Sun, 26 Apr 2015 13:10:55 +0300 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: crochet build fails at ubldr Wandboard-Dual From: Daniel Braniss In-Reply-To: Date: Sun, 26 Apr 2015 13:10:55 +0300 Cc: Tim Kientzle , freebsd-arm , Ian Lepore Message-Id: <0DADE75A-8680-4DEB-86AE-8764ACA4504C@cs.huji.ac.il> References: <1429456908.1182.82.camel@freebsd.org> <1429458041.1182.86.camel@freebsd.org> <1CA4192E-F6B5-4BD8-8BF8-8F725E1EC7BA@kientzle.com> <32B72D5A-742C-4B58-AD65-EA33B306D30C@kientzle.com> To: Luiz Otavio O Souza X-Mailer: Apple Mail (2.2098) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2015 10:11:07 -0000 > On Apr 25, 2015, at 10:28 PM, Luiz Otavio O Souza = wrote: >=20 > On 25 April 2015 at 14:58, Tim Kientzle wrote: >>=20 >>> On Apr 19, 2015, at 4:44 PM, O'Connor, Daniel wrote: >>>=20 >>>=20 >>>> On 20 Apr 2015, at 08:41, Tim Kientzle wrote: >>>>>>=20 >>>>>> Crochet does use the standard build machinery; the only = significant difference is that it builds ubldr separately after a = successful buildworld. ... >>>>>=20 >>>>> So maybe its truly a documentation issue since everyone is = convinced crochet is correct. I didnt see that mentioned in the docs. >>>>>=20 >>>> You=E2=80=99ve certainly encountered a problem but I don=E2=80=99t = yet have enough information to say anything more. Certainly, Ian is = right that you should not have to set LIBSTAND to make this work. >>>>=20 >>>> Unfortunately, it will be at least a few days before I have a = chance to try reproducing what you=E2=80=99re seeing. If you can = reproduce it consistently, please let me know; I could work up some = patches based on Ian=E2=80=99s suggestions and you could try them to see = if they change anything. >>>>=20 >>>> Another things to try: blow away Crochet=E2=80=99s work directory = before you next rebuild. In particular, that will ensure that your = world build and ubldr build are consistent with each other. >>>=20 >>> I had this issue also and worked around it by modifying the loader = Makefiles to set LIBSTAND. >>> diff --git a/sys/boot/arm/uboot/Makefile = b/sys/boot/arm/uboot/Makefile >>> index e0ea828..cbd173e 100644 >>> --- a/sys/boot/arm/uboot/Makefile >>> +++ b/sys/boot/arm/uboot/Makefile >>> @@ -113,6 +113,8 @@ CFLAGS+=3D = -I${.CURDIR}/../../../../lib/libstand/ >>> # clang doesn't understand %D as a specifier to printf >>> NO_WERROR.clang=3D >>>=20 >>> +LIBSTAND=3D ${.OBJDIR}/../../../../lib/libstand/libstand.a >>> + >>> DPADD=3D ${LIBFICL} ${LIBUBOOT} ${LIBFDT} ${LIBUBOOT_FDT} = ${LIBSTAND} >>> LDADD=3D ${LIBFICL} ${LIBUBOOT} ${LIBFDT} ${LIBUBOOT_FDT} = -lstand >>>=20 >>> diff --git a/sys/boot/efi/loader/Makefile = b/sys/boot/efi/loader/Makefile >>> index 5585f78..55b8673 100644 >>> --- a/sys/boot/efi/loader/Makefile >>> +++ b/sys/boot/efi/loader/Makefile >>> @@ -29,6 +29,8 @@ SRCS=3D autoload.c \ >>> .PATH: ${.CURDIR}/../../i386/libi386 >>> .include "${.CURDIR}/arch/${MACHINE}/Makefile.inc" >>>=20 >>> +LIBSTAND=3D ${.OBJDIR}/../../../../lib/libstand/libstand.a >>> + >>> CFLAGS+=3D -I${.CURDIR} >>> CFLAGS+=3D -I${.CURDIR}/arch/${MACHINE} >>> CFLAGS+=3D -I${.CURDIR}/../include >>>=20 >>> I did it that way because I noticed some other loader Makfiles set = LIBSTAND so I assumed it was removed incorrectly from the arm and uefi = ones. >>=20 >> I think this is the right fix, though I would be more confident if I = could locate the exact change that broke the earlier behavior. >>=20 >> Certainly most of the other boot loader Makefiles do set LIBSTAND in = this way, and arm/uboot/Makefile overrides a number of other libraries = to ensure they are for the target architecture and not the host = architecture. >>=20 >> I also notice that sys/boot/arm/uboot/Makefile has the following: >>=20 >> # where to get libstand from >> CFLAGS+=3D -I${.CURDIR}/../../../../lib/libstand/ >>=20 >> It definitely looks like a bug that it=E2=80=99s overriding the = include path for libstand but not the library path. Just above this is = a similar section for libuboot that overrides both. >>=20 >> Tim >=20 > This issue was introduced by r281156 when andrew@ enabled the build of > efi/loader for ARM. >=20 > I don't know what is the right fix for this, but the following change > also works for me: http://pastie.org/10103315 = >=20 > The idea for this change comes from sys/boot/arm/uboot/Makefile. >=20 the addition of efi is causing other problems too. I first tried crochet for arm/current, and kept hitting the libstand.a = issue, so I tried cd ..src/ and make with all the flags (including -j16), and = succeeded but failed in install. i use 10.1 to cross compile for arm/current, so I commented out efi in = Makefile.arm, and it installed ok. danny