RFC: Sentosa boot fix

RFC: Sentosa boot fix

[Daniel Jacobowitz]

From: Daniel Jacobowitz <dan@codesourcery.com>

Always support CKSEG0 for 64-bit kernels.

This prevents an early exception when used without a ramdisk.

Signed-off-by: Daniel Jacobowitz <dan@codesourcery.com>

---

Here's a crude patch that lets my Sentosa boot using GIT HEAD.
The problem is __pa_symbol(&_end); the kernel is linked at
0xffffffff80xxxxxx, so subtracting a PAGE_OFFSET of 0xa800000000000000
does not do anything useful to this address at all.

This may be the wrong fix, but if so, I don't understand what's going
on.  What does CKSEG0 have to do with !CONFIG_BUILD_ELF64?

diff --git a/include/asm-mips/page.h b/include/asm-mips/page.h
index 2f9e1a9..81dc8a6 100644
--- a/include/asm-mips/page.h
+++ b/include/asm-mips/page.h
@@ -132,7 +132,7 @@ typedef struct { unsigned long pgprot; } pgprot_t;
 /* to align the pointer to the (next) page boundary */
 #define PAGE_ALIGN(addr)	(((addr) + PAGE_SIZE - 1) & PAGE_MASK)
 
-#if defined(CONFIG_64BIT) && !defined(CONFIG_BUILD_ELF64)
+#if defined(CONFIG_64BIT)
 #define __pa_page_offset(x)	((unsigned long)(x) < CKSEG0 ? PAGE_OFFSET : CKSEG0)
 #else
 #define __pa_page_offset(x)	PAGE_OFFSET

-- 
Daniel Jacobowitz
CodeSourcery

Re: RFC: Sentosa boot fix

[Franck Bui-Huu]

Hi,

On 1/28/07, Daniel Jacobowitz <dan@debian.org> wrote:
> The problem is __pa_symbol(&_end); the kernel is linked at
> 0xffffffff80xxxxxx, so subtracting a PAGE_OFFSET of 0xa800000000000000
> does not do anything useful to this address at all.
>

In my understanding, if your kernel is linked at 0xffffffff80xxxxxx,
you shouldn't have CONFIG_BUILD_ELF64 set.

-- 
               Franck

Re: RFC: Sentosa boot fix

[Maciej W. Rozycki]

On Mon, 29 Jan 2007, Franck Bui-Huu wrote:

> > The problem is __pa_symbol(&_end); the kernel is linked at
> > 0xffffffff80xxxxxx, so subtracting a PAGE_OFFSET of 0xa800000000000000
> > does not do anything useful to this address at all.
> >
> 
> In my understanding, if your kernel is linked at 0xffffffff80xxxxxx,
> you shouldn't have CONFIG_BUILD_ELF64 set.

 Well, the option used to select between 64-bit and 32-bit ELF for 
building 64-bit configurations.  I can see it has been changed from its 
original meaning and it now only controls whether "-mno-explicit-relocs" 
is passed to the compiler or not, which is sort of useless and certainly 
does not match the intent nor what the description says.  The 64-bit 
format is now used unconditionally and you can always pass such obscure 
options to the compiler on the make's command line, so instead of this fix 
I vote for complete removal of the BUILD_ELF64 option.

  Maciej

Re: RFC: Sentosa boot fix

[Atsushi Nemoto]

On Mon, 29 Jan 2007 15:46:20 +0000 (GMT), "Maciej W. Rozycki" <macro@linux-mips.org> wrote:
>  Well, the option used to select between 64-bit and 32-bit ELF for 
> building 64-bit configurations.  I can see it has been changed from its 
> original meaning and it now only controls whether "-mno-explicit-relocs" 
> is passed to the compiler or not, which is sort of useless and certainly 
> does not match the intent nor what the description says.  The 64-bit 
> format is now used unconditionally and you can always pass such obscure 
> options to the compiler on the make's command line, so instead of this fix 
> I vote for complete removal of the BUILD_ELF64 option.

