[PATCH v3 0/3] Workaround the Out-of-order Issue of Loongson-2F

[PATCH v3 0/3] Workaround the Out-of-order Issue of Loongson-2F

[Wu Zhangjin]

From: Wu Zhangjin <wuzhangjin@gmail.com>

Hi, Ralf

Is that possible to apply this patchset for both 2.6.33(the stable release) and
2.6.34? then we can get a not broken support for loongson-2f with the
options(-mfix-loongson2f-nop, -mfix-loongson2f-jump) provided by the latest
binutils (>=2.20.1).

Thanks & Regards,
       Wu Zhangjin

-------

Changes:

v2->v3:

  o Herein, RAS is short for Return Address Stack not Row Address Strobe, at
  the same time, the "model" in the translation of Chapter 15 should be "mode".
  (feedback from Shinya Kuribayashi)
	
v1->v2:

  o Cleanup some comments and align some instructions.
  
----

As the Chapter 15: "Errata: Issue of Out-of-order in loongson"[1] shows, to
workaround the Issue of Loongson-2F，We need to do:

  o When switching from user mode to kernel mode, you should flush the branch
  target history such as BTB and RAS.
 
  o Doing some tricks to the indirect branch target to make sure that the
  indirect branch target can not be in the I/O region.

This patchset applied the above methods and for the binutils patch[3] have been
merged into binutils 2.20.1, so, it's time to upstream this patchset now.
without this patch, the machines will hang when the instruction sequence hit
the Out-of-order Issue of Loongson-2F, therefore, this patchset is very urgent
for both 2.6.33 and 2.6.34.

[1] Chinese Version: http://www.loongson.cn/uploadfile/file/20080821113149.pdf
[2] English Version of Chapter 15:
http://groups.google.com.hk/group/loongson-dev/msg/e0d2e220958f10a6?dmode=source
[3] http://sourceware.org/ml/binutils/2009-11/msg00387.html 

Regards,
        Wu Zhangjin

Wu Zhangjin (3):
  Loongson-2F: Flush the branch target history such as BTB and RAS
  Loongson-2F: Enable fixups of binutils 2.20.1
  Loongson-2F: Fixup of problems introduced by -mfix-loongson2f-jump of
    binutils 2.20.1

 arch/mips/Makefile                 |    4 +++-
 arch/mips/include/asm/stackframe.h |   19 +++++++++++++++++++
 arch/mips/loongson/common/reset.c  |   11 ++++++++++-
 3 files changed, 32 insertions(+), 2 deletions(-)

[PATCH v3 1/3] Loongson-2F: Flush the branch target history such as BTB and RAS

[Wu Zhangjin]

From: Wu Zhangjin <wuzhangjin@gmail.com>

As the Chapter 15: "Errata: Issue of Out-of-order in loongson"[1] shows, to
workaround the Issue of Loongson-2F，We need to do:

"When switching from user mode to kernel mode, you should flush the
branch target history such as BTB and RAS."

This patch did clear BTB(branch target buffer), forbid RAS(return
address stack) via Loongson-2F's 64bit diagnostic register.

[1] Chinese Version: http://www.loongson.cn/uploadfile/file/200808211
[2] English Version of Chapter 15:
http://groups.google.com.hk/group/loongson-dev/msg/e0d2e220958f10a6?dmode=source

Signed-off-by: Wu Zhangjin <wuzhangjin@gmail.com>
---
 arch/mips/include/asm/stackframe.h |   19 +++++++++++++++++++
 1 files changed, 19 insertions(+), 0 deletions(-)

diff --git a/arch/mips/include/asm/stackframe.h b/arch/mips/include/asm/stackframe.h
index 3b6da33..c841912 100644
--- a/arch/mips/include/asm/stackframe.h
+++ b/arch/mips/include/asm/stackframe.h
@@ -121,6 +121,25 @@
 		.endm
 #else
 		.macro	get_saved_sp	/* Uniprocessor variation */
+#ifdef CONFIG_CPU_LOONGSON2F
+		/*
+		 * Clear BTB (branch target buffer), forbid RAS (return address
+		 * stack) to workaround the Out-of-order Issue in Loongson2F
+		 * via its diagnostic register.
+		 */
+		move	k0, ra
+		jal	1f
+		 nop
+1:		jal	1f
+		 nop
+1:		jal	1f
+		 nop
+1:		jal	1f
+		 nop
+1:		move	ra, k0
+		li	k0, 3
+		mtc0	k0, $22
+#endif /* CONFIG_CPU_LOONGSON2F */
 #if defined(CONFIG_32BIT) || defined(KBUILD_64BIT_SYM32)
 		lui	k1, %hi(kernelsp)
 #else
