Date: Sat, 21 Oct 2017 22:52:18 -0700 From: Mark Millard <markmi@dsl-only.net> To: Emmanuel Vadot <manu@bidouilliste.com>, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: svn commit: r324822 - head/sys/modules/dtb/allwinner [removal of sinovoip-bpi-m3.dts from sys/modules/dtb/allwinner/Makefile DTS list] Message-ID: <757DA0FB-D69E-45BC-B81C-5CE0C6636E79@dsl-only.net> In-Reply-To: <FFF37C2C-D108-4583-8BE4-41DE9C535271@dsl-only.net> References: <3AD6B1F8-512C-43BB-AC76-7721454AD02F@dsl-only.net> <20171021195812.5bdb902401b8e756b6abfe40@bidouilliste.com> <C9F6BF5E-28DB-4569-B71E-EDE2A042FC78@dsl-only.net> <20171021204356.47e3cd6066144bcd07f46699@bidouilliste.com> <50728566-11C2-45EB-8367-00CAF38D4548@dsl-only.net> <B3F39A7C-339B-4072-9E41-A3F9DA1F590B@dsl-only.net> <8696CCFA-AE7D-4324-90A8-BB73402FA124@dsl-only.net> <FFF37C2C-D108-4583-8BE4-41DE9C535271@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
[I was not controlling UBLDR_LOADADDR in my builds.] On 2017-Oct-21, at 9:31 PM, Mark Millard <markmi@dsl-only.net> 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 : [<bff6869c>] > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?757DA0FB-D69E-45BC-B81C-5CE0C6636E79>