From owner-freebsd-arm@freebsd.org Sun Oct 22 05:52:22 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 8C50AE49DE8 for ; Sun, 22 Oct 2017 05:52:22 +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 3A44E7EA16 for ; Sun, 22 Oct 2017 05:52:21 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 475 invoked from network); 22 Oct 2017 05:52:20 -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 05:52:20 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sun, 22 Oct 2017 01:52:20 -0400 (EDT) Received: (qmail 14315 invoked from network); 22 Oct 2017 05:52:20 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 22 Oct 2017 05:52:20 -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 82FE8EC7B89; Sat, 21 Oct 2017 22:52:19 -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: Sat, 21 Oct 2017 22:52:18 -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> To: Emmanuel Vadot , freebsd-arm In-Reply-To: Message-Id: <757DA0FB-D69E-45BC-B81C-5CE0C6636E79@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 05:52:22 -0000 [I was not controlling UBLDR_LOADADDR in my builds.] On 2017-Oct-21, at 9:31 PM, Mark Millard wrote: > [Ignoring message history here.] > > One of my assumptions was bad. It turns out > that one reason that the BPI-M3 is working > is that I've not been updating ubldr and > ubldr.bin : > > # ls -lT /boot/msdos/ > total 488 > -rwxr-xr-x 1 root wheel 271949 Oct 24 03:28:54 2016 ubldr > -rwxr-xr-x 1 root wheel 224044 Oct 24 03:28:54 2016 ubldr.bin > > vs. what was built for -r317015 : > > # ls -lT /boot/ubldr* > -r--r--r-- 1 root wheel 286515 Apr 18 23:41:42 2017 /boot/ubldr > -r--r--r-- 1 root wheel 234960 Apr 18 23:41:42 2017 /boot/ubldr.bin > > If I substitute the pair from /boot/ubldr* into > /boot/msdos/ the boot fails with: > > Booting from: mmc 0 ubldr > reading ubldr > 286515 bytes read in 102 ms (2.7 MiB/s) > ## Starting application at 0x01000098 ... > undefined instruction > pc : [<01401000>] lr : [] > reloc pc : [<8b49c000>] lr : [<4a00369c>] > sp : bbf42cb0 ip : 00000002 fp : bff68560 > r10: 00000001 r9 : bbf44ee8 r8 : 00000000 > r7 : 00000001 r6 : bbf47c50 r5 : 01000098 r4 : 00000000 > r3 : 00000001 r2 : 0000000a r1 : 00000000 r0 : 00000000 > Flags: nZCv IRQs off FIQs off Mode SVC_32 > Resetting CPU ... > > resetting ... > > So overall my -r317015 build is broken as well, > likely for different reasons. > > With the 2016-Oct-24 unbldr* pair the matching > text is: > > Booting from: mmc 0 ubldr > reading ubldr > 271949 bytes read in 96 ms (2.7 MiB/s) > ## Starting application at 0x42000098 ... > Consoles: U-Boot console > Compatible U-Boot API signature found @0xbbf46368 > > FreeBSD/armv6 U-Boot loader, Revision 1.2 > (markmi@FreeBSDx64, Mon Oct 24 00:41:23 PDT 2016) > > > and so on. > > A very different "Starting application at" between > the failing and working ones. > > I'd have to get past this before I could test an > overall build with more modern issues. > > I have no clue if/when I'll figure this out. I was not controlling UBLDR_LOADADDR in my armv7 builds. My original build was via crochet and it established the ubldr ubldr.bin pair that was still in use --with the UBLDR_LOADADDR correctly filled in when they were generated. The two types of boards that I have access to need different UBLDR_LOADADDR values. Neither was being set. Both were dependent on having it being correct the first time and not updating ubldr* since then. === Mark Millard markmi at dsl-only.net