From owner-freebsd-arm@freebsd.org Sun Oct 22 16:42:24 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A3036E56677 for ; Sun, 22 Oct 2017 16:42:24 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-161.reflexion.net [208.70.211.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4FDEA6D08E for ; Sun, 22 Oct 2017 16:42:23 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 27577 invoked from network); 22 Oct 2017 16:42:22 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 22 Oct 2017 16:42:22 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sun, 22 Oct 2017 12:42:22 -0400 (EDT) Received: (qmail 9900 invoked from network); 22 Oct 2017 16:42:22 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 22 Oct 2017 16:42:22 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id B868CEC8EFB; Sun, 22 Oct 2017 09:42:21 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: svn commit: r324822 - head/sys/modules/dtb/allwinner [removal of sinovoip-bpi-m3.dts from sys/modules/dtb/allwinner/Makefile DTS list] Date: Sun, 22 Oct 2017 09:42:21 -0700 References: <3AD6B1F8-512C-43BB-AC76-7721454AD02F@dsl-only.net> <20171021195812.5bdb902401b8e756b6abfe40@bidouilliste.com> <20171021204356.47e3cd6066144bcd07f46699@bidouilliste.com> <50728566-11C2-45EB-8367-00CAF38D4548@dsl-only.net> <8696CCFA-AE7D-4324-90A8-BB73402FA124@dsl-only.net> <757DA0FB-D69E-45BC-B81C-5CE0C6636E79@dsl-only.net> <1508688836.7314.6.camel@freebsd.org> To: Warner Losh , Ian Lepore , Emmanuel Vadot , freebsd-arm In-Reply-To: Message-Id: <3923365A-21CB-46AD-9715-A2F687ED4B97@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2017 16:42:24 -0000 [Providing UBLDR_LOADADDR fixed the problem for BPI-M3.] On 2017-Oct-22, at 9:23 AM, Warner Losh wrote: > On Sun, Oct 22, 2017 at 10:13 AM, Ian Lepore wrote: >> On Sat, 2017-10-21 at 22:52 -0700, Mark Millard wrote: >> > [I was not controlling UBLDR_LOADADDR in >> > my builds.] >> > >> >> UBLDR_LOADADDR is meaningless; it's not significant on arm systems, >> dating back to well before 11.0 was released. It used to set the fixed >> physical address at which ubldr[.bin] was linked to run, but now ubldr >> is self-relocating and can be loaded at any 2mb boundary (really 1mb >> boundary on most arm systems). For BPI-M3 ubldr is used and providing UBLDR_LOADADDR=0x42000000 fixed the problem by changing the start address actually used. Systems that ignore ubldr.bin and use ubldr do use UBLDR_LOADADDR as I understand. So, at least the BPI-M3 fits my more general understanding. (Is it the only one?) As I understand Ian's comment is correct for systems that use ubldr.bin and ignore ubldr: ubldr.bin is the self relocating one and ubldr is for ones that do not deal with that. FYI: The sysutils/u-boot-sinovoip-bpi-m3 has never been updated from its original distfiles. >> It should be noted that ubldr is obsolete as well; only ubldr.bin is >> needed. The older version with the elf headers intact was supposed to >> be kept around "for a few weeks, until crochet can be adjusted to not >> refer to it". That was like 3 years ago, but it never got removed. >> >> Hmmm, actually, since UBLDR_LOADADDR does end up stored in the elf >> headers, I guess if you're using the obsolete ubldr with headers >> intact, maybe it is influencing uboot's behavior and causing failures. That is what happens on the BPI-M3 based on its sysutils/u-boot-sinovoip-bpi-m3 . > Maybe it's time to delete it, other build systems ready or not. If the BPI-M3 is the only one with the issue and if support is dropped for the other issues with supporting it, then sure. Otherwise the BPI-M3 needs to progress to ubldr.bin use first. FYI: BPI-M3 are an armv7 (cortex-a7) context. === Mark Millard markmi at dsl-only.net