-- 
1.7.0.1

Re: [PATCH v3 1/3] Loongson-2F: Flush the branch target history such as BTB and RAS

[Ralf Baechle]

On Sat, Mar 13, 2010 at 12:34:15PM +0800, Wu Zhangjin wrote:

> From: Wu Zhangjin <wuzhangjin@gmail.com>
> 
> As the Chapter 15: "Errata: Issue of Out-of-order in loongson"[1] shows, to
> workaround the Issue of Loongson-2F，We need to do:
> 
> "When switching from user mode to kernel mode, you should flush the
> branch target history such as BTB and RAS."
> 
> This patch did clear BTB(branch target buffer), forbid RAS(return
> address stack) via Loongson-2F's 64bit diagnostic register.
> 
> [1] Chinese Version: http://www.loongson.cn/uploadfile/file/200808211
> [2] English Version of Chapter 15:
> http://groups.google.com.hk/group/loongson-dev/msg/e0d2e220958f10a6?dmode=source

Thanks, applied.

  Ralf

Re: [PATCH v3 1/3] Loongson-2F: Flush the branch target history such as BTB and RAS

[Andreas Barth]

* Wu Zhangjin (wuzhangjin@gmail.com) [100313 05:45]:
> This patch did clear BTB(branch target buffer), forbid RAS(return
> address stack) via Loongson-2F's 64bit diagnostic register.

Unfortunatly the Loongson 2F here still fails with this patch,
compiled with the new binutils and both options enabled.

Testcase: plain debian unstable chroot, build binutils in that chroot.

More ideas, codes, whatever welcome.



Andi

Re: [PATCH v3 1/3] Loongson-2F: Flush the branch target history such as BTB and RAS

[Wu Zhangjin]

On Fri, 2010-04-02 at 16:54 +0200, Andreas Barth wrote:
> * Wu Zhangjin (wuzhangjin@gmail.com) [100313 05:45]:
> > This patch did clear BTB(branch target buffer), forbid RAS(return
> > address stack) via Loongson-2F's 64bit diagnostic register.
> 
> Unfortunatly the Loongson 2F here still fails with this patch,
> compiled with the new binutils and both options enabled.
> 
> Testcase: plain debian unstable chroot, build binutils in that chroot.
> 
> More ideas, codes, whatever welcome.

Hi,

This patch is not enough, please use the kernel(>=2.6.32) from
http://dev.lemote.com/code/rt4ls or
http://dev.lemote.com/code/linux-loongson-community

Regards,
	Wu Zhangjin

Re: [PATCH v3 1/3] Loongson-2F: Flush the branch target history such as BTB and RAS

[Andreas Barth]

* Wu Zhangjin (wuzhangjin@gmail.com) [100403 03:50]:
> On Fri, 2010-04-02 at 16:54 +0200, Andreas Barth wrote:
> > * Wu Zhangjin (wuzhangjin@gmail.com) [100313 05:45]:
> > > This patch did clear BTB(branch target buffer), forbid RAS(return
> > > address stack) via Loongson-2F's 64bit diagnostic register.
> > 
> > Unfortunatly the Loongson 2F here still fails with this patch,
> > compiled with the new binutils and both options enabled.
> > 
> > Testcase: plain debian unstable chroot, build binutils in that chroot.
> > 
> > More ideas, codes, whatever welcome.


> This patch is not enough, please use the kernel(>=2.6.32) from
> http://dev.lemote.com/code/rt4ls or
> http://dev.lemote.com/code/linux-loongson-community

The kernel vmlinuz-2.6.33-lemote2f-bfs inside of
http://www.anheng.com.cn/loongson/install/loongson2_debian6_20100328.tar.lzma
(linked via linux-loongson-community) fails at the same place:

touch stamp-picdir
if [ x"-fPIC" != x ]; then \
          gcc -c -DHAVE_CONFIG_H -g -O2  -I. -I../../libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic  -fPIC ../../libiberty/regex.c -o pic/regex.o; \
        else true; fi
gcc -c -DHAVE_CONFIG_H -g -O2  -I. -I../../libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic  ../../libiberty/regex.c -o regex.o
if [ x"-fPIC" != x ]; then \
          gcc -c -DHAVE_CONFIG_H -g -O2  -I. -I../../libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic  -fPIC ../../libiberty/cplus-dem.c -o pic/cplus-dem.o; \
        else true; fi


Any other kernel I should try?



Andi

Re: [PATCH v3 1/3] Loongson-2F: Flush the branch target history such as BTB and RAS

