On Tue, 27 Mar 2018, James Hogan wrote: > > Make the default for PHYSICAL_START always 64-bit, ensuring that a > > correct sign-extended value is used if a 32-bit image is loaded by a > > 64-bit system, and matching how the load address is set in platform > > Makefile fragments (arch/mips/*/Platform) in the absence of the > > PHYSICAL_START configuration option. > > This looks correct given the defaults in the Makefile fragments. However > I presume a 32BIT kernel will produce a 32-bit ELF, in which case the > result will be indistinguishable? For other kernel image formats which > always use 64-bit pointers perhaps it matters more (if they can be > loaded by kexec-tools). uImage is 32-bit ISTR, and our ITB stuff seems > to only use 32bit addresses for CONFIG_32BIT. I don't now about other > formats. For ELF it does not matter, but as you say $VMLINUX_LOAD_ADDRESS and $VMLINUX_ENTRY_ADDRESS is needed for software which does not interpret ELF files. However my interpretation is based solely on source examination and the commit description and not actual use of these features. I assume platform Makefile fragments do use 64-bit representation for a reason though. > So unless I hear otherwise I'll probably drop the stable tag and apply > for 4.17. I won't insist on backporting. After all it's the default only and the value can be entered manually if the default does not work. Maciej
