On 1/30/07, Maciej W. Rozycki <macro@xxxxxxxxxxxxxx> wrote:
On Tue, 30 Jan 2007, Atsushi Nemoto wrote:
> Though I do not object to remove "&& !defined(CONFIG_BUILD_ELF64)"
> from __pa_page_offset(), are there any point of CONFIG_BUILD_ELF64=y
> if your load address was CKSEG0?
Checking for code correctness and validation of the toolchain (Linux is
one of the few non-PIC users of (n)64) without having to chase hardware
that would support running from XPHYS without serious pain (the firmware
being the usual offender).
This use case was unknown by the time we introduced __pa_page_offset().
Basically this macro assumes that if BUILD_ELF64 is set the load
address is in XKPHYS. This allows to simplify __pa_page_offset()
definition for this case.
However if BUILD_ELF64 is not set then the macro deals with both
CKSEG0 and XKPHYS virtual addresses.
That said, I have not checked the every single use of __pa_page_offset(),
but the sole existence of this condition raises a question about whether
we are sure __pa_page_offset() is going to be only used on virtual
addresses in the same segment the kernel is linked to.
Well it all depends if we consider the case with BUILD_ELF64 set and a
load address in CKSEG0 a useful case. If so, then we can remove "&&
!defined(CONFIG_BUILD_ELF64)"
from __pa_page_offset(). It shouldn't hurt the case where BUILD_ELF64
is not set and Atsushi seems to agree.
BTW, maybe we can simply remove BUILD_ELF64 at all, since it's only
used to add '-msym32' switch in the makefile. This switch could be
automatically be added by the makefile instead thanks the following
condition:
if CONFIG_64BITS and ${load-y} in CKSEG0
cflags-y += -msym32
endif
what do you think ?
Sometimes
references to both CKSEG0 and XPHYS may be used in the same kernel, e.g.
because the the kernel is linked to XPHYS, but the firmware is limited to
accept CKSEG0 addresses only (and we do call back into firmware on some
platforms).
Please keep these conversions in the platform specific codes before
calling back the firmware.
--
Franck
