[Top] [All Lists]

Re: Unknown ARCS message/hang

To: "" <>
Subject: Re: Unknown ARCS message/hang
From: "Erik J. Green" <>
Date: Fri, 4 Apr 2003 14:57:30 +0000
In-reply-to: <>
Original-recipient: rfc822;
References: <>
User-agent: Internet Messaging Program (IMP) 4.0-cvs
Quoting "Maciej W. Rozycki" <>:

> 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 J. Green

<Prev in Thread] Current Thread [Next in Thread>