On Mon, 19 Mar 2007 10:24:34 -0400, Kumba <firstname.lastname@example.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...