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.