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