[Wu Zhangjin]

On Tue, 2010-04-06 at 21:10 +0200, Andreas Barth wrote:
[...]
> 
> The kernel vmlinuz-2.6.33-lemote2f-bfs inside of
> http://www.anheng.com.cn/loongson/install/loongson2_debian6_20100328.tar.lzma
> (linked via linux-loongson-community) fails at the same place:
> 
> touch stamp-picdir
> if [ x"-fPIC" != x ]; then \
>           gcc -c -DHAVE_CONFIG_H -g -O2  -I. -I../../libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic  -fPIC ../../libiberty/regex.c -o pic/regex.o; \
>         else true; fi
> gcc -c -DHAVE_CONFIG_H -g -O2  -I. -I../../libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic  ../../libiberty/regex.c -o regex.o
> if [ x"-fPIC" != x ]; then \
>           gcc -c -DHAVE_CONFIG_H -g -O2  -I. -I../../libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic  -fPIC ../../libiberty/cplus-dem.c -o pic/cplus-dem.o; \
>         else true; fi
> 

When & where did you get the above information?

do you mean the kernel can not boot or there are some other problems
after the kernel booting?

I guess: the whole system crashed when you was compiling something? then
please ensure the as & ld is ok via fixing the NOPS with the tool
(fix-nop.c) from  http://dev.lemote.com/code/linux-loongson-community :

$ ./fix-nop `which as`
$ ./fix-nop `which ld`

> 
> Any other kernel I should try?
> 

The kernel in the above link should boot, or you can compile one
yourself.

Regards,
	Wu Zhangjin

Re: [PATCH v3 1/3] Loongson-2F: Flush the branch target history such as BTB and RAS

[Andreas Barth]

* Wu Zhangjin (wuzhangjin@gmail.com) [100407 09:38]:
> On Tue, 2010-04-06 at 21:10 +0200, Andreas Barth wrote:
> [...]
> > 
> > The kernel vmlinuz-2.6.33-lemote2f-bfs inside of
> > http://www.anheng.com.cn/loongson/install/loongson2_debian6_20100328.tar.lzma
> > (linked via linux-loongson-community) fails at the same place:
> > 
> > touch stamp-picdir
> > if [ x"-fPIC" != x ]; then \
> >           gcc -c -DHAVE_CONFIG_H -g -O2  -I. -I../../libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic  -fPIC ../../libiberty/regex.c -o pic/regex.o; \
> >         else true; fi
> > gcc -c -DHAVE_CONFIG_H -g -O2  -I. -I../../libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic  ../../libiberty/regex.c -o regex.o
> > if [ x"-fPIC" != x ]; then \
> >           gcc -c -DHAVE_CONFIG_H -g -O2  -I. -I../../libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic  -fPIC ../../libiberty/cplus-dem.c -o pic/cplus-dem.o; \
> >         else true; fi
> > 
> 
> When & where did you get the above information?
> 
> do you mean the kernel can not boot or there are some other problems
> after the kernel booting?
> 
> I guess: the whole system crashed when you was compiling something? then
> please ensure the as & ld is ok via fixing the NOPS with the tool
> (fix-nop.c) from  http://dev.lemote.com/code/linux-loongson-community :

The kernel does boot, but the whole machines crashes.

I know the fixups (I have adjusted binutils), but I need an kernel
that userland cannot crash (otherwise it gets a bit hard to run that
as debian buildd).


Andi

Re: [PATCH v3 1/3] Loongson-2F: Flush the branch target history such as BTB and RAS

[Wu Zhangjin]

On Sat, 2010-04-10 at 10:10 +0200, Andreas Barth wrote:
> * Wu Zhangjin (wuzhangjin@gmail.com) [100407 09:38]:
> > On Tue, 2010-04-06 at 21:10 +0200, Andreas Barth wrote:
> > [...]
> > > 
> > > The kernel vmlinuz-2.6.33-lemote2f-bfs inside of
> > > http://www.anheng.com.cn/loongson/install/loongson2_debian6_20100328.tar.lzma
> > > (linked via linux-loongson-community) fails at the same place:
> > > 
> > > touch stamp-picdir
> > > if [ x"-fPIC" != x ]; then \
> > >           gcc -c -DHAVE_CONFIG_H -g -O2  -I. -I../../libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic  -fPIC ../../libiberty/regex.c -o pic/regex.o; \
> > >         else true; fi
> > > gcc -c -DHAVE_CONFIG_H -g -O2  -I. -I../../libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic  ../../libiberty/regex.c -o regex.o
> > > if [ x"-fPIC" != x ]; then \
> > >           gcc -c -DHAVE_CONFIG_H -g -O2  -I. -I../../libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic  -fPIC ../../libiberty/cplus-dem.c -o pic/cplus-dem.o; \
> > >         else true; fi
> > > 
> > 
> > When & where did you get the above information?
> > 
> > do you mean the kernel can not boot or there are some other problems
> > after the kernel booting?
> > 
> > I guess: the whole system crashed when you was compiling something? then
> > please ensure the as & ld is ok via fixing the NOPS with the tool
> > (fix-nop.c) from  http://dev.lemote.com/code/linux-loongson-community :
> 
> The kernel does boot, but the whole machines crashes.
> 
> I know the fixups (I have adjusted binutils), but I need an kernel
> that userland cannot crash (otherwise it gets a bit hard to run that
> as debian buildd).
> 
> 

