linux-mips
[Top] [All Lists]

Re: [PATCH]: Remove CONFIG_BUILD_ELF64 entirely

To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Subject: Re: [PATCH]: Remove CONFIG_BUILD_ELF64 entirely
From: Kumba <kumba@gentoo.org>
Date: Fri, 30 Mar 2007 02:18:34 -0400
Cc: linux-mips@linux-mips.org, ths@networkno.de, ralf@linux-mips.org
In-reply-to: <20070329.235333.25910277.anemo@mba.ocn.ne.jp>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <460A6CED.1070308@gentoo.org> <20070329.002453.18311528.anemo@mba.ocn.ne.jp> <460B1B64.1040401@gentoo.org> <20070329.235333.25910277.anemo@mba.ocn.ne.jp>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Thunderbird 2.0b2 (Windows/20070116)
Atsushi Nemoto wrote:
Hmm... really strange.

This is OK:
                lui     k1, %highest(kernelsp)
                daddiu  k1, %higher(kernelsp)
                dsll    k1, k1, 16
                daddiu  k1, %hi(kernelsp)
                dsll    k1, k1, 16

This is NG:
                lui     k1, %hi(kernelsp)

So, could you try this one?

                nop
                nop
                nop
                nop
                lui     k1, %hi(kernelsp)

If it booted, the problem should be in something irrelevant place.
I.e. this optimization just triggers other bug by code/data movement.

Yup, it booted. On further testing at iluxa's behest, it turns out it may be some quirk/cpu errata related to the RM5200 I use in my O2. I swapped it out for a plain R5000 @ 200MHz, and removed the nop's -- boots fine.

This may also explain why the cobalt's were hitting something odd. They also use a member of the RM52xx family (RM5231 iirc, O2 uses an RM5261).


--Kumba

--
Gentoo/MIPS Team Lead

"Such is oft the course of deeds that move the wheels of the world: small hands do them because they must, while the eyes of the great are elsewhere." --Elrond

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