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