The userland canot be prevented from crash without user-space fixups,
that's why we need the fix-nop.c to fix the NOPs in the binaries of
user-land applications or using the -mfix-loongson-nop to compile the
user-land applications.

If you just need to rebuild debian, you just need to fix the NOPs in the
as and ld with fix-nop.c as I have mentioned before:

$ ./fix-nop $(which as)
$ ./fix-nop $(which ld)

Regards,
	Wu Zhangjin

Re: [PATCH v3 1/3] Loongson-2F: Flush the branch target history such as BTB and RAS

[Zhang Le]

On 16:54 Fri 02 Apr     , Andreas Barth wrote:
> * Wu Zhangjin (wuzhangjin@gmail.com) [100313 05:45]:
> > This patch did clear BTB(branch target buffer), forbid RAS(return
> > address stack) via Loongson-2F's 64bit diagnostic register.
> 
> Unfortunatly the Loongson 2F here still fails with this patch,
> compiled with the new binutils and both options enabled.

Which version of binutils exactly?
The patch is in cvs, but latest binutils-2.20.1 still didn't include it.
You need to patch it.

Zhang, Le

Re: [PATCH v3 1/3] Loongson-2F: Flush the branch target history such as BTB and RAS

[Andreas Barth]

* Zhang Le (r0bertz@gentoo.org) [100403 04:20]:
> On 16:54 Fri 02 Apr     , Andreas Barth wrote:
> > * Wu Zhangjin (wuzhangjin@gmail.com) [100313 05:45]:
> > > This patch did clear BTB(branch target buffer), forbid RAS(return
> > > address stack) via Loongson-2F's 64bit diagnostic register.
> > 
> > Unfortunatly the Loongson 2F here still fails with this patch,
> > compiled with the new binutils and both options enabled.
> 
> Which version of binutils exactly?
> The patch is in cvs, but latest binutils-2.20.1 still didn't include it.
> You need to patch it.

Yes, binutils are patched with
http://sourceware.org/ml/binutils/2009-11/msg00387.html


Andi

[PATCH v3 2/3] Loongson-2F: Enable fixups of binutils 2.20.1

[Wu Zhangjin]

From: Wu Zhangjin <wuzhangjin@gmail.com>

As the "Fixups of Loongson2F" patch[1] to binutils have been applied
into binutils 2.20.1. It's time to enable the options provided by the
patch to compile the kernel.

Without these fixups, the system will hang unexpectedly for the bug of
processor.

To learn more about these fixups, please refer to the following
references.

[1] "Fixups of Loongson2F" patch for binutils(actually for gas)
http://sourceware.org/ml/binutils/2009-11/msg00387.html
[2] Chapter 15 of "Loongson2F User Manual"(Chinese Version)
http://www.loongson.cn/uploadfile/file/200808211
[3] English Version of the above chapter 15
http://groups.google.com.hk/group/loongson-dev/msg/e0d2e220958f10a6?dmode=source

Signed-off-by: Zhang Le <r0bertz@gentoo.org>
Signed-off-by: Wu Zhangjin <wuzj@lemote.com>
---
 arch/mips/Makefile |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/arch/mips/Makefile b/arch/mips/Makefile
index 2f2eac2..5ae342e 100644
--- a/arch/mips/Makefile
+++ b/arch/mips/Makefile
@@ -135,7 +135,9 @@ cflags-$(CONFIG_CPU_LOONGSON2)	+= -Wa,--trap
 cflags-$(CONFIG_CPU_LOONGSON2E) += \
 	$(call cc-option,-march=loongson2e,-march=r4600)
 cflags-$(CONFIG_CPU_LOONGSON2F) += \