Though I do not know much about -mno-explicit-relocs,
CONFIG_BUILD_ELF64 controls -msym32 option and this is the reason of
the tweak in __pa_page_offset().

I thought -msym32 can not be used for 64-bit kernels which do not have
CKSEG load address, but apparently IP27 is using -msym32 with XKPHYS
load address.  Hmm...

---
Atsushi Nemoto

Re: RFC: Sentosa boot fix

[Franck Bui-Huu]

On 1/29/07, Atsushi Nemoto <anemo@mba.ocn.ne.jp> wrote:
>
> I thought -msym32 can not be used for 64-bit kernels which do not have
> CKSEG load address, but apparently IP27 is using -msym32 with XKPHYS
> load address.  Hmm...
>

It may be interesting to have a look to the assembly code in this case
to see what the compiler does exactly.

-- 
               Franck

Re: RFC: Sentosa boot fix

[Atsushi Nemoto]

On Mon, 29 Jan 2007 17:27:04 +0100, "Franck Bui-Huu" <vagabon.xyz@gmail.com> wrote:
> It may be interesting to have a look to the assembly code in this case
> to see what the compiler does exactly.

I compiled ip27 kernel and really confused...

head.S:
	PTR_LA		t0, __bss_start		# clear .bss
	LONG_S		zero, (t0)

System.map:
a8000000003b6000 A __bss_start

vmlinux:
a800000000385058:	3c0c003b 	lui	t0,0x3b
a80000000038505c:	658c6000 	daddiu	t0,t0,24576
a800000000385060:	fd800000 	sd	zero,0(t0)

vmlinux.32:
80385058:	3c0c003b 	lui	t4,0x3b
8038505c:	658c6000 	daddiu	t4,t4,24576
80385060:	fd800000 	sd	zero,0(t4)

How does this code work?  Isn't address 0x3b6000 in user space?

---
Atsushi Nemoto

Re: RFC: Sentosa boot fix

[Maciej W. Rozycki]

On Wed, 31 Jan 2007, Atsushi Nemoto wrote:

> I compiled ip27 kernel and really confused...
> 
> head.S:
> 	PTR_LA		t0, __bss_start		# clear .bss
> 	LONG_S		zero, (t0)
> 
> System.map:
> a8000000003b6000 A __bss_start
> 
> vmlinux:
> a800000000385058:	3c0c003b 	lui	t0,0x3b
> a80000000038505c:	658c6000 	daddiu	t0,t0,24576
> a800000000385060:	fd800000 	sd	zero,0(t0)
> 
> vmlinux.32:
> 80385058:	3c0c003b 	lui	t4,0x3b
> 8038505c:	658c6000 	daddiu	t4,t4,24576
> 80385060:	fd800000 	sd	zero,0(t4)
> 
> How does this code work?  Isn't address 0x3b6000 in user space?

 Well, the default config for this machine specifies -msym32 with the load 
address of 0xa80000000001c000.  No wonder it does not work.

 I suppose the setup for this platform should be more or less like this:

ifdef CONFIG_BUILD_ELF64
ifdef CONFIG_MAPPED_KERNEL
load-$(CONFIG_SGI_IP27)		+= 0xc00000004001c000
dataoffset-$(CONFIG_SGI_IP27)	+= 0x01000000
else
load-$(CONFIG_SGI_IP27)		+= 0xa80000000001c000
endif
else
ifdef CONFIG_MAPPED_KERNEL
load-$(CONFIG_SGI_IP27)		+= 0xffffffffc001c000
OBJCOPYFLAGS			:= --change-addresses=0xc000000080000000
dataoffset-$(CONFIG_SGI_IP27)	+= 0x01000000
else
load-$(CONFIG_SGI_IP27)		+= 0xffffffff8001c000
OBJCOPYFLAGS			:= --change-addresses=0xa800000080000000
endif
endif

 I can cook a patch if some SGI expert steps in and comments whether this 
makes sense from the platform point of view or not.

  Maciej

Re: RFC: Sentosa boot fix

[Thiemo Seufer]

