64 to 32 bit jr

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

Quoting "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>:
[deletions]
> > > > *** 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.

Okay, I want to make sure I understand the addressing correctly for the 64 to 32
bit jump.  The existing code for the IP27 (seems to load at about
a800000000000000, which is one of the segments in xkphys, corresponding to
physical memory starting at address 0.  Head.S then jumps to the 32-bit part of
the xkphys address, which happens to be arranged so that it matches the correct
(next instruction) address in kseg0.

I am unable to arrange my addresses similarly neatly, mostly I think due to
fighting with the toolchain I have.  Is it "legal" for me to load a kernel using
the xkphys address and then do something like:

lui    t0,0x8000
addiu  t0,t0,@next
jr     t0
nop
next:


to jump to the next instruction but in kseg0 instead of xkphys?  I believe the
jump target should be word aligned in this case because it's the start of an
instruction.  I'm assuming if I generate a jr to a 32 bit address that the cpu
will assume I'm jumping to a compatibility segment, am I wrong?

Erik




-- 
Erik J. Green
erik@greendragon.org