-	$(call cc-option,-march=loongson2f,-march=r4600)
+	$(call cc-option,-march=loongson2f,-march=r4600) \
+	$(call as-option,-Wa$(comma)-mfix-loongson2f-nop,) \
+	$(call as-option,-Wa$(comma)-mfix-loongson2f-jump,)
 
 cflags-$(CONFIG_CPU_MIPS32_R1)	+= $(call cc-option,-march=mips32,-mips32 -U_MIPS_ISA -D_MIPS_ISA=_MIPS_ISA_MIPS32) \
 			-Wa,-mips32 -Wa,--trap
-- 
1.7.0.1

Re: [PATCH v3 2/3] Loongson-2F: Enable fixups of binutils 2.20.1

[Ralf Baechle]

On Sat, Mar 13, 2010 at 12:34:16PM +0800, Wu Zhangjin wrote:

> diff --git a/arch/mips/Makefile b/arch/mips/Makefile
> index 2f2eac2..5ae342e 100644
> --- a/arch/mips/Makefile
> +++ b/arch/mips/Makefile
> @@ -135,7 +135,9 @@ cflags-$(CONFIG_CPU_LOONGSON2)	+= -Wa,--trap
>  cflags-$(CONFIG_CPU_LOONGSON2E) += \
>  	$(call cc-option,-march=loongson2e,-march=r4600)
>  cflags-$(CONFIG_CPU_LOONGSON2F) += \
> -	$(call cc-option,-march=loongson2f,-march=r4600)
> +	$(call cc-option,-march=loongson2f,-march=r4600) \
> +	$(call as-option,-Wa$(comma)-mfix-loongson2f-nop,) \
> +	$(call as-option,-Wa$(comma)-mfix-loongson2f-jump,)

Shouldn't these options be used unconditionally?  It seems a kernel build
should rather fail than a possibly unreliable kernel be built - possibly
even without the user noticing the problem.

  Ralf

Re: [PATCH v3 2/3] Loongson-2F: Enable fixups of binutils 2.20.1

[Zhang Le]

On 14:52 Wed 17 Mar     , Ralf Baechle wrote:
> On Sat, Mar 13, 2010 at 12:34:16PM +0800, Wu Zhangjin wrote:
> 
> > diff --git a/arch/mips/Makefile b/arch/mips/Makefile
> > index 2f2eac2..5ae342e 100644
> > --- a/arch/mips/Makefile
> > +++ b/arch/mips/Makefile
> > @@ -135,7 +135,9 @@ cflags-$(CONFIG_CPU_LOONGSON2)	+= -Wa,--trap
> >  cflags-$(CONFIG_CPU_LOONGSON2E) += \
> >  	$(call cc-option,-march=loongson2e,-march=r4600)
> >  cflags-$(CONFIG_CPU_LOONGSON2F) += \
> > -	$(call cc-option,-march=loongson2f,-march=r4600)
> > +	$(call cc-option,-march=loongson2f,-march=r4600) \
> > +	$(call as-option,-Wa$(comma)-mfix-loongson2f-nop,) \
> > +	$(call as-option,-Wa$(comma)-mfix-loongson2f-jump,)
> 
> Shouldn't these options be used unconditionally?  It seems a kernel build
> should rather fail than a possibly unreliable kernel be built - possibly
> even without the user noticing the problem.

Zhangjin has been busy preparing for his graduation paper.
I just talked to him. He said later batches of 2F processor is not affected by
these two problems, according to Zhang Fuxin, manager of Lemote.

I am not sure on which model of Fuloong and Yeeloong these "good" 2F processors
have been used. I think Fuxin should know this.

If Fuxin could told us now, we can make a new patch. In this patch, we decide
whether to add these options or not base on the model number.

Otherwise, for now, I think we should enable these options unconditionally.

Zhang, Le

Re: [PATCH v3 2/3] Loongson-2F: Enable fixups of binutils 2.20.1

[Zhang Le]

