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

[Mark Millard]

[Providing UBLDR_LOADADDR fixed the problem for BPI-M3.]

On 2017-Oct-22, at 9:23 AM, Warner Losh <imp at bsdimp.com> 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).


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