Atsushi Nemoto wrote:
> On Mon, 29 Jan 2007 15:46:20 +0000 (GMT), "Maciej W. Rozycki" <macro@linux-mips.org> wrote:
> >  Well, the option used to select between 64-bit and 32-bit ELF for 
> > building 64-bit configurations.  I can see it has been changed from its 
> > original meaning and it now only controls whether "-mno-explicit-relocs" 
> > is passed to the compiler or not, which is sort of useless and certainly 
> > does not match the intent nor what the description says.  The 64-bit 
> > format is now used unconditionally and you can always pass such obscure 
> > options to the compiler on the make's command line, so instead of this fix 
> > I vote for complete removal of the BUILD_ELF64 option.
> 
> Though I do not know much about -mno-explicit-relocs,
> CONFIG_BUILD_ELF64 controls -msym32 option and this is the reason of
> the tweak in __pa_page_offset().
> 
> I thought -msym32 can not be used for 64-bit kernels which do not have
> CKSEG load address, but apparently IP27 is using -msym32 with XKPHYS
> load address.  Hmm...

IP27 kernels get objcopied to a CKSEG0 address.


Thiemo

Re: RFC: Sentosa boot fix

[Maciej W. Rozycki]

On Tue, 30 Jan 2007, Atsushi Nemoto wrote:

> >  Well, the option used to select between 64-bit and 32-bit ELF for 
> > building 64-bit configurations.  I can see it has been changed from its 
> > original meaning and it now only controls whether "-mno-explicit-relocs" 
> > is passed to the compiler or not, which is sort of useless and certainly 
> > does not match the intent nor what the description says.  The 64-bit 
> > format is now used unconditionally and you can always pass such obscure 
> > options to the compiler on the make's command line, so instead of this fix 
> > I vote for complete removal of the BUILD_ELF64 option.
> 
> Though I do not know much about -mno-explicit-relocs,
> CONFIG_BUILD_ELF64 controls -msym32 option and this is the reason of
> the tweak in __pa_page_offset().

 I missed this bit, sorry.  Then the original note applies -- the setting 
of BUILD_ELF64 is whatever suits one building the kernel the best.  And 
certainly for binaries built to run from CKSEG0 either value of 
BUILD_ELF64 is reasonable.

  Maciej

Re: RFC: Sentosa boot fix

[Thiemo Seufer]

Maciej W. Rozycki wrote:
> On Mon, 29 Jan 2007, Franck Bui-Huu wrote:
> 
> > > The problem is __pa_symbol(&_end); the kernel is linked at
> > > 0xffffffff80xxxxxx, so subtracting a PAGE_OFFSET of 0xa800000000000000
> > > does not do anything useful to this address at all.
> > >
> > 
> > In my understanding, if your kernel is linked at 0xffffffff80xxxxxx,
> > you shouldn't have CONFIG_BUILD_ELF64 set.
> 
>  Well, the option used to select between 64-bit and 32-bit ELF for 
> building 64-bit configurations.  I can see it has been changed from its 
> original meaning and it now only controls whether "-mno-explicit-relocs" 
> is passed to the compiler or not, which is sort of useless and certainly 
> does not match the intent nor what the description says.  The 64-bit 
> format is now used unconditionally and you can always pass such obscure 
> options to the compiler on the make's command line, so instead of this fix 
> I vote for complete removal of the BUILD_ELF64 option.

AFAIR at some point in gcc development the compiler expanded explicit
relocs to 32bit sequences unless -mno-xplicit-relocs was specified.


Thiemo

Re: RFC: Sentosa boot fix

[Daniel Jacobowitz]

On Mon, Jan 29, 2007 at 10:59:37AM +0100, Franck Bui-Huu wrote:
> Hi,
> 
> On 1/28/07, Daniel Jacobowitz <dan@debian.org> wrote:
> >The problem is __pa_symbol(&_end); the kernel is linked at
> >0xffffffff80xxxxxx, so subtracting a PAGE_OFFSET of 0xa800000000000000
> >does not do anything useful to this address at all.
> >
> 
> In my understanding, if your kernel is linked at 0xffffffff80xxxxxx,
> you shouldn't have CONFIG_BUILD_ELF64 set.

