Re: IP32 prom crashes due to __pa() funkiness

[Franck Bui-Huu <vagabon.xyz@gmail.com>]

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