[Top] [All Lists]

Re: IP32 prom crashes due to __pa() funkiness

To: Franck <>
Subject: Re: IP32 prom crashes due to __pa() funkiness
From: Kumba <>
Date: Mon, 19 Mar 2007 10:24:34 -0400
Cc: Linux MIPS List <>, Arnaud Giersch <>
In-reply-to: <>
Original-recipient: rfc822;
References: <> <> <> <> <> <>
User-agent: Thunderbird 2.0b2 (Windows/20070116)
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

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

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


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

<Prev in Thread] Current Thread [Next in Thread>