What Maciej said.  But also: please compare the description of
CONFIG_BUILD_ELF64 with the targets that link at that address.
Almost every supported target links at that address, except for
IP27.  How do any of them work today?

config BUILD_ELF64
        bool "Use 64-bit ELF format for building"
        depends on 64BIT
        help
          A 64-bit kernel is usually built using the 64-bit ELF binary object
          format as it's one that allows arbitrary 64-bit constructs.  For
          kernels that are loaded within the KSEG compatibility segments the
          32-bit ELF format can optionally be used resulting in a somewhat
          smaller binary, but this option is not explicitly supported by the
          toolchain and since binutils 2.14 it does not even work at all.

          Say Y to use the 64-bit format or N to use the 32-bit one.

          If unsure say Y.


% grep load- arch/mips/Makefile | grep ffffffff8 | wc
     55     165    2743

-- 
Daniel Jacobowitz
CodeSourcery

Re: RFC: Sentosa boot fix

[Franck Bui-Huu]

On 1/29/07, Daniel Jacobowitz <dan@debian.org> wrote:
> On Mon, Jan 29, 2007 at 10:59:37AM +0100, Franck Bui-Huu wrote:
> > In my understanding, if your kernel is linked at 0xffffffff80xxxxxx,
> > you shouldn't have CONFIG_BUILD_ELF64 set.
>
> What Maciej said.  But also: please compare the description of
> CONFIG_BUILD_ELF64 with the targets that link at that address.
> Almost every supported target links at that address, except for
> IP27.  How do any of them work today?
>

Surely because none of them define CONFIG_BUILD_ELF64:

        $ git grep BUILD_ELF arch/mips/configs
        arch/mips/configs/bigsur_defconfig:# CONFIG_BUILD_ELF64 is not set
        arch/mips/configs/ip27_defconfig:# CONFIG_BUILD_ELF64 is not set
        arch/mips/configs/ip32_defconfig:# CONFIG_BUILD_ELF64 is not set
        arch/mips/configs/ocelot_c_defconfig:# CONFIG_BUILD_ELF64 is not set
        arch/mips/configs/ocelot_g_defconfig:# CONFIG_BUILD_ELF64 is not set
        arch/mips/configs/sb1250-swarm_defconfig:# CONFIG_BUILD_ELF64 is not set

-- 
               Franck

Re: RFC: Sentosa boot fix

[Daniel Jacobowitz]

On Mon, Jan 29, 2007 at 05:06:39PM +0100, Franck Bui-Huu wrote:
> >What Maciej said.  But also: please compare the description of
> >CONFIG_BUILD_ELF64 with the targets that link at that address.
> >Almost every supported target links at that address, except for
> >IP27.  How do any of them work today?
> >
> 
> Surely because none of them define CONFIG_BUILD_ELF64:

Huh - you're right, it must just be living in my local .config since
back when it meant something different.

-- 
Daniel Jacobowitz
CodeSourcery

Re: RFC: Sentosa boot fix

[Maciej W. Rozycki]

Daniel,

> > Surely because none of them define CONFIG_BUILD_ELF64:
> 
> Huh - you're right, it must just be living in my local .config since
> back when it meant something different.

 It looks like the meaning is still the same (although the note about 
binutils versions supported needs be adjusted) and you are free to change 
what's provided by a default configuration to whatever you like.

 I have BUILD_ELF64 enabled for my SWARM configuration and I do not plan 
to change it.  If there is a bug in the definition of __pa_page_offset() 
for such a setup it should be fixed indeed.

 Also "-mno-explicit-relocs" was only required with the old hack to 
truncate addresses at the assembly level -- where "-mabi=64 -Wa,-mabi=32" 
was used.  The option should go now, yielding a small code size 
improvement for inline assembly, where the "R" constraint is used.

  Maciej

Re: RFC: Sentosa boot fix

[Atsushi Nemoto]

On Mon, 29 Jan 2007 18:47:12 +0000 (GMT), "Maciej W. Rozycki" <macro@linux-mips.org> wrote:
>  I have BUILD_ELF64 enabled for my SWARM configuration and I do not plan 
> to change it.  If there is a bug in the definition of __pa_page_offset() 
> for such a setup it should be fixed indeed.

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?

---
Atsushi Nemoto

Re: RFC: Sentosa boot fix

[Ralf Baechle]

On Tue, Jan 30, 2007 at 11:45:37PM +0900, Atsushi Nemoto wrote:

> On Mon, 29 Jan 2007 18:47:12 +0000 (GMT), "Maciej W. Rozycki" <macro@linux-mips.org> wrote:
> >  I have BUILD_ELF64 enabled for my SWARM configuration and I do not plan 
> > to change it.  If there is a bug in the definition of __pa_page_offset() 
> > for such a setup it should be fixed indeed.
> 
> 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?

Code in CKSEG0 allows shorter a shorter code sequence for address loads.
Yet some machines such as IP27 require 64-bit ELF for booting.

  Ralf

Re: RFC: Sentosa boot fix

[Maciej W. Rozycki]

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).

 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.  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).

  Maciej

Re: RFC: Sentosa boot fix

[Franck Bui-Huu]

On 1/30/07, Maciej W. Rozycki <macro@linux-mips.org> 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

Re: RFC: Sentosa boot fix

[Maciej W. Rozycki]

On Thu, 1 Feb 2007, Franck Bui-Huu wrote:

> > 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().

 Well, I am afraid it was known well before.  I introduced it first to 2.4 
a while ago and I forward-ported the patch immediately to 2.6.  Both 
changes went in on Oct 20th, 2004.  The help text for the option has not 
changed since.  And even 2.6.18 that I'm still using does not have this 
__pa_page_offset() macro!  I did build various kernel versions with 
BUILD_ELF64 set for the DECstation (which links at 0xffffffff80040000).

> 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.

 Wrong assumption.  And nowhere guaranteed either.

> However if BUILD_ELF64 is not set then the macro deals with both
> CKSEG0 and XKPHYS virtual addresses.

 Indeed.

> > 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.

 It hurts performance a little bit, so if you can assure the macro shall 
never be used on addresses from CKSEG0 if the load address is in XPHYS, 
then you can easily arrange for the load address to be passed to the 
preprocessor and use it as a condition here instead, which will be 
optimised away as required by the compiler.

> 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 ?

 I do not see enough of justification for -msym32 to be forced.  This will 
also raise the minimum version of binutils required to 2.16 for the 
affected platforms, which may be a little bit too aggressive.

> Please keep these conversions in the platform specific codes before
> calling back the firmware.

 The DECstation uses CPHYSADDR() for these purposes; see e.g.
arch/mips/dec/tc.c (not yet in the linux-mips.org repository -- to be 
merged from the -mm tree sometime after 2.6.20).  But I recall seeing 
suggestions for this macro to be removed.  Which I object against if there 
is no usable alternative available (and I refuse to implement generic 
functionality in platform-specific code -- there has been too much pain 
already to merge many such bits scattered around).

  Maciej

Re: RFC: Sentosa boot fix

[Atsushi Nemoto]

On Thu, 1 Feb 2007 13:20:15 +0000 (GMT), "Maciej W. Rozycki" <macro@linux-mips.org> wrote:
> > if CONFIG_64BITS and ${load-y} in CKSEG0
> >    cflags-y += -msym32
> > endif
> > 
> > what do you think ?
> 
>  I do not see enough of justification for -msym32 to be forced.  This will 
> also raise the minimum version of binutils required to 2.16 for the 
> affected platforms, which may be a little bit too aggressive.

Well, $(call cc-option,-msym32) can be used safely.  AFAIK -msym32 was
added to gcc 4.0 which was released on Apr 2005, and binutils 2.16 was
release on May 2005.  So if gcc accepted -msym32 we can assume
binutils accept too.

I think killing BUILD_ELF64 and adding -msym32 automatically are good
idea.  Also I do not think __pa_page_offset() is critical for
performance.

---
Atsushi Nemoto

Re: RFC: Sentosa boot fix

[Atsushi Nemoto]

On Thu, 01 Feb 2007 23:31:20 +0900 (JST), Atsushi Nemoto <anemo@mba.ocn.ne.jp> wrote:
> Well, $(call cc-option,-msym32) can be used safely.  AFAIK -msym32 was
> added to gcc 4.0 which was released on Apr 2005, and binutils 2.16 was
> release on May 2005.  So if gcc accepted -msym32 we can assume
> binutils accept too.

Oops, Apr 2005 was before May 2005 :)
Anyway I suppose gcc 4.x users are using modern binutils.

---
Atsushi Nemoto

Re: RFC: Sentosa boot fix

[Franck Bui-Huu]

Maciej W. Rozycki wrote:
> On Thu, 1 Feb 2007, Franck Bui-Huu wrote:
>
>>> 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().
>
>  Well, I am afraid it was known well before.  I introduced it first to 2.4

sorry I meant it wasn't for _me_.

>
>  It hurts performance a little bit, so if you can assure the macro shall

Well __pa() is only used in a few places. Futhermore it's used
only during boot mem init so it really shouldn't hurt.

>
>> 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 ?
>
>  I do not see enough of justification for -msym32 to be forced.
>

It gives good default behaviours without both user's intervention or
configuration:

	if CONFIG_64BITS
		ifndef sym32
			if load-y in XKPHYS
				sym32 = ''		[1]
			elif load-y in CKSEG0
				sym32 = '-msym32'	[2]
		else
			if sym32 eq 'yes'
				sym32 = '-msym32'	[3]
		endef
	fi
	cflags-y += $(sym32)

[1] since there is no reason to add '-msym32' and it would generate
    wrong code anyways.
[2] since it's used by all platforms to generate smaller code.
    Warn if this option is not supported by the tool chains.
[3] if you really want to generate code loaded in CKSEG0 without
    -msym32 switch you could always do:

		$ make sym32=no

    IMHO, for normal users, this case is probably a configuration
    bug and that's the reason we should request for a user to ask for
    it explicitly.

-- 
               Franck

Re: RFC: Sentosa boot fix

[Maciej W. Rozycki]

On Thu, 1 Feb 2007, Franck Bui-Huu wrote:

> It gives good default behaviours without both user's intervention or
> configuration:
> 
> 	if CONFIG_64BITS
> 		ifndef sym32
> 			if load-y in XKPHYS
> 				sym32 = ''		[1]
> 			elif load-y in CKSEG0
> 				sym32 = '-msym32'	[2]
> 		else
> 			if sym32 eq 'yes'
> 				sym32 = '-msym32'	[3]
> 		endef
> 	fi
> 	cflags-y += $(sym32)
> 
> [1] since there is no reason to add '-msym32' and it would generate
>    wrong code anyways.
> [2] since it's used by all platforms to generate smaller code.
>    Warn if this option is not supported by the tool chains.
> [3] if you really want to generate code loaded in CKSEG0 without
>    -msym32 switch you could always do:
> 
> 		$ make sym32=no

 Well, it seems fair enough indeed, as long as the availability of 
"-msym32" is verified as suggested by Atsushi-san.

>    IMHO, for normal users, this case is probably a configuration
>    bug and that's the reason we should request for a user to ask for
>    it explicitly.

 Hmm, that just raises the question for a definition of who a "normal 
user" is.  And in general -- what "normality" is and why exactly that and 
not something else. ;-)

  Maciej

Re: RFC: Sentosa boot fix

[Franck Bui-Huu]

On 2/8/07, Maciej W. Rozycki <macro@linux-mips.org> wrote:
>  Hmm, that just raises the question for a definition of who a "normal
> user" is.

With the definition I gave, you don't seem to be a 'normal' user ;)

-- 
               Franck