Kumba wrote:
[snip]
> 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.
BUILD_ELF64 + -sym32 + objcopy into a ELF32 file is supposed to be the
full replacement for the old o64-in-o32 hack.
> 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
The 64/64 configs can do both:
| BUILD_ELF64 | BUILD_ELF32
---------------------------------------------------
64bit firmware loader | CKSEG0/XKPHYS | CKSEG0
32bit firmware loader | CKSEG0 | CKSEG0
Thiemo
