Taking a walk on the mips64 side of the world, I'm compiling with the i386-linux=>mips64-linux cross tools from the rpms at oss.sgi.com. Looking at the build process, we build at kseg0, then objcopy and relocate to xkphys space as the last step in the build. I assume this is to work around the known elf64 compilation issues, and seems fine in theory. Unfortunately, it doesn't seem to quite work for me. Looking at bootmem_init() in arch/mips64/mm/init.c, __pa(&_end) is optimized down to a literal load during compilation: a800000000113a2c: 3c0280aa lui $v0,0x80aa a800000000113a30: 64427b18 daddiu $v0,$v0,31512 a800000000113a34: 0040202d move $a0,$v0 a800000000113a38: 3c035800 lui $v1,0x5800 a800000000113a3c: 0003183c dsll32 $v1,$v1,0x0 a800000000113a40: 34630fff ori $v1,$v1,0xfff a800000000113a44: 0043102d daddu $v0,$v0,$v1 This is the result of having &_end be in kseg0, but __pa assuming that it's in xkphys. Also, at this point, the relocation is gone. So when I objcopy, I'm left with the strange address from hell being passed in to bootmem_init(). This, of course, makes the kernel very unhappy. I could fix this instance any number of ways, but that doesn't seem to be a solution for the general problem...I'm sure this same kind of thing is going to bite me in a couple dozen other places. I assume other people are successfully building mips64 kernels with those tools; does anyone have any hints as to how to fix this? Thanks, -Justin carlson@sibyte.com