On 16:29 Sat 27 Mar     , Zhang Le wrote:
> On 14:52 Wed 17 Mar     , Ralf Baechle wrote:
> > On Sat, Mar 13, 2010 at 12:34:16PM +0800, Wu Zhangjin wrote:
> > 
> > > diff --git a/arch/mips/Makefile b/arch/mips/Makefile
> > > index 2f2eac2..5ae342e 100644
> > > --- a/arch/mips/Makefile
> > > +++ b/arch/mips/Makefile
> > > @@ -135,7 +135,9 @@ cflags-$(CONFIG_CPU_LOONGSON2)	+= -Wa,--trap
> > >  cflags-$(CONFIG_CPU_LOONGSON2E) += \
> > >  	$(call cc-option,-march=loongson2e,-march=r4600)
> > >  cflags-$(CONFIG_CPU_LOONGSON2F) += \
> > > -	$(call cc-option,-march=loongson2f,-march=r4600)
> > > +	$(call cc-option,-march=loongson2f,-march=r4600) \
> > > +	$(call as-option,-Wa$(comma)-mfix-loongson2f-nop,) \
> > > +	$(call as-option,-Wa$(comma)-mfix-loongson2f-jump,)
> > 
> > Shouldn't these options be used unconditionally?  It seems a kernel build
> > should rather fail than a possibly unreliable kernel be built - possibly
> > even without the user noticing the problem.
> 
> Zhangjin has been busy preparing for his graduation paper.
> I just talked to him. He said later batches of 2F processor is not affected by
> these two problems, according to Zhang Fuxin, manager of Lemote.
> 
> I am not sure on which model of Fuloong and Yeeloong these "good" 2F processors
> have been used. I think Fuxin should know this.
> 
> If Fuxin could told us now, we can make a new patch. In this patch, we decide
> whether to add these options or not base on the model number.
> 
> Otherwise, for now, I think we should enable these options unconditionally.

Sorry, I got Zhang Fuxin's email wrong. Now fixed.

Zhang, Le

Re: [PATCH v3 2/3] Loongson-2F: Enable fixups of binutils 2.20.1

[zhangfx]

The revision with these bugs fixed is 2F03. Up to now all processors 
used in current products are 2F01/02.
2F03 is in production and expected in this summer.

Zhang Le wrote:
> On 16:29 Sat 27 Mar     , Zhang Le wrote:
>   
>> On 14:52 Wed 17 Mar     , Ralf Baechle wrote:
>>     
>>> On Sat, Mar 13, 2010 at 12:34:16PM +0800, Wu Zhangjin wrote:
>>>
>>>       
>>>> diff --git a/arch/mips/Makefile b/arch/mips/Makefile
>>>> index 2f2eac2..5ae342e 100644
>>>> --- a/arch/mips/Makefile
>>>> +++ b/arch/mips/Makefile
>>>> @@ -135,7 +135,9 @@ cflags-$(CONFIG_CPU_LOONGSON2)	+= -Wa,--trap
>>>>  cflags-$(CONFIG_CPU_LOONGSON2E) += \
>>>>  	$(call cc-option,-march=loongson2e,-march=r4600)
>>>>  cflags-$(CONFIG_CPU_LOONGSON2F) += \
>>>> -	$(call cc-option,-march=loongson2f,-march=r4600)
>>>> +	$(call cc-option,-march=loongson2f,-march=r4600) \
>>>> +	$(call as-option,-Wa$(comma)-mfix-loongson2f-nop,) \
>>>> +	$(call as-option,-Wa$(comma)-mfix-loongson2f-jump,)
>>>>         
>>> Shouldn't these options be used unconditionally?  It seems a kernel build
>>> should rather fail than a possibly unreliable kernel be built - possibly
>>> even without the user noticing the problem.
>>>       
>> Zhangjin has been busy preparing for his graduation paper.
>> I just talked to him. He said later batches of 2F processor is not affected by
>> these two problems, according to Zhang Fuxin, manager of Lemote.
>>
>> I am not sure on which model of Fuloong and Yeeloong these "good" 2F processors
>> have been used. I think Fuxin should know this.
>>
>> If Fuxin could told us now, we can make a new patch. In this patch, we decide
>> whether to add these options or not base on the model number.
>>
>> Otherwise, for now, I think we should enable these options unconditionally.
>>     
>
> Sorry, I got Zhang Fuxin's email wrong. Now fixed.
>
> Zhang, Le
>
>   

-- 
张福新 Zhang Fuxin
龙芯梦兰 管理部 总经理 Lemote General Manager 
zhangfx@lemote.com

Re: [PATCH v3 2/3] Loongson-2F: Enable fixups of binutils 2.20.1

[Wu Zhangjin]

