svn commit: r324822 - head/sys/modules/dtb/allwinner [removal of sinovoip-bpi-m3.dts from sys/modules/dtb/allwinner/Makefile DTS list]

[Mark Millard]

[I was not controlling UBLDR_LOADADDR in
my builds.]

On 2017-Oct-21, at 9:31 PM, Mark Millard <markmi at 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 at 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