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

[Ian Lepore]

On Sun, 2017-10-22 at 10:23 -0600, Warner Losh wrote:
> On Sun, Oct 22, 2017 at 10:13 AM, Ian Lepore <ian at freebsd.org> 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).
> > 
> > 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.
> > 
> Maybe it's time to delete it, other build systems ready or not.
> 
> Warner

After digging through some old IRC logs, where we left off on this when
it was last discussed in April 2017, we were waiting for a last few
remaining uboot ports to either get converted to the new master scheme,
or have their one-off patches updated to stop referring to the elf
ubldr.  Also, there was a need to ensure the cache-flushing patches
(flush before launching ubldr and in the API IO code) are in place in
your uboot fork.

I think at this point we're probably down to just the one-off uboot
ports needing small changes.

-- Ian