Re: MIPS Alchemy machine don't boot
Simon Burge <[email protected]> Sat, 09 Jan 2010 22:49:48 +1100
| Newsgroups | gmane.os.netbsd.ports.evbmips,gmane.os.netbsd.ports.mips.devel |
|---|---|
| Message-ID | <[email protected]> |
Simon Burge wrote: > KIYOHARA Takashi wrote: > > > Hi! Simon, > > > > > > From: Simon Burge <[email protected]> > > Date: Fri, 08 Jan 2010 23:03:20 +1100 > > > > > This is all sounding like some 64-bit code merge issue. I wonder if any > > > 32-bit evbmips machines were tested during or after that merge? > > > > I had not tested long time. > > > > Maybe, I cannot solve it. Should I post to tech-kern@ this problem? > > This should be the right list, but I've CC'd Matt Thomas as well. Which I forgot to do :) I've found the problem. In lock_stubs.S we have the following code: .set mips3 ... move t1, a2 which will always generate a 64-bit move, since the ".set mips3" will override any -mabi=<abi> command line flag. The following snippet from mipsX_subr.S shows what is needed. Perhaps we can wrap this up in a macro? /* * Set ISA level for the assembler. */ #if defined(MIPS3) .set mips3 #endif #if defined(MIPS32) .set mips32 #endif #if defined(MIPS64) .set mips64 #endif The three ".set mips3" in locore.S look to be safe. The same in locore_mips3.S I think we get lucky because we don't use "move" that file. We will need to fix that, but should be ok for today. Kiyohara - I've committed a workaround to lock_stubs.S - can you cvs update and test on your Alchemy board? I hope that this is the only place it causes a problem. I can't see any others in the kernel or userland. Matt - was there any testing the merged 64-bit code on 32-bit only hardware (either mips1 or mips32)? Cheers, Simon.