On Wed, 2010-03-17 at 14:52 +0100, Ralf Baechle wrote:
> On Sat, Mar 13, 2010 at 12:34:16PM +0800, Wu Zhangjin wrote:
> 
> > diff --git a/arch/mips/Makefile b/arch/mips/Makefile
> > index 2f2eac2..5ae342e 100644
> > --- a/arch/mips/Makefile
> > +++ b/arch/mips/Makefile
> > @@ -135,7 +135,9 @@ cflags-$(CONFIG_CPU_LOONGSON2)	+= -Wa,--trap
> >  cflags-$(CONFIG_CPU_LOONGSON2E) += \
> >  	$(call cc-option,-march=loongson2e,-march=r4600)
> >  cflags-$(CONFIG_CPU_LOONGSON2F) += \
> > -	$(call cc-option,-march=loongson2f,-march=r4600)
> > +	$(call cc-option,-march=loongson2f,-march=r4600) \
> > +	$(call as-option,-Wa$(comma)-mfix-loongson2f-nop,) \
> > +	$(call as-option,-Wa$(comma)-mfix-loongson2f-jump,)
> 
> Shouldn't these options be used unconditionally?  It seems a kernel build
> should rather fail than a possibly unreliable kernel be built - possibly
> even without the user noticing the problem.

Thanks for your good suggestion!

Just added a new kernel config option: CPU_LOONGSON2F_WORKAROUNDS to
allow the users to enable the workarounds for the necessary loongson2f
batches and it is enabled by default. And to force the users to use the
right binutils with the workarounds, errors will be printed on the
standard output with the following stuff:

  ifeq ($(call as-option,-Wa$(comma)-mfix-loongson2f-nop,),)
    $(error gcc does not support needed option -mfix-loongson2f-nop)
  else
    cflags-$(CONFIG_CPU_NOP_WORKAROUNDS) += -Wa
$(comma)-mfix-loongson2f-nop
  endif

Will resend the new patchset with your feedbacks asap.

Regards,
	Wu Zhangjin

[PATCH v3 3/3] Loongson-2F: Fixup of problems introduced by -mfix-loongson2f-jump of binutils 2.20.1

[Wu Zhangjin]

From: Wu Zhangjin <wuzhangjin@gmail.com>

The -mfix-loongson2f-jump option provided by the binutils 2.20.1 have fixed the
Out-of-order Issue of Loongson-2F described in Chapter 15 of "Loongson2F User
Manual"[1,2], but introduced some problems.

The option changes all of the jumping target to "addr & 0xcfffffff" through the
at($1) register, but for the REBOOT address of loongson-2F: 0xbfc00000, this is
totally wrong, so, this patch try to avoid the problem via telling the
assembler not to use at($1) register.

[1] Loongson2F User Manual(Chinese Version)
http://www.loongson.cn/uploadfile/file/200808211
[2] English Version of Chapter 15:
http://groups.google.com.hk/group/loongson-dev/msg/e0d2e220958f10a6?dmode=source

Reported-and-tested-by: Liu Shiwei <liushiwei@gmail.com>
Signed-off-by: Wu Zhangjin <wuzhangjin@gmail.com>
---
 arch/mips/loongson/common/reset.c |   11 ++++++++++-
 1 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/arch/mips/loongson/common/reset.c b/arch/mips/loongson/common/reset.c
index 4bd9c18..dc311f2 100644
--- a/arch/mips/loongson/common/reset.c
+++ b/arch/mips/loongson/common/reset.c
@@ -21,8 +21,17 @@ static void loongson_restart(char *command)
 	/* do preparation for reboot */
 	mach_prepare_reboot();
 
-	/* reboot via jumping to boot base address */
+	/* reboot via jumping to boot base address
+	 *
+	 * ".set noat" and ".set at" are used to ensure the address not break
+	 * by the -mfix-loongson2f-jump option provided by binutils 2.20.1 (or
+	 * higher version) which try to change the jumping address to "addr &
+	 * 0xcfffffff" via the at($1) register, this is totally wrong for
+	 * 0xbfc00000 (LOONGSON_BOOT_BASE).
+	 */
+	__asm__ __volatile__(".set noat\n");
 	((void (*)(void))ioremap_nocache(LOONGSON_BOOT_BASE, 4)) ();
+	__asm__ __volatile__(".set at\n");
 }
 
 static void loongson_poweroff(void)
-- 
1.7.0.1

Re: [PATCH v3 3/3] Loongson-2F: Fixup of problems introduced by -mfix-loongson2f-jump of binutils 2.20.1

[Ralf Baechle]

On Sat, Mar 13, 2010 at 12:34:17PM +0800, Wu Zhangjin wrote:

> -	/* reboot via jumping to boot base address */
> +	/* reboot via jumping to boot base address
> +	 *
> +	 * ".set noat" and ".set at" are used to ensure the address not break
> +	 * by the -mfix-loongson2f-jump option provided by binutils 2.20.1 (or
> +	 * higher version) which try to change the jumping address to "addr &
> +	 * 0xcfffffff" via the at($1) register, this is totally wrong for
> +	 * 0xbfc00000 (LOONGSON_BOOT_BASE).
> +	 */
> +	__asm__ __volatile__(".set noat\n");
>  	((void (*)(void))ioremap_nocache(LOONGSON_BOOT_BASE, 4)) ();
> +	__asm__ __volatile__(".set at\n");

