Re: Building 64 bit kernel on Cobalt

[Kumba <kumba@gentoo.org>]

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