CONFIG_BUILD_ELF64 broken on IP32 since 2.6.20

CONFIG_BUILD_ELF64 broken on IP32 since 2.6.20

[Martin Michlmayr]

IP32 kernels that are built with CONFIG_BUILD_ELF64=y only produce an
exception when booted.  This worked with 2.6.19 and before.  I haven't
had a chance to dig deep yet but it seems both Franck Bui-Huu and
Atsushi Nemoto had patches in 2.6.20 that might have caused this.
This still happens with 2.6.22.  I cannot boot current git for other
reasons.

If anyone has an idea which specific patch might have caused this,
please let me know.  Otherwise I'll try to find time in the next few
days to revert various patches.
-- 
Martin Michlmayr
http://www.cyrius.com/

Re: CONFIG_BUILD_ELF64 broken on IP32 since 2.6.20

[sknauert]

> IP32 kernels that are built with CONFIG_BUILD_ELF64=y only produce an
> exception when booted.  This worked with 2.6.19 and before.  I haven't
> had a chance to dig deep yet but it seems both Franck Bui-Huu and
> Atsushi Nemoto had patches in 2.6.20 that might have caused this.
> This still happens with 2.6.22.  I cannot boot current git for other
> reasons.
>
> If anyone has an idea which specific patch might have caused this,
> please let me know.  Otherwise I'll try to find time in the next few
> days to revert various patches.
> --
> Martin Michlmayr
> http://www.cyrius.com/
>

Nice to know someone's still working on Linux on the O2. I can confirm
that its been broken, and I had believed I was even told why by Kumba
http://www.nabble.com/Re:-Cross-Compile-difficulties-p10769217.html:

> One, make sure you're doing "make vmlinux.32", and two, CONFIG_BUILD_ELF64
> is
> _not_ enabled. For 2.6.20, I had to cram in a patch from Frank to get
> these
> things to not PROM crash (due to the elimination of CPHYSADDY and
> replacement by
> __pa()), but on 2.6.21, this patch was unnecessary.  Unsure about
> 2.6.22-rcX.

Anyway... sad to say this is a little beyond my understanding, but maybe
it can help you start hacking. For what its worth, I'll gladly test
patches on my O2s as I have an R5K 200 and RM7K 600.

Re: CONFIG_BUILD_ELF64 broken on IP32 since 2.6.20

[Martin Michlmayr]

* sknauert@wesleyan.edu <sknauert@wesleyan.edu> [2007-09-25 11:32]:
> > One, make sure you're doing "make vmlinux.32", and two, CONFIG_BUILD_ELF64

I should say that I'm indeed using "make vmlinux.32".  Anyway, I see
no reason why this would break, especially given that it used to work.
And if it really isn't supported anymore, make it impossible to chose
CONFIG_BUILD_ELF64 on IP32.
-- 
Martin Michlmayr
http://www.cyrius.com/

Re: CONFIG_BUILD_ELF64 broken on IP32 since 2.6.20

[sknauert]

> * sknauert@wesleyan.edu <sknauert@wesleyan.edu> [2007-09-25 11:32]:
>> > One, make sure you're doing "make vmlinux.32", and two,
>> CONFIG_BUILD_ELF64
>
> I should say that I'm indeed using "make vmlinux.32".  Anyway, I see
> no reason why this would break, especially given that it used to work.
> And if it really isn't supported anymore, make it impossible to chose
> CONFIG_BUILD_ELF64 on IP32.
> --
> Martin Michlmayr
> http://www.cyrius.com/
>
>
Sorry, you're misinterpreting what I said. The indented text was the
advice given to me by Kumba (I highlighted the part of the linked thread)
of why a 64-bit kernel won't work. Or at least I think that's what he was
saying. Since you asked when 64-bit on IP32 was killed, and what patches
did it, I thought this information might help.

Re: CONFIG_BUILD_ELF64 broken on IP32 since 2.6.20

[Franck Bui-Huu]

Martin Michlmayr wrote:
> IP32 kernels that are built with CONFIG_BUILD_ELF64=y only produce an
> exception when booted.  This worked with 2.6.19 and before.  I haven't
> had a chance to dig deep yet but it seems both Franck Bui-Huu and
> Atsushi Nemoto had patches in 2.6.20 that might have caused this.

I'm the culprit ;) but...

> This still happens with 2.6.22.  I cannot boot current git for other
> reasons.
> 
> If anyone has an idea which specific patch might have caused this,
> please let me know.  Otherwise I'll try to find time in the next few
> days to revert various patches.

It's sad to see this issue is still not fixed. Some people complained
about IPxx kernels broken by CONFIG_BUILD_ELF64 config but disappear
once they reported the problem. Anyways, hopefully this time we could
do a better job...

OK, it seems that Ralf's commit
db423f6e86c3c4c70edf3eaf504e22c467b9f97c fixes your issue. But
actually I think it just hides another problem. Because with
CONFIG_BUILD_ELF64=y you claim to run a kernel with 64 bit
symbols. However if the previous commit fixes your issue then it shows
that your kernel handles a symbol linked in CKSEG0 although
CONFIG_BUILD_ELF64 is set.

To verify this, could you apply the following patch _without_ Ralf's
commit and report back the trace. You may need to enable early printk
to see something and be sure CONFIG_KALLSYMS_ALL is set.

thanks,
		Franck

-- 8< --

diff --git a/include/asm-mips/page.h b/include/asm-mips/page.h
index b92dd8c..a469cf1 100644
--- a/include/asm-mips/page.h
+++ b/include/asm-mips/page.h
@@ -149,8 +149,17 @@ typedef struct { unsigned long pgprot; } pgprot_t;
     __x < CKSEG0 ? XPHYSADDR(__x) : CPHYSADDR(__x);			\
 })
 #else
-#define __pa(x)								\
-    ((unsigned long)(x) - PAGE_OFFSET + PHYS_OFFSET)
+static inline unsigned long __pa(void *p)
+{
+	unsigned long x = (unsigned long)p;
+
+	if (x > CKSEG0 - 1) {
+		__print_symbol("*** __pa: symbol in CKSEG0 found: %s\n", x);
+		BUG();
+	}
+
+	return x - PAGE_OFFSET + PHYS_OFFSET;
+}
 #endif
 #define __va(x)		((void *)((unsigned long)(x) + PAGE_OFFSET - PHYS_OFFSET))
 #define __pa_symbol(x)	__pa(RELOC_HIDE((unsigned long)(x),0))

Re: CONFIG_BUILD_ELF64 broken on IP32 since 2.6.20

[Martin Michlmayr]

* Franck Bui-Huu <vagabon.xyz@gmail.com> [2007-09-26 10:03]:
> To verify this, could you apply the following patch _without_ Ralf's
> commit and report back the trace. You may need to enable early printk
> to see something and be sure CONFIG_KALLSYMS_ALL is set.

5152902+253674 entry: 0x804ac000
Linux version 2.6.22-2-r5k-ip32 (2.6.22-5) (tbm@em64t) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #3 Wed Sep 26 09:10:31 UTC 2007
ARCH: SGI-IP32
PROMLIB: ARC firmware Version 1 Revision 10
CRIME id a rev 1 at 0x0000000014000000
CRIME MC: bank 0 base 0x0000000000000000 size 128MiB
CRIME MC: bank 1 base 0x0000000008000000 size 128MiB
CRIME MC: bank 2 base 0x0000000050000000 size 32MiB
CRIME MC: bank 3 base 0x0000000052000000 size 32MiB
CPU revision is: 00002321
FPU revision is: 00002310
Determined physical RAM map:
 memory: 0000000010000000 @ 0000000000000000 (usable)
 memory: 0000000004000000 @ 0000000050000000 (usable)
*** __pa: symbol in CKSEG0 found: wireless_nlevent_queue+0x20/0x20

Exception: <vector=Normal>
Status register: 0x34010082<CU1,CU0,FR,DE,IPL=8,KX,MODE=KERNEL>
Cause register: 0x8024<CE=0,IP8,EXC=BREAK>
Exception PC: 0x804bbc2c, Exception RA: 0x804bbc2c
Breakpoint exception at address 0xbffffff7
  Saved user regs in hex (&gpda 0x810617b8, &_regs 0x810619b8):
  arg: 81070000 2f1 0 1
  tmp: 81070000 8052bf70 a13fb518 81077d40 8052bf70 a13fba0c 810723b0 81054090
  sve: 81070000 4015fa0c 0 4618fbd8 0 4047cfc7 0 3ebf5e51
  t8 81070000 t9 0 at 0 v0 402003f7 v1 0 k1 46
  gp 81070000 fp 0 sp 0 ra 0

PANIC: Unexpected exception

-- 
Martin Michlmayr
http://www.cyrius.com/

Re: CONFIG_BUILD_ELF64 broken on IP32 since 2.6.20

[Franck Bui-Huu]

Martin Michlmayr wrote:
> * Franck Bui-Huu <vagabon.xyz@gmail.com> [2007-09-26 10:03]:
>> To verify this, could you apply the following patch _without_ Ralf's
>> commit and report back the trace. You may need to enable early printk
>> to see something and be sure CONFIG_KALLSYMS_ALL is set.
> 
> 5152902+253674 entry: 0x804ac000
> Linux version 2.6.22-2-r5k-ip32 (2.6.22-5) (tbm@em64t) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #3 Wed Sep 26 09:10:31 UTC 2007
> ARCH: SGI-IP32
> PROMLIB: ARC firmware Version 1 Revision 10
> CRIME id a rev 1 at 0x0000000014000000
> CRIME MC: bank 0 base 0x0000000000000000 size 128MiB
> CRIME MC: bank 1 base 0x0000000008000000 size 128MiB
> CRIME MC: bank 2 base 0x0000000050000000 size 32MiB
> CRIME MC: bank 3 base 0x0000000052000000 size 32MiB
> CPU revision is: 00002321
> FPU revision is: 00002310
> Determined physical RAM map:
>  memory: 0000000010000000 @ 0000000000000000 (usable)
>  memory: 0000000004000000 @ 0000000050000000 (usable)
> *** __pa: symbol in CKSEG0 found: wireless_nlevent_queue+0x20/0x20
> 

hmm it doesn't really help here. Could you print out the address value
instead ?

> Exception: <vector=Normal>
> Status register: 0x34010082<CU1,CU0,FR,DE,IPL=8,KX,MODE=KERNEL>
> Cause register: 0x8024<CE=0,IP8,EXC=BREAK>
> Exception PC: 0x804bbc2c, Exception RA: 0x804bbc2c
> Breakpoint exception at address 0xbffffff7
>   Saved user regs in hex (&gpda 0x810617b8, &_regs 0x810619b8):
>   arg: 81070000 2f1 0 1
>   tmp: 81070000 8052bf70 a13fb518 81077d40 8052bf70 a13fba0c 810723b0 81054090
>   sve: 81070000 4015fa0c 0 4618fbd8 0 4047cfc7 0 3ebf5e51
>   t8 81070000 t9 0 at 0 v0 402003f7 v1 0 k1 46
>   gp 81070000 fp 0 sp 0 ra 0
> 

Weird, all these symbols seem to be 32 bits ones...

Could you put somewhere your vmlinux you're actually running ?

thanks,

		Franck

Re: CONFIG_BUILD_ELF64 broken on IP32 since 2.6.20

[Martin Michlmayr]

* Franck Bui-Huu <vagabon.xyz@gmail.com> [2007-09-26 11:54]:
> >  memory: 0000000004000000 @ 0000000050000000 (usable)
> > *** __pa: symbol in CKSEG0 found: wireless_nlevent_queue+0x20/0x20
> > 
> 
> hmm it doesn't really help here. Could you print out the address value
> instead ?

*** __pa: symbol in CKSEG0 found: wireless_nlevent_queue+0x20/0x20
ffffffff8052bf70

> Weird, all these symbols seem to be 32 bits ones...
> 
> Could you put somewhere your vmlinux you're actually running ?

http://merkel.debian.org/~tbm/tmp/vmlinux.32
Note that I'm using "make vmlinux.32"
-- 
Martin Michlmayr
http://www.cyrius.com/

Re: CONFIG_BUILD_ELF64 broken on IP32 since 2.6.20

[Maciej W. Rozycki]

On Wed, 26 Sep 2007, Martin Michlmayr wrote:

> > Weird, all these symbols seem to be 32 bits ones...
> > 
> > Could you put somewhere your vmlinux you're actually running ?
> 
> http://merkel.debian.org/~tbm/tmp/vmlinux.32
> Note that I'm using "make vmlinux.32"

 It should not matter here -- the build is done using the ELF32 or ELF64 
file format according to CONFIG_BUILD_ELF64 and if you request a target 
like "vmlinux.32" or "vmlinux.64" the resulting "vmlinux" binary is 
converted to ELF32 or ELF64 respectively with `objcopy' (which is 
equivalent to `cp', barring oddities of `objcopy', if "vmlinux" is already 
of the "right" type).

  Maciej

Re: CONFIG_BUILD_ELF64 broken on IP32 since 2.6.20

[Franck Bui-Huu]

Maciej W. Rozycki wrote:
> On Wed, 26 Sep 2007, Martin Michlmayr wrote:
> 
>>> Weird, all these symbols seem to be 32 bits ones...
>>>
>>> Could you put somewhere your vmlinux you're actually running ?
>> http://merkel.debian.org/~tbm/tmp/vmlinux.32
>> Note that I'm using "make vmlinux.32"
> 
>  It should not matter here -- the build is done using the ELF32 or ELF64 
> file format according to CONFIG_BUILD_ELF64 and if you request a target 

Except that if CONFIG_BUILD_ELF64 is set then we assume that the kernel
is linked in XKPHYS which results in Martin's crash since his kernel is
linked in CKSEG0.

If you can recall that was done for a micro-optimization in __pa() but it
was a huge mistake because it relies on the configuration of BUILD_ELF64
to be setup correctly by the user... So in this case there's no point to
set CONFIG_BUILD_ELF64='y' since it makes the kernel bigger and slower.
But it used to work until my change, so my own fault.

Now it's going to be fixed in v2.6.23 by Ralf's commit.

Martin, can you live with CONFIG_BUILD_ELF64='n' for now ?

		Franck

Re: CONFIG_BUILD_ELF64 broken on IP32 since 2.6.20

[Martin Michlmayr]

* Franck Bui-Huu <vagabon.xyz@gmail.com> [2007-09-26 15:34]:
> Martin, can you live with CONFIG_BUILD_ELF64='n' for now ?

Yeah.
-- 
Martin Michlmayr
http://www.cyrius.com/

Re: CONFIG_BUILD_ELF64 broken on IP32 since 2.6.20

[Maciej W. Rozycki]

On Wed, 26 Sep 2007, Franck Bui-Huu wrote:

> Except that if CONFIG_BUILD_ELF64 is set then we assume that the kernel
> is linked in XKPHYS which results in Martin's crash since his kernel is
> linked in CKSEG0.
> 
> If you can recall that was done for a micro-optimization in __pa() but it
> was a huge mistake because it relies on the configuration of BUILD_ELF64
> to be setup correctly by the user... So in this case there's no point to
> set CONFIG_BUILD_ELF64='y' since it makes the kernel bigger and slower.
> But it used to work until my change, so my own fault.

 While, as expressed previously, the assumption of CONFIG_BUILD_ELF64 
meaning XKPHYS mapping is questionable, a requirement for the user to 
somehow magically know that the two became related somehow is 
unreasonable.  Especially as in many cases people just copy an old .config 
over to a new version of the kernel and run `make oldconfig'; I have 
certainly not done anything else for years.

 Given the dependency is quite straightforward it could have been sorted 
out with a reverse dependency in Kconfig based on the load addresses 
specified in Makefile -- boring, but easily done.  That assuming the 
failure of -msym32 resulting from the use of an older unsupported 
toolchain would be reported as fatal to the user, together with 
information of which versions are the minimum.

 Of course requiring a different version of the toolchain based on whether 
XKPHYS or KSEG0 mapping is used (i.e. newer for the latter!) is 
questionable too, but that is a different matter.

  Maciej

Re: CONFIG_BUILD_ELF64 broken on IP32 since 2.6.20

[Atsushi Nemoto]

On Wed, 26 Sep 2007 15:49:41 +0100 (BST), "Maciej W. Rozycki" <macro@linux-mips.org> wrote:
>  Given the dependency is quite straightforward it could have been sorted 
> out with a reverse dependency in Kconfig based on the load addresses 
> specified in Makefile -- boring, but easily done.  That assuming the 
> failure of -msym32 resulting from the use of an older unsupported 
> toolchain would be reported as fatal to the user, together with 
> information of which versions are the minimum.

Current linux-queue code adds -msym32 if the load address was CKSEG0,
so it can not be compiled with gcc 3.x.  I think this patch fixes the
problem:

http://www.linux-mips.org/archives/linux-mips/2007-03/msg00404.html

---
Atsushi Nemoto

Re: CONFIG_BUILD_ELF64 broken on IP32 since 2.6.20

[Maciej W. Rozycki]

On Thu, 27 Sep 2007, Atsushi Nemoto wrote:

> Current linux-queue code adds -msym32 if the load address was CKSEG0,
> so it can not be compiled with gcc 3.x.  I think this patch fixes the
> problem:
> 
> http://www.linux-mips.org/archives/linux-mips/2007-03/msg00404.html

 It looks like it should -- why hasn't it been pushed?

 Everybody please note that officially GCC 3.2 is the oldest version of 
the compiler supported and based on recent activity we do care about it.

  Maciej

Re: CONFIG_BUILD_ELF64 broken on IP32 since 2.6.20

[Franck Bui-Huu]

Maciej W. Rozycki wrote:
> On Thu, 27 Sep 2007, Atsushi Nemoto wrote:
> 
>> Current linux-queue code adds -msym32 if the load address was CKSEG0,
>> so it can not be compiled with gcc 3.x.  I think this patch fixes the
>> problem:
>>
>> http://www.linux-mips.org/archives/linux-mips/2007-03/msg00404.html
> 
>  It looks like it should -- why hasn't it been pushed?
> 

I don't remember. I thought the last patchset had the fix.

Just to be sure I understand both of you correctly, could
you confirm that in case of '-msym32' switch isn't supported,
we should _silently_ drop this option ? That's what Atsushi
was suggesting. But reading what Maciej wrote, it seems that
we should notify the user...

		Franck

Re: CONFIG_BUILD_ELF64 broken on IP32 since 2.6.20

[Maciej W. Rozycki]

On Thu, 27 Sep 2007, Franck Bui-Huu wrote:

> Just to be sure I understand both of you correctly, could
> you confirm that in case of '-msym32' switch isn't supported,
> we should _silently_ drop this option ? That's what Atsushi
> was suggesting. But reading what Maciej wrote, it seems that
> we should notify the user...

 Wrong assumption.  I have thought the "-msym32" option was wired straight 
to CONFIG_BUILD_ELF64, which would be reasonable given what the 
configuration option is meant to be doing.  From the code generation's 
point of view the "-msym32" option can be safely dropped silently, but 
that questions the CONFIG_BUILD_ELF64 option itself and I think we have 
agreed, not necessarily enthusiastically, but still, that 
CONFIG_BUILD_ELF64 will be dropped altogether.

  Maciej

Re: CONFIG_BUILD_ELF64 broken on IP32 since 2.6.20

[Ralf Baechle]

On Thu, Sep 27, 2007 at 10:11:49AM +0200, Franck Bui-Huu wrote:
> From: Franck Bui-Huu <vagabon.xyz@gmail.com>
> Date: Thu, 27 Sep 2007 10:11:49 +0200
> To: "Maciej W. Rozycki" <macro@linux-mips.org>
> CC: Atsushi Nemoto <anemo@mba.ocn.ne.jp>, tbm@cyrius.com,
> 	linux-mips@linux-mips.org
> Subject: Re: CONFIG_BUILD_ELF64 broken on IP32 since 2.6.20
> Content-Type: text/plain; charset=ISO-8859-1
> 
> Maciej W. Rozycki wrote:
> > On Thu, 27 Sep 2007, Atsushi Nemoto wrote:
> > 
> >> Current linux-queue code adds -msym32 if the load address was CKSEG0,
> >> so it can not be compiled with gcc 3.x.  I think this patch fixes the
> >> problem:
> >>
> >> http://www.linux-mips.org/archives/linux-mips/2007-03/msg00404.html
> > 
> >  It looks like it should -- why hasn't it been pushed?
> > 
> 
> I don't remember. I thought the last patchset had the fix.
> 
> Just to be sure I understand both of you correctly, could
> you confirm that in case of '-msym32' switch isn't supported,
> we should _silently_ drop this option ? That's what Atsushi
> was suggesting. But reading what Maciej wrote, it seems that
> we should notify the user...

-msym32 and previously the strategy to tell the compiler to generate 64-bit
code but the assembler to put it into 32-bit ELF was initially a hack
to get around the lack of proper 64-bit binutils support and later 
turned into a neat optimization with significant code size savings.  But
it's really just an optimization so there is nothing wrong with just
dropping the option (and whatever else goes along with it, I forgot all
the nasty details) on the floor if due to a vintage compiler it can't be
suported.

  Ralf

Re: CONFIG_BUILD_ELF64 broken on IP32 since 2.6.20

[Franck Bui-Huu]

Ralf Baechle wrote:
> -msym32 and previously the strategy to tell the compiler to generate 64-bit
> code but the assembler to put it into 32-bit ELF was initially a hack
> to get around the lack of proper 64-bit binutils support and later 
> turned into a neat optimization with significant code size savings.  But
> it's really just an optimization so there is nothing wrong with just
> dropping the option (and whatever else goes along with it, I forgot all
> the nasty details) on the floor if due to a vintage compiler it can't be
> suported.
> 

ok, I'll send a patch to reflect that.

		Franck

Building 64 bit kernel on Cobalt

[Jim Gifford]

Last working Kernel was 2.6.19 series.

Some changes from 2.6.19 and the 2.6.20 make it impossible to build a 64 
bit kernel to boot on the cobalt. Ya, I know why, building a N32 
actually but need a 64 bit kernel in order to do that. Anyone got any 
suggestions. Looking through the difference between the kernels to 
figure this out, but it's like looking for a needle in a haystack. Any 
suggestions as to a starting point?

Re: Building 64 bit kernel on Cobalt

[Ralf Baechle]

On Sun, Mar 04, 2007 at 03:18:45PM -0800, Jim Gifford wrote:

> Last working Kernel was 2.6.19 series.
> 
> Some changes from 2.6.19 and the 2.6.20 make it impossible to build a 64 
> bit kernel to boot on the cobalt. Ya, I know why, building a N32 
> actually but need a 64 bit kernel in order to do that. Anyone got any 
> suggestions. Looking through the difference between the kernels to 
> figure this out, but it's like looking for a needle in a haystack. Any 
> suggestions as to a starting point?

Try git-bisect to track down the changeset that broke things.

  Ralf

Re: Building 64 bit kernel on Cobalt

[Jim Gifford]

Ralf Baechle wrote:
> On Sun, Mar 04, 2007 at 03:18:45PM -0800, Jim Gifford wrote:
>
>   
>> Last working Kernel was 2.6.19 series.
>>
>> Some changes from 2.6.19 and the 2.6.20 make it impossible to build a 64 
>> bit kernel to boot on the cobalt. Ya, I know why, building a N32 
>> actually but need a 64 bit kernel in order to do that. Anyone got any 
>> suggestions. Looking through the difference between the kernels to 
>> figure this out, but it's like looking for a needle in a haystack. Any 
>> suggestions as to a starting point?
>>     
>
> Try git-bisect to track down the changeset that broke things.
>
>   Ralf
>
>   
We got it nailed down to arch/mips/kernel /setup.c. But we have not 
isolated which change is actually causing it.

We do know that reverting back to the 2.6.19.x arch/mips/kernel /setup.c 
will fix the issue. We will continue to dwindle it down until we come up 
with the offender.

Re: Building 64 bit kernel on Cobalt

[Jim Gifford]

[-- Attachment #1: Type: text/plain, Size: 2619 bytes --]

Here's what we isolated it to.

The problem looks like this

inflate: decompressing
elf64: 00080000 - 0037701f (ffffffff.80326000) (ffffffff.80000000)
elf64: ffffffff.80080000 (80080000) 2957446t + 151450t
net: interface down

If we apply the patch that's attached we can boot all the way up, but we 
do get some errors. I'm hoping one of these errors might shed the light 
on what the actual issue is.

VFS: Mounted root (nfs filesystem) readonly.
Unhandled kernel unaligned access[#1]:
Cpu 0
$ 0   : 0000000000000000 ffffffff802adc60 0000000000000000 0000000000000000
$ 4   : ffffffff80089eec ffffffffde020000 ffffffff8008c588 0000000000000000
$ 8   : 0000000000561024 996bffffff40b050 0000000000000000 000000000000f6f8
$12   : ffffffff94004ce0 000000001000001e 0000000000000000 ffffffff80300000
$16   : 9800000000387df0 ffffffff80326000 0000000000000000 00067ffffff80326
$20   : 00067ffffff80326 000000000000002d fffffffffffffbff 67ffffff80353000
$24   : 0000000000000010 ffffffff801768d8
$28   : 9800000000384000 9800000000387dc0 67ffffff80326000 ffffffff80081e28
Hi    : 0000000000000000
Lo    : 0000000000000000
epc   : ffffffff80089f04 do_ade+0x3a4/0x4c0     Not tainted
ra    : ffffffff80081e28 ret_from_exception+0x0/0x1c
Status: 94004ce2    KX SX UX KERNEL EXL
Cause : 00808010
BadVA : 996bffffff40b057
PrId  : 000028a0
Process swapper (pid: 1, threadinfo=9800000000384000, task=9800000000381828)
Stack : 996bffffff40b050 ffffffff80326000 016bfffffe40b050 00067ffffff80326
        ffffffff80081e28 0000000000000000 0000000000000000 ffffffff94004ce0
        9800000001000000 019ffffffe00c980 ffffffff94004ce1 00067ffffff80353
        6800000000000000 9800000000381828 98000000013e9a40 98000000003b3000
        ffffffff80309758 000000000000f6f8 0000000000000001 ffffffff801b9388
        0000000000000000 ffffffff80300000 996bffffff40b050 ffffffff80326000
        016bfffffe40b050 00067ffffff80326 00067ffffff80326 000000000000002d
        fffffffffffffbff 67ffffff80353000 0000000000000010 ffffffff801768d8
        ffffffff800fb5ac ffffffff800fb5ac 9800000000384000 9800000000387f20
        67ffffff80326000 ffffffff8008c4d0 ffffffff94004ce2 0000000000000000
        ...
Call Trace:
[<ffffffff80089f04>] do_ade+0x3a4/0x4c0
[<ffffffff80081e28>] ret_from_exception+0x0/0x1c
[<ffffffff8008c588>] free_initmem+0xe8/0x218
[<ffffffff80080688>] init+0x248/0x510
[<ffffffff80084420>] kernel_thread_helper+0x10/0x18


Code: 00431024  5440ff77  de020100 <69230007> 6d230000  24020000  
1440ffba  00051402  08022760
Kernel panic - not syncing: Attempted to kill init!

patch - at http://ftp.jg555.com/revert.working.diff


[-- Attachment #2: revert.working.diff --]
[-- Type: text/x-patch, Size: 4639 bytes --]

--- linux-2.6.19.2/arch/mips/kernel/setup.c	2007-01-10 11:10:37.000000000 -0800
+++ linux-2.6.20.1/arch/mips/kernel/setup.c	2007-03-07 20:59:28.000000000 -0800
@@ -145,13 +145,12 @@
 	unsigned long start = memparse(p, &p);
 
 #ifdef CONFIG_64BIT
-	/* HACK: Guess if the sign extension was forgotten */
-	if (start > 0x0000000080000000 && start < 0x00000000ffffffff)
-		start |= 0xffffffff00000000UL;
+	/* Guess if the sign extension was forgotten by bootloader */
+	if (start < XKPHYS)
+		start = (int)start;
 #endif
 	initrd_start = start;
 	initrd_end += start;
-
 	return 0;
 }
 early_param("rd_start", rd_start_early);
@@ -159,41 +158,64 @@
 static int __init rd_size_early(char *p)
 {
 	initrd_end += memparse(p, &p);
-
 	return 0;
 }
 early_param("rd_size", rd_size_early);
 
+/* it returns the next free pfn after initrd */
 static unsigned long __init init_initrd(void)
 {
-	unsigned long tmp, end, size;
+	unsigned long end;
 	u32 *initrd_header;
 
-	ROOT_DEV = Root_RAM0;
-
 	/*
 	 * Board specific code or command line parser should have
 	 * already set up initrd_start and initrd_end. In these cases
 	 * perfom sanity checks and use them if all looks good.
 	 */
-	size = initrd_end - initrd_start;
-	if (initrd_end == 0 || size == 0) {
-		initrd_start = 0;
-		initrd_end = 0;
-	} else
-		return initrd_end;
-
-	end = (unsigned long)&_end;
-	tmp = PAGE_ALIGN(end) - sizeof(u32) * 2;
-	if (tmp < end)
-		tmp += PAGE_SIZE;
-
-	initrd_header = (u32 *)tmp;
-	if (initrd_header[0] == 0x494E5244) {
-		initrd_start = (unsigned long)&initrd_header[2];
-		initrd_end = initrd_start + initrd_header[1];
+	if (initrd_start && initrd_end > initrd_start)
+		goto sanitize;
+
+	/*
+	 * See if initrd has been added to the kernel image by
+	 * arch/mips/boot/addinitrd.c. In that case a header is
+	 * prepended to initrd and is made up by 8 bytes. The fisrt
+	 * word is a magic number and the second one is the size of
+	 * initrd.  Initrd start must be page aligned in any cases.
+	 */
+	initrd_header = __va(PAGE_ALIGN(__pa_symbol(&_end) + 8)) - 8;
+	if (initrd_header[0] != 0x494E5244)
+		goto disable;
+	initrd_start = (unsigned long)(initrd_header + 2);
+	initrd_end = initrd_start + initrd_header[1];
+
+sanitize:
+	if (initrd_start & ~PAGE_MASK) {
+		printk(KERN_ERR "initrd start must be page aligned\n");
+		goto disable;
 	}
-	return initrd_end;
+	if (initrd_start < PAGE_OFFSET) {
+		printk(KERN_ERR "initrd start < PAGE_OFFSET\n");
+		goto disable;
+	}
+
+	/*
+	 * Sanitize initrd addresses. For example firmware
+	 * can't guess if they need to pass them through
+	 * 64-bits values if the kernel has been built in pure
+	 * 32-bit. We need also to switch from KSEG0 to XKPHYS
+	 * addresses now, so the code can now safely use __pa().
+	 */
+	end = __pa(initrd_end);
+	initrd_end = (unsigned long)__va(end);
+	initrd_start = (unsigned long)__va(__pa(initrd_start));
+
+	ROOT_DEV = Root_RAM0;
+	return PFN_UP(end);
+disable:
+	initrd_start = 0;
+	initrd_end = 0;
+	return 0;
 }
 
 static void __init finalize_initrd(void)
@@ -204,12 +226,12 @@
 		printk(KERN_INFO "Initrd not found or empty");
 		goto disable;
 	}
-	if (CPHYSADDR(initrd_end) > PFN_PHYS(max_low_pfn)) {
+	if (__pa(initrd_end) > PFN_PHYS(max_low_pfn)) {
 		printk("Initrd extends beyond end of memory");
 		goto disable;
 	}
 
-	reserve_bootmem(CPHYSADDR(initrd_start), size);
+	reserve_bootmem(__pa(initrd_start), size);
 	initrd_below_start_ok = 1;
 
 	printk(KERN_INFO "Initial ramdisk at: 0x%lx (%lu bytes)\n",
@@ -259,8 +281,7 @@
 	 * not selected. Once that done we can determine the low bound
 	 * of usable memory.
 	 */
-	reserved_end = init_initrd();
-	reserved_end = PFN_UP(CPHYSADDR(max(reserved_end, (unsigned long)&_end)));
+	reserved_end = max(init_initrd(), PFN_UP(__pa_symbol(&_end)));
 
 	/*
 	 * Find the highest page frame number we have available.
@@ -432,10 +453,10 @@
 	if (UNCAC_BASE != IO_BASE)
 		return;
 
-	code_resource.start = virt_to_phys(&_text);
-	code_resource.end = virt_to_phys(&_etext) - 1;
-	data_resource.start = virt_to_phys(&_etext);
-	data_resource.end = virt_to_phys(&_edata) - 1;
+	code_resource.start = __pa_symbol(&_text);
+	code_resource.end = __pa_symbol(&_etext) - 1;
+	data_resource.start = __pa_symbol(&_etext);
+	data_resource.end = __pa_symbol(&_edata) - 1;
 
 	/*
 	 * Request address space for all standard RAM.
@@ -500,7 +521,7 @@
 #endif
 }
 
-int __init fpu_disable(char *s)
+static int __init fpu_disable(char *s)
 {
 	int i;
 
@@ -512,7 +533,7 @@
 
 __setup("nofpu", fpu_disable);
 
-int __init dsp_disable(char *s)
+static int __init dsp_disable(char *s)
 {
 	cpu_data[0].ases &= ~MIPS_ASE_DSP;
 

Re: Building 64 bit kernel on Cobalt

[Franck Bui-Huu]

Hi,

On 3/8/07, Jim Gifford <maillist@jg555.com> wrote:
> Ralf Baechle wrote:
> > On Sun, Mar 04, 2007 at 03:18:45PM -0800, Jim Gifford wrote:
> >
> >
> >> Last working Kernel was 2.6.19 series.
> >>

It seems that I broke things again :(

> >> Some changes from 2.6.19 and the 2.6.20 make it impossible to build a 64
> >> bit kernel to boot on the cobalt. Ya, I know why, building a N32
> >> actually but need a 64 bit kernel in order to do that. Anyone got any
> >> suggestions. Looking through the difference between the kernels to
> >> figure this out, but it's like looking for a needle in a haystack. Any
> >> suggestions as to a starting point?
> >>
> >
> > Try git-bisect to track down the changeset that broke things.
> >
> >   Ralf
> >
> >
> We got it nailed down to arch/mips/kernel /setup.c. But we have not
> isolated which change is actually causing it.
>

Do you use any initrd ? If so how do you pass its address to the kernel ?

What is your kernel load address ?

can you send your .config file you're using ?

> We do know that reverting back to the 2.6.19.x arch/mips/kernel /setup.c
> will fix the issue. We will continue to dwindle it down until we come up
> with the offender.
>
>

What did the console say ? If nothing early console may help if available.

thanks
-- 
               Franck

Re: Building 64 bit kernel on Cobalt

[Jim Gifford]

Franck Bui-Huu wrote:
> Hi,
>
> On 3/8/07, Jim Gifford <maillist@jg555.com> wrote:
>> Ralf Baechle wrote:
>> > On Sun, Mar 04, 2007 at 03:18:45PM -0800, Jim Gifford wrote:
>> >
>> >
>> >> Last working Kernel was 2.6.19 series.
>> >>
>
> It seems that I broke things again :(
>
>> >> Some changes from 2.6.19 and the 2.6.20 make it impossible to 
>> build a 64
>> >> bit kernel to boot on the cobalt. Ya, I know why, building a N32
>> >> actually but need a 64 bit kernel in order to do that. Anyone got any
>> >> suggestions. Looking through the difference between the kernels to
>> >> figure this out, but it's like looking for a needle in a haystack. 
>> Any
>> >> suggestions as to a starting point?
>> >>
>> >
>> > Try git-bisect to track down the changeset that broke things.
>> >
>> >   Ralf
>> >
>> >
>> We got it nailed down to arch/mips/kernel /setup.c. But we have not
>> isolated which change is actually causing it.
>>
>
> Do you use any initrd ? If so how do you pass its address to the kernel ?
No.
>
> What is your kernel load address ?
Not sure
>
> can you send your .config file you're using ?
I'll send it to you later, since I'm not at the office right now.
>
>> We do know that reverting back to the 2.6.19.x arch/mips/kernel /setup.c
>> will fix the issue. We will continue to dwindle it down until we come up
>> with the offender.
>>
>>
>
> What did the console say ? If nothing early console may help if 
> available.
All I get is this
inflate: decompressing
elf64: 00080000 - 0037701f (ffffffff.80326000) (ffffffff.80000000)
elf64: ffffffff.80080000 (80080000) 2957446t + 151450t
net: interface down

>
> thanks

Re: Building 64 bit kernel on Cobalt

[Jim Gifford]

Jim Gifford wrote:
> Franck Bui-Huu wrote:
>> Hi,
>>
>> On 3/8/07, Jim Gifford <maillist@jg555.com> wrote:
>>> Ralf Baechle wrote:
>>> > On Sun, Mar 04, 2007 at 03:18:45PM -0800, Jim Gifford wrote:
>>> >
>>> >
>>> >> Last working Kernel was 2.6.19 series.
>>> >>
>>
>> It seems that I broke things again :(
>>
>>> >> Some changes from 2.6.19 and the 2.6.20 make it impossible to 
>>> build a 64
>>> >> bit kernel to boot on the cobalt. Ya, I know why, building a N32
>>> >> actually but need a 64 bit kernel in order to do that. Anyone got 
>>> any
>>> >> suggestions. Looking through the difference between the kernels to
>>> >> figure this out, but it's like looking for a needle in a 
>>> haystack. Any
>>> >> suggestions as to a starting point?
>>> >>
>>> >
>>> > Try git-bisect to track down the changeset that broke things.
>>> >
>>> >   Ralf
>>> >
>>> >
>>> We got it nailed down to arch/mips/kernel /setup.c. But we have not
>>> isolated which change is actually causing it.
>>>
>>
>> Do you use any initrd ? If so how do you pass its address to the 
>> kernel ?
> No.
>>
>> What is your kernel load address ?
> Not sure
>>
>> can you send your .config file you're using ?
> I'll send it to you later, since I'm not at the office right now.
>>
>>> We do know that reverting back to the 2.6.19.x arch/mips/kernel 
>>> /setup.c
>>> will fix the issue. We will continue to dwindle it down until we 
>>> come up
>>> with the offender.
>>>
>>>
>>
>> What did the console say ? If nothing early console may help if 
>> available.
> All I get is this
> inflate: decompressing
> elf64: 00080000 - 0037701f (ffffffff.80326000) (ffffffff.80000000)
> elf64: ffffffff.80080000 (80080000) 2957446t + 151450t
> net: interface down
>
>>
>> thanks
>
>
Frank any ideas on a solution?

Re: Building 64 bit kernel on Cobalt

[Franck Bui-Huu]

Jim Gifford wrote:
> Jim Gifford wrote:
>>> What did the console say ? If nothing early console may help if
>>> available.
>> All I get is this
>> inflate: decompressing
>> elf64: 00080000 - 0037701f (ffffffff.80326000) (ffffffff.80000000)
>> elf64: ffffffff.80080000 (80080000) 2957446t + 151450t
>> net: interface down
>>

Where does this trace come from ? from a bootloader ?
I don't understand its format, can you explain ? All I can say that
it seems that you're using CKSEG0 for kernel addresses.

You also said that you don't have any initrd. And most of the changes
you reverted back is related to initrd except this part:

-	reserved_end = init_initrd();
-	reserved_end = PFN_UP(CPHYSADDR(max(reserved_end, (unsigned long)&_end)));
+	reserved_end = max(init_initrd(), PFN_UP(__pa_symbol(&_end)));

Can you try a plain 2.6.20 with this only change ? If it helps, can
you give the value of 'reserved_end' in both cases ?

Do you use default cobalt config file ?

BTW does Cobalt platform have early printk available ? if so can you use
it ?
-- 
               Franck

Re: Building 64 bit kernel on Cobalt

[Ralf Baechle]

On Tue, Mar 13, 2007 at 11:38:23AM +0100, Franck Bui-Huu wrote:

> BTW does Cobalt platform have early printk available ? if so can you use
> it ?

Yes, it does since a long time.

  Ralf

Re: Building 64 bit kernel on Cobalt

[Jim Gifford]

Frank,
    Got it narrowed down further. This reverting these 3 sections will 
allow it to boot, but then mounting root it gives a unaligned access 
error. Reverting all the changes to setup.c, fixes the issue and boots 
completely.

--- linux-2.6.19.2/arch/mips/kernel/setup.c     2007-01-10 
11:10:37.000000000 -0800
+++ linux-2.6.20.1/arch/mips/kernel/setup.c     2007-03-07 
20:59:28.000000000 -0800
@@ -204,12 +226,12 @@
                printk(KERN_INFO "Initrd not found or empty");
                goto disable;
        }
-       if (CPHYSADDR(initrd_end) > PFN_PHYS(max_low_pfn)) {
+       if (__pa(initrd_end) > PFN_PHYS(max_low_pfn)) {
                printk("Initrd extends beyond end of memory");
                goto disable;
        }

-       reserve_bootmem(CPHYSADDR(initrd_start), size);
+       reserve_bootmem(__pa(initrd_start), size);
        initrd_below_start_ok = 1;

        printk(KERN_INFO "Initial ramdisk at: 0x%lx (%lu bytes)\n",
@@ -259,8 +281,7 @@
         * not selected. Once that done we can determine the low bound
         * of usable memory.
         */
-       reserved_end = init_initrd();
-       reserved_end = PFN_UP(CPHYSADDR(max(reserved_end, (unsigned 
long)&_end)));
+       reserved_end = max(init_initrd(), PFN_UP(__pa_symbol(&_end)));

        /*
         * Find the highest page frame number we have available.
@@ -432,10 +453,10 @@
        if (UNCAC_BASE != IO_BASE)
                return;

-       code_resource.start = virt_to_phys(&_text);
-       code_resource.end = virt_to_phys(&_etext) - 1;
-       data_resource.start = virt_to_phys(&_etext);
-       data_resource.end = virt_to_phys(&_edata) - 1;
+       code_resource.start = __pa_symbol(&_text);
+       code_resource.end = __pa_symbol(&_etext) - 1;
+       data_resource.start = __pa_symbol(&_etext);
+       data_resource.end = __pa_symbol(&_edata) - 1;

        /*
         * Request address space for all standard RAM.

VFS: Mounted root (nfs filesystem) readonly.
Unhandled kernel unaligned access[#1]:
Cpu 0
$ 0   : 0000000000000000 ffffffff802adc70 0000000000000000 0000000000000000
$ 4   : ffffffff80089fac ffffffffde020000 ffffffff8008c648 0000000000000000
$ 8   : 0000000000561024 996bffffff40b050 0000000000000000 000000000000f6f8
$12   : ffffffff94004ce0 000000001000001e 0000000000000000 ffffffff80300000
$16   : 9800000000387df0 ffffffff80326000 0000000000000000 00067ffffff80326
$20   : 00067ffffff80326 000000000000002d fffffffffffffbff 67ffffff80353000
$24   : 0000000000000010 ffffffff80176998
$28   : 9800000000384000 9800000000387dc0 67ffffff80326000 ffffffff80081ee8
Hi    : 0000000000000000
Lo    : 0000000000000000
epc   : ffffffff80089fc4 do_ade+0x3a4/0x4c0     Not tainted
ra    : ffffffff80081ee8 ret_from_exception+0x0/0x1c
Status: 94004ce2    KX SX UX KERNEL EXL
Cause : 00808010
BadVA : 996bffffff40b057
PrId  : 000028a0
Process swapper (pid: 1, threadinfo=9800000000384000, task=9800000000381828)
Stack : 996bffffff40b050 ffffffff80326000 016bfffffe40b050 00067ffffff80326
        ffffffff80081ee8 0000000000000000 0000000000000000 ffffffff94004ce0
        9800000001000000 019ffffffe00c980 ffffffff94004ce1 00067ffffff80353
        6800000000000000 9800000000381828 98000000013e9a40 98000000003b3000
        ffffffff803097a8 000000000000f6f8 0000000000000001 ffffffff801b9448
        0000000000000000 ffffffff80300000 996bffffff40b050 ffffffff80326000
        016bfffffe40b050 00067ffffff80326 00067ffffff80326 000000000000002d
        fffffffffffffbff 67ffffff80353000 0000000000000010 ffffffff80176998
        ffffffff800fb66c ffffffff800fb66c 9800000000384000 9800000000387f20
        67ffffff80326000 ffffffff8008c590 ffffffff94004ce2 0000000000000000
        ...
Call Trace:
[<ffffffff80089fc4>] do_ade+0x3a4/0x4c0
[<ffffffff80081ee8>] ret_from_exception+0x0/0x1c
[<ffffffff8008c648>] free_initmem+0xe8/0x218
[<ffffffff80080688>] init+0x248/0x510
[<ffffffff800844e0>] kernel_thread_helper+0x10/0x18


Code: 00431024  5440ff77  de020100 <69230007> 6d230000  24020000  
1440ffba  00051402  08022790

Re: Building 64 bit kernel on Cobalt

[Atsushi Nemoto]

On Sun, 18 Mar 2007 14:52:24 -0700, Jim Gifford <maillist@jg555.com> wrote:
> Frank,
>     Got it narrowed down further. This reverting these 3 sections will 
> allow it to boot, but then mounting root it gives a unaligned access 
> error. Reverting all the changes to setup.c, fixes the issue and boots 
> completely.

You said you are not using initrd, right?  I can not see why these
changes affects non-initrd environment.  Full boot log and .config
would help us to find what was wrong.

---
Atsushi Nemoto

Re: Building 64 bit kernel on Cobalt

[Jim Gifford]

Atsushi Nemoto wrote:
> On Sun, 18 Mar 2007 14:52:24 -0700, Jim Gifford <maillist@jg555.com> wrote:
>   
>> Frank,
>>     Got it narrowed down further. This reverting these 3 sections will 
>> allow it to boot, but then mounting root it gives a unaligned access 
>> error. Reverting all the changes to setup.c, fixes the issue and boots 
>> completely.
>>     
>
> You said you are not using initrd, right?  I can not see why these
> changes affects non-initrd environment.  Full boot log and .config
> would help us to find what was wrong.
>
> ---
> Atsushi Nemoto
>
>   
Here's the config file I'm using http://ftp.jg555.com/cobalt.config
Now if I revert all changes that have occurred to setup.c from 2.6.19 to 
2.6.20, everything works perfectly.

Without that patch, this is as far as it gets.

 > execute root=/dev/nfs nfsroot=192.168.55.2:/nfsroot 
console=ttyS0,115200 ip=dhcp
inflate: decompressing
elf64: 00080000 - 0037701f (ffffffff.80326000) (ffffffff.80000000)
elf64: ffffffff.80080000 (80080000) 2957446t + 151450t
net: interface down
Linux version 2.6.20.1 (root@build) (gcc version 4.1.2) #1 Sun Mar 18 
22:07:40 PDT 2007
CPU revision is: 000028a0
FPU revision is: 000028a0
Cobalt board ID: 6
registering PCI controller with io_map_base unset
Cobalt: early console registered
Determined physical RAM map:
 memory: 0000000010000000 @ 0000000000000000 (usable)

With the patch, here's the info
 > execute root=/dev/nfs nfsroot=192.168.55.2:/nfsroot 
console=ttyS0,115200 ip=dhcp
inflate: decompressing
elf64: 00080000 - 0037701f (ffffffff.80326000) (ffffffff.80000000)
elf64: ffffffff.80080000 (80080000) 2957446t + 151450t
net: interface down
Linux version 2.6.20.1 (root@build) (gcc version 4.1.2) #1 Sun Mar 18 
22:15:54 PDT 2007
CPU revision is: 000028a0
FPU revision is: 000028a0
Cobalt board ID: 6
registering PCI controller with io_map_base unset
Cobalt: early console registered
Determined physical RAM map:
 memory: 0000000010000000 @ 0000000000000000 (usable)
Built 1 zonelists.  Total pages: 64640
Kernel command line: root=/dev/nfs nfsroot=192.168.55.2:/nfsroot 
console=ttyS0,115200 ip=dhcp
Primary instruction cache 32kB, physically tagged, 2-way, linesize 32 bytes.
Primary data cache 32kB, 2-way, linesize 32 bytes.
Synthesized TLB refill handler (32 instructions).
Synthesized TLB load handler fastpath (46 instructions).
Synthesized TLB store handler fastpath (46 instructions).
Synthesized TLB modify handler fastpath (45 instructions).
PID hash table entries: 1024 (order: 10, 8192 bytes)
Linux version 2.6.20.1 (root@build) (gcc version 4.1.2) #1 Sun Mar 18 
22:15:54 PDT 2007
CPU revision is: 000028a0
FPU revision is: 000028a0
Cobalt board ID: 6
registering PCI controller with io_map_base unset
Cobalt: early console registered
Determined physical RAM map:
 memory: 0000000010000000 @ 0000000000000000 (usable)
Built 1 zonelists.  Total pages: 64640
Kernel command line: root=/dev/nfs nfsroot=192.168.55.2:/nfsroot 
console=ttyS0,115200 ip=dhcp
Primary instruction cache 32kB, physically tagged, 2-way, linesize 32 bytes.
Primary data cache 32kB, 2-way, linesize 32 bytes.
Synthesized TLB refill handler (32 instructions).
Synthesized TLB load handler fastpath (46 instructions).
Synthesized TLB store handler fastpath (46 instructions).
Synthesized TLB modify handler fastpath (45 instructions).
PID hash table entries: 1024 (order: 10, 8192 bytes)
Dentry cache hash table entries: 32768 (order: 6, 262144 bytes)
Inode-cache hash table entries: 16384 (order: 5, 131072 bytes)
Memory: 254464k/262144k available (2214k kernel code, 7540k reserved, 
493k data, 180k init, 0k highmem)
Mount-cache hash table entries: 256
Checking for the multiply/shift bug... no.
Checking for the daddi bug... no.
Checking for the daddiu bug... no.
NET: Registered protocol family 16
Galileo: fixed bridge class
Galileo: revision 17
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 2, 16384 bytes)
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 4096 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 8192 bind 4096)
TCP reno registered
io scheduler noop registered
io scheduler anticipatory registered (default)
Activating ISA DMA hang workarounds.
rtc: SRM (post-2000) epoch (2000) detected
Real Time Clock Driver v1.12ac
Cobalt LCD Driver v2.10
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
ÿserial8250: ttyS0 at I/O 0xc800000 (irq = 21) is a ST16650V2
Linux Tulip driver version 1.1.14 (December 15, 2004)
PCI: Enabling device 0000:00:07.0 (0041 -> 0043)
io_map_base of root PCI bus 0000:00 unset.  Trying to continue but you 
better
fix this issue or report it to linux-mips@linux-mips.org or your vendor.
tulip0: Old format EEPROM on 'Cobalt Microserver' board.  Using 
substitute media control info.
tulip0:  EEPROM default media type Autosense.
tulip0:  Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block.
tulip0:  MII transceiver #1 config 1000 status 7809 advertising 01e1.
eth0: Digital DS21142/43 Tulip rev 65 at Port 0x1000, 00:10:E0:00:47:6E, 
IRQ 19.
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller at PCI slot 0000:00:09.1
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt82c586a (rev 27) IDE UDMA33 controller on pci0000:00:09.1
    ide0: BM-DMA at 0x10a0-0x10a7, BIOS settings: hda:pio, hdb:pio
    ide1: BM-DMA at 0x10a8-0x10af, BIOS settings: hdc:pio, hdd:pio
ide0: I/O resource 0xFFFFFFFFF00003F6-0xFFFFFFFFF00003F6 not free.
ide0: ports already in use, skipping probe
ide1: I/O resource 0xFFFFFFFFF0000376-0xFFFFFFFFF0000376 not free.
ide1: ports already in use, skipping probe
ide0: I/O resource 0xFFFFFFFFF00003F6-0xFFFFFFFFF00003F6 not free.
ide0: ports already in use, skipping probe
ide1: I/O resource 0xFFFFFFFFF0000376-0xFFFFFFFFF0000376 not free.
ide1: ports already in use, skipping probe
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
Sending DHCP requests .<7>0000:00:07.0: tulip_stop_rxtx() failed (CSR5 
0xf0660000 CSR6 0xb20e2202)
eth0: Setting full-duplex based on MII#1 link partner capability of 4de1.
., OK
IP-Config: Got DHCP answer from 192.168.55.2, my address is 192.168.55.112
IP-Config: Complete:
      device=eth0, addr=192.168.55.112, mask=255.255.255.0, gw=192.168.55.1,
     host=raq22, domain=jg555.com, nis-domain=(none),
     bootserver=192.168.55.2, rootserver=192.168.55.2, rootpath=/nfsroot
Looking up port of RPC 100003/2 on 192.168.55.2
Looking up port of RPC 100005/1 on 192.168.55.2
VFS: Mounted root (nfs filesystem) readonly.
Unhandled kernel unaligned access[#1]:
Cpu 0
$ 0   : 0000000000000000 ffffffff802adc70 0000000000000000 0000000000000000
$ 4   : ffffffff80089fac ffffffffde020000 ffffffff8008c648 0000000000000000
$ 8   : 0000000000561024 996bffffff40b050 0000000000000000 000000000000f6f8
$12   : ffffffff94004ce0 000000001000001e 0000000000000000 ffffffff80300000
$16   : 9800000000387df0 ffffffff80326000 0000000000000000 00067ffffff80326
$20   : 00067ffffff80326 000000000000002d fffffffffffffbff 67ffffff80353000
$24   : 0000000000000010 ffffffff80176998
$28   : 9800000000384000 9800000000387dc0 67ffffff80326000 ffffffff80081ee8
Hi    : 0000000000000000
Lo    : 0000000000000000
epc   : ffffffff80089fc4 do_ade+0x3a4/0x4c0     Not tainted
ra    : ffffffff80081ee8 ret_from_exception+0x0/0x1c
Status: 94004ce2    KX SX UX KERNEL EXL
Cause : 00808010
BadVA : 996bffffff40b057
PrId  : 000028a0
Process swapper (pid: 1, threadinfo=9800000000384000, task=9800000000381828)
Stack : 996bffffff40b050 ffffffff80326000 016bfffffe40b050 00067ffffff80326
        ffffffff80081ee8 0000000000000000 0000000000000000 ffffffff94004ce0
        9800000001000000 019ffffffe00c980 ffffffff94004ce1 00067ffffff80353
        6800000000000000 9800000000381828 98000000013e9a40 98000000003b3000
        ffffffff803097a8 000000000000f6f8 0000000000000001 ffffffff801b9448
        0000000000000000 ffffffff80300000 996bffffff40b050 ffffffff80326000
        016bfffffe40b050 00067ffffff80326 00067ffffff80326 000000000000002d
        fffffffffffffbff 67ffffff80353000 0000000000000010 ffffffff80176998
        ffffffff800fb66c ffffffff800fb66c 9800000000384000 9800000000387f20
        67ffffff80326000 ffffffff8008c590 ffffffff94004ce2 0000000000000000
        ...
Call Trace:
[<ffffffff80089fc4>] do_ade+0x3a4/0x4c0
[<ffffffff80081ee8>] ret_from_exception+0x0/0x1c
[<ffffffff8008c648>] free_initmem+0xe8/0x218
[<ffffffff80080688>] init+0x248/0x510
[<ffffffff800844e0>] kernel_thread_helper+0x10/0x18


Code: 00431024  5440ff77  de020100 <69230007> 6d230000  24020000  
1440ffba  00051402  08022790
Kernel panic - not syncing: Attempted to kill init!

Re: Building 64 bit kernel on Cobalt

[Atsushi Nemoto]

On Sun, 18 Mar 2007 22:20:21 -0700, Jim Gifford <maillist@jg555.com> wrote:
> Here's the config file I'm using http://ftp.jg555.com/cobalt.config
> Now if I revert all changes that have occurred to setup.c from 2.6.19 to 
> 2.6.20, everything works perfectly.
> 
> Without that patch, this is as far as it gets.

You are using CONFIG_BUILD_ELF64=y and CKSEG0 load address.
This combination does not work.  Please refer these threads:

http://www.linux-mips.org/archives/linux-mips/2006-10/msg00064.html
http://www.linux-mips.org/archives/linux-mips/2006-10/msg00154.html
http://www.linux-mips.org/archives/linux-mips/2007-01/msg00305.html

Please try CONFIG_BUILD_ELF64=n.

BTW, Ralf, any chance to Franck's CONFIG_BUILD_ELF64 cleanup patchset?
I hope the patchset make things clearer...

---
Atsushi Nemoto

Re: Building 64 bit kernel on Cobalt

[Franck Bui-Huu]

On 3/19/07, Atsushi Nemoto <anemo@mba.ocn.ne.jp> wrote:
> On Sun, 18 Mar 2007 22:20:21 -0700, Jim Gifford <maillist@jg555.com> wrote:
> > Here's the config file I'm using http://ftp.jg555.com/cobalt.config
> > Now if I revert all changes that have occurred to setup.c from 2.6.19 to
> > 2.6.20, everything works perfectly.
> >
> > Without that patch, this is as far as it gets.
>
> You are using CONFIG_BUILD_ELF64=y and CKSEG0 load address.
> This combination does not work.  Please refer these threads:
>

Thanks Atsushi for sorting this out. It's a bit sad to get these type
of information after so many email echanges...

>
> Please try CONFIG_BUILD_ELF64=n.
>
> BTW, Ralf, any chance to Franck's CONFIG_BUILD_ELF64 cleanup patchset?
> I hope the patchset make things clearer...
>

Well, this patch may be not enough. From last thread about 64bits kernel issue:

http://marc.info/?l=linux-mips&m=117418351419352&w=2

It seems that objcopy can be used to do some addresses translations.
In that case the current patch won't help. At least we could add more
sanity checks to detect all buggy configs we can have for 64 bits
kernel and panic if they fail.
-- 
               Franck

Re: Building 64 bit kernel on Cobalt

[Franck Bui-Huu]

On 3/19/07, Franck Bui-Huu <vagabon.xyz@gmail.com> wrote:
> On 3/19/07, Atsushi Nemoto <anemo@mba.ocn.ne.jp> wrote:
> > On Sun, 18 Mar 2007 22:20:21 -0700, Jim Gifford <maillist@jg555.com> wrote:
> > > Here's the config file I'm using http://ftp.jg555.com/cobalt.config
> > > Now if I revert all changes that have occurred to setup.c from 2.6.19 to
> > > 2.6.20, everything works perfectly.
> > >
> > > Without that patch, this is as far as it gets.
> >
> > You are using CONFIG_BUILD_ELF64=y and CKSEG0 load address.
> > This combination does not work.  Please refer these threads:
> >
>
> Thanks Atsushi for sorting this out. It's a bit sad to get these type
> of information after so many email echanges...
>

BTW, how this config has ever worked for a 2.6.19 kernel ? I don't see
why using __pa() instead of CPHYSADDR() breaks this config...
-- 
               Franck

Re: Building 64 bit kernel on Cobalt

[Atsushi Nemoto]

On Mon, 19 Mar 2007 11:17:48 +0100, "Franck Bui-Huu" <vagabon.xyz@gmail.com> wrote:
> > > You are using CONFIG_BUILD_ELF64=y and CKSEG0 load address.
> > > This combination does not work.  Please refer these threads:
> > >
> >
> > Thanks Atsushi for sorting this out. It's a bit sad to get these type
> > of information after so many email echanges...
> >
> 
> BTW, how this config has ever worked for a 2.6.19 kernel ? I don't see
> why using __pa() instead of CPHYSADDR() breaks this config...

2.6.19:
	CPHYSADDR(0xffffffff80000000) == 0
	__pa(0xffffffff80000000) == 0xffffffff80000000 - 0x9800000000000000
2.6.20 (CONFIG_BUILD_ELF64=y):
	CPHYSADDR(0xffffffff80000000) == 0
	__pa(0xffffffff80000000) == 0xffffffff80000000 - 0x9800000000000000
2.6.20 (CONFIG_BUILD_ELF64=n):
	CPHYSADDR(0xffffffff80000000) == 0
	__pa(0xffffffff80000000) == 0

The reason is obvious, isn't it? ;)

---
Atsushi Nemoto

Re: Building 64 bit kernel on Cobalt

[Franck Bui-Huu]

On 3/21/07, Atsushi Nemoto <anemo@mba.ocn.ne.jp> wrote:
> On Mon, 19 Mar 2007 11:17:48 +0100, "Franck Bui-Huu" <vagabon.xyz@gmail.com> wrote:
> > > > You are using CONFIG_BUILD_ELF64=y and CKSEG0 load address.
> > > > This combination does not work.  Please refer these threads:
> > > >
> > >
> > > Thanks Atsushi for sorting this out. It's a bit sad to get these type
> > > of information after so many email echanges...
> > >
> >
> > BTW, how this config has ever worked for a 2.6.19 kernel ? I don't see
> > why using __pa() instead of CPHYSADDR() breaks this config...
>
> 2.6.19:
>         CPHYSADDR(0xffffffff80000000) == 0
>         __pa(0xffffffff80000000) == 0xffffffff80000000 - 0x9800000000000000
> 2.6.20 (CONFIG_BUILD_ELF64=y):
>         CPHYSADDR(0xffffffff80000000) == 0
>         __pa(0xffffffff80000000) == 0xffffffff80000000 - 0x9800000000000000
> 2.6.20 (CONFIG_BUILD_ELF64=n):
>         CPHYSADDR(0xffffffff80000000) == 0
>         __pa(0xffffffff80000000) == 0
>
> The reason is obvious, isn't it? ;)
>

Yes it is !

After writing this I just realised that I was confused by what you said earlier:

    You are using CONFIG_BUILD_ELF64=y and CKSEG0 load address.
    This combination does not work.  Please refer these threads:

This combo should theoritically work but currently does not. Unlike
the following one

    CONFIG_BUILD_ELF64=n and XKPHYS load address.

which definitely don't work. And I mixed the second case with the first one...

no other comment ;)
-- 
               Franck

Re: Building 64 bit kernel on Cobalt

[Kumba]

[-- Attachment #1: Type: text/plain, Size: 1723 bytes --]

Franck Bui-Huu wrote:

> Yes it is !
> 
> After writing this I just realised that I was confused by what you said 
> earlier:
> 
>    You are using CONFIG_BUILD_ELF64=y and CKSEG0 load address.
>    This combination does not work.  Please refer these threads:
> 
> This combo should theoritically work but currently does not. Unlike
> the following one
> 
>    CONFIG_BUILD_ELF64=n and XKPHYS load address.
> 
> which definitely don't work. And I mixed the second case with the first 
> one...
> 
> no other comment ;)


Cobalt's, being just like IP32, should work fine, provided that the 
__pa_page_offset() macro gets set properly.  The thing isn't whether or not 
CKSEG0 works or doesn't work (IMHO, it works just fine), it's just making sure 
that macro gets set properly, and sanely.

These three systems (IP22, IP32, & Cobalt) are the kinds of systems that are 
gonna violate whatever rule that says CONFIG_BUILD_ELF64 && CKSEG0 is invalid. 
This is the nature of MIPS, especially on the SGI platform.  They're also the 
most common types of machines end user/hobbyists are gonna get, so these 
machines need to work.  If it was some obscure mips board only available for 
large sums of <insert currency>, then I figure things would be different.

Can someone review this patch for sanity?  It achieves my desire and lets IP32 
boot using the way I've been told (BUILD_ELF64 + -msym32 + vmlinux.32).  Likely, 
it'll also do the same for Cobalt and IP22 64bit kernels (good luck getting 
those to work right anyways).


--Kumba

-- 
Gentoo/MIPS Team Lead

"Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere."  --Elrond

[-- Attachment #2: mips-kconfig-ckseg0-idea.patch --]
[-- Type: text/plain, Size: 1353 bytes --]

diff -Naurp mipslinux/arch/mips/Kconfig mipslinux.ckseg0-a/arch/mips/Kconfig
--- mipslinux/arch/mips/Kconfig	2007-03-17 21:12:06.000000000 -0400
+++ mipslinux.ckseg0-a/arch/mips/Kconfig	2007-03-20 01:38:42.000000000 -0400
@@ -1659,6 +1659,11 @@ config SB1_PASS_2_1_WORKAROUNDS
 	depends on CPU_SB1 && CPU_SB1_PASS_2
 	default y
 
+config SYS_LOADS_IN_CKSEG0
+	bool
+	depends on BUILD_ELF64 && (SGI_IP22 || (SGI_IP32 && (CPU_R5000 || CPU_NEVADA || CPU_RM7000)) || MIPS_COBALT)
+	default y
+
 config 64BIT_PHYS_ADDR
 	bool "Support for 64-bit physical address space"
 	depends on (CPU_R4X00 || CPU_R5000 || CPU_RM7000 || CPU_RM9000 || CPU_R10000 || CPU_SB1 || CPU_MIPS32 || CPU_MIPS64) && 32BIT
diff -Naurp mipslinux/include/asm-mips/page.h mipslinux.ckseg0-a/include/asm-mips/page.h
--- mipslinux/include/asm-mips/page.h	2007-03-17 21:12:31.000000000 -0400
+++ mipslinux.ckseg0-a/include/asm-mips/page.h	2007-03-20 01:37:31.000000000 -0400
@@ -149,7 +149,7 @@ typedef struct { unsigned long pgprot; }
 /*
  * __pa()/__va() should be used only during mem init.
  */
-#if defined(CONFIG_64BIT) && !defined(CONFIG_BUILD_ELF64)
+#if defined(CONFIG_64BIT) && (!defined(CONFIG_BUILD_ELF64) || defined(CONFIG_SYS_LOADS_IN_CKSEG0))
 #define __pa_page_offset(x)	((unsigned long)(x) < CKSEG0 ? PAGE_OFFSET : CKSEG0)
 #else
 #define __pa_page_offset(x)	PAGE_OFFSET

Re: Building 64 bit kernel on Cobalt

[Atsushi Nemoto]

On Fri, 23 Mar 2007 09:47:32 -0400, Kumba <kumba@gentoo.org> wrote:
> Can someone review this patch for sanity?  It achieves my desire and
> lets IP32 boot using the way I've been told (BUILD_ELF64 + -msym32 +
> vmlinux.32).  Likely, it'll also do the same for Cobalt and IP22
> 64bit kernels (good luck getting those to work right anyways).

Let me ask again:  Why do you want to use CONFIG_BUILD_ELF64=y ?

If your board use CKSEG0 load address, I can not see any point setting
CONFIG_BUILD_ELF64=y.  I think the description in Kconfig (and the
name of CONFIG_BUILD_ELF64 itself) should be changed to make people
enable it only if really needed.  And it is already done by Franck's
pending patchset.

---
Atsushi Nemoto

Re: Building 64 bit kernel on Cobalt

[Kumba]

Atsushi Nemoto wrote:
> 
> Let me ask again:  Why do you want to use CONFIG_BUILD_ELF64=y ?
> 
> If your board use CKSEG0 load address, I can not see any point setting
> CONFIG_BUILD_ELF64=y.  I think the description in Kconfig (and the
> name of CONFIG_BUILD_ELF64 itself) should be changed to make people
> enable it only if really needed.  And it is already done by Franck's
> pending patchset.

Well, the story, as it's been explained to me a half-dozen times, cause I keep 
forgetting, is that three particular machines, IP22, IP32 (R5K/Nevada/RM7K), and 
apparently cobalt, ran best when built with the old -mabi=o64 hack, because it 
generated less instructions for certain routines (loads, I think).  Especially 
in the case of cobalt, you lack a L2 cache, so you want to squeeze every thing 
possible out of the cpu.

Well, o64 went away as we all know.  It was never a favourable option for very 
good reasons (although I used it right up until it died and I was forced off of 
it).  The replacement for it, that was more preferred and resulted in similar 
code was building a kernel for any of these three systems using 
CONFIG_BUILD_ELF64 + -msym32 (auto selected in the Makefile) + the make 
vmlinux.32 target.  I believe this method is what Debian uses for building their 
mips kernels for SGI systems, but don't quote me on that.  If someone from 
Debian wants to comment, please do.

The idea being to stuff 64bit code into a 32bit object/kernel, since at least 
one of these systems, namely IP22, will only accept a 32bit object for booting. 
  It can't understand 64bit kernel objects.  Cobalt's colo bootloader will 
handle 64bit I believe, but my experience a year or two ago showed that a 
32bit/64bit hybrid kernel ran much faster than a pure 64bit kernel, simply due 
to the decreased overhead.  IP32's prom usually has no problem booting either, 
but I seem to also see a minor improvement in console redraw speed under the 
hyrbid kernel as well.

The issue is, if this method is broken, what's its replacement?  Is this 
replacement capable of generating the same (or near enough) code w/o incurring a 
penalty hit?  I mean, part of the reason for discussion going on for as long as 
it has been is the relative confusion surrounding the proper way to build these 
kernels for these particular systems.  If someone can hash that out, I think 
we'll all figure out what track to get on and get something in the tree that 
works, and works well.



--Kumba

-- 
Gentoo/MIPS Team Lead

"Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere."  --Elrond

Re: Building 64 bit kernel on Cobalt

[Atsushi Nemoto]

On Fri, 23 Mar 2007 23:31:57 -0400, Kumba <kumba@gentoo.org> wrote:
> Well, o64 went away as we all know.  It was never a favourable
> option for very good reasons (although I used it right up until it
> died and I was forced off of it).  The replacement for it, that was
> more preferred and resulted in similar code was building a kernel
> for any of these three systems using CONFIG_BUILD_ELF64 + -msym32
> (auto selected in the Makefile) + the make vmlinux.32 target.  I
> believe this method is what Debian uses for building their mips
> kernels for SGI systems, but don't quote me on that.  If someone
> from Debian wants to comment, please do.

The replacement is CONFIG_BUILD_ELF64=n (it adds -msym32 option) +
CONFIG_BOOT_ELF32=y (it adds vmlinux.32 to "all" target).  Not
CONFIG_BUILD_ELF64=y.

CONFIG_BUILD_ELF64=n enables -msym32 option, which means the kernel
load address should be CKSEG0.  And if the kernel load address was
CKSEG0, -msym32 make the kernel smaller and faster so it is absolutely
preferred.

CONFIG_BOOT_ELF32=y enables objcopying vmlinux to vmlinux.32.

---
Atsushi Nemoto

Re: Building 64 bit kernel on Cobalt

[Thiemo Seufer]

Atsushi Nemoto wrote:
> On Fri, 23 Mar 2007 23:31:57 -0400, Kumba <kumba@gentoo.org> wrote:
> > Well, o64 went away as we all know.  It was never a favourable
> > option for very good reasons (although I used it right up until it
> > died and I was forced off of it).  The replacement for it, that was
> > more preferred and resulted in similar code was building a kernel
> > for any of these three systems using CONFIG_BUILD_ELF64 + -msym32
> > (auto selected in the Makefile) + the make vmlinux.32 target.  I
> > believe this method is what Debian uses for building their mips
> > kernels for SGI systems, but don't quote me on that.  If someone
> > from Debian wants to comment, please do.
> 
> The replacement is CONFIG_BUILD_ELF64=n (it adds -msym32 option) +
> CONFIG_BOOT_ELF32=y (it adds vmlinux.32 to "all" target).  Not
> CONFIG_BUILD_ELF64=y.
> 
> CONFIG_BUILD_ELF64=n enables -msym32 option, which means the kernel
> load address should be CKSEG0.

This sounds wrong to me, since CONFIG_BUILD_ELF64=n will build a
ELF64 kernel (from compiler/linker POV). This tricks people into
believing they need no ELF64 capable toolchain for a 64bit kernel.

IMO -msym32 should depend on:
    ((Compiler can do -msym32)
     && (load address is in ckseg0)
     && CONFIG_64BIT)

which obsoletes the whole CONFIG_BUILD_ELF* stuff.


Thiemo

[PATCH]: Remove CONFIG_BUILD_ELF64 entirely

[Kumba]

[-- Attachment #1: Type: text/plain, Size: 2497 bytes --]

Thiemo Seufer wrote:
>> The replacement is CONFIG_BUILD_ELF64=n (it adds -msym32 option) +
>> CONFIG_BOOT_ELF32=y (it adds vmlinux.32 to "all" target).  Not
>> CONFIG_BUILD_ELF64=y.
>>
>> CONFIG_BUILD_ELF64=n enables -msym32 option, which means the kernel
>> load address should be CKSEG0.
> 
> This sounds wrong to me, since CONFIG_BUILD_ELF64=n will build a
> ELF64 kernel (from compiler/linker POV). This tricks people into
> believing they need no ELF64 capable toolchain for a 64bit kernel.
> 
> IMO -msym32 should depend on:
>     ((Compiler can do -msym32)
>      && (load address is in ckseg0)
>      && CONFIG_64BIT)
> 
> which obsoletes the whole CONFIG_BUILD_ELF* stuff.
> 
> 
> Thiemo

Going on this, I propose the following patch to fix our lovely SGI/Cobalt 
systems, and eliminate a confusing Kconfig option whose time is likely long 
since passed.  The attached patch achieves the following:

* Introduces a new flag for IP22, IP32, and Cobalt called 'kernel_loads_in_ckseg0'.
* Introduces a new header, mem-layout.h, in include/asm-mips/mach-<platform>/ 
for this flag for these three systems, and a dummy entry for mach-generic, 
calling it in where appropriate.
* Removes CONFIG_BUILD_ELF64 from Kconfig, Makefile, and several defconfigs, and 
replaces its few references in header files with 'kernel_loads_in_ckseg0', with 
appropriate flips in logic (except in stackframe.h).
* Includes Frank's patch to eliminate the need for -mno-explicit-relocs.
* Moves -msym32 calling to the Makefile locations for the three machines that 
actually need it.


--Kumba


Signed-off-by: Joshua Kinard <kumba@gentoo.org>

  arch/mips/Kconfig                          |   15 ---------------
  arch/mips/Makefile                         |   11 +++++------
  arch/mips/configs/bigsur_defconfig         |    1 -
  arch/mips/configs/ip27_defconfig           |    1 -
  arch/mips/configs/ip32_defconfig           |    1 -
  arch/mips/configs/ocelot_c_defconfig       |    1 -
  arch/mips/configs/sb1250-swarm_defconfig   |    1 -
  include/asm-mips/mach-cobalt/mem-layout.h  |    7 +++++++
  include/asm-mips/mach-generic/mem-layout.h |    7 +++++++
  include/asm-mips/mach-ip22/mem-layout.h    |    7 +++++++
  include/asm-mips/mach-ip32/mem-layout.h    |    7 +++++++
  include/asm-mips/page.h                    |    3 ++-
  include/asm-mips/pgtable-64.h              |    4 +++-
  include/asm-mips/stackframe.h              |    6 ++++--
  14 files changed, 42 insertions(+), 30 deletions(-)


[-- Attachment #2: mips-fix-ckseg0-stuff.patch --]
[-- Type: text/plain, Size: 9271 bytes --]

diff -Naurp mipslinux/arch/mips/Kconfig mipslinux.ckseg0/arch/mips/Kconfig
--- mipslinux/arch/mips/Kconfig	2007-03-17 21:12:06.000000000 -0400
+++ mipslinux.ckseg0/arch/mips/Kconfig	2007-03-25 02:03:06.000000000 -0400
@@ -2072,21 +2072,6 @@ source "fs/Kconfig.binfmt"
 config TRAD_SIGNALS
 	bool
 
-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.
-
 config BINFMT_IRIX
 	bool "Include IRIX binary compatibility"
 	depends on CPU_BIG_ENDIAN && 32BIT && BROKEN
diff -Naurp mipslinux/arch/mips/Makefile mipslinux.ckseg0/arch/mips/Makefile
--- mipslinux/arch/mips/Makefile	2007-03-17 21:12:06.000000000 -0400
+++ mipslinux.ckseg0/arch/mips/Makefile	2007-03-25 02:15:22.000000000 -0400
@@ -60,11 +60,6 @@ vmlinux-32		= vmlinux.32
 vmlinux-64		= vmlinux
 
 cflags-y		+= -mabi=64
-ifdef CONFIG_BUILD_ELF64
-cflags-y		+= $(call cc-option,-mno-explicit-relocs)
-else
-cflags-y		+= $(call cc-option,-msym32)
-endif
 endif
 
 
@@ -271,6 +266,9 @@ load-$(CONFIG_MIPS_XXS1500)	+= 0xfffffff
 #
 core-$(CONFIG_MIPS_COBALT)	+= arch/mips/cobalt/
 cflags-$(CONFIG_MIPS_COBALT)	+= -Iinclude/asm-mips/mach-cobalt
+ifdef CONFIG_64BIT
+cflags-$(CONFIG_MIPS_COBALT)	+= $(call cc-option,-msym32)
+endif
 load-$(CONFIG_MIPS_COBALT)	+= 0xffffffff80080000
 
 #
@@ -494,6 +492,7 @@ ifdef CONFIG_32BIT
 load-$(CONFIG_SGI_IP22)		+= 0xffffffff88002000
 endif
 ifdef CONFIG_64BIT
+cflags-$(CONFIG_SGI_IP22)	+= $(call cc-option,-msym32)
 load-$(CONFIG_SGI_IP22)		+= 0xffffffff88004000
 endif
 
@@ -526,7 +525,7 @@ endif
 # will break.
 #
 core-$(CONFIG_SGI_IP32)		+= arch/mips/sgi-ip32/
-cflags-$(CONFIG_SGI_IP32)	+= -Iinclude/asm-mips/mach-ip32
+cflags-$(CONFIG_SGI_IP32)	+= -Iinclude/asm-mips/mach-ip32 $(call cc-option,-msym32)
 load-$(CONFIG_SGI_IP32)		+= 0xffffffff80004000
 
 #
diff -Naurp mipslinux/arch/mips/configs/bigsur_defconfig mipslinux.ckseg0/arch/mips/configs/bigsur_defconfig
--- mipslinux/arch/mips/configs/bigsur_defconfig	2007-03-17 21:12:06.000000000 -0400
+++ mipslinux.ckseg0/arch/mips/configs/bigsur_defconfig	2007-03-25 02:02:32.000000000 -0400
@@ -279,7 +279,6 @@ CONFIG_MMU=y
 #
 CONFIG_BINFMT_ELF=y
 # CONFIG_BINFMT_MISC is not set
-# CONFIG_BUILD_ELF64 is not set
 CONFIG_MIPS32_COMPAT=y
 CONFIG_COMPAT=y
 CONFIG_SYSVIPC_COMPAT=y
diff -Naurp mipslinux/arch/mips/configs/ip27_defconfig mipslinux.ckseg0/arch/mips/configs/ip27_defconfig
--- mipslinux/arch/mips/configs/ip27_defconfig	2007-03-17 21:12:06.000000000 -0400
+++ mipslinux.ckseg0/arch/mips/configs/ip27_defconfig	2007-03-25 02:02:12.000000000 -0400
@@ -272,7 +272,6 @@ CONFIG_MMU=y
 #
 CONFIG_BINFMT_ELF=y
 # CONFIG_BINFMT_MISC is not set
-# CONFIG_BUILD_ELF64 is not set
 CONFIG_MIPS32_COMPAT=y
 CONFIG_COMPAT=y
 CONFIG_SYSVIPC_COMPAT=y
diff -Naurp mipslinux/arch/mips/configs/ip32_defconfig mipslinux.ckseg0/arch/mips/configs/ip32_defconfig
--- mipslinux/arch/mips/configs/ip32_defconfig	2007-03-17 21:12:06.000000000 -0400
+++ mipslinux.ckseg0/arch/mips/configs/ip32_defconfig	2007-03-25 02:02:00.000000000 -0400
@@ -252,7 +252,6 @@ CONFIG_MMU=y
 #
 CONFIG_BINFMT_ELF=y
 CONFIG_BINFMT_MISC=y
-# CONFIG_BUILD_ELF64 is not set
 CONFIG_MIPS32_COMPAT=y
 CONFIG_COMPAT=y
 CONFIG_SYSVIPC_COMPAT=y
diff -Naurp mipslinux/arch/mips/configs/ocelot_c_defconfig mipslinux.ckseg0/arch/mips/configs/ocelot_c_defconfig
--- mipslinux/arch/mips/configs/ocelot_c_defconfig	2007-03-17 21:12:06.000000000 -0400
+++ mipslinux.ckseg0/arch/mips/configs/ocelot_c_defconfig	2007-03-25 02:01:50.000000000 -0400
@@ -250,7 +250,6 @@ CONFIG_MMU=y
 #
 CONFIG_BINFMT_ELF=y
 # CONFIG_BINFMT_MISC is not set
-# CONFIG_BUILD_ELF64 is not set
 CONFIG_MIPS32_COMPAT=y
 CONFIG_COMPAT=y
 CONFIG_SYSVIPC_COMPAT=y
diff -Naurp mipslinux/arch/mips/configs/sb1250-swarm_defconfig mipslinux.ckseg0/arch/mips/configs/sb1250-swarm_defconfig
--- mipslinux/arch/mips/configs/sb1250-swarm_defconfig	2007-03-17 21:12:06.000000000 -0400
+++ mipslinux.ckseg0/arch/mips/configs/sb1250-swarm_defconfig	2007-03-25 02:02:22.000000000 -0400
@@ -281,7 +281,6 @@ CONFIG_MMU=y
 #
 CONFIG_BINFMT_ELF=y
 # CONFIG_BINFMT_MISC is not set
-# CONFIG_BUILD_ELF64 is not set
 CONFIG_MIPS32_COMPAT=y
 CONFIG_COMPAT=y
 CONFIG_SYSVIPC_COMPAT=y
diff -Naurp mipslinux/include/asm-mips/mach-cobalt/mem-layout.h mipslinux.ckseg0/include/asm-mips/mach-cobalt/mem-layout.h
--- mipslinux/include/asm-mips/mach-cobalt/mem-layout.h	1969-12-31 19:00:00.000000000 -0500
+++ mipslinux.ckseg0/include/asm-mips/mach-cobalt/mem-layout.h	2007-03-25 03:13:13.000000000 -0400
@@ -0,0 +1,7 @@
+#ifndef __ASM_MACH_COBALT_MEM_LAYOUT_H
+#define __ASM_MACH_COBALT_MEM_LAYOUT_H
+
+
+#define kernel_loads_in_ckseg0		1
+
+#endif /* __ASM_MACH_COBALT_MEM_LAYOUT_H */
diff -Naurp mipslinux/include/asm-mips/mach-generic/mem-layout.h mipslinux.ckseg0/include/asm-mips/mach-generic/mem-layout.h
--- mipslinux/include/asm-mips/mach-generic/mem-layout.h	1969-12-31 19:00:00.000000000 -0500
+++ mipslinux.ckseg0/include/asm-mips/mach-generic/mem-layout.h	2007-03-25 03:20:05.000000000 -0400
@@ -0,0 +1,7 @@
+#ifndef __ASM_MACH_GENERIC_MEM_LAYOUT_H
+#define __ASM_MACH_GENERIC_MEM_LAYOUT_H
+
+
+#define kernel_loads_in_ckseg0		0
+
+#endif /* __ASM_MACH_GENERIC_MEM_LAYOUT_H */
diff -Naurp mipslinux/include/asm-mips/mach-ip22/mem-layout.h mipslinux.ckseg0/include/asm-mips/mach-ip22/mem-layout.h
--- mipslinux/include/asm-mips/mach-ip22/mem-layout.h	1969-12-31 19:00:00.000000000 -0500
+++ mipslinux.ckseg0/include/asm-mips/mach-ip22/mem-layout.h	2007-03-25 03:13:06.000000000 -0400
@@ -0,0 +1,7 @@
+#ifndef __ASM_MACH_IP22_MEM_LAYOUT_H
+#define __ASM_MACH_IP22_MEM_LAYOUT_H
+
+
+#define kernel_loads_in_ckseg0		1
+
+#endif /* __ASM_MACH_IP22_MEM_LAYOUT_H */
diff -Naurp mipslinux/include/asm-mips/mach-ip32/mem-layout.h mipslinux.ckseg0/include/asm-mips/mach-ip32/mem-layout.h
--- mipslinux/include/asm-mips/mach-ip32/mem-layout.h	1969-12-31 19:00:00.000000000 -0500
+++ mipslinux.ckseg0/include/asm-mips/mach-ip32/mem-layout.h	2007-03-25 03:13:01.000000000 -0400
@@ -0,0 +1,7 @@
+#ifndef __ASM_MACH_IP32_MEM_LAYOUT_H
+#define __ASM_MACH_IP32_MEM_LAYOUT_H
+
+
+#define kernel_loads_in_ckseg0		1
+
+#endif /* __ASM_MACH_IP32_MEM_LAYOUT_H */
diff -Naurp mipslinux/include/asm-mips/page.h mipslinux.ckseg0/include/asm-mips/page.h
--- mipslinux/include/asm-mips/page.h	2007-03-17 21:12:31.000000000 -0400
+++ mipslinux.ckseg0/include/asm-mips/page.h	2007-03-25 02:08:47.000000000 -0400
@@ -13,6 +13,7 @@
 #ifdef __KERNEL__
 
 #include <spaces.h>
+#include <mem-layout.h>
 
 /*
  * PAGE_SHIFT determines the page size
@@ -149,7 +150,7 @@ typedef struct { unsigned long pgprot; }
 /*
  * __pa()/__va() should be used only during mem init.
  */
-#if defined(CONFIG_64BIT) && !defined(CONFIG_BUILD_ELF64)
+#if defined(CONFIG_64BIT) && defined(kernel_loads_in_ckseg0)
 #define __pa_page_offset(x)	((unsigned long)(x) < CKSEG0 ? PAGE_OFFSET : CKSEG0)
 #else
 #define __pa_page_offset(x)	PAGE_OFFSET
diff -Naurp mipslinux/include/asm-mips/pgtable-64.h mipslinux.ckseg0/include/asm-mips/pgtable-64.h
--- mipslinux/include/asm-mips/pgtable-64.h	2007-03-25 01:16:58.000000000 -0400
+++ mipslinux.ckseg0/include/asm-mips/pgtable-64.h	2007-03-25 02:09:25.000000000 -0400
@@ -16,6 +16,8 @@
 #include <asm/cachectl.h>
 #include <asm/fixmap.h>
 
+#include <mem-layout.h>
+
 #include <asm-generic/pgtable-nopud.h>
 
 /*
@@ -104,7 +106,7 @@
 #define VMALLOC_START		MAP_BASE
 #define VMALLOC_END	\
 	(VMALLOC_START + PTRS_PER_PGD * PTRS_PER_PMD * PTRS_PER_PTE * PAGE_SIZE)
-#if defined(CONFIG_MODULES) && !defined(CONFIG_BUILD_ELF64) && \
+#if defined(CONFIG_MODULES) && defined(kernel_loads_in_ckseg0) && \
 	VMALLOC_START != CKSSEG
 /* Load modules into 32bit-compatible segment. */
 #define MODULE_START	CKSSEG
diff -Naurp mipslinux/include/asm-mips/stackframe.h mipslinux.ckseg0/include/asm-mips/stackframe.h
--- mipslinux/include/asm-mips/stackframe.h	2007-03-17 21:12:32.000000000 -0400
+++ mipslinux.ckseg0/include/asm-mips/stackframe.h	2007-03-25 03:00:25.000000000 -0400
@@ -17,6 +17,8 @@
 #include <asm/mipsregs.h>
 #include <asm/asm-offsets.h>
 
+#include <mem-layout.h>
+
 #ifdef CONFIG_MIPS_MT_SMTC
 #include <asm/mipsmtregs.h>
 #endif /* CONFIG_MIPS_MT_SMTC */
@@ -79,7 +81,7 @@
 #else
 		MFC0	k0, CP0_CONTEXT
 #endif
-#if defined(CONFIG_BUILD_ELF64) || (defined(CONFIG_64BIT) && __GNUC__ < 4)
+#if defined(kernel_loads_in_ckseg0) || (defined(CONFIG_64BIT) && __GNUC__ < 4)
 		lui	k1, %highest(kernelsp)
 		daddiu	k1, %higher(kernelsp)
 		dsll	k1, 16
@@ -104,7 +106,7 @@
 		.endm
 #else
 		.macro	get_saved_sp	/* Uniprocessor variation */
-#if defined(CONFIG_BUILD_ELF64) || (defined(CONFIG_64BIT) && __GNUC__ < 4)
+#if defined(kernel_loads_in_ckseg0) || (defined(CONFIG_64BIT) && __GNUC__ < 4)
 		lui	k1, %highest(kernelsp)
 		daddiu	k1, %higher(kernelsp)
 		dsll	k1, k1, 16

Re: [PATCH]: Remove CONFIG_BUILD_ELF64 entirely

[Thiemo Seufer]

Kumba wrote:
> Thiemo Seufer wrote:
> >>The replacement is CONFIG_BUILD_ELF64=n (it adds -msym32 option) +
> >>CONFIG_BOOT_ELF32=y (it adds vmlinux.32 to "all" target).  Not
> >>CONFIG_BUILD_ELF64=y.
> >>
> >>CONFIG_BUILD_ELF64=n enables -msym32 option, which means the kernel
> >>load address should be CKSEG0.
> >
> >This sounds wrong to me, since CONFIG_BUILD_ELF64=n will build a
> >ELF64 kernel (from compiler/linker POV). This tricks people into
> >believing they need no ELF64 capable toolchain for a 64bit kernel.
> >
> >IMO -msym32 should depend on:
> >    ((Compiler can do -msym32)
> >     && (load address is in ckseg0)
> >     && CONFIG_64BIT)
> >
> >which obsoletes the whole CONFIG_BUILD_ELF* stuff.
> >
> >
> >Thiemo
> 
> Going on this, I propose the following patch to fix our lovely SGI/Cobalt 
> systems, and eliminate a confusing Kconfig option whose time is likely long 
> since passed.  The attached patch achieves the following:
> 
> * Introduces a new flag for IP22, IP32, and Cobalt called 
> 'kernel_loads_in_ckseg0'.
> * Introduces a new header, mem-layout.h, in 
> include/asm-mips/mach-<platform>/ for this flag for these three systems, 
> and a dummy entry for mach-generic, calling it in where appropriate.
> * Removes CONFIG_BUILD_ELF64 from Kconfig, Makefile, and several 
> defconfigs, and replaces its few references in header files with 
> 'kernel_loads_in_ckseg0', with appropriate flips in logic (except in 
> stackframe.h).
> * Includes Frank's patch to eliminate the need for -mno-explicit-relocs.

[snip]
> diff -Naurp mipslinux/arch/mips/Makefile mipslinux.ckseg0/arch/mips/Makefile
> --- mipslinux/arch/mips/Makefile	2007-03-17 21:12:06.000000000 -0400
> +++ mipslinux.ckseg0/arch/mips/Makefile	2007-03-25 02:15:22.000000000 -0400
> @@ -60,11 +60,6 @@ vmlinux-32		= vmlinux.32
>  vmlinux-64		= vmlinux
>  
>  cflags-y		+= -mabi=64
> -ifdef CONFIG_BUILD_ELF64
> -cflags-y		+= $(call cc-option,-mno-explicit-relocs)
> -else
> -cflags-y		+= $(call cc-option,-msym32)
> -endif
>  endif

AFAICS this loses -mno-explicit-relocs completely, but it is needed for
all non-ckseg0 CONFIG_64BIT builds.


Thiemo

Re: [PATCH]: Remove CONFIG_BUILD_ELF64 entirely

[Maciej W. Rozycki]

On Sun, 25 Mar 2007, Thiemo Seufer wrote:

> AFAICS this loses -mno-explicit-relocs completely, but it is needed for
> all non-ckseg0 CONFIG_64BIT builds.

 Why?  I reckon GCC should support them just fine these days.

  Maciej

Re: [PATCH]: Remove CONFIG_BUILD_ELF64 entirely

[Ralf Baechle]

On Mon, Mar 26, 2007 at 12:35:59PM +0100, Maciej W. Rozycki wrote:

> On Sun, 25 Mar 2007, Thiemo Seufer wrote:
> 
> > AFAICS this loses -mno-explicit-relocs completely, but it is needed for
> > all non-ckseg0 CONFIG_64BIT builds.
> 
>  Why?  I reckon GCC should support them just fine these days.

Please remember that we officially only require GCC 3.2 or newer.  3.2
turned out to be too broken to be supported for 64-bit builds but as long
as there is no significant problem I'd like to keep support for these
compiler antiques alive.

  Ralf

Re: [PATCH]: Remove CONFIG_BUILD_ELF64 entirely

[Maciej W. Rozycki]

On Mon, 26 Mar 2007, Ralf Baechle wrote:

> > > AFAICS this loses -mno-explicit-relocs completely, but it is needed for
> > > all non-ckseg0 CONFIG_64BIT builds.
> > 
> >  Why?  I reckon GCC should support them just fine these days.
> 
> Please remember that we officially only require GCC 3.2 or newer.  3.2
> turned out to be too broken to be supported for 64-bit builds but as long
> as there is no significant problem I'd like to keep support for these
> compiler antiques alive.

 Hmm, from the back of my head I think it should not be a problem -- IIRC 
the versions of GCC that did not support explicit relocs for 64-bit ELF 
would force "-mno-explicit-relocs" internally even if asked otherwise.  
They did not support "-msym32" either, which went in later, and then 
non-PIC support for 64-bit explicit relocs went in earlier than for PIC -- 
quite unsurprisingly, as %higher() and %highest() are not necessarily 
rocket science unlike %disp() and friends.

 If anybody cares I could probably make the excavations needed to verify 
the above.

  Maciej

Re: [PATCH]: Remove CONFIG_BUILD_ELF64 entirely

[Ralf Baechle]

On Mon, Mar 26, 2007 at 01:09:37PM +0100, Maciej W. Rozycki wrote:

> 
>  Hmm, from the back of my head I think it should not be a problem -- IIRC 
> the versions of GCC that did not support explicit relocs for 64-bit ELF 
> would force "-mno-explicit-relocs" internally even if asked otherwise.  
> They did not support "-msym32" either, which went in later, and then 
> non-PIC support for 64-bit explicit relocs went in earlier than for PIC -- 
> quite unsurprisingly, as %higher() and %highest() are not necessarily 
> rocket science unlike %disp() and friends.
> 
>  If anybody cares I could probably make the excavations needed to verify 
> the above.

That would be appreciated.  I did that on my side, I also tried to build
a few 64-bit test kernels with gcc 3.3 and 4.1.2 yesterday and did not
find any real reason why we would still need -mno-explicit-relocs.  Thiemo
said there was something like a modern gcc in combination with old
binutils.  That's the comination I haven't tested.

  Ralf

Re: [PATCH]: Remove CONFIG_BUILD_ELF64 entirely

[Atsushi Nemoto]

On Sun, 25 Mar 2007 03:25:52 -0400, Kumba <kumba@gentoo.org> wrote:
> Going on this, I propose the following patch to fix our lovely SGI/Cobalt 
> systems, and eliminate a confusing Kconfig option whose time is likely long 
> since passed.  The attached patch achieves the following:
> 
> * Introduces a new flag for IP22, IP32, and Cobalt called 'kernel_loads_in_ckseg0'.
> * Introduces a new header, mem-layout.h, in include/asm-mips/mach-<platform>/ 
> for this flag for these three systems, and a dummy entry for mach-generic, 
> calling it in where appropriate.
> * Removes CONFIG_BUILD_ELF64 from Kconfig, Makefile, and several defconfigs, and 
> replaces its few references in header files with 'kernel_loads_in_ckseg0', with 
> appropriate flips in logic (except in stackframe.h).
> * Includes Frank's patch to eliminate the need for -mno-explicit-relocs.
> * Moves -msym32 calling to the Makefile locations for the three machines that 
> actually need it.

I can not see why you handle IP22, IP32, Cobalt as so "special".
There are many other platforms which supports 64-bit and uses CKSEG0
load address (well, actually all 64-bit platforms except for IP27).

So I think Franck's approach, which enables -msym32 and defines
KBUILD_64BIT_SYM32 automatically if load-y was CKSEG0, is better.  Are
there any problem with his patchset?

---
Atsushi Nemoto

Re: [PATCH]: Remove CONFIG_BUILD_ELF64 entirely

[Ralf Baechle]

On Mon, Mar 26, 2007 at 01:10:00AM +0900, Atsushi Nemoto wrote:

> On Sun, 25 Mar 2007 03:25:52 -0400, Kumba <kumba@gentoo.org> wrote:
> > Going on this, I propose the following patch to fix our lovely SGI/Cobalt 
> > systems, and eliminate a confusing Kconfig option whose time is likely long 
> > since passed.  The attached patch achieves the following:
> > 
> > * Introduces a new flag for IP22, IP32, and Cobalt called 'kernel_loads_in_ckseg0'.
> > * Introduces a new header, mem-layout.h, in include/asm-mips/mach-<platform>/ 
> > for this flag for these three systems, and a dummy entry for mach-generic, 
> > calling it in where appropriate.
> > * Removes CONFIG_BUILD_ELF64 from Kconfig, Makefile, and several defconfigs, and 
> > replaces its few references in header files with 'kernel_loads_in_ckseg0', with 
> > appropriate flips in logic (except in stackframe.h).
> > * Includes Frank's patch to eliminate the need for -mno-explicit-relocs.
> > * Moves -msym32 calling to the Makefile locations for the three machines that 
> > actually need it.
> 
> I can not see why you handle IP22, IP32, Cobalt as so "special".
> There are many other platforms which supports 64-bit and uses CKSEG0
> load address (well, actually all 64-bit platforms except for IP27).

Note IP27 works fine either way and the code size difference is considerable:
Here are numbers for ip27_defconfig with gcc 4.1.2 and binutils 2.17:

   text    data     bss     dec     hex filename
3397944  415768  256816 4070528  3e1c80 vmlinux BUILD_ELF64=n
3774968  415768  248624 4439360  43bd40 vmlinux BUILD_ELF64=y

> So I think Franck's approach, which enables -msym32 and defines
> KBUILD_64BIT_SYM32 automatically if load-y was CKSEG0, is better.  Are
> there any problem with his patchset?

Alot more platforms could make use of this approach; the kernel size savings
are considerable.

The worst thing about CONFIG_BUILD_ELF64 is that it's interactivly available
so making it easy for the user to choose suboptimal value or one that
does not work at all, so it must become unavailable from Kconfig.

  Ralf

Re: [PATCH]: Remove CONFIG_BUILD_ELF64 entirely

[Franck Bui-Huu]

On 3/25/07, Ralf Baechle <ralf@linux-mips.org> wrote:
> Note IP27 works fine either way and the code size difference is considerable:
> Here are numbers for ip27_defconfig with gcc 4.1.2 and binutils 2.17:
>
>    text    data     bss     dec     hex filename
> 3397944  415768  256816 4070528  3e1c80 vmlinux BUILD_ELF64=n
> 3774968  415768  248624 4439360  43bd40 vmlinux BUILD_ELF64=y
>

Impressive figures !

However I can't understand why there's a such difference, I'm surely
missing something. AFAIK, we're not doing so many symbol loads in the
kernel ? Maybe this difference is related to ksymall ?

Could you make these 2 kernels available for downloading ?

thanks
-- 
               Franck

Re: [PATCH]: Remove CONFIG_BUILD_ELF64 entirely

[Thiemo Seufer]

Franck Bui-Huu wrote:
> On 3/25/07, Ralf Baechle <ralf@linux-mips.org> wrote:
> >Note IP27 works fine either way and the code size difference is 
> >considerable:
> >Here are numbers for ip27_defconfig with gcc 4.1.2 and binutils 2.17:
> >
> >   text    data     bss     dec     hex filename
> >3397944  415768  256816 4070528  3e1c80 vmlinux BUILD_ELF64=n
> >3774968  415768  248624 4439360  43bd40 vmlinux BUILD_ELF64=y
> >
> 
> Impressive figures !
> 
> However I can't understand why there's a such difference, I'm surely
> missing something. AFAIK, we're not doing so many symbol loads in the
> kernel ?

Yes we do, for many local symbols. It's the reason why the toolchain
has a -msym32 switch now.


Thiemo

Re: [PATCH]: Remove CONFIG_BUILD_ELF64 entirely

[Kumba]

Atsushi Nemoto wrote:
> I can not see why you handle IP22, IP32, Cobalt as so "special".
> There are many other platforms which supports 64-bit and uses CKSEG0
> load address (well, actually all 64-bit platforms except for IP27).

Mainly because, to the best of my knowledge, these are the only three systems 
where things get weird with ckseg0 and this specific Kconfig option.  Afaik with 
other systems, they don't need weird hacks like stuffing 64bit code into 32bit 
objects to work best (or at all).


> So I think Franck's approach, which enables -msym32 and defines
> KBUILD_64BIT_SYM32 automatically if load-y was CKSEG0, is better.  Are
> there any problem with his patchset?

I missed the other two additions to this patch, which is probably why it didn't 
work :)  Taken as a whole, they also boot my O2 now.


--Kumba

-- 
Gentoo/MIPS Team Lead

"Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere."  --Elrond

Re: [PATCH]: Remove CONFIG_BUILD_ELF64 entirely

[Atsushi Nemoto]

On Sun, 25 Mar 2007 12:59:32 -0400, Kumba <kumba@gentoo.org> wrote:
> > So I think Franck's approach, which enables -msym32 and defines
> > KBUILD_64BIT_SYM32 automatically if load-y was CKSEG0, is better.  Are
> > there any problem with his patchset?
> 
> I missed the other two additions to this patch, which is probably why it didn't 
> work :)  Taken as a whole, they also boot my O2 now.

Thanks, good news!

And Ralf's number shows that we can use -msym32 even for IP27.
Another good news.

---
Atsushi Nemoto

Re: [PATCH]: Remove CONFIG_BUILD_ELF64 entirely

[Kumba]

Atsushi Nemoto wrote:
> On Sun, 25 Mar 2007 12:59:32 -0400, Kumba <kumba@gentoo.org> wrote:
>>> So I think Franck's approach, which enables -msym32 and defines
>>> KBUILD_64BIT_SYM32 automatically if load-y was CKSEG0, is better.  Are
>>> there any problem with his patchset?
>> I missed the other two additions to this patch, which is probably why it didn't 
>> work :)  Taken as a whole, they also boot my O2 now.
> 
> Thanks, good news!
> 
> And Ralf's number shows that we can use -msym32 even for IP27.
> Another good news.

Actually, I just realized I didn't rehash my dhcpd, so it booted the wrong 
kernel.  A kernel built with this patchset won't boot without the following 
change in include/asm-mips/stackframe.h:

--- include/asm-mips/stackframe.h.orig	2007-03-25 14:22:04.000000000 -0400
+++ include/asm-mips/stackframe.h	2007-03-25 14:22:21.000000000 -0400
@@ -70,7 +70,7 @@
  #else
  		MFC0	k0, CP0_CONTEXT
  #endif
-#if defined(CONFIG_32BIT) || defined(KBUILD_64BIT_SYM32)
+#if defined(CONFIG_32BIT) || !defined(KBUILD_64BIT_SYM32)
  		lui	k1, %hi(kernelsp)
  #else
  		lui	k1, %highest(kernelsp)
@@ -95,7 +95,7 @@
  		.endm
  #else
  		.macro	get_saved_sp	/* Uniprocessor variation */
-#if defined(CONFIG_32BIT) || defined(KBUILD_64BIT_SYM32)
+#if defined(CONFIG_32BIT) || !defined(KBUILD_64BIT_SYM32)
  		lui	k1, %hi(kernelsp)
  #else
  		lui	k1, %highest(kernelsp)




You'll just get a silent hang after ARCS jumps into the kernel.  My guess is 
these systems need the extra asm commands.  Perhaps the use of CONFIG_32BIT is 
incorrect?

Maybe we should use the older form instead, with appropriate change?

--- include/asm-mips/stackframe.h.orig	2007-03-25 14:22:04.000000000 -0400
+++ include/asm-mips/stackframe.h.2	2007-03-25 14:30:01.000000000 -0400
@@ -70,14 +70,14 @@
  #else
  		MFC0	k0, CP0_CONTEXT
  #endif
-#if defined(CONFIG_32BIT) || defined(KBUILD_64BIT_SYM32)
-		lui	k1, %hi(kernelsp)
-#else
+#if defined(CONFIG_64BIT) || defined(KBUILD_64BIT_SYM32)
  		lui	k1, %highest(kernelsp)
  		daddiu	k1, %higher(kernelsp)
  		dsll	k1, 16
  		daddiu	k1, %hi(kernelsp)
  		dsll	k1, 16
+#else
+		lui	k1, %hi(kernelsp)
  #endif
  		LONG_SRL	k0, PTEBASE_SHIFT
  		LONG_ADDU	k1, k0
@@ -95,14 +95,14 @@
  		.endm
  #else
  		.macro	get_saved_sp	/* Uniprocessor variation */
-#if defined(CONFIG_32BIT) || defined(KBUILD_64BIT_SYM32)
-		lui	k1, %hi(kernelsp)
-#else
+#if defined(CONFIG_64BIT) || defined(KBUILD_64BIT_SYM32)
  		lui	k1, %highest(kernelsp)
  		daddiu	k1, %higher(kernelsp)
  		dsll	k1, k1, 16
  		daddiu	k1, %hi(kernelsp)
  		dsll	k1, k1, 16
+#else
+		lui	k1, %hi(kernelsp)
  #endif
  		LONG_L	k1, %lo(kernelsp)(k1)
  		.endm



--Kumba

-- 
Gentoo/MIPS Team Lead

"Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere."  --Elrond

Re: [PATCH]: Remove CONFIG_BUILD_ELF64 entirely

[Atsushi Nemoto]

On Sun, 25 Mar 2007 14:33:07 -0400, Kumba <kumba@gentoo.org> wrote:
> Actually, I just realized I didn't rehash my dhcpd, so it booted the wrong 
> kernel.  A kernel built with this patchset won't boot without the following 
> change in include/asm-mips/stackframe.h:
> 
> --- include/asm-mips/stackframe.h.orig	2007-03-25 14:22:04.000000000 -0400
> +++ include/asm-mips/stackframe.h	2007-03-25 14:22:21.000000000 -0400
> @@ -70,7 +70,7 @@
>   #else
>   		MFC0	k0, CP0_CONTEXT
>   #endif
> -#if defined(CONFIG_32BIT) || defined(KBUILD_64BIT_SYM32)
> +#if defined(CONFIG_32BIT) || !defined(KBUILD_64BIT_SYM32)
>   		lui	k1, %hi(kernelsp)
>   #else

It looks very strange.  "lui k1, %hi(kernelsp)" should be enough for
the -msym32 kernel.  What is a version of binutils and gcc you are using?

And could you show me disassembled list of handle_int (or some other
rountines using get_saved_sp) of failed kernel?

If you were using gcc 3.x, does this fix work for you?

#if defined(CONFIG_32BIT) || (defined(KBUILD_64BIT_SYM32) &&  __GNUC__ >= 4)
  		lui	k1, %hi(kernelsp)
#else
...


---
Atsushi Nemoto

Re: [PATCH]: Remove CONFIG_BUILD_ELF64 entirely

[Kumba]

[-- Attachment #1: Type: text/plain, Size: 1072 bytes --]

Atsushi Nemoto wrote:

> It looks very strange.  "lui k1, %hi(kernelsp)" should be enough for
> the -msym32 kernel.  What is a version of binutils and gcc you are using?
> 
> And could you show me disassembled list of handle_int (or some other
> rountines using get_saved_sp) of failed kernel?
> 
> If you were using gcc 3.x, does this fix work for you?
> 
> #if defined(CONFIG_32BIT) || (defined(KBUILD_64BIT_SYM32) &&  __GNUC__ >= 4)
>   		lui	k1, %hi(kernelsp)
> #else

# mips64-unknown-linux-gnu-ld --version
GNU ld version 2.16.1

# mips64-unknown-linux-gnu-gcc --version
mips64-unknown-linux-gnu-gcc (GCC) 4.1.1 (Gentoo 4.1.1-r3)

And the disassembly of vmlinux.32 for the handle_int function is attached.

I haven't built a kernel w/ gcc-3.x for some time, probably last time being when 
I was chasing down the strange funkiness in my Octane's userland in 2.6.19.



--Kumba

-- 
Gentoo/MIPS Team Lead

"Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere."  --Elrond

[-- Attachment #2: vmlnx-26204-dis-hi.txt --]
[-- Type: text/plain, Size: 2260 bytes --]

80006ac0 <handle_int>:
80006ac0:	401a6000 	mfc0	k0,$12
80006ac4:	001ad0c0 	sll	k0,k0,0x3
80006ac8:	07400007 	bltz	k0,80006ae8 <handle_int+0x28>
80006acc:	03a0d82d 	move	k1,sp
80006ad0:	3c1b0000 	lui	k1,0x0
80006ad4:	677b0000 	daddiu	k1,k1,0
80006ad8:	001bdc38 	dsll	k1,k1,0x10
80006adc:	677b8047 	daddiu	k1,k1,-32697
80006ae0:	001bdc38 	dsll	k1,k1,0x10
80006ae4:	df7b5008 	ld	k1,20488(k1)
80006ae8:	03a0d02d 	move	k0,sp
80006aec:	677dfed0 	daddiu	sp,k1,-304
80006af0:	ffba00e8 	sd	k0,232(sp)
80006af4:	ffa30018 	sd	v1,24(sp)
80006af8:	ffa00000 	sd	zero,0(sp)
80006afc:	40036000 	mfc0	v1,$12
80006b00:	ffa20010 	sd	v0,16(sp)
80006b04:	ffa30100 	sd	v1,256(sp)
80006b08:	ffa40020 	sd	a0,32(sp)
80006b0c:	40036800 	mfc0	v1,$13
80006b10:	ffa50028 	sd	a1,40(sp)
80006b14:	ffa30120 	sd	v1,288(sp)
80006b18:	ffa60030 	sd	a2,48(sp)
80006b1c:	40237000 	dmfc0	v1,$14
80006b20:	ffa70038 	sd	a3,56(sp)
80006b24:	ffa80040 	sd	t0,64(sp)
80006b28:	ffa90048 	sd	t1,72(sp)
80006b2c:	ffa30128 	sd	v1,296(sp)
80006b30:	ffb900c8 	sd	t9,200(sp)
80006b34:	ffbc00e0 	sd	gp,224(sp)
80006b38:	ffbf00f8 	sd	ra,248(sp)
80006b3c:	37bc3fff 	ori	gp,sp,0x3fff
80006b40:	3b9c3fff 	xori	gp,gp,0x3fff
80006b44:	ffa10008 	sd	at,8(sp)
80006b48:	00001810 	mfhi	v1
80006b4c:	ffa30108 	sd	v1,264(sp)
80006b50:	00001812 	mflo	v1
80006b54:	ffaa0050 	sd	t2,80(sp)
80006b58:	ffab0058 	sd	t3,88(sp)
80006b5c:	ffa30110 	sd	v1,272(sp)
80006b60:	ffac0060 	sd	t4,96(sp)
80006b64:	ffad0068 	sd	t5,104(sp)
80006b68:	ffae0070 	sd	t6,112(sp)
80006b6c:	ffaf0078 	sd	t7,120(sp)
80006b70:	ffb800c0 	sd	t8,192(sp)
80006b74:	ffb00080 	sd	s0,128(sp)
80006b78:	ffb10088 	sd	s1,136(sp)
80006b7c:	ffb20090 	sd	s2,144(sp)
80006b80:	ffb30098 	sd	s3,152(sp)
80006b84:	ffb400a0 	sd	s4,160(sp)
80006b88:	ffb500a8 	sd	s5,168(sp)
80006b8c:	ffb600b0 	sd	s6,176(sp)
80006b90:	ffb700b8 	sd	s7,184(sp)
80006b94:	ffbe00f0 	sd	s8,240(sp)
80006b98:	400c6000 	mfc0	t4,$12
80006b9c:	3c0d1000 	lui	t5,0x1000
80006ba0:	35ad001f 	ori	t5,t5,0x1f
80006ba4:	018d6025 	or	t4,t4,t5
80006ba8:	398c001f 	xori	t4,t4,0x1f
80006bac:	408c6000 	mtc0	t4,$12
	...
80006bbc:	df900058 	ld	s0,88(gp)
80006bc0:	ff9d0058 	sd	sp,88(gp)
80006bc4:	3c1f8000 	lui	ra,0x8000
80006bc8:	0800154e 	j	80005538 <plat_irq_dispatch>
80006bcc:	67ff68a0 	daddiu	ra,ra,26784

Re: [PATCH]: Remove CONFIG_BUILD_ELF64 entirely

[Atsushi Nemoto]

On Mon, 26 Mar 2007 09:48:13 -0400, Kumba <kumba@gentoo.org> wrote:
> # mips64-unknown-linux-gnu-ld --version
> GNU ld version 2.16.1
> 
> # mips64-unknown-linux-gnu-gcc --version
> mips64-unknown-linux-gnu-gcc (GCC) 4.1.1 (Gentoo 4.1.1-r3)
> 
> And the disassembly of vmlinux.32 for the handle_int function is attached.

Thanks.  Is this a disassembly of _failed_ kernel?

If so, it looks KBUILD_64BIT_SYM32 is not defined.  So strange...

And even if %highest, etc. were used, it should work for CKSEG0
kernel, while using only %hi should be just an optimization.  Another
strangeness.

> 80006ad0:	3c1b0000 	lui	k1,0x0
> 80006ad4:	677b0000 	daddiu	k1,k1,0
> 80006ad8:	001bdc38 	dsll	k1,k1,0x10
> 80006adc:	677b8047 	daddiu	k1,k1,-32697
> 80006ae0:	001bdc38 	dsll	k1,k1,0x10
> 80006ae4:	df7b5008 	ld	k1,20488(k1)

The address of kernelsp should be 0xffffffff80475008.  It seems
a regular value.

---
Atsushi Nemoto

Re: [PATCH]: Remove CONFIG_BUILD_ELF64 entirely

[Kumba]

[-- Attachment #1: Type: text/plain, Size: 1282 bytes --]

Atsushi Nemoto wrote:
> Thanks.  Is this a disassembly of _failed_ kernel?
> 
> If so, it looks KBUILD_64BIT_SYM32 is not defined.  So strange...
> 
> And even if %highest, etc. were used, it should work for CKSEG0
> kernel, while using only %hi should be just an optimization.  Another
> strangeness.
> 
>> 80006ad0:	3c1b0000 	lui	k1,0x0
>> 80006ad4:	677b0000 	daddiu	k1,k1,0
>> 80006ad8:	001bdc38 	dsll	k1,k1,0x10
>> 80006adc:	677b8047 	daddiu	k1,k1,-32697
>> 80006ae0:	001bdc38 	dsll	k1,k1,0x10
>> 80006ae4:	df7b5008 	ld	k1,20488(k1)
> 
> The address of kernelsp should be 0xffffffff80475008.  It seems
> a regular value.

Note to Self: Drink coffee before attempting to follow clearly-stated 
instructions on sending in disassembly of failed kernel.

Lets try this one; the kernel was built with gcc-4.1.2 and binutils-2.17 this 
time around, and I tested it before running objdump on it.  It just hangs right 
after loading:

 > bootp(): console=ttyS0,38400 root=/dev/md0
Setting $netaddr to 192.168.1.12 (from server )
Obtaining  from server
4358278+315290 entry: 0x80401000



--Kumba

-- 
Gentoo/MIPS Team Lead

"Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere."  --Elrond

[-- Attachment #2: vmlnx-26204-dis-hi.txt --]
[-- Type: text/plain, Size: 2116 bytes --]

80006ae0 <handle_int>:
80006ae0:	401a6000 	mfc0	k0,$12
80006ae4:	001ad0c0 	sll	k0,k0,0x3
80006ae8:	07400003 	bltz	k0,80006af8 <handle_int+0x18>
80006aec:	03a0d82d 	move	k1,sp
80006af0:	3c1b8048 	lui	k1,0x8048
80006af4:	df7b9008 	ld	k1,-28664(k1)
80006af8:	03a0d02d 	move	k0,sp
80006afc:	677dfed0 	daddiu	sp,k1,-304
80006b00:	ffba00e8 	sd	k0,232(sp)
80006b04:	ffa30018 	sd	v1,24(sp)
80006b08:	ffa00000 	sd	zero,0(sp)
80006b0c:	40036000 	mfc0	v1,$12
80006b10:	ffa20010 	sd	v0,16(sp)
80006b14:	ffa30100 	sd	v1,256(sp)
80006b18:	ffa40020 	sd	a0,32(sp)
80006b1c:	40036800 	mfc0	v1,$13
80006b20:	ffa50028 	sd	a1,40(sp)
80006b24:	ffa30120 	sd	v1,288(sp)
80006b28:	ffa60030 	sd	a2,48(sp)
80006b2c:	40237000 	dmfc0	v1,$14
80006b30:	ffa70038 	sd	a3,56(sp)
80006b34:	ffa80040 	sd	t0,64(sp)
80006b38:	ffa90048 	sd	t1,72(sp)
80006b3c:	ffa30128 	sd	v1,296(sp)
80006b40:	ffb900c8 	sd	t9,200(sp)
80006b44:	ffbc00e0 	sd	gp,224(sp)
80006b48:	ffbf00f8 	sd	ra,248(sp)
80006b4c:	37bc3fff 	ori	gp,sp,0x3fff
80006b50:	3b9c3fff 	xori	gp,gp,0x3fff
80006b54:	ffa10008 	sd	at,8(sp)
80006b58:	00001810 	mfhi	v1
80006b5c:	ffa30108 	sd	v1,264(sp)
80006b60:	00001812 	mflo	v1
80006b64:	ffaa0050 	sd	t2,80(sp)
80006b68:	ffab0058 	sd	t3,88(sp)
80006b6c:	ffa30110 	sd	v1,272(sp)
80006b70:	ffac0060 	sd	t4,96(sp)
80006b74:	ffad0068 	sd	t5,104(sp)
80006b78:	ffae0070 	sd	t6,112(sp)
80006b7c:	ffaf0078 	sd	t7,120(sp)
80006b80:	ffb800c0 	sd	t8,192(sp)
80006b84:	ffb00080 	sd	s0,128(sp)
80006b88:	ffb10088 	sd	s1,136(sp)
80006b8c:	ffb20090 	sd	s2,144(sp)
80006b90:	ffb30098 	sd	s3,152(sp)
80006b94:	ffb400a0 	sd	s4,160(sp)
80006b98:	ffb500a8 	sd	s5,168(sp)
80006b9c:	ffb600b0 	sd	s6,176(sp)
80006ba0:	ffb700b8 	sd	s7,184(sp)
80006ba4:	ffbe00f0 	sd	s8,240(sp)
80006ba8:	400c6000 	mfc0	t4,$12
80006bac:	3c0d1000 	lui	t5,0x1000
80006bb0:	35ad001f 	ori	t5,t5,0x1f
80006bb4:	018d6025 	or	t4,t4,t5
80006bb8:	398c001f 	xori	t4,t4,0x1f
80006bbc:	408c6000 	mtc0	t4,$12
	...
80006bcc:	df900058 	ld	s0,88(gp)
80006bd0:	ff9d0058 	sd	sp,88(gp)
80006bd4:	3c1f8000 	lui	ra,0x8000
80006bd8:	0800154e 	j	80005538 <plat_irq_dispatch>
80006bdc:	67ff68c0 	daddiu	ra,ra,26816

Re: [PATCH]: Remove CONFIG_BUILD_ELF64 entirely

[Atsushi Nemoto]

On Mon, 26 Mar 2007 20:51:28 -0400, Kumba <kumba@gentoo.org> wrote:
> Lets try this one; the kernel was built with gcc-4.1.2 and binutils-2.17 this 
> time around, and I tested it before running objdump on it.  It just hangs right 
> after loading:
> 
>  > bootp(): console=ttyS0,38400 root=/dev/md0
> Setting $netaddr to 192.168.1.12 (from server )
> Obtaining  from server
> 4358278+315290 entry: 0x80401000

Now I can not see any problem with the disassembled code.  No idea why
it does not work at all...

BTW, why IP32 does not support 32-bit kernel, though it has 32-bit
firmware?
---
Atsushi Nemoto

Re: [PATCH]: Remove CONFIG_BUILD_ELF64 entirely

[Ilya A. Volynets-Evenbakh]

Because we are too lazy to get HIGHMEM working in order to get
support for all of its memory. Not to mention that HIGHMEM is Evil(TM).

Atsushi Nemoto wrote:
> On Mon, 26 Mar 2007 20:51:28 -0400, Kumba <kumba@gentoo.org> wrote:
>   
>> Lets try this one; the kernel was built with gcc-4.1.2 and binutils-2.17 this 
>> time around, and I tested it before running objdump on it.  It just hangs right 
>> after loading:
>>
>>  > bootp(): console=ttyS0,38400 root=/dev/md0
>> Setting $netaddr to 192.168.1.12 (from server )
>> Obtaining  from server
>> 4358278+315290 entry: 0x80401000
>>     
>
> Now I can not see any problem with the disassembled code.  No idea why
> it does not work at all...
>
> BTW, why IP32 does not support 32-bit kernel, though it has 32-bit
> firmware?
> ---
> Atsushi Nemoto
>
>   

-- 
Ilya A. Volynets-Evenbakh
Total Knowledge. CTO
http://www.total-knowledge.com

Re: [PATCH]: Remove CONFIG_BUILD_ELF64 entirely

[Atsushi Nemoto]

On Tue, 27 Mar 2007 10:54:40 -0700, "Ilya A. Volynets-Evenbakh" <ilya@total-knowledge.com> wrote:
> Because we are too lazy to get HIGHMEM working in order to get
> support for all of its memory. Not to mention that HIGHMEM is Evil(TM).

Oh I see.  The 64-bit kernel should be a right thing.
---
Atsushi Nemoto

Re: [PATCH]: Remove CONFIG_BUILD_ELF64 entirely

[Thiemo Seufer]

Atsushi Nemoto wrote:
> On Mon, 26 Mar 2007 20:51:28 -0400, Kumba <kumba@gentoo.org> wrote:
> > Lets try this one; the kernel was built with gcc-4.1.2 and binutils-2.17 this 
> > time around, and I tested it before running objdump on it.  It just hangs right 
> > after loading:
> > 
> >  > bootp(): console=ttyS0,38400 root=/dev/md0
> > Setting $netaddr to 192.168.1.12 (from server )
> > Obtaining  from server
> > 4358278+315290 entry: 0x80401000
> 
> Now I can not see any problem with the disassembled code.  No idea why
> it does not work at all...
> 
> BTW, why IP32 does not support 32-bit kernel, though it has 32-bit
> firmware?

It wants to do 64bit register accesses, and supports more memory than
KSEG0 can hold. The resulting 32bit kernel was ugly enough to kill it
and replace it with a 64bit one.


Thiemo

Re: [PATCH]: Remove CONFIG_BUILD_ELF64 entirely

[Kumba]

Atsushi Nemoto wrote:
> On Mon, 26 Mar 2007 20:51:28 -0400, Kumba <kumba@gentoo.org> wrote:
>> Lets try this one; the kernel was built with gcc-4.1.2 and binutils-2.17 this 
>> time around, and I tested it before running objdump on it.  It just hangs right 
>> after loading:
>>
>>  > bootp(): console=ttyS0,38400 root=/dev/md0
>> Setting $netaddr to 192.168.1.12 (from server )
>> Obtaining  from server
>> 4358278+315290 entry: 0x80401000
> 
> Now I can not see any problem with the disassembled code.  No idea why
> it does not work at all...
> 
> BTW, why IP32 does not support 32-bit kernel, though it has 32-bit
> firmware?

Well, what's the need to use the move/lui/ld sequence over 
move/lui/daddui/dsll/daddui/dsll//ld anyways?  I'll have to warm the Indy up and 
try a 64bit kernel there I guess, to see if it exhibits similar issues with this 
segment of code.


--Kumba

-- 
Gentoo/MIPS Team Lead

"Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere."  --Elrond

Re: [PATCH]: Remove CONFIG_BUILD_ELF64 entirely

[Atsushi Nemoto]

On Wed, 28 Mar 2007 09:26:05 -0400, Kumba <kumba@gentoo.org> wrote:
> Well, what's the need to use the move/lui/ld sequence over 
> move/lui/daddui/dsll/daddui/dsll//ld anyways?  I'll have to warm the Indy up and 
> try a 64bit kernel there I guess, to see if it exhibits similar issues with this 
> segment of code.

Just an optimization.  For CKSEG0 symbol, a LUI instruction can fill
high 32-bit by sign-extention.  Either code should work for CKSEG0
kernel.

---
Atsushi Nemoto

Re: [PATCH]: Remove CONFIG_BUILD_ELF64 entirely

[Kumba]

Atsushi Nemoto wrote:
> Just an optimization.  For CKSEG0 symbol, a LUI instruction can fill
> high 32-bit by sign-extention.  Either code should work for CKSEG0
> kernel.

Hmm, strange then.  It's gotta be something those four extra commands do that 
IP32 likes.  IP22 boots fine with either form, though that has a separate 
problem where it looks like serial console on the zilog chip panics the system 
after booting into a netboot.

Doing some tests, I found out that by commenting out one or more of the 
daddui/dsll instructions for IP32 produced a kernel that still booted, but hung 
at running init/freeing kernel memory.  Using the single lui booted once, but I 
suspect that was my fault on not doing something proper, cause the next time 
around, it didn't boot at all.  I tested this all on a real console, versus 
serial, case there was an early panic or something.  But I see nothing to 
indicate why IP32 dislikes the lui->ld sequence versus the 
lui->daddui->dsll->etc->ld sequence.

There's no early printk on these systems either, so doing low-level debugging is 
difficult on them as well.


--Kumba

-- 
Gentoo/MIPS Team Lead

"Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere."  --Elrond

Re: [PATCH]: Remove CONFIG_BUILD_ELF64 entirely

[Atsushi Nemoto]

On Wed, 28 Mar 2007 21:50:28 -0400, Kumba <kumba@gentoo.org> wrote:
> Doing some tests, I found out that by commenting out one or more of the 
> daddui/dsll instructions for IP32 produced a kernel that still booted, but hung 
> at running init/freeing kernel memory.  Using the single lui booted once, but I 
> suspect that was my fault on not doing something proper, cause the next time 
> around, it didn't boot at all.  I tested this all on a real console, versus 
> serial, case there was an early panic or something.  But I see nothing to 
> indicate why IP32 dislikes the lui->ld sequence versus the 
> lui->daddui->dsll->etc->ld sequence.

Hmm... really strange.

This is OK:
		lui	k1, %highest(kernelsp)
		daddiu	k1, %higher(kernelsp)
		dsll	k1, k1, 16
		daddiu	k1, %hi(kernelsp)
		dsll	k1, k1, 16

This is NG:
		lui	k1, %hi(kernelsp)

So, could you try this one?

		nop
		nop
		nop
		nop
		lui	k1, %hi(kernelsp)

If it booted, the problem should be in something irrelevant place.
I.e. this optimization just triggers other bug by code/data movement.

---
Atsushi Nemoto

Re: [PATCH]: Remove CONFIG_BUILD_ELF64 entirely

[Kumba]

Atsushi Nemoto wrote:
> Hmm... really strange.
> 
> This is OK:
> 		lui	k1, %highest(kernelsp)
> 		daddiu	k1, %higher(kernelsp)
> 		dsll	k1, k1, 16
> 		daddiu	k1, %hi(kernelsp)
> 		dsll	k1, k1, 16
> 
> This is NG:
> 		lui	k1, %hi(kernelsp)
> 
> So, could you try this one?
> 
> 		nop
> 		nop
> 		nop
> 		nop
> 		lui	k1, %hi(kernelsp)
> 
> If it booted, the problem should be in something irrelevant place.
> I.e. this optimization just triggers other bug by code/data movement.

Yup, it booted.  On further testing at iluxa's behest, it turns out it may be 
some quirk/cpu errata related to the RM5200 I use in my O2.  I swapped it out 
for a plain R5000 @ 200MHz, and removed the nop's -- boots fine.

This may also explain why the cobalt's were hitting something odd.  They also 
use a member of the RM52xx family (RM5231 iirc, O2 uses an RM5261).


--Kumba

-- 
Gentoo/MIPS Team Lead

"Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere."  --Elrond

Re: [PATCH]: Remove CONFIG_BUILD_ELF64 entirely

[Kumba]

Atsushi Nemoto wrote:
> On Wed, 28 Mar 2007 09:26:05 -0400, Kumba <kumba@gentoo.org> wrote:
>> Well, what's the need to use the move/lui/ld sequence over 
>> move/lui/daddui/dsll/daddui/dsll//ld anyways?  I'll have to warm the Indy up and 
>> try a 64bit kernel there I guess, to see if it exhibits similar issues with this 
>> segment of code.
> 
> Just an optimization.  For CKSEG0 symbol, a LUI instruction can fill
> high 32-bit by sign-extention.  Either code should work for CKSEG0
> kernel.

Well, thinking about it some more, can this stackframe change be segmented out 
of Frank's main patches, so we can get them into git, and spend time in 
2.6.21/2.6.22/2.6.23 chasing down what exactly is up with this specific asm 
sequence?

Of course, wiring in a quick check on !defined(CONFIG_SGI_IP32) would also work, 
but that's not proper to go kludging in specific machine checks in a generic 
file like stackframe, IMHO.


--Kumba

-- 
Gentoo/MIPS Team Lead

"Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere."  --Elrond

IP32 prom crashes due to __pa() funkiness

[Kumba]

Initially, booting a straight git checkout on an IP32 will cause it to prom 
crash, usually somewhere in between init_bootmem() and init_bootmem_core().  I 
bisected git to trace this back to one of the inital __pa() introduction patches 
from commit d4df6d4 (get ride of CPHYSADDR()).  It actually appears that the 
actual commit that broke things was 620a480 (Make __pa() aware of XKPHYS/CKSEG0 
address mix for 64 bit kernels).

The [short-term] fix highlighted by Ilya is to make __pa() unconditionally be 
defined to "((unsigned long)(x) < CKSEG0 ? PAGE_OFFSET : CKSEG0)"; Discovered by 
building IP32 with CONFIG_BUILD_ELF64=n.

Normally, this shouldn't be possible, as CONFIG_BUILD_ELF64=n was originally 
only allowed by using the old o64 hack, which has subsequently died and been 
replaced with the newer -msym32 form.  As far as I know, CONFIG_BUILD_ELF64 is 
apparently supposed to be removed at some point in the future, since I believe 
it existed only for quirky 64bit-in-32bit kernels for IP22 and more commonly, 
IP32.  From 2.6.17 onwards, I've been building IP32 kernels with 
CONFIG_BUILD_ELF64=y and using gcc-4, and haven't had problems up until now.

Anyways, I'm not sure if this is an IP32-specific oddity or not (probably is), 
but it needs the define highlighted above to work properly.  Plain PAGE_OFFSET 
won't work for these machines.  Given the same trick os -msym32 is used for the 
rare IP22 64bit kernel, I would not be surprised if the same problem and fix 
both occur and work for those machines as well.  Something to maybe test later, 
I suppose.

But for now, anyone got thoughts as to a sane workaround for this?  Perhaps some 
conditional tweaks in mach-ip32/*.h files somewheres, would it be simpler to 
just switch to:

#if defined(CONFIG_64BIT) && (!defined(CONFIG_BUILD_ELF64) || 
defined(CONFIG_SGI_IP32))

(assuming that IP22 doesn't need it; I'll find out later)



--Kumba

-- 
Gentoo/MIPS Team Lead

"Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere."  --Elrond

Re: IP32 prom crashes due to __pa() funkiness

[Kumba]

Kumba wrote:
> 
> Initially, booting a straight git checkout on an IP32 will cause it to 
> prom crash, usually somewhere in between init_bootmem() and 
> init_bootmem_core().  I bisected git to trace this back to one of the 
> inital __pa() introduction patches from commit d4df6d4 (get ride of 
> CPHYSADDR()).  It actually appears that the actual commit that broke 
> things was 620a480 (Make __pa() aware of XKPHYS/CKSEG0 address mix for 
> 64 bit kernels).
> 
> The [short-term] fix highlighted by Ilya is to make __pa() 
> unconditionally be defined to "((unsigned long)(x) < CKSEG0 ? 
> PAGE_OFFSET : CKSEG0)"; Discovered by building IP32 with 
> CONFIG_BUILD_ELF64=n.
> 
> Normally, this shouldn't be possible, as CONFIG_BUILD_ELF64=n was 
> originally only allowed by using the old o64 hack, which has 
> subsequently died and been replaced with the newer -msym32 form.  As far 
> as I know, CONFIG_BUILD_ELF64 is apparently supposed to be removed at 
> some point in the future, since I believe it existed only for quirky 
> 64bit-in-32bit kernels for IP22 and more commonly, IP32.  From 2.6.17 
> onwards, I've been building IP32 kernels with CONFIG_BUILD_ELF64=y and 
> using gcc-4, and haven't had problems up until now.
> 
> Anyways, I'm not sure if this is an IP32-specific oddity or not 
> (probably is), but it needs the define highlighted above to work 
> properly.  Plain PAGE_OFFSET won't work for these machines.  Given the 
> same trick os -msym32 is used for the rare IP22 64bit kernel, I would 
> not be surprised if the same problem and fix both occur and work for 
> those machines as well.  Something to maybe test later, I suppose.
> 
> But for now, anyone got thoughts as to a sane workaround for this?  
> Perhaps some conditional tweaks in mach-ip32/*.h files somewheres, would 
> it be simpler to just switch to:
> 
> #if defined(CONFIG_64BIT) && (!defined(CONFIG_BUILD_ELF64) || 
> defined(CONFIG_SGI_IP32))
> 
> (assuming that IP22 doesn't need it; I'll find out later)

"Re-verify range to target, One ping only."


So, anyone got thoughts on this?

I've actually built and booted an SGI IP32 kernel using this logic in 
include/asm-mips/page.h, Line 135:

#if defined(CONFIG_64BIT) && (!defined(CONFIG_BUILD_ELF64) || 
(defined(CONFIG_SGI_IP32) || defined(CONFIG_SGI_IP22)))



--Kumba

-- 
Gentoo/MIPS Team Lead

"Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere."  --Elrond

Re: IP32 prom crashes due to __pa() funkiness

[Franck Bui-Huu]

Hi,

Kumba wrote:
>
> Initially, booting a straight git checkout on an IP32 will cause it to
> prom crash, usually somewhere in between init_bootmem() and
> init_bootmem_core().  I bisected git to trace this back to one of the
> inital __pa() introduction patches from commit d4df6d4 (get ride of
> CPHYSADDR()).  It actually appears that the actual commit that broke
> things was 620a480 (Make __pa() aware of XKPHYS/CKSEG0 address mix for
> 64 bit kernels).
>
> The [short-term] fix highlighted by Ilya is to make __pa()
> unconditionally be defined to "((unsigned long)(x) < CKSEG0 ?
> PAGE_OFFSET : CKSEG0)"; Discovered by building IP32 with
> CONFIG_BUILD_ELF64=n.
>

Well, it means that you previously used CONFIG_BUILD_ELF64=y (this
implied that PAGE_OFFSET is in XKPHYS) whereas your kernel has CKSEG
load address (symbols need PAGE_OFFSET in CKSEG for address
translation).

So the question is why can't you use CONFIG_BUILD_ELF64=n (and
reagarding the current definition of CONFIG_BUILD_ELF64).

> Normally, this shouldn't be possible, as CONFIG_BUILD_ELF64=n was
> originally only allowed by using the old o64 hack, which has
> subsequently died and been replaced with the newer -msym32 form.  As far
> as I know, CONFIG_BUILD_ELF64 is apparently supposed to be removed at
> some point in the future, since I believe it existed only for quirky

It makes me think that I posted a patch for that a couple of weeks ago:

http://marc.theaimsgroup.com/?l=linux-mips&m=117154480225936&w=2
http://marc.theaimsgroup.com/?l=linux-mips&m=117154480126802&w=2
http://marc.theaimsgroup.com/?l=linux-mips&m=117154587014827&w=2

Basically this patch removes CONFIG_BUILD_ELF64 and makes Kbuild to use
'-msym32' switch if you really need it. Kbuild makes its choice according
the load address of your kernel image.

Could you give it a try ? This patch was based on 2.6.20 but it should
apply fine on a 2.6.21-rc[12].
-- 
               Franck

[PATCH], Re: IP32 prom crashes due to __pa() funkiness

[peter fuerst]

Hi !

Watching the discussion about __pa(), CPHYSADDR and related stuff, with about
a hundred e-mails last October, and rising again several times recently (see
below), i wonder why we must cling so firmly to the "x - page_offset"
algorithm, the least capable one. AFAIK this method is taken over unaltered
from the i386 arch (yes, i know, the majority of archs did this), where we
have a situation quite different from MIPS:
A (preferably simple) mapping must be invented for kernel-memory with some,
more or less deliberately chosen, "page-offset". There exist no addresses
beside this mapping, no hardware "kernel-mappings" with (un)cached regions,
cached-attributes, unmapped spaces, etc. and "x - page_offset" is necessary
and sufficient to handle all addresses.

On the MIPS-side there isn't really something like "the" page-offset, and
the processor architecture already defines kernel spaces with respective
address-syntax. In other words, the definitions in asm-mips/addrspace.h
properly describe the virtual/physical conversions and masking, not some
subtracting, is the natural way to go.

Since __pa() and virt_to_phys() are currently "under construction" anyway,
i think it's time to submit robust versions (with kernel_physaddr() stolen
from the IP30 patch) for both, that handle any pitfall in one place and may
be used without pain throughout the kernel. I don't know, which one to prefer,
29 drivers are using __pa(), 60 are using virt_to_phys(), the uses in
arch/mips files are about equal.

Having a robust __pa()/virt_to_phys() avoids the need for local fixes, like
in sgiwd93.c and sgiseeq.c, which have to cope with at least one uncached
(usu. 0x9000...) address-type and at least one cached type (usu. 0xa800...)
in xkphys, and where virt_to_phys() blew up nicely. In some situation there
may be need to handle a ckseg0/1 address additionaly.


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

> Date: Thu, 1 Mar 2007 10:39:08 +0100
> From: Franck Bui-Huu <vagabon.xyz@gmail.com>
> To: Kumba <kumba@gentoo.org>
> Cc: Linux MIPS List <linux-mips@linux-mips.org>
> Subject: Re: IP32 prom crashes due to __pa() funkiness
>
> Hi,
>
> Kumba wrote:
> >
> > Initially, booting a straight git checkout on an IP32 will cause it to
> > prom crash, usually somewhere in between init_bootmem() and
> > init_bootmem_core().  I bisected git to trace this back to one of the
> > inital __pa() introduction patches from commit d4df6d4 (get ride of
> > CPHYSADDR()).  It actually appears that the actual commit that broke
> > things was 620a480 (Make __pa() aware of XKPHYS/CKSEG0 address mix for
> > 64 bit kernels).
> >
> > The [short-term] fix highlighted by Ilya is to make __pa()
> > unconditionally be defined to "((unsigned long)(x) < CKSEG0 ?
> > PAGE_OFFSET : CKSEG0)"; Discovered by building IP32 with
> > CONFIG_BUILD_ELF64=n.
> >
>
> Well, it means that you previously used CONFIG_BUILD_ELF64=y (this
> implied that PAGE_OFFSET is in XKPHYS) whereas your kernel has CKSEG
> load address (symbols need PAGE_OFFSET in CKSEG for address
> translation).
>
> ...



Signed-off-by: peter fuerst <post@pfrst.de>

========================================================================
--- c6275088cf65aaa1826e426e9e683b6c3e1f371c/include/asm-mips/addrspace.h	Sat Mar 10 08:38:53 2007
+++ kernelphysaddr-version/include/asm-mips/addrspace.h	Sat Mar 10 08:38:53 2007
@@ -54,6 +54,17 @@
 #define XPHYSADDR(a)            ((_ACAST64_(a)) &			\
 				 _CONST64_(0x000000ffffffffff))

+static inline unsigned long kernel_physaddr(unsigned long kva)
+{
+#ifdef CONFIG_64BIT
+	if((kva & 0xffffffff80000000UL) == 0xffffffff80000000UL)
+		return CPHYSADDR(kva);
+	return XPHYSADDR(kva);
+#else
+	return CPHYSADDR(kva);
+#endif
+}
+
 #ifdef CONFIG_64BIT

 /*
--- 92ec2618560c984355e653d33d5dc935e5e1488c/include/asm-mips/io.h	Sat Mar 10 08:41:06 2007
+++ kernelphysaddr-version/include/asm-mips/io.h	Sat Mar 10 08:41:06 2007
@@ -116,7 +116,7 @@ static inline void set_io_port_base(unsi
  */
 static inline unsigned long virt_to_phys(volatile const void *address)
 {
-	return (unsigned long)address - PAGE_OFFSET + PHYS_OFFSET;
+	return kernel_physaddr((unsigned long)address);
 }

 /*
--- d3fbd83ff545e49e2a0a5ca0f00dda4eedaf8be7/include/asm-mips/page.h	Sat Mar 10 08:43:17 2007
+++ kernelphysaddr-version/include/asm-mips/page.h	Sat Mar 10 08:43:17 2007
@@ -154,7 +154,7 @@ typedef struct { unsigned long pgprot; }
 #else
 #define __pa_page_offset(x)	PAGE_OFFSET
 #endif
-#define __pa(x)		((unsigned long)(x) - __pa_page_offset(x) + PHYS_OFFSET)
+#define __pa(x)		kernel_physaddr((unsigned long)(x))
 #define __va(x)		((void *)((unsigned long)(x) + PAGE_OFFSET - PHYS_OFFSET))
 #define __pa_symbol(x)	__pa(RELOC_HIDE((unsigned long)(x),0))
========================================================================

Re: IP32 prom crashes due to __pa() funkiness

[Kumba]

(whoops, reply didn't send to the ML, sorry Frank!)


Franck Bui-Huu wrote:
 > Hi,
 >
[snip]
 >
 > Well, it means that you previously used CONFIG_BUILD_ELF64=y (this
 > implied that PAGE_OFFSET is in XKPHYS) whereas your kernel has CKSEG
 > load address (symbols need PAGE_OFFSET in CKSEG for address
 > translation).
 >
 > So the question is why can't you use CONFIG_BUILD_ELF64=n (and
 > reagarding the current definition of CONFIG_BUILD_ELF64).
 >
[snip]
 >
 > It makes me think that I posted a patch for that a couple of weeks ago:
 >
 > http://marc.theaimsgroup.com/?l=linux-mips&m=117154480225936&w=2
 > http://marc.theaimsgroup.com/?l=linux-mips&m=117154480126802&w=2
 > http://marc.theaimsgroup.com/?l=linux-mips&m=117154587014827&w=2
 >
 > Basically this patch removes CONFIG_BUILD_ELF64 and makes Kbuild to use
 > '-msym32' switch if you really need it. Kbuild makes its choice according
 > the load address of your kernel image.
 >
 > Could you give it a try ? This patch was based on 2.6.20 but it should
 > apply fine on a 2.6.21-rc[12].

Tested, and it still failed.

And I didn't always use CONFIG_BUILD_ELF64.  In fact, for the longest time (up 
until 2.6.17) I built IP32 and 64bit IP22 kernels without CONFIG_BUILD_eLF64, 
passing -mabi=o64 (a.k.a., the binutils hack).  This let me use the plain 
'vmlinux' target w/o the need for an objcopy to boot these systems.  After 
2.6.17, the nature of o64 was mostly neutered, so I switched to using 
CONFIG_BUILD_ELF64 and the 'vmlinux.32' target, as this is apparently the way 
Debian builds their IP32 kernels (and was the way geoman/spbecker said I 
should've been using all along).

So with the changes brought in by __pa(), I suppose a new, RightWay(TM) to build 
IP32 (and conversely, 64bit IP22) kernels needs to be found.  These two systems 
are particularly wacky, hence why they need a bit more special care than more 
traditional, proper, 64bit systems like Origin and Octane.

Also, Peter raises a good point in this case.  It sounds like a re-thinking of 
how all this address stuff is handled will fix not only special cases like 
IP32/IP22, but the really weird systems, like IP28, as well.  Which would be a 
big plus in my opinion.


--Kumba

-- 
Gentoo/MIPS Team Lead

"Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere."  --Elrond

Re: IP32 prom crashes due to __pa() funkiness

[Arnaud Giersch]

Samedi 17 mars 2007, vers 20:52:16 (+0100), Kumba a écrit:

> So with the changes brought in by __pa(), I suppose a new,
> RightWay(TM) to build IP32 (and conversely, 64bit IP22) kernels needs
> to be found.

I don't know if it is the RightWay(TM), but I am running here a fresh
IP32 kernel (l.m.o git updated yesterday).  It was compiled with
CONFIG_BUILD_ELF64=n, and I am using vmlinux.

$ file /boot/vmlinux-2.6.21-rc3-g839fd555 
/boot/vmlinux-2.6.21-rc3-g839fd555: ELF 64-bit MSB executable, MIPS, MIPS-IV version 1 (SYSV), statically linked, not stripped

If it makes a difference, I am using arcboot.

        Arnaud

Re: IP32 prom crashes due to __pa() funkiness

[Kumba]

Arnaud Giersch wrote:
> 
> I don't know if it is the RightWay(TM), but I am running here a fresh
> IP32 kernel (l.m.o git updated yesterday).  It was compiled with
> CONFIG_BUILD_ELF64=n, and I am using vmlinux.
> 
> $ file /boot/vmlinux-2.6.21-rc3-g839fd555 
> /boot/vmlinux-2.6.21-rc3-g839fd555: ELF 64-bit MSB executable, MIPS, MIPS-IV version 1 (SYSV), statically linked, not stripped
> 
> If it makes a difference, I am using arcboot.

I suppose then the question is, which is better for IP32?  CONFIG_BUILD_ELF64=y 
or CONFIG_BUILD_ELF64=n.  The reason the o64 hack used to exist, if my memory 
serves me correctly, was that someone once said that when built and run as a 
pure 64bit binary converted to 32bit via objcopy, 6 extra insns were run every 
cycle (I think), introducing unneeded slowdown.  This changed to 2 insns by 
going the o64 route, which involved CONFIG_BUILD_ELF64=n.  So 4 less insns 
technically resulted in a quicker kernel, though the layman might not notice 
such.  I believe that all changed at some point, which is why 
CONFIG_BUILD_ELF64=y was an A-OK thing prior to the __pa() introduction.

Now I guess we're back to CONFIG_BUILD_ELF64=n?  I guess the real question is, 
which way is the OneWay(TM), RightWay(TM) and OnlyWay(TM)?


Cheers,

--Kumba

-- 
Gentoo/MIPS Team Lead

"Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere."  --Elrond

Re: IP32 prom crashes due to __pa() funkiness

[Franck Bui-Huu]

Kumba wrote:
> Arnaud Giersch wrote:
>>
>> I don't know if it is the RightWay(TM), but I am running here a fresh
>> IP32 kernel (l.m.o git updated yesterday).  It was compiled with
>> CONFIG_BUILD_ELF64=n, and I am using vmlinux.
>>
>> $ file /boot/vmlinux-2.6.21-rc3-g839fd555
>> /boot/vmlinux-2.6.21-rc3-g839fd555: ELF 64-bit MSB executable, MIPS,
>> MIPS-IV version 1 (SYSV), statically linked, not stripped
>>
>> If it makes a difference, I am using arcboot.
> 
> I suppose then the question is, which is better for IP32? 

That's the question I was wondering during my first reply to your initial
post...

> CONFIG_BUILD_ELF64=y or CONFIG_BUILD_ELF64=n.  The reason the o64 hack
> used to exist, if my memory serves me correctly, was that someone once
> said that when built and run as a pure 64bit binary converted to 32bit
> via objcopy, 6 extra insns were run every cycle (I think), introducing
> unneeded slowdown.  This changed to 2 insns by going the o64 route,

OK that's the reason why the last patch you applied has no effect. If
you're using 'objcopy' your kernel can still be miss configured.

BTW, does your gcc support '-sym32' switch ?

> which involved CONFIG_BUILD_ELF64=n.  So 4 less insns technically
> resulted in a quicker kernel, though the layman might not notice such. 
> I believe that all changed at some point, which is why
> CONFIG_BUILD_ELF64=y was an A-OK thing prior to the __pa() introduction.
> 

My current feeling is that __pa() introduction now breaks configs
which were initialy _broken_, IMHO. CPHYSADDR() hide them because it
can happily convert any virutal address form both CKSEG0 or XKPHYS.

It may be a good thing to crash at this point. CONFIG_BUILD_ELF64 is
used in some others places, where it can introduce some others bugs
harder to find (if miss configured of course). The sad thing is that
the kernel does not report any useful messages. That's why I think
adding some specific sanity checks for 64 bit kernels in boot mem init
code may be usefull.

> Now I guess we're back to CONFIG_BUILD_ELF64=n?  I guess the real
> question is, which way is the OneWay(TM), RightWay(TM) and OnlyWay(TM)?
> 

Now it's clear that CONFIG_BUILD_ELF64 is really confusing. I would say
that whatever the value of CONFIG_BUILD_ELF64, your kernel should run
fine. BUT it really depends on your kernel load address:

if CONFIG_BUILD_ELF64=y then kernel load address must be in XKPHYS
if CONFIG_BUILD_ELF64=n then kernel load address must be in CKSEG0

All others configs (I think) are buggy...

That's said, it seems that IPxx kernels are really special
beasts. Take from MIPS makefile:

"""
Some machines like the Indy need 32-bit ELF binaries for booting
purposes.
"""

So I dunno if this statement is still correct but it sounds that you
have no other choice thatn CONFIG_BUILD_ELF64=n and load address in
CKSEG0.

I'm sorry but my IPxx background is 0 ;)

 		Franck

Re: IP32 prom crashes due to __pa() funkiness

[Thiemo Seufer]

Franck Bui-Huu wrote:
[snip]
> > Now I guess we're back to CONFIG_BUILD_ELF64=n?  I guess the real
> > question is, which way is the OneWay(TM), RightWay(TM) and OnlyWay(TM)?
> 
> Now it's clear that CONFIG_BUILD_ELF64 is really confusing. I would say
> that whatever the value of CONFIG_BUILD_ELF64, your kernel should run
> fine. BUT it really depends on your kernel load address:
> 
> if CONFIG_BUILD_ELF64=y then kernel load address must be in XKPHYS
> if CONFIG_BUILD_ELF64=n then kernel load address must be in CKSEG0
> 
> All others configs (I think) are buggy...

Why? A ELF64 kernel for CKSEG0 should be fine, at least in principle,
even if it doesn't work wih the current codebase.

> That's said, it seems that IPxx kernels are really special
> beasts. Take from MIPS makefile:
> 
> """
> Some machines like the Indy need 32-bit ELF binaries for booting
> purposes.
> """

This is true for netbooting via firmware. For booting from disk the
bootloaders support AFAIR ELF64-for-CKSEG0.


Thiemo

Re: IP32 prom crashes due to __pa() funkiness

[Franck Bui-Huu]

On 3/19/07, Thiemo Seufer <ths@networkno.de> wrote:
>
> Why? A ELF64 kernel for CKSEG0 should be fine, at least in principle,
> even if it doesn't work wih the current codebase.
>

Yes you're right. I just replied to my self to say that.

Thanks
-- 
               Franck

Re: IP32 prom crashes due to __pa() funkiness

[Franck Bui-Huu]

On 3/19/07, Franck Bui-Huu <vagabon.xyz@gmail.com> wrote:
> Now it's clear that CONFIG_BUILD_ELF64 is really confusing. I would say
> that whatever the value of CONFIG_BUILD_ELF64, your kernel should run
> fine. BUT it really depends on your kernel load address:
>
> if CONFIG_BUILD_ELF64=y then kernel load address must be in XKPHYS
> if CONFIG_BUILD_ELF64=n then kernel load address must be in CKSEG0

to be more accurate, the following other config:

        CONFIG_BUILD_ELF64=y and kernel load address in CKSEG0

should theoretically work but currently doesn't because of __pa() introduction.

This config should not be used because it's normally not interesting
for normal user. It's only interesting for testing purpose if I recall
correctly. And the patch that automatically set CONFIG_BUILD_ELF64
should fix this.

BTW, you should take a look at:

http://marc.info/?l=linux-mips&m=117019833420946&w=2

this thread clearly state that current config of IP32 kernel is
broken. Sorry for remembering so lately...
-- 
               Franck

Re: IP32 prom crashes due to __pa() funkiness

[Kumba]

Franck Bui-Huu wrote:

> OK that's the reason why the last patch you applied has no effect. If
> you're using 'objcopy' your kernel can still be miss configured.
> 
> BTW, does your gcc support '-sym32' switch ?

I'll have to re-try some runs w/ the straight 64bit vmlinux later on then, but 
AFAICT, __pa() braks IP32 because of the assumption I highlighted.  This, 
cobalt, and IP22 are a bit "special" in their needs, I guess.  Anyone got a 
short yellow bus?


> My current feeling is that __pa() introduction now breaks configs
> which were initialy _broken_, IMHO. CPHYSADDR() hide them because it
> can happily convert any virutal address form both CKSEG0 or XKPHYS.
> 
> It may be a good thing to crash at this point. CONFIG_BUILD_ELF64 is
> used in some others places, where it can introduce some others bugs
> harder to find (if miss configured of course). The sad thing is that
> the kernel does not report any useful messages. That's why I think
> adding some specific sanity checks for 64 bit kernels in boot mem init
> code may be usefull.

A good idea to crash at this point?  Not for users.  Up until this point, I've 
never really seen any bugs produced by CONFIG_BUILD_ELF64, granted I avoided 
using it until ~2.6.17 (when o64 died).  If there were bugs, they were subtle 
and didn't appear to affect the day-to-day running of the system.  At minimum, 
__pa() should recreate this effect, and then we can trace down the bugs and 
hammer them to death later.


> Now it's clear that CONFIG_BUILD_ELF64 is really confusing. I would say
> that whatever the value of CONFIG_BUILD_ELF64, your kernel should run
> fine. BUT it really depends on your kernel load address:
> 
> if CONFIG_BUILD_ELF64=y then kernel load address must be in XKPHYS
> if CONFIG_BUILD_ELF64=n then kernel load address must be in CKSEG0
> 
> All others configs (I think) are buggy...
> 
> That's said, it seems that IPxx kernels are really special
> beasts. Take from MIPS makefile:
> 
> """
> Some machines like the Indy need 32-bit ELF binaries for booting
> purposes.
> """
> 
> So I dunno if this statement is still correct but it sounds that you
> have no other choice thatn CONFIG_BUILD_ELF64=n and load address in
> CKSEG0.


Most of this is because IP22 (Indy/Idigo2 R4xx) and IP32 (O2 R5xxx), while 
supporting 64bit kernels (same for cobalt, since it's a mips4-level CPU), we had 
to "trick" them into accepting 64bit code.  IP32 at one point ran 32bit kernels 
only, but it was later converted to supporting only 64bit kernels, hence the 
hackery involved.  We describe it as wrapping 64bit code into a 32bit object, 
because their proms will only recognize 32bit objects (specifically, IP22 will 
only boot 32bit objects; crash on 64bit; IP32 will take both, but likes 32bit 
better).

So really, CONFIG_BUILD_ELF64 was probably part of this "magic" to stuff 64bit 
code into a candy-coated 32bit wrapper for the Indy (And later the O2) to suck 
down w/o complaint.  Hence, __pa() probably needs to replicate this support, or 
we all need to brainstorm a proper way to get these systems to boot.

Octane, Origin, IP28 (Indigo2 R10000). et al, don't complain, and don't need 
this hacker, because their proms boot proper 64bit binaries only (they reject 
all else).

So probably the following is true (someone correct me if not)

if (CONFIG_BUILD_ELF64=y and (!CONFIG_SGI_IP22 or !CONFIG_SGI_IP32 or 
!CONFIG_COBALT)) then kernel load address must be in XKPHYS
else load address must be in CKSEG0
if CONFIG_BUILD_ELF64=n then kernel load address must be in CKSEG0



> I'm sorry but my IPxx background is 0 ;)

Time to buy an O2 :)


--Kumba

-- 
Gentoo/MIPS Team Lead

"Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere."  --Elrond

Re: IP32 prom crashes due to __pa() funkiness

[Thiemo Seufer]

Kumba wrote:
[snip]
> Most of this is because IP22 (Indy/Idigo2 R4xx) and IP32 (O2 R5xxx), while 
> supporting 64bit kernels (same for cobalt, since it's a mips4-level CPU), 
> we had to "trick" them into accepting 64bit code.  IP32 at one point ran 
> 32bit kernels only, but it was later converted to supporting only 64bit 
> kernels, hence the hackery involved.  We describe it as wrapping 64bit code 
> into a 32bit object, because their proms will only recognize 32bit objects 
> (specifically, IP22 will only boot 32bit objects; crash on 64bit; IP32 will 
> take both, but likes 32bit better).
> 
> So really, CONFIG_BUILD_ELF64 was probably part of this "magic" to stuff 
> 64bit code into a candy-coated 32bit wrapper for the Indy (And later the 
> O2) to suck down w/o complaint.  Hence, __pa() probably needs to replicate 
> this support, or we all need to brainstorm a proper way to get these 
> systems to boot.

BUILD_ELF64 + -sym32 + objcopy into a ELF32 file is supposed to be the
full replacement for the old o64-in-o32 hack.

> Octane, Origin, IP28 (Indigo2 R10000). et al, don't complain, and don't 
> need this hacker, because their proms boot proper 64bit binaries only (they 
> reject all else).
> 
> So probably the following is true (someone correct me if not)
> 
> if (CONFIG_BUILD_ELF64=y and (!CONFIG_SGI_IP22 or !CONFIG_SGI_IP32 or 
> !CONFIG_COBALT)) then kernel load address must be in XKPHYS
> else load address must be in CKSEG0
> if CONFIG_BUILD_ELF64=n then kernel load address must be in CKSEG0

The 64/64 configs can do both:

                      |  BUILD_ELF64  | BUILD_ELF32
---------------------------------------------------
64bit firmware loader | CKSEG0/XKPHYS |   CKSEG0
32bit firmware loader |     CKSEG0    |   CKSEG0


Thiemo

Re: IP32 prom crashes due to __pa() funkiness

[Atsushi Nemoto]

On Mon, 19 Mar 2007 10:24:34 -0400, Kumba <kumba@gentoo.org> wrote:
> Most of this is because IP22 (Indy/Idigo2 R4xx) and IP32 (O2 R5xxx),
> while supporting 64bit kernels (same for cobalt, since it's a
> mips4-level CPU), we had to "trick" them into accepting 64bit code.
> IP32 at one point ran 32bit kernels only, but it was later converted
> to supporting only 64bit kernels, hence the hackery involved.  We
> describe it as wrapping 64bit code into a 32bit object, because
> their proms will only recognize 32bit objects (specifically, IP22
> will only boot 32bit objects; crash on 64bit; IP32 will take both,
> but likes 32bit better).
> 
> So really, CONFIG_BUILD_ELF64 was probably part of this "magic" to
> stuff 64bit code into a candy-coated 32bit wrapper for the Indy (And
> later the O2) to suck down w/o complaint.  Hence, __pa() probably
> needs to replicate this support, or we all need to brainstorm a
> proper way to get these systems to boot.

The "magic" is CONFIG_BOOT_ELF32 and CONFIG_BOOT_ELF64, isn't it?
CONFIG_BUILD_ELF64 is not irrelevant to ELF format.

I feel there are some confusions about this issue on this discussion...
---
Atsushi Nemoto

Re: IP32 prom crashes due to __pa() funkiness

[Franck Bui-Huu]

[-- Attachment #1: Type: text/plain, Size: 1505 bytes --]

On 3/19/07, Kumba <kumba@gentoo.org> wrote:
>
> Most of this is because IP22 (Indy/Idigo2 R4xx) and IP32 (O2 R5xxx), while
> supporting 64bit kernels (same for cobalt, since it's a mips4-level CPU), we had
> to "trick" them into accepting 64bit code.  IP32 at one point ran 32bit kernels
> only, but it was later converted to supporting only 64bit kernels, hence the
> hackery involved.  We describe it as wrapping 64bit code into a 32bit object,
> because their proms will only recognize 32bit objects (specifically, IP22 will
> only boot 32bit objects; crash on 64bit; IP32 will take both, but likes 32bit
> better).
>
> So really, CONFIG_BUILD_ELF64 was probably part of this "magic" to stuff 64bit
> code into a candy-coated 32bit wrapper for the Indy (And later the O2) to suck
> down w/o complaint.  Hence, __pa() probably needs to replicate this support, or
> we all need to brainstorm a proper way to get these systems to boot.
>

I'm really not confident with all your tricks you described. Maybe a
config that I believed to be uninsteresting and useless should be
supported still.

Can you try the attached patch with a plain linux-mips kernel ? This
patch restore CPHYSADDR() for 64 bits kernels _only_. I guess it's ok
because we won't need to support mapped kernels on 64 bits machines...

Could others give their opinions ?

> > I'm sorry but my IPxx background is 0 ;)
>
> Time to buy an O2 :)
>

As soon as it will work with a plain linux-mips without hackery ;)
-- 
               Franck

[-- Attachment #2: pa-64bits-kernel.patch --]
[-- Type: text/x-patch, Size: 917 bytes --]

diff --git a/include/asm-mips/page.h b/include/asm-mips/page.h
index d3fbd83..6461154 100644
--- a/include/asm-mips/page.h
+++ b/include/asm-mips/page.h
@@ -149,12 +149,12 @@ typedef struct { unsigned long pgprot; } pgprot_t;
 /*
  * __pa()/__va() should be used only during mem init.
  */
-#if defined(CONFIG_64BIT) && !defined(CONFIG_BUILD_ELF64)
-#define __pa_page_offset(x)	((unsigned long)(x) < CKSEG0 ? PAGE_OFFSET : CKSEG0)
+#ifdef CONFIG_64BIT
+#define __pa(x)		((unsigned long)(x) < CKSEG0 ? XPHYSADDR((unsigned long)(x))\
+						     : CPHYSADDR((unsigned long)(x)))
 #else
-#define __pa_page_offset(x)	PAGE_OFFSET
+#define __pa(x)		((unsigned long)(x) - PAGE_OFFSET + PHYS_OFFSET)
 #endif
-#define __pa(x)		((unsigned long)(x) - __pa_page_offset(x) + PHYS_OFFSET)
 #define __va(x)		((void *)((unsigned long)(x) + PAGE_OFFSET - PHYS_OFFSET))
 #define __pa_symbol(x)	__pa(RELOC_HIDE((unsigned long)(x),0))
 

Re: IP32 prom crashes due to __pa() funkiness

[Kumba]

[-- Attachment #1: Type: text/plain, Size: 2288 bytes --]

Franck Bui-Huu wrote:
> 
> I'm really not confident with all your tricks you described. Maybe a
> config that I believed to be uninsteresting and useless should be
> supported still.
> 
> Can you try the attached patch with a plain linux-mips kernel ? This
> patch restore CPHYSADDR() for 64 bits kernels _only_. I guess it's ok
> because we won't need to support mapped kernels on 64 bits machines...
> 
> Could others give their opinions ?

After going through all the fun to get rid of CPHYSADDR, I see no point really 
to bring it back.  Plus that patch unnecessarily complicates those defines.  As 
I highlighted in my original mail, O2 doesn't need CPHYSADDR added to __pa(), it 
just needs the conditional define for __pa_page_offset to be a little bit more 
flexible.

Since only three machines, O2 R5xx, Indy/Indigo2 R4xx, and Cobalt will exhibit 
similar issues (the latter two when booting 64bit kernels), a saner method in my 
opinion is to introduce a flag of sorts into the conditional for 
__pa_page_offset to determine whether to define it strictly to PAGE_OFFSET or to 
the other value listed in the code.  The only thing is, I'm not sure which 
method of the two I've thought up is cleaner.

The first introduces a hidden Kconfig value, CONFIG_SYS_LOADS_IN_CKSEG0, that 
only turns on when BUILD_ELF64 && (SGI_IP22 || (SGI_IP32 && (CPU_R5000 || 
CPU_NEVADA || CPU_RM7000)) || MIPS_COBALT), and then we test for this flag in 
include/asm-mips/page.h when setting the value of __pa_page_offset.

The other way is to define a similar flag in a new header file, memmap.h, in 
include/asm-mips/mach-{ip22,ip32,cobalt}/* called MIPS_USES_CKSEG0, and 
similarly, test for that flag in the same spot as above.  With this method, 
though, I'm not sure where exactly to pull in the memmap.h header, so the patch 
for it is incomplete (but included for reference).

I've tested the first patch (kconfig one), and it works fine.  The second one 
will also work, provided I find a nice spot to pull in memmap.h, but from a 
semantics perspective, which one do you guys like better?



--Kumba

-- 
Gentoo/MIPS Team Lead

"Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere."  --Elrond

[-- Attachment #2: mips-kconfig-ckseg0-idea.patch --]
[-- Type: text/plain, Size: 1353 bytes --]

diff -Naurp mipslinux/arch/mips/Kconfig mipslinux.ckseg0-a/arch/mips/Kconfig
--- mipslinux/arch/mips/Kconfig	2007-03-17 21:12:06.000000000 -0400
+++ mipslinux.ckseg0-a/arch/mips/Kconfig	2007-03-20 01:38:42.000000000 -0400
@@ -1659,6 +1659,11 @@ config SB1_PASS_2_1_WORKAROUNDS
 	depends on CPU_SB1 && CPU_SB1_PASS_2
 	default y
 
+config SYS_LOADS_IN_CKSEG0
+	bool
+	depends on BUILD_ELF64 && (SGI_IP22 || (SGI_IP32 && (CPU_R5000 || CPU_NEVADA || CPU_RM7000)) || MIPS_COBALT)
+	default y
+
 config 64BIT_PHYS_ADDR
 	bool "Support for 64-bit physical address space"
 	depends on (CPU_R4X00 || CPU_R5000 || CPU_RM7000 || CPU_RM9000 || CPU_R10000 || CPU_SB1 || CPU_MIPS32 || CPU_MIPS64) && 32BIT
diff -Naurp mipslinux/include/asm-mips/page.h mipslinux.ckseg0-a/include/asm-mips/page.h
--- mipslinux/include/asm-mips/page.h	2007-03-17 21:12:31.000000000 -0400
+++ mipslinux.ckseg0-a/include/asm-mips/page.h	2007-03-20 01:37:31.000000000 -0400
@@ -149,7 +149,7 @@ typedef struct { unsigned long pgprot; }
 /*
  * __pa()/__va() should be used only during mem init.
  */
-#if defined(CONFIG_64BIT) && !defined(CONFIG_BUILD_ELF64)
+#if defined(CONFIG_64BIT) && (!defined(CONFIG_BUILD_ELF64) || defined(CONFIG_SYS_LOADS_IN_CKSEG0))
 #define __pa_page_offset(x)	((unsigned long)(x) < CKSEG0 ? PAGE_OFFSET : CKSEG0)
 #else
 #define __pa_page_offset(x)	PAGE_OFFSET

[-- Attachment #3: mips-asm-mach-ckseg0-idea.patch --]
[-- Type: text/plain, Size: 2169 bytes --]

diff -Naurp mipslinux/include/asm-mips/mach-cobalt/memmap.h mipslinux.ckseg0-b/include/asm-mips/mach-cobalt/memmap.h
--- mipslinux/include/asm-mips/mach-cobalt/memmap.h	1969-12-31 19:00:00.000000000 -0500
+++ mipslinux.ckseg0-b/include/asm-mips/mach-cobalt/memmap.h	2007-03-20 01:19:59.000000000 -0400
@@ -0,0 +1,9 @@
+#ifndef __ASM_MACH_IP32_MEMMAP_H
+#define __ASM_MACH_IP32_MEMMAP_H
+
+
+#ifdef CONFIG_64BIT
+#define MIPS_USES_CKSEG0	1
+#endif
+
+#endif /* __ASM_MACH_IP32_MEMMAP_H */
diff -Naurp mipslinux/include/asm-mips/mach-ip22/memmap.h mipslinux.ckseg0-b/include/asm-mips/mach-ip22/memmap.h
--- mipslinux/include/asm-mips/mach-ip22/memmap.h	1969-12-31 19:00:00.000000000 -0500
+++ mipslinux.ckseg0-b/include/asm-mips/mach-ip22/memmap.h	2007-03-20 01:20:14.000000000 -0400
@@ -0,0 +1,9 @@
+#ifndef __ASM_MACH_IP32_MEMMAP_H
+#define __ASM_MACH_IP32_MEMMAP_H
+
+
+#ifdef CONFIG_64BIT
+#define MIPS_USES_CKSEG0	1
+#endif
+
+#endif /* __ASM_MACH_IP32_MEMMAP_H */
diff -Naurp mipslinux/include/asm-mips/mach-ip32/memmap.h mipslinux.ckseg0-b/include/asm-mips/mach-ip32/memmap.h
--- mipslinux/include/asm-mips/mach-ip32/memmap.h	1969-12-31 19:00:00.000000000 -0500
+++ mipslinux.ckseg0-b/include/asm-mips/mach-ip32/memmap.h	2007-03-20 01:12:24.000000000 -0400
@@ -0,0 +1,9 @@
+#ifndef __ASM_MACH_IP32_MEMMAP_H
+#define __ASM_MACH_IP32_MEMMAP_H
+
+
+#if defined(CONFIG_CPU_R5000) || defined(CONFIG_CPU_NEVADA) || defined (CONFIG_CPU_RM7000)
+#define MIPS_USES_CKSEG0	1
+#endif
+
+#endif /* __ASM_MACH_IP32_MEMMAP_H */
diff -Naurp mipslinux/include/asm-mips/page.h mipslinux.ckseg0-b/include/asm-mips/page.h
--- mipslinux/include/asm-mips/page.h	2007-03-17 21:12:31.000000000 -0400
+++ mipslinux.ckseg0-b/include/asm-mips/page.h	2007-03-20 01:15:35.000000000 -0400
@@ -149,7 +149,7 @@ typedef struct { unsigned long pgprot; }
 /*
  * __pa()/__va() should be used only during mem init.
  */
-#if defined(CONFIG_64BIT) && !defined(CONFIG_BUILD_ELF64)
+#if defined(CONFIG_64BIT) && (!defined(CONFIG_BUILD_ELF64) || defined(MIPS_USES_CKSEG0))
 #define __pa_page_offset(x)	((unsigned long)(x) < CKSEG0 ? PAGE_OFFSET : CKSEG0)
 #else
 #define __pa_page_offset(x)	PAGE_OFFSET

Re: IP32 prom crashes due to __pa() funkiness

[Franck Bui-Huu]

Kumba wrote:
>
> After going through all the fun to get rid of CPHYSADDR, I see no
> point really to bring it back.

The patch restores CPHYSADDR() but in __pa()'s _implementation_. It
makes a huge difference.

I think CPHYSADDR() is not that bad for 64 bits kernels. With such
beasts we need to handle two PAGE_OFFSET values if we stick with the
current implementation of __pa(). Magically using CPHYSADDR() removes
this need. OTOH, CPHYSADDR() is quite bad for mapped kernels.

But do we really care in 64 bits world ?

>  Plus that patch unnecessarily complicates those defines.  As I
> highlighted in my original mail, O2 doesn't need CPHYSADDR added to
> __pa(), it just needs the conditional define for __pa_page_offset to
> be a little bit more flexible.
>

I don't see why the patch complicates those defines. It actually gets
rid of CONFIG_BUILD_ELF64 and __pa_page_offset(). OK I could have
written it a little bit more readable:

#ifdef CONFIG_64BIT
#define __pa(x)							\
({								\
	unsigned long __x = (unsigned long)(x);			\
	__x < CKSEG0 ? XPHYSADDR(__x) : CPHYSADDR(__x);		\
})
#else
#define __pa(x)							\
	((unsigned long)(x) - PAGE_OFFSET + PHYS_OFFSET)
#endif

Yes, it actually increases size code for CONFIG_64BIT because we
always test if the virtual address is from XKPHYS or CKSEG0. But how
much ? I would say not a lot, and it maybe worths it since we get rid
of an obscure config option.

		Franck

-- 
               Franck

Re: IP32 prom crashes due to __pa() funkiness

[peter fuerst]

Hi!

Did you try to use PHYS_OFFSET > 0 ?  __pa() ist still (as of
d3fbd83ff545e49e2a0a5ca0f00dda4eedaf8be7) defined as (casts omitted):

#define __pa(x) (x - (x < CKSEG0 ? PAGE_OFFSET:CKSEG0) + PHYS_OFFSET)

This gives __pa(CKSEG0) == PHYS_OFFSET, which will never work for
PHYS_OFFSET > 0. A quick fix (assuming this was the cause for failure)
could be:

========================================================================
--- d3fbd83ff545e49e2a0a5ca0f00dda4eedaf8be7/include/asm-mips/page.h	Sat Mar 10 08:43:17 2007
+++ quickfix/include/asm-mips/page.h	Sun Mar 18 10:24:34 2007
@@ -150,7 +150,7 @@ typedef struct { unsigned long pgprot; }
  * __pa()/__va() should be used only during mem init.
  */
 #if defined(CONFIG_64BIT) && !defined(CONFIG_BUILD_ELF64)
-#define __pa_page_offset(x)	((unsigned long)(x) < CKSEG0 ? PAGE_OFFSET : CKSEG0)
+#define __pa_page_offset(x)	((unsigned long)(x) < CKSEG0 ? PAGE_OFFSET : CKSEG0+PHYS_OFFSET)
 #else
 #define __pa_page_offset(x)	PAGE_OFFSET
 #endif


Signed-off-by: peter fuerst <post@pfrst.de>

========================================================================

Of course, "#define PAGE_OFFSET (CAC_BASE + PHYS_OFFSET)" is also needed.

kind regards

peter


On Sat, 17 Mar 2007, Kumba wrote:

> Date: Sat, 17 Mar 2007 14:53:23 -0400
> From: Kumba <kumba@gentoo.org>
> To: Franck Bui-Huu <vagabon.xyz@gmail.com>
> Cc: peter fuerst <post@pfrst.de>
> Subject: Re: IP32 prom crashes due to __pa() funkiness
>
> Franck Bui-Huu wrote:
> > Hi,
> >
> [snip]
> >
> > Well, it means that you previously used CONFIG_BUILD_ELF64=y (this
> > implied that PAGE_OFFSET is in XKPHYS) whereas your kernel has CKSEG
> > load address (symbols need PAGE_OFFSET in CKSEG for address
> > translation).
> >
> > So the question is why can't you use CONFIG_BUILD_ELF64=n (and
> > reagarding the current definition of CONFIG_BUILD_ELF64).
> >
> [snip]
> >
> > It makes me think that I posted a patch for that a couple of weeks ago:
> >
> > http://marc.theaimsgroup.com/?l=linux-mips&m=117154480225936&w=2
> > http://marc.theaimsgroup.com/?l=linux-mips&m=117154480126802&w=2
> > http://marc.theaimsgroup.com/?l=linux-mips&m=117154587014827&w=2
> >
> > Basically this patch removes CONFIG_BUILD_ELF64 and makes Kbuild to use
> > '-msym32' switch if you really need it. Kbuild makes its choice according
> > the load address of your kernel image.
> >
> > Could you give it a try ? This patch was based on 2.6.20 but it should
> > apply fine on a 2.6.21-rc[12].
>
> Tested, and it still failed.
>
> And I didn't always use CONFIG_BUILD_ELF64.  In fact, for the longest time (up
> until 2.6.17) I built IP32 and 64bit IP22 kernels without CONFIG_BUILD_eLF64,
> passing -mabi=o64 (a.k.a., the binutils hack).  This let me use the plain
> 'vmlinux' target w/o the need for an objcopy to boot these systems.  After
> 2.6.17, the nature of o64 was mostly neutered, so I switched to using
> CONFIG_BUILD_ELF64 and the 'vmlinux.32' target, as this is apparently the way
> Debian builds their IP32 kernels (and was the way geoman/spbecker said I
> should've been using all along).
>
> So with the changes brought in by __pa(), I suppose a new, RightWay(TM) to build
> IP32 (and conversely, 64bit IP22) kernels needs to be found.  These two systems
> are particularly wacky, hence why they need a bit more special care than more
> traditional, proper, 64bit systems like Origin and Octane.
>
> Also, Peter raises a good point in this case.  It sounds like a re-thinking of
> how all this address stuff is handled will fix not only special cases like
> IP32/IP22, but the really weird systems, like IP28, as well.  Which would be a
> big plus in my opinion.
>
>
> --Kumba
>
> --
> Gentoo/MIPS Team Lead
>
> "Such is oft the course of deeds that move the wheels of the world: small hands
> do them because they must, while the eyes of the great are elsewhere."  --Elrond
>
>

Re: IP32 prom crashes due to __pa() funkiness

[Kumba]

peter fuerst wrote:
> 
> Hi!
> 
> Did you try to use PHYS_OFFSET > 0 ?  __pa() ist still (as of
> d3fbd83ff545e49e2a0a5ca0f00dda4eedaf8be7) defined as (casts omitted):
> 
> #define __pa(x) (x - (x < CKSEG0 ? PAGE_OFFSET:CKSEG0) + PHYS_OFFSET)
> 
> This gives __pa(CKSEG0) == PHYS_OFFSET, which will never work for
> PHYS_OFFSET > 0. A quick fix (assuming this was the cause for failure)
> could be:
> 
> ========================================================================
> --- d3fbd83ff545e49e2a0a5ca0f00dda4eedaf8be7/include/asm-mips/page.h	Sat Mar 10 08:43:17 2007
> +++ quickfix/include/asm-mips/page.h	Sun Mar 18 10:24:34 2007
> @@ -150,7 +150,7 @@ typedef struct { unsigned long pgprot; }
>   * __pa()/__va() should be used only during mem init.
>   */
>  #if defined(CONFIG_64BIT) && !defined(CONFIG_BUILD_ELF64)
> -#define __pa_page_offset(x)	((unsigned long)(x) < CKSEG0 ? PAGE_OFFSET : CKSEG0)
> +#define __pa_page_offset(x)	((unsigned long)(x) < CKSEG0 ? PAGE_OFFSET : CKSEG0+PHYS_OFFSET)
>  #else
>  #define __pa_page_offset(x)	PAGE_OFFSET
>  #endif
> 
> 
> Signed-off-by: peter fuerst <post@pfrst.de>
> 
> ========================================================================
> 
> Of course, "#define PAGE_OFFSET (CAC_BASE + PHYS_OFFSET)" is also needed.
> 
> kind regards
> 
> peter

Hmm, I can't find where PHYS_OFFSET is defined for mips.  A grep shows it mostly 
existing for the arm arch.  Is there an alternative macro available, or is this 
something that needs porting over?


--Kumba

-- 
Gentoo/MIPS Team Lead

"Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere."  --Elrond

Re: IP32 prom crashes due to __pa() funkiness

[Kumba]

Kumba wrote:
> peter fuerst wrote:
>>
>> Hi!
>>
>> Did you try to use PHYS_OFFSET > 0 ?  __pa() ist still (as of
>> d3fbd83ff545e49e2a0a5ca0f00dda4eedaf8be7) defined as (casts omitted):
>>
>> #define __pa(x) (x - (x < CKSEG0 ? PAGE_OFFSET:CKSEG0) + PHYS_OFFSET)
>>
>> This gives __pa(CKSEG0) == PHYS_OFFSET, which will never work for
>> PHYS_OFFSET > 0. A quick fix (assuming this was the cause for failure)
>> could be:
>>
>> ========================================================================
>> --- 
>> d3fbd83ff545e49e2a0a5ca0f00dda4eedaf8be7/include/asm-mips/page.h    
>> Sat Mar 10 08:43:17 2007
>> +++ quickfix/include/asm-mips/page.h    Sun Mar 18 10:24:34 2007
>> @@ -150,7 +150,7 @@ typedef struct { unsigned long pgprot; }
>>   * __pa()/__va() should be used only during mem init.
>>   */
>>  #if defined(CONFIG_64BIT) && !defined(CONFIG_BUILD_ELF64)
>> -#define __pa_page_offset(x)    ((unsigned long)(x) < CKSEG0 ? 
>> PAGE_OFFSET : CKSEG0)
>> +#define __pa_page_offset(x)    ((unsigned long)(x) < CKSEG0 ? 
>> PAGE_OFFSET : CKSEG0+PHYS_OFFSET)
>>  #else
>>  #define __pa_page_offset(x)    PAGE_OFFSET
>>  #endif
>>
>>
>> Signed-off-by: peter fuerst <post@pfrst.de>
>>
>> ========================================================================
>>
>> Of course, "#define PAGE_OFFSET (CAC_BASE + PHYS_OFFSET)" is also needed.
>>
>> kind regards
>>
>> peter
> 
> Hmm, I can't find where PHYS_OFFSET is defined for mips.  A grep shows 
> it mostly existing for the arm arch.  Is there an alternative macro 
> available, or is this something that needs porting over?
> 
> 
> --Kumba

Ah, duh.  PHYS_OFFSET was introduced post-2.6.20, so I won't be able to leverage 
this w/o backporting.


--Kumba

-- 
Gentoo/MIPS Team Lead

"Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere."  --Elrond

Re: IP32 prom crashes due to __pa() funkiness

[Kumba]

peter fuerst wrote:
> 
> Hi!
> 
> Did you try to use PHYS_OFFSET > 0 ?  __pa() ist still (as of
> d3fbd83ff545e49e2a0a5ca0f00dda4eedaf8be7) defined as (casts omitted):
> 
> #define __pa(x) (x - (x < CKSEG0 ? PAGE_OFFSET:CKSEG0) + PHYS_OFFSET)
> 
> This gives __pa(CKSEG0) == PHYS_OFFSET, which will never work for
> PHYS_OFFSET > 0. A quick fix (assuming this was the cause for failure)
> could be:
> 
> ========================================================================
> --- d3fbd83ff545e49e2a0a5ca0f00dda4eedaf8be7/include/asm-mips/page.h	Sat Mar 10 08:43:17 2007
> +++ quickfix/include/asm-mips/page.h	Sun Mar 18 10:24:34 2007
> @@ -150,7 +150,7 @@ typedef struct { unsigned long pgprot; }
>   * __pa()/__va() should be used only during mem init.
>   */
>  #if defined(CONFIG_64BIT) && !defined(CONFIG_BUILD_ELF64)
> -#define __pa_page_offset(x)	((unsigned long)(x) < CKSEG0 ? PAGE_OFFSET : CKSEG0)
> +#define __pa_page_offset(x)	((unsigned long)(x) < CKSEG0 ? PAGE_OFFSET : CKSEG0+PHYS_OFFSET)
>  #else
>  #define __pa_page_offset(x)	PAGE_OFFSET
>  #endif
> 
> 
> Signed-off-by: peter fuerst <post@pfrst.de>
> 
> ========================================================================
> 
> Of course, "#define PAGE_OFFSET (CAC_BASE + PHYS_OFFSET)" is also needed.
> 
> kind regards
> 
> peter


Backported the patches that bring in PHYS_OFFSET and tried both with and without 
Frank's patches to remove CONFIG_BUILD_ELF64 from the Makefile, plus this 
change, and still no go.  W/o CONFIG_BUILD_ELF64, both the vmlinux and 
vmlinux.32 targets just silently hang.  With CONFIG_BUILD_ELF64 in the Makefile, 
the same Prom crash.


--Kumba

-- 
Gentoo/MIPS Team Lead

"Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere."  --Elrond

Re: IP32 prom crashes due to __pa() funkiness

[Franck Bui-Huu]

On 3/18/07, Kumba <kumba@gentoo.org> wrote:
>
> Backported the patches that bring in PHYS_OFFSET and tried both with and without
> Frank's patches to remove CONFIG_BUILD_ELF64 from the Makefile, plus this
> change, and still no go.  W/o CONFIG_BUILD_ELF64, both the vmlinux and
> vmlinux.32 targets just silently hang.  With CONFIG_BUILD_ELF64 in the Makefile,
> the same Prom crash.
>

wait wait wait. PHYS_OFFSET has nothing to do in this case. You are
obvioulsy not using it by default.

-- 
               Franck

Re: [PATCH]: Remove CONFIG_BUILD_ELF64 entirely

[Atsushi Nemoto]

On Thu, 29 Mar 2007 22:20:52 -0400, Kumba <kumba@gentoo.org> wrote:
> > Just an optimization.  For CKSEG0 symbol, a LUI instruction can fill
> > high 32-bit by sign-extention.  Either code should work for CKSEG0
> > kernel.
> 
> Well, thinking about it some more, can this stackframe change be segmented out 
> of Frank's main patches, so we can get them into git, and spend time in 
> 2.6.21/2.6.22/2.6.23 chasing down what exactly is up with this specific asm 
> sequence?

This is not Franck's fault.  His patchset does not change behavior if
kernel load address was CKSEG0 and CONFIG_BUILD_ELF64 was not set
(unless you are using gcc 3.x).

Let's clarify things a bit: The Franck's patchset is _not_ fix.  It
just tried to avoid undesirable configuration (CKSEG0 kernel with
BUILD_ELF64=y), and clarify some namings.

So I should ask you again, does current git (or 2.6.20-stable) kernel
compiled by binutils-2.17/gcc-4.[12] work for IP32 if you disabled
CONFIG_BUILD_ELF64?

On Sun, 18 Feb 2007 15:00:48 -0500, Kumba <kumba@gentoo.org> wrote:
> The [short-term] fix highlighted by Ilya is to make __pa() unconditionally be 
> defined to "((unsigned long)(x) < CKSEG0 ? PAGE_OFFSET : CKSEG0)"; Discovered by 
> building IP32 with CONFIG_BUILD_ELF64=n.

So I had thought CONFIG_BUILD_ELF64=n worked for IP32...

---
Atsushi Nemoto

Re: [PATCH]: Remove CONFIG_BUILD_ELF64 entirely

[Kumba]

Atsushi Nemoto wrote:
> This is not Franck's fault.  His patchset does not change behavior if
> kernel load address was CKSEG0 and CONFIG_BUILD_ELF64 was not set
> (unless you are using gcc 3.x).

I wasn't implying it was anyone's fault of any kind.  I actually didn't see your 
last response cause Thunderbird got stupid and stopped checking for new mail for 
some odd reason.


> Let's clarify things a bit: The Franck's patchset is _not_ fix.  It
> just tried to avoid undesirable configuration (CKSEG0 kernel with
> BUILD_ELF64=y), and clarify some namings.

As far as I can tell, the majority of what CONFIG_BUILD_ELF64 did got neutered 
in 2.6.17.  It's pretty much down to those minor #ifdef checks and a few 
references on the defconfigs.  Removing it entirely is probably the best idea, 
and if Frank's patch is one way of doing it, I'm game.  Besides, he's got that 
loadaddr detector thrown in so we don't have to check on a machine-by-machine 
basis if they're loading in CKSEG0 or not.


> So I should ask you again, does current git (or 2.6.20-stable) kernel
> compiled by binutils-2.17/gcc-4.[12] work for IP32 if you disabled
> CONFIG_BUILD_ELF64?
[snip]
> So I had thought CONFIG_BUILD_ELF64=n worked for IP32...


If memory serves, yes, it'll boot, because it's close to the old way I that I 
used to use when building them.  Prior to 2.6.17, I did CONFIG_BUILD_ELF64=n 
with -mabi=o64.  This let me use the plain 'vmlinux' target without any special 
changes.  2.6.17 is when I stopped using gcc-3.x for kernels, moved to 4.x, and 
started using CONFIG_BUILD_ELF64=y w/ -msym32 and friends.  Thus I now use 
vmlinux.32.  I was told that that was the RightWay(TM) to do it.

Hence, the real point of this long chain is mainly to accomplish two things:

1) Finally determine the OneTrueWay(TM) to build 64bit kernels for our three 
main CKSEG0-based systems (ip22, ip32, cobalt), and get that way documented so 
as to avoid confusion in the future.

2) Get a solution into the tree that does #1, and does it well.  So far, Frank's 
patch seems like the leading contender here.



--Kumba

-- 
Gentoo/MIPS Team Lead

"Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere."  --Elrond

Re: [PATCH]: Remove CONFIG_BUILD_ELF64 entirely

[Atsushi Nemoto]

On Fri, 30 Mar 2007 01:35:39 -0400, Kumba <kumba@gentoo.org> wrote:
> > So I should ask you again, does current git (or 2.6.20-stable) kernel
> > compiled by binutils-2.17/gcc-4.[12] work for IP32 if you disabled
> > CONFIG_BUILD_ELF64?
> [snip]
> > So I had thought CONFIG_BUILD_ELF64=n worked for IP32...
> 
> 
> If memory serves, yes, it'll boot, because it's close to the old way I that I 
> used to use when building them.  Prior to 2.6.17, I did CONFIG_BUILD_ELF64=n 
> with -mabi=o64.  This let me use the plain 'vmlinux' target without any special 
> changes.  2.6.17 is when I stopped using gcc-3.x for kernels, moved to 4.x, and 
> started using CONFIG_BUILD_ELF64=y w/ -msym32 and friends.  Thus I now use 
> vmlinux.32.  I was told that that was the RightWay(TM) to do it.

IMHO here is a root of confusion.  The -msym32 option is/was enabled
only if CONFIG_BUILD_ELF64=n.  The vmlinux.32 thing are controled by
CONFIG_BOOT_ELF32 or CONFIG_BOOT_ELF64.  The word BOOT and BUILD seems
too umbiguous ;)

> Hence, the real point of this long chain is mainly to accomplish two things:
> 
> 1) Finally determine the OneTrueWay(TM) to build 64bit kernels for our three 
> main CKSEG0-based systems (ip22, ip32, cobalt), and get that way documented so 
> as to avoid confusion in the future.
> 
> 2) Get a solution into the tree that does #1, and does it well.  So far, Frank's 
> patch seems like the leading contender here.

Yes.  I agree.

And I think the answer is

1) Disable CONFIG_BUILD_ELF64 in short term.

2) Apply Franck's patchset with a slight change (enclose -msym32 by
   $(call cc-option)).

And _if_ this did not work on IP32, something needs to be fixed, but I
can not see why for now.

---
Atsushi Nemoto

Re: CONFIG_BUILD_ELF64 broken on IP32 since 2.6.20

[Atsushi Nemoto]

On Tue, 25 Sep 2007 20:13:53 +0200, Martin Michlmayr <tbm@cyrius.com> wrote:
> IP32 kernels that are built with CONFIG_BUILD_ELF64=y only produce an
> exception when booted.  This worked with 2.6.19 and before.  I haven't
> had a chance to dig deep yet but it seems both Franck Bui-Huu and
> Atsushi Nemoto had patches in 2.6.20 that might have caused this.
> This still happens with 2.6.22.  I cannot boot current git for other
> reasons.

I think this is solved on current git a few weeks ago by this commit
(not mainlined yet):

> Subject: [MIPS] Fix CONFIG_BUILD_ELF64 kernels with symbols in CKSEG0.
> Date: 	Tue, 11 Sep 2007 11:12:03 +0100
> Author: Ralf Baechle <ralf@linux-mips.org> Tue Sep 11 08:50:40 2007 +0100
> Commit: db423f6e86c3c4c70edf3eaf504e22c467b9f97c
> Gitweb: http://www.linux-mips.org/g/linux/db423f6e
> Branch: master

It is just one liner and can be backported easily.

> If anyone has an idea which specific patch might have caused this,
> please let me know.  Otherwise I'll try to find time in the next few
> days to revert various patches.

Well, It might be a bit hard to revert specific patch in patchset with
dependencies.

For background, there were fairly lengthy discussion on this topic.
My thought was abstracted in this:

(http://www.linux-mips.org/archives/linux-mips/2007-03/msg00484.html)
On Fri, 30 Mar 2007 15:09:12 +0900 (JST), Atsushi Nemoto <anemo@mba.ocn.ne.jp> wrote:
> And I think the answer is
> 
> 1) Disable CONFIG_BUILD_ELF64 in short term.
> 
> 2) Apply Franck's patchset with a slight change (enclose -msym32 by
>    $(call cc-option)).
> 
> And _if_ this did not work on IP32, something needs to be fixed, but I
> can not see why for now.

I still think CONFIG_BUILD_ELF64=n is best choice.  You can get
smaller and faster kernel with this.  Are there any reason to use
CONFIG_BUILD_ELF64=y for IP32?  (Note that CONFIG_BUILD_ELF64 and
CONFIG_BOOT_ELF64 is separate thing.)

And The Franck's patchset is already in linux-queue tree of lmo so
should be in 2.6.24.

And finally I can remember the report from Kumba:

http://www.linux-mips.org/archives/linux-mips/2007-03/msg00485.html

I do not know this RM52xx thing is fixed or not. ;)

---
Atsushi Nemoto

Re: CONFIG_BUILD_ELF64 broken on IP32 since 2.6.20

[Martin Michlmayr]

* Atsushi Nemoto <anemo@mba.ocn.ne.jp> [2007-09-26 11:08]:
> I think this is solved on current git a few weeks ago by this commit
> (not mainlined yet):
> > Subject: [MIPS] Fix CONFIG_BUILD_ELF64 kernels with symbols in CKSEG0.
> > Gitweb: http://www.linux-mips.org/g/linux/db423f6e
> It is just one liner and can be backported easily.

I put this into 2.6.22 and it works.  Thanks a lot for the link.

> I still think CONFIG_BUILD_ELF64=n is best choice.  You can get
> smaller and faster kernel with this.  Are there any reason to use
> CONFIG_BUILD_ELF64=y for IP32?

I don't know.  All I know is that it's enabled in the Debian kernel
for IP22 and IP32 and has broken the kernel.  Thiemo, do you remember
why this option is enabled in our kernels?

> (Note that CONFIG_BUILD_ELF64 and CONFIG_BOOT_ELF64 is separate
> thing.)

Yeah, I'm aware of this.  We want to keep CONFIG_BOOT_ELF64 but I'm
happy to turn CONFIG_BUILD_ELF64 off in the Debian kernel if Thiemo
agrees.

Thanks for your response.
-- 
Martin Michlmayr
http://www.cyrius.com/

Re: CONFIG_BUILD_ELF64 broken on IP32 since 2.6.20

[Giuseppe Sacco]

Il giorno mer, 26/09/2007 alle 07.59 +0200, Martin Michlmayr ha scritto:
> * Atsushi Nemoto <anemo@mba.ocn.ne.jp> [2007-09-26 11:08]:
> > I think this is solved on current git a few weeks ago by this commit
> > (not mainlined yet):
> > > Subject: [MIPS] Fix CONFIG_BUILD_ELF64 kernels with symbols in CKSEG0.
> > > Gitweb: http://www.linux-mips.org/g/linux/db423f6e
> > It is just one liner and can be backported easily.
> 
> I put this into 2.6.22 and it works.  Thanks a lot for the link.

I just checked that 2.6.23-rc8 include this patch, so I am going to try
it.

Re: CONFIG_BUILD_ELF64 broken on IP32 since 2.6.20

[Thiemo Seufer]

Martin Michlmayr wrote:
> * Atsushi Nemoto <anemo@mba.ocn.ne.jp> [2007-09-26 11:08]:
> > I think this is solved on current git a few weeks ago by this commit
> > (not mainlined yet):
> > > Subject: [MIPS] Fix CONFIG_BUILD_ELF64 kernels with symbols in CKSEG0.
> > > Gitweb: http://www.linux-mips.org/g/linux/db423f6e
> > It is just one liner and can be backported easily.
> 
> I put this into 2.6.22 and it works.  Thanks a lot for the link.
> 
> > I still think CONFIG_BUILD_ELF64=n is best choice.  You can get
> > smaller and faster kernel with this.  Are there any reason to use
> > CONFIG_BUILD_ELF64=y for IP32?
> 
> I don't know.  All I know is that it's enabled in the Debian kernel
> for IP22 and IP32 and has broken the kernel.  Thiemo, do you remember
> why this option is enabled in our kernels?

ISTR we needed this for older toolchains, it should be obsolete now
(for ip32).


Thiemo

Re: CONFIG_BUILD_ELF64 broken on IP32 since 2.6.20

[Franck Bui-Huu]

Atsushi Nemoto wrote:
> On Tue, 25 Sep 2007 20:13:53 +0200, Martin Michlmayr <tbm@cyrius.com> wrote:
>> IP32 kernels that are built with CONFIG_BUILD_ELF64=y only produce an
>> exception when booted.  This worked with 2.6.19 and before.  I haven't
>> had a chance to dig deep yet but it seems both Franck Bui-Huu and
>> Atsushi Nemoto had patches in 2.6.20 that might have caused this.
>> This still happens with 2.6.22.  I cannot boot current git for other
>> reasons.
> 
> I think this is solved on current git a few weeks ago by this commit
> (not mainlined yet):
> 
>> Subject: [MIPS] Fix CONFIG_BUILD_ELF64 kernels with symbols in CKSEG0.

ISTR we kept 2 versions of __pa() for 64 bits kernels for
micro-optimization reason. And I think it was a mistake...

>> Date: 	Tue, 11 Sep 2007 11:12:03 +0100
>> Author: Ralf Baechle <ralf@linux-mips.org> Tue Sep 11 08:50:40 2007 +0100
>> Commit: db423f6e86c3c4c70edf3eaf504e22c467b9f97c
>> Gitweb: http://www.linux-mips.org/g/linux/db423f6e
>> Branch: master
> 
> It is just one liner and can be backported easily.

Hmm I didn't know about this change but I think it's a good one. It
basically removes one CONFIG_BUILD_ELF64 dependency in the _code_
which is good. CONFIG_BUILD_ELF64=y makes the kernel code weak since
the kernel will crash as soon as a CKSEG0 symbol will be
encountered. And ISTR that the bootloader/firmware on some platforms
doens't work with 64 bits symbols and objcopy is used after compiling
the kernel for these reasons. But I'm really not sure...

So IMHO, we should just forget the 4 micro-optimizations associated
with CONFIG_BUILD_ELF64 because it doesn't worth the pain it brings.

> And The Franck's patchset is already in linux-queue tree of lmo so
> should be in 2.6.24.
> 

Ah but as I suggested I think we should get rid of
KBUILD_64BIT_SYM32 in the code. This patchset won't work if the kernel
symbols are modified latter through objcopy or whatever...

What do you think ?

		Franck

Re: CONFIG_BUILD_ELF64 broken on IP32 since 2.6.20

[Atsushi Nemoto]

On Wed, 26 Sep 2007 11:14:47 +0200, Franck Bui-Huu <vagabon.xyz@gmail.com> wrote:
> Ah but as I suggested I think we should get rid of
> KBUILD_64BIT_SYM32 in the code. This patchset won't work if the kernel
> symbols are modified latter through objcopy or whatever...
> 
> What do you think ?

Well, KBUILD_64BIT_SYM32 in stackframe.h is in critical path.

And for KBUILD_64BIT_SYM32 in pgtable-64, I'm not sure non-sym32
module can work on CKSSEG.  It might work but it seems XKSEG is more
natural for non-sym32 module.

So now I'm happy with your patchset as is in linux-queue tree ;)

---
Atsushi Nemoto

Re: [PATCH]: Remove CONFIG_BUILD_ELF64 entirely

[Ralf Baechle]

On Sun, Mar 25, 2007 at 12:59:32PM -0400, Kumba wrote:

> Atsushi Nemoto wrote:
> >I can not see why you handle IP22, IP32, Cobalt as so "special".
> >There are many other platforms which supports 64-bit and uses CKSEG0
> >load address (well, actually all 64-bit platforms except for IP27).
> 
> Mainly because, to the best of my knowledge, these are the only three 
> systems where things get weird with ckseg0 and this specific Kconfig 
> option.  Afaik with other systems, they don't need weird hacks like 
> stuffing 64bit code into 32bit objects to work best (or at all).
> 
> 
> >So I think Franck's approach, which enables -msym32 and defines
> >KBUILD_64BIT_SYM32 automatically if load-y was CKSEG0, is better.  Are
> >there any problem with his patchset?
> 
> I missed the other two additions to this patch, which is probably why it 
> didn't work :)  Taken as a whole, they also boot my O2 now.

Well, how about this solution that solve the whole thing entirely with
Kconfig?

  Ralf

Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 0253584..6283fd2 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -2072,20 +2072,9 @@ source "fs/Kconfig.binfmt"
 config TRAD_SIGNALS
 	bool
 
-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.
+config KERNEL_LOADS_IN_CKSEG0
+	bool
+	default y if (SYS_SUPPORTS_32BIT_KERNEL || SGI_IP32 || SGI_IP27) && 64BIT
 
 config BINFMT_IRIX
 	bool "Include IRIX binary compatibility"
diff --git a/arch/mips/Makefile b/arch/mips/Makefile
index 92bca6a..d31f2d1 100644
--- a/arch/mips/Makefile
+++ b/arch/mips/Makefile
@@ -60,10 +60,10 @@ vmlinux-32		= vmlinux.32
 vmlinux-64		= vmlinux
 
 cflags-y		+= -mabi=64
-ifdef CONFIG_BUILD_ELF64
-cflags-y		+= $(call cc-option,-mno-explicit-relocs)
-else
+ifdef CONFIG_KERNEL_LOADS_IN_CKSEG0
 cflags-y		+= $(call cc-option,-msym32)
+else
+cflags-y		+= $(call cc-option,-mno-explicit-relocs)
 endif
 endif
 
diff --git a/arch/mips/configs/bigsur_defconfig b/arch/mips/configs/bigsur_defconfig
index 4713a13..abb0b48 100644
--- a/arch/mips/configs/bigsur_defconfig
+++ b/arch/mips/configs/bigsur_defconfig
@@ -279,7 +279,7 @@ CONFIG_MMU=y
 #
 CONFIG_BINFMT_ELF=y
 # CONFIG_BINFMT_MISC is not set
-# CONFIG_BUILD_ELF64 is not set
+CONFIG_KERNEL_LOADS_IN_CKSEG0=y
 CONFIG_MIPS32_COMPAT=y
 CONFIG_COMPAT=y
 CONFIG_SYSVIPC_COMPAT=y
diff --git a/arch/mips/configs/ip27_defconfig b/arch/mips/configs/ip27_defconfig
index 9ddc3ef..ea625b7 100644
--- a/arch/mips/configs/ip27_defconfig
+++ b/arch/mips/configs/ip27_defconfig
@@ -272,7 +272,7 @@ CONFIG_MMU=y
 #
 CONFIG_BINFMT_ELF=y
 # CONFIG_BINFMT_MISC is not set
-# CONFIG_BUILD_ELF64 is not set
+CONFIG_KERNEL_LOADS_IN_CKSEG0=y
 CONFIG_MIPS32_COMPAT=y
 CONFIG_COMPAT=y
 CONFIG_SYSVIPC_COMPAT=y
diff --git a/arch/mips/configs/ip32_defconfig b/arch/mips/configs/ip32_defconfig
index 8fc1880..d8b8c8f 100644
--- a/arch/mips/configs/ip32_defconfig
+++ b/arch/mips/configs/ip32_defconfig
@@ -252,7 +252,7 @@ CONFIG_MMU=y
 #
 CONFIG_BINFMT_ELF=y
 CONFIG_BINFMT_MISC=y
-# CONFIG_BUILD_ELF64 is not set
+CONFIG_KERNEL_LOADS_IN_CKSEG0=y
 CONFIG_MIPS32_COMPAT=y
 CONFIG_COMPAT=y
 CONFIG_SYSVIPC_COMPAT=y
diff --git a/arch/mips/configs/ocelot_c_defconfig b/arch/mips/configs/ocelot_c_defconfig
index 82ff6fc..16b4b63 100644
--- a/arch/mips/configs/ocelot_c_defconfig
+++ b/arch/mips/configs/ocelot_c_defconfig
@@ -250,7 +250,7 @@ CONFIG_MMU=y
 #
 CONFIG_BINFMT_ELF=y
 # CONFIG_BINFMT_MISC is not set
-# CONFIG_BUILD_ELF64 is not set
+CONFIG_KERNEL_LOADS_IN_CKSEG0=y
 CONFIG_MIPS32_COMPAT=y
 CONFIG_COMPAT=y
 CONFIG_SYSVIPC_COMPAT=y
diff --git a/arch/mips/configs/sb1250-swarm_defconfig b/arch/mips/configs/sb1250-swarm_defconfig
index 6c4f09a..0664e3f 100644
--- a/arch/mips/configs/sb1250-swarm_defconfig
+++ b/arch/mips/configs/sb1250-swarm_defconfig
@@ -281,7 +281,7 @@ CONFIG_MMU=y
 #
 CONFIG_BINFMT_ELF=y
 # CONFIG_BINFMT_MISC is not set
-# CONFIG_BUILD_ELF64 is not set
+CONFIG_KERNEL_LOADS_IN_CKSEG0=y
 CONFIG_MIPS32_COMPAT=y
 CONFIG_COMPAT=y
 CONFIG_SYSVIPC_COMPAT=y
diff --git a/include/asm-mips/page.h b/include/asm-mips/page.h
index d3fbd83..266542a 100644
--- a/include/asm-mips/page.h
+++ b/include/asm-mips/page.h
@@ -149,7 +149,7 @@ typedef struct { unsigned long pgprot; } pgprot_t;
 /*
  * __pa()/__va() should be used only during mem init.
  */
-#if defined(CONFIG_64BIT) && !defined(CONFIG_BUILD_ELF64)
+#if defined(CONFIG_64BIT) && defined(CONFIG_KERNEL_LOADS_IN_CKSEG0)
 #define __pa_page_offset(x)	((unsigned long)(x) < CKSEG0 ? PAGE_OFFSET : CKSEG0)
 #else
 #define __pa_page_offset(x)	PAGE_OFFSET
diff --git a/include/asm-mips/pgtable-64.h b/include/asm-mips/pgtable-64.h
index 49f5a1a..96c8927 100644
--- a/include/asm-mips/pgtable-64.h
+++ b/include/asm-mips/pgtable-64.h
@@ -104,7 +104,7 @@
 #define VMALLOC_START		MAP_BASE
 #define VMALLOC_END	\
 	(VMALLOC_START + PTRS_PER_PGD * PTRS_PER_PMD * PTRS_PER_PTE * PAGE_SIZE)
-#if defined(CONFIG_MODULES) && !defined(CONFIG_BUILD_ELF64) && \
+#if defined(CONFIG_MODULES) && defined(CONFIG_KERNEL_LOADS_IN_CKSEG0) && \
 	VMALLOC_START != CKSSEG
 /* Load modules into 32bit-compatible segment. */
 #define MODULE_START	CKSSEG
diff --git a/include/asm-mips/stackframe.h b/include/asm-mips/stackframe.h
index 7afa1fd..9ea32c9 100644
--- a/include/asm-mips/stackframe.h
+++ b/include/asm-mips/stackframe.h
@@ -79,7 +79,7 @@
 #else
 		MFC0	k0, CP0_CONTEXT
 #endif
-#if defined(CONFIG_BUILD_ELF64) || (defined(CONFIG_64BIT) && __GNUC__ < 4)
+#if !defined(CONFIG_KERNEL_LOADS_IN_CKSEG0) || (defined(CONFIG_64BIT) && __GNUC__ < 4)
 		lui	k1, %highest(kernelsp)
 		daddiu	k1, %higher(kernelsp)
 		dsll	k1, 16
@@ -104,7 +104,7 @@
 		.endm
 #else
 		.macro	get_saved_sp	/* Uniprocessor variation */
-#if defined(CONFIG_BUILD_ELF64) || (defined(CONFIG_64BIT) && __GNUC__ < 4)
+#if !defined(CONFIG_KERNEL_LOADS_IN_CKSEG0) || (defined(CONFIG_64BIT) && __GNUC__ < 4)
 		lui	k1, %highest(kernelsp)
 		daddiu	k1, %higher(kernelsp)
 		dsll	k1, k1, 16

Re: [PATCH]: Remove CONFIG_BUILD_ELF64 entirely

[Atsushi Nemoto]

On Sun, 25 Mar 2007 23:19:19 +0100, Ralf Baechle <ralf@linux-mips.org> wrote:
> --- a/include/asm-mips/stackframe.h
> +++ b/include/asm-mips/stackframe.h
> @@ -79,7 +79,7 @@
>  #else
>  		MFC0	k0, CP0_CONTEXT
>  #endif
> -#if defined(CONFIG_BUILD_ELF64) || (defined(CONFIG_64BIT) && __GNUC__ < 4)
> +#if !defined(CONFIG_KERNEL_LOADS_IN_CKSEG0) || (defined(CONFIG_64BIT) && __GNUC__ < 4)
>  		lui	k1, %highest(kernelsp)
>  		daddiu	k1, %higher(kernelsp)
>  		dsll	k1, 16

CONFIG_KERNEL_LOADS_IN_CKSEG0 is not defined on 32-bit kernel.

#if defined(CONFIG_64BIT) && (!defined(CONFIG_KERNEL_LOADS_IN_CKSEG0) || __GNUC__ < 4)

Perhaps?
---
Atsushi Nemoto

Re: [PATCH]: Remove CONFIG_BUILD_ELF64 entirely

[Franck Bui-Huu]

Hi Ralf,

On 3/26/07, Ralf Baechle <ralf@linux-mips.org> wrote:
>
> Well, how about this solution that solve the whole thing entirely with
> Kconfig?
>

Could you explain why you don't actually like the patchset that care
about that in Kbuild ?

You were asked several times why this patchset have not been
considerated without any answers. So I have no clue why it's broken.

And now we have a third (well at least) solution... and I don't see
why it's better than Kbuild one: it still has GCC version test which
should be part of Kbuild for this case, if someone changes the kernel
load address and don't know about the new Kconfig option, then it will
still fail...

thanks for answering...
-- 
               Franck

Re: [PATCH]: Remove CONFIG_BUILD_ELF64 entirely

[Atsushi Nemoto]

On Mon, 26 Mar 2007 15:54:03 +0200, "Franck Bui-Huu" <vagabon.xyz@gmail.com> wrote:
> You were asked several times why this patchset have not been
> considerated without any answers. So I have no clue why it's broken.

One thing I noticed recently: Your patchset dropped gcc test for
availability of -msym32, so may not work with gcc 3.x.

---
Atsushi Nemoto

Re: [PATCH]: Remove CONFIG_BUILD_ELF64 entirely

[Franck Bui-Huu]

Hi Atsushi,

On 3/26/07, Atsushi Nemoto <anemo@mba.ocn.ne.jp> wrote:
> One thing I noticed recently: Your patchset dropped gcc test for
> availability of -msym32, so may not work with gcc 3.x.
>

I suspect you're asking why I did not do this:

diff --git a/arch/mips/Makefile b/arch/mips/Makefile
index 3ec0c12..b0d8240 100644
--- a/arch/mips/Makefile
+++ b/arch/mips/Makefile
@@ -627,7 +627,7 @@ ifdef CONFIG_64BIT
   endif

   ifeq ($(KBUILD_SYM32), y)
-    cflags-y += -msym32 -DKBUILD_64BIT_SYM32
+    cflags-y += $(call cc-option,-msym32) -DKBUILD_64BIT_SYM32
   endif
 endif

I remove the call to cc-option because this function removes
_silently_ '-msym32' option if it's not supported by the compiler. IOW
it's really not what we want.

IIRC I haven't found an other function like 'cc-option-strict' which
makes a compilation error in case.

So I assumed that the compiler will complain if it doesn't understand
this option. But it may be incorrect. If so I can add an error message
in Kbuild or add a new Kbuild helper. But I'd like to understand
what's wrong with it before.

Thanks
-- 
               Franck

Re: [PATCH]: Remove CONFIG_BUILD_ELF64 entirely

[Atsushi Nemoto]

On Mon, 26 Mar 2007 17:31:18 +0200, "Franck Bui-Huu" <vagabon.xyz@gmail.com> wrote:
> I suspect you're asking why I did not do this:

Yes.

> I remove the call to cc-option because this function removes
> _silently_ '-msym32' option if it's not supported by the compiler. IOW
> it's really not what we want.
> 
> IIRC I haven't found an other function like 'cc-option-strict' which
> makes a compilation error in case.
> 
> So I assumed that the compiler will complain if it doesn't understand
> this option. But it may be incorrect. If so I can add an error message
> in Kbuild or add a new Kbuild helper. But I'd like to understand
> what's wrong with it before.

I think dropping gcc 3.x support for 64-bit kernel is not what we
wanted.  And -msym32 is just an optimization and kernel should be
buildable without it.  So "remove -msym32 silently" is not so bad, I
suppose.

"If you used newer compiler, you can get better result" is natural
thing, isn't it? ;)
---
Atsushi Nemoto

Re: [PATCH]: Remove CONFIG_BUILD_ELF64 entirely

[Franck Bui-Huu]

On 3/26/07, Atsushi Nemoto <anemo@mba.ocn.ne.jp> wrote:
> I think dropping gcc 3.x support for 64-bit kernel is not what we
> wanted.  And -msym32 is just an optimization and kernel should be
> buildable without it.  So "remove -msym32 silently" is not so bad, I
> suppose.
>
> "If you used newer compiler, you can get better result" is natural
> thing, isn't it? ;)

ok, I suppose a warning is fine. What about this patch on top of the patchset ?

diff --git a/arch/mips/Makefile b/arch/mips/Makefile
index 3ec0c12..b886945 100644
--- a/arch/mips/Makefile
+++ b/arch/mips/Makefile
@@ -627,7 +627,12 @@ ifdef CONFIG_64BIT
   endif

   ifeq ($(KBUILD_SYM32), y)
-    cflags-y += -msym32 -DKBUILD_64BIT_SYM32
+    ifeq ($(call cc-option-yn,-msym32), y)
+      cflags-y += -msym32 -DKBUILD_64BIT_SYM32
+    else
+      $(warning '-msym32' option is not supported by your compiler. \
+               You should use a new one to get best result)
+    endif
   endif
 endif
-- 
               Franck

Re: [PATCH]: Remove CONFIG_BUILD_ELF64 entirely

[Atsushi Nemoto]

On Mon, 26 Mar 2007 18:07:21 +0200, "Franck Bui-Huu" <vagabon.xyz@gmail.com> wrote:
> ok, I suppose a warning is fine. What about this patch on top of the patchset ?
> 
> diff --git a/arch/mips/Makefile b/arch/mips/Makefile
> index 3ec0c12..b886945 100644
> --- a/arch/mips/Makefile
> +++ b/arch/mips/Makefile
> @@ -627,7 +627,12 @@ ifdef CONFIG_64BIT
>    endif
> 
>    ifeq ($(KBUILD_SYM32), y)
> -    cflags-y += -msym32 -DKBUILD_64BIT_SYM32
> +    ifeq ($(call cc-option-yn,-msym32), y)
> +      cflags-y += -msym32 -DKBUILD_64BIT_SYM32
> +    else
> +      $(warning '-msym32' option is not supported by your compiler. \
> +               You should use a new one to get best result)
> +    endif
>    endif
>  endif

Well, I feel even a warning is intrusive, while it is not necessary
optimization.

---
Atsushi Nemoto

Re: [PATCH]: Remove CONFIG_BUILD_ELF64 entirely

[Franck Bui-Huu]

On 3/27/07, Atsushi Nemoto <anemo@mba.ocn.ne.jp> wrote:
> On Mon, 26 Mar 2007 18:07:21 +0200, "Franck Bui-Huu" <vagabon.xyz@gmail.com> wrote:
> > ok, I suppose a warning is fine. What about this patch on top of the patchset ?
> >
> > diff --git a/arch/mips/Makefile b/arch/mips/Makefile
> > index 3ec0c12..b886945 100644
> > --- a/arch/mips/Makefile
> > +++ b/arch/mips/Makefile
> > @@ -627,7 +627,12 @@ ifdef CONFIG_64BIT
> >    endif
> >
> >    ifeq ($(KBUILD_SYM32), y)
> > -    cflags-y += -msym32 -DKBUILD_64BIT_SYM32
> > +    ifeq ($(call cc-option-yn,-msym32), y)
> > +      cflags-y += -msym32 -DKBUILD_64BIT_SYM32
> > +    else
> > +      $(warning '-msym32' option is not supported by your compiler. \
> > +               You should use a new one to get best result)
> > +    endif
> >    endif
> >  endif
>
> Well, I feel even a warning is intrusive, while it is not necessary
> optimization.
>

OK, I'll remove it.

thanks
-- 
               Franck

Re: [PATCH]: Remove CONFIG_BUILD_ELF64 entirely

[Thiemo Seufer]

Franck Bui-Huu wrote:
> Hi Atsushi,
> 
> On 3/26/07, Atsushi Nemoto <anemo@mba.ocn.ne.jp> wrote:
> >One thing I noticed recently: Your patchset dropped gcc test for
> >availability of -msym32, so may not work with gcc 3.x.
> >
> 
> I suspect you're asking why I did not do this:
> 
> diff --git a/arch/mips/Makefile b/arch/mips/Makefile
> index 3ec0c12..b0d8240 100644
> --- a/arch/mips/Makefile
> +++ b/arch/mips/Makefile
> @@ -627,7 +627,7 @@ ifdef CONFIG_64BIT
>   endif
> 
>   ifeq ($(KBUILD_SYM32), y)
> -    cflags-y += -msym32 -DKBUILD_64BIT_SYM32
> +    cflags-y += $(call cc-option,-msym32) -DKBUILD_64BIT_SYM32
>   endif
> endif
> 
> I remove the call to cc-option because this function removes
> _silently_ '-msym32' option if it's not supported by the compiler. IOW
> it's really not what we want.

It is _exactly_ what we want. -msym32 is always an optional optimization.


Thiemo

Re: [PATCH]: Remove CONFIG_BUILD_ELF64 entirely

[Franck Bui-Huu]

On 3/25/07, Kumba <kumba@gentoo.org> wrote:
> I missed the other two additions to this patch, which is probably why it didn't
> work :)  Taken as a whole, they also boot my O2 now.
>

Argh !

-- 
               Franck

Re: Building 64 bit kernel on Cobalt

[Atsushi Nemoto]

On Sat, 24 Mar 2007 23:16:02 +0000, Thiemo Seufer <ths@networkno.de> wrote:
> IMO -msym32 should depend on:
>     ((Compiler can do -msym32)
>      && (load address is in ckseg0)
>      && CONFIG_64BIT)
> 
> which obsoletes the whole CONFIG_BUILD_ELF* stuff.

Sure.  And it is already done by Franck but is still pending (why?).

http://www.linux-mips.org/archives/linux-mips/2007-02/msg00228.html
http://www.linux-mips.org/archives/linux-mips/2007-02/msg00227.html
http://www.linux-mips.org/archives/linux-mips/2007-02/msg00231.html

---
Atsushi Nemoto