On Fri, 2009-05-15 at 10:25 +0200, Arnaud Patard wrote:
> Wu Zhangjin <wuzhangjin@xxxxxxxxx> writes:
>
> Hi,
>
> > Dear all,
> >
> > I have cleaned up the source code of loongson-based machines support and
> > updated it to linux-2.6.29.3, the result is put to the following git
> > repository:
> >
> > git://dev.lemote.com/rt4ls.git linux-2.6.29-stable-loongson-to-ralf
> >
> > this job is based on the to-mips branch of Yanhua's
> > git://dev.lemote.com/linux_loongson.git and the lm2e-fixes branch of
> > Philippe's git://git.linux-cisco.org/linux-mips.git. thanks goes to
> > them.
>
> I'd like to look at your patches but getting a git url prevents me to do
> this because replying/commenting is not possible. Can you please send
> patches to the list instead ?
>
Yes, I will tune some commits and then send the patches out.
thanks very much for your reply :-)
> >
> > I have tested it with gcc 4.3 on fuloong(2e), fuloong(2f), yeeloong(2f),
> > both 32bit and 64bit kernel works well, if you want to try it with gcc
> > 4.4, please use the patch from attachment.
>
> I have some questions/comments :
>
> - Why this patch is not merged in your patchset ?
this patch is not ready yet for several reasons:
1. under gcc 4.4(I'm using the version 4.4.0 20090313, not update to the
latest one yet), there are tons of problems when compiling
linux-loongson in 32bit. basically, 64bit is okay, but also some
problems there(i just found the reboot command of fuloong2f not work
under gcc4.4, but works well under gcc 4.3).
2. -march=loongson2* only goes into gcc >= 4.4, so, there is a need to
consider gcc >= 4.4 and gcc <= 4.3 differently, beside this compile
option, some extra source code should be treated differently too. for
example, this fix for gcc 4.4 will not work under gcc 4.3.
diff --git a/arch/mips/include/asm/delay.h
b/arch/mips/include/asm/delay.h
index b0bccd2..db054ec 100644
--- a/arch/mips/include/asm/delay.h
+++ b/arch/mips/include/asm/delay.h
@@ -82,12 +82,10 @@ static inline void __udelay(unsigned long usecs,
unsigned long lpj)
: "=h" (usecs), "=l" (lo)
: "r" (usecs), "r" (lpj)
: GCC_REG_ACCUM);
- else if (sizeof(long) == 8 && !R4000_WAR)
- __asm__("dmultu\t%2, %3"
- : "=h" (usecs), "=l" (lo)
- : "r" (usecs), "r" (lpj)
- : GCC_REG_ACCUM);
- else if (sizeof(long) == 8 && R4000_WAR)
+ else if (sizeof(long) == 8 && !R4000_WAR) {
+ typedef unsigned int uint128_t
__attribute__((mode(TI)));
+ usecs = ((uint128_t) usecs * lpj) >> 64;
+ } else if (sizeof(long) == 8 && R4000_WAR)
__asm__("dmultu\t%3, %4\n\tmfhi\t%0"
: "=r" (usecs), "=h" (hi), "=l" (lo)
: "r" (usecs), "r" (lpj
> - even if it should not affect the kernel, compiling with
> -march=loongson2f even for 2e (you're matching on loongson2 so 2e and
> 2f) looks weird.
sorry, this is really a very obvious error, in 2e, -march=loongson2e
should be used.
to fix this problem, perhaps we can add two new kernel options:
config CPU_LOONGSON2E
bool
config CPU_LOONGSON2F
bool
and then use this solution:
config FULOONG2E
...
select CPU_LOONGSON2E
...
config YEELOONG2F
...
select CPU_LOONGSON2F
...
cflags-$(CONFIG_CPU_LOONGSON2E) += -march=loongson2e -Wa,--trap
cflags-$(CONFIG_CPU_LOONGSON2F) += -march=loongson2f -Wa,--trap
is this solution okay?
> - you're using the -mfix-ls2f-kernel binutils flag but afaik upstream
> binutils doesn't know it. I really don't know how such a thing should
> be handled but it seems strange to use this flag before binutils has
> been patched for it. (the previous comment about -march=loongson2f
> applies here too)
>
so, it is better not use -mfix-ls2f-kernel before this option goes to
the upstream binutils, i will remove it later.
but for the above reasons, i really do not want to focus on gcc 4.4
support currently, is it okay?
thanks!
Wu Zhangjin