Ouch.  This is fragile and totally puts the kernels fate at the mercy of
gcc and the ioremap_nocache() implementation.  GCC might emit a .set noat
at any time.  Something like

void loongson_restart(char *command)
{
	void (*func)(void);

	/* do preparation for reboot */
	mach_prepare_reboot();

	/* reboot via jumping to boot base address */
	func = (void *) ioremap_nocache(LOONGSON_BOOT_BASE, 4);

	__asm__ __volatile__(
	"	.set	noat						\n"
	"	jr	%[func]						\n"
	"	.set	at						\n"
	: /* No outputs */
	: [func] "r" (func));
}

should be safe against -mfix-loongson2f-jump I think.

The workaround in http://sourceware.org/ml/binutils/2009-11/msg00387.html
will also cause problems calling functions with bits 28..29 set, that is
in the ranges 0x81000000..0xbffffff and 0xd0000000..0xffffffff.  The
first range is not much of a problem as only the kernel proper resides
there and the kernel load address is manually selected in the Makefile.
The 2nd range might be used for under certain circumstances.

  Ralf

Re: [PATCH v3 3/3] Loongson-2F: Fixup of problems introduced by -mfix-loongson2f-jump of binutils 2.20.1

[Zhang Le]

On 16:02 Wed 17 Mar     , Ralf Baechle wrote:
> The workaround in http://sourceware.org/ml/binutils/2009-11/msg00387.html
> will also cause problems calling functions with bits 28..29 set, that is

Yes. If all functions address doesn't have 28..29 set, this patch will not have
any side effect. That means all functions should reside in two ranges:
0x80000000..0x8fffffff
0xc0000000..0xcfffffff

> in the ranges 0x81000000..0xbffffff and 0xd0000000..0xffffffff.  The
                ^^^^^^^^^^
I think you mean 0x90000000, right?

> first range is not much of a problem as only the kernel proper resides
> there and the kernel load address is manually selected in the Makefile.
> The 2nd range might be used for under certain circumstances.

It seems the Loongson kernel I compiled satisfies the requirement I listed
above:

ffffffff80200000 A _text
...
ffffffff8089bbe0 A _end

So, if I understand it correctly, as long as the kernel size is smaller than
254MB, the patch should be ok. Is there anything I overlooked?

Zhang, Le

Re: [PATCH v3 3/3] Loongson-2F: Fixup of problems introduced by -mfix-loongson2f-jump of binutils 2.20.1

[Wu Zhangjin]

On Wed, 2010-03-17 at 16:02 +0100, Ralf Baechle wrote:
> On Sat, Mar 13, 2010 at 12:34:17PM +0800, Wu Zhangjin wrote:
> 
> > -	/* reboot via jumping to boot base address */
> > +	/* reboot via jumping to boot base address
> > +	 *
> > +	 * ".set noat" and ".set at" are used to ensure the address not break
> > +	 * by the -mfix-loongson2f-jump option provided by binutils 2.20.1 (or
> > +	 * higher version) which try to change the jumping address to "addr &
> > +	 * 0xcfffffff" via the at($1) register, this is totally wrong for
> > +	 * 0xbfc00000 (LOONGSON_BOOT_BASE).
> > +	 */
> > +	__asm__ __volatile__(".set noat\n");
> >  	((void (*)(void))ioremap_nocache(LOONGSON_BOOT_BASE, 4)) ();
> > +	__asm__ __volatile__(".set at\n");
> 
> Ouch.  This is fragile and totally puts the kernels fate at the mercy of
> gcc and the ioremap_nocache() implementation.  GCC might emit a .set noat
> at any time.  Something like
> 
> void loongson_restart(char *command)
> {
> 	void (*func)(void);
> 
> 	/* do preparation for reboot */
> 	mach_prepare_reboot();
> 
> 	/* reboot via jumping to boot base address */
> 	func = (void *) ioremap_nocache(LOONGSON_BOOT_BASE, 4);
> 
> 	__asm__ __volatile__(
> 	"	.set	noat						\n"
> 	"	jr	%[func]						\n"
> 	"	.set	at						\n"
> 	: /* No outputs */
> 	: [func] "r" (func));
> }
> 
> should be safe against -mfix-loongson2f-jump I think.

Thanks very much, will apply it in the revision of this patch.

Regards,
	Wu Zhangjin