Quoting "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>: > On Fri, 4 Apr 2003, Guido Guenther wrote: > > > > > Obtaining /vmlinux.64 from server > > > > 1813568+1150976+172144 entry: 0xa8000000211c4000 > > > > > > > > *** PROM write error on cacheline 0x1fcd3b00 at PC=0x211c4018 > RA=0xffffffff9fc5ace4 > > [..snip..] > > > > > > 0x211c4018 is a mapped address, which you can't use that early in a > boot. > > Isn't 0xa8000000211c4000 in xkphys and therefore unmapped? The PROM only > > seems to look at the lower 32bits of PC though. > > 0xa8000000211c4000 is indeed in XKPHYS but the code jumps to 0x211c4018. Ah, okay. I didn't understand the jr instruction there. That's generated as part of a macro: .macro ARC64_TWIDDLE_PC #if defined(CONFIG_ARC64) || defined(CONFIG_MAPPED_KERNEL) /* We get launched at a XKPHYS address but the kernel is linked to run at a KSEG0 address, so jump there. */ PTR_LA t0, \@f jr t0 \@: I was under the assumption that Octane is ARC64, I may be wrong. Clearly then, the kernel is linked at the wrong address to have this work. The question I have is, why is kseg0 used in this case? Is it due to the 32 to 64 bit conversion that happens later on in the build? It looks like the IP27 load address was originally 0xa80000000001c000, but was amended to 0x8001c000 for the current CVS(2.4) kernel. Again, due to the conversion? Erik -- Erik J. Green erik@greendragon.org
