Re: Unknown ARCS message/hang

["Erik J. Green" <erik@greendragon.org>]

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