[ANNOUNCE] linux-loongson-2.6.30.1/2.6.29.6

[Wu Zhangjin]

We are pleased to announce linux-loongson-2.6.30.1 and
linux-loongson-2.6.29.6 are ready for you.

the main changes:

1. update to Linux 2.6.30.1/2.6.29.6
2. fix STD with CONFIG_FLATMEM
3. merge ec_modules(EC+PMON) in

homepage: http://dev.lemote.com/code/rt4ls

git branches:

git://dev.lemote.com/rt4ls.git linux-loongson/2.6.30/stable
git://dev.lemote.com/rt4ls.git linux-loongson/2.6.29/stable

tags:
linux-loongson-2.6.30.1-STD+EC
linux-loongson-2.6.29.6-STD+EC

the most important change is that we have merged EC modules in, so,
there is no need to download an extra ec_module, and also STD become
more stable.

if you want to build your own linux kernel from source code, an extra
rtl8187B wifi driver is needed, you can download the latest one here:

http://www.lemote.com/upfiles/wifi/rtl8187B_linux_26.1049.1215.2008_release2.tar.gz

and the following several relative documents are recommended.

* linux-loongson compiling guide

http://dev.lemote.com/code/rt4ls/wiki/linux-loongson-howto

* STD user-manual

http://dev.lemote.com/code/rt4ls/wiki/linux-loongson-std-howto

* more about loongson

http://groups.google.com/group/archlinux-for-loongson/web/loongson

and now, I'm planning to merge rtl8187B wifi driver in, hope I can
finish it asap.

Enjoy!
Wu Zhangjin

[Zhang Le]

On 21:25 Thu 09 Jul , Wu Zhangjin wrote:
> and now, I'm planning to merge rtl8187B wifi driver in, hope I can
> finish it asap.

I just tried your allinone branch, the rtl8187B driver failed in linking.
Because some of the .c files should be standalone modules, they have their own
module_init calls. When linking together, there will be multiple definition
errors.

--
Zhang, Le
Gentoo/Loongson Developer
http://zhangle.is-a-geek.org
0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973

[Wu Zhangjin]

Hi,

On Tue, 2009-07-14 at 02:11 +0800, Zhang Le wrote:
> On 21:25 Thu 09 Jul , Wu Zhangjin wrote:
> > and now, I'm planning to merge rtl8187B wifi driver in, hope I can
> > finish it asap.
>
> I just tried your allinone branch, the rtl8187B driver failed in linking.
> Because some of the .c files should be standalone modules, they have their own
> module_init calls. When linking together, there will be multiple definition
> errors.

just fixed it, thanks for your report.

PS: this failure only can be triggered when compiling it as a module.

Regards,
Wu Zhangjin

[Zhang Le]

On 15:16 Tue 14 Jul , Wu Zhangjin wrote:
>
> Hi,
>
> On Tue, 2009-07-14 at 02:11 +0800, Zhang Le wrote:
> > On 21:25 Thu 09 Jul , Wu Zhangjin wrote:
> > > and now, I'm planning to merge rtl8187B wifi driver in, hope I can
> > > finish it asap.
> >
> > I just tried your allinone branch, the rtl8187B driver failed in linking.
> > Because some of the .c files should be standalone modules, they have their own
> > module_init calls. When linking together, there will be multiple definition
> > errors.
>
> just fixed it, thanks for your report.

Thanks.

> PS: this failure only can be triggered when compiling it as a module.

Of course.

[Zhang Le]

On 15:16 Tue 14 Jul , Wu Zhangjin wrote:
>
> Hi,
>
> On Tue, 2009-07-14 at 02:11 +0800, Zhang Le wrote:
> > On 21:25 Thu 09 Jul , Wu Zhangjin wrote:
> > > and now, I'm planning to merge rtl8187B wifi driver in, hope I can
> > > finish it asap.
> >
> > I just tried your allinone branch, the rtl8187B driver failed in linking.
> > Because some of the .c files should be standalone modules, they have their own
> > module_init calls. When linking together, there will be multiple definition
> > errors.
>
> just fixed it, thanks for your report.

I just checked the fix:
http://dev.lemote.com/git?p=rt4ls.git;a=blobdiff;f=drivers/net/wireless/rtl8187b/ieee80211/ieee80211_crypt.c;h=85e00874a304e413c017f3dc7e0345bdba490276;hp=7e8a3ca565268e613acf1bfcd783d9b00c5ff412;hb=e25a98f50a7a1e9788003480087383181d6c35a2;hpb=ad7a3421ac4696c8f9a36a2c8521a2075a4a0ff3

I'd rather call it a workaround.

However, I agree that a "proper fix" maybe doesn't make sense at this time,
because this driver needs an overhaul anyway.

BTW, I found there is a rtl8187se driver under drivers/staging. Its directory
layout and component looks similar to 8187b. Could these two drivers be
integrated together?

[Wu Zhangjin]

Hi,

> > > I just tried your allinone branch, the rtl8187B driver failed in linking.
> > > Because some of the .c files should be standalone modules, they have their own
> > > module_init calls. When linking together, there will be multiple definition
> > > errors.
> >
> > just fixed it, thanks for your report.
>
> I just checked the fix:
> http://dev.lemote.com/git?p=rt4ls.git;a=blobdiff;f=drivers/net/wireless/rtl8187b/ieee80211/ieee80211_crypt.c;h=85e00874a304e413c017f3dc7e0345bdba490276;hp=7e8a3ca565268e613acf1bfcd783d9b00c5ff412;hb=e25a98f50a7a1e9788003480087383181d6c35a2;hpb=ad7a3421ac4696c8f9a36a2c8521a2075a4a0ff3
>
> I'd rather call it a workaround.
>
> However, I agree that a "proper fix" maybe doesn't make sense at this time,
> because this driver needs an overhaul anyway.
>

yes, that is only a workaround for this driver is very hard to maintain,
so, currently, I don't want to touch it a lot.

> BTW, I found there is a rtl8187se driver under drivers/staging. Its directory
> layout and component looks similar to 8187b. Could these two drivers be
> integrated together?

and seems there is another similar driver named rtl8187su/ in the latest
kernel git tree, I think both of them are not ready to 'play with',
perhaps they should be integrated in the not-long future.

and the sm712 driver in the linux kernel have the similar situation as
rtl8187b, is it better to use/maintain this one(not use it yet, seems
you have sent out several patches of it):
http://cgit.freedesktop.org/xorg/driver/xf86-video-siliconmotion/

Regards,
Wu Zhangjin

[Zhang Le]

On 21:18 Tue 14 Jul , Wu Zhangjin wrote:
> and the sm712 driver in the linux kernel have the similar situation as
> rtl8187b, is it better to use/maintain this one(not use it yet, seems
> you have sent out several patches of it):
> http://cgit.freedesktop.org/xorg/driver/xf86-video-siliconmotion/

Yes, I helped to fix a problem in xf86-video-siliconmotion (xorg version, as
opposed to manufacturer's version) so that it can be used on yeeloong.

I have already mentioned it here:
http://groups.google.com/group/loongson-dev/msg/83cc8fe21f794647

There are two bugs.freedesktop.org links, one of which is this problem.

The other problem is system sometimes hangs when using 16bit depth. And because
of this, dual head mode can't be used.

However, it seems there is a misunderstanding here. If this is the case, let
me explain a little bit. Otherwise, please ignore the following.

xf86-video-siliconmotion has nothing to do with kernel. It is an X's driver.

sm712 kernel driver has nothing to do with X, it is a frame buffer driver, used
in console mode. It will be used in X only if X uses xf86-video-fbdev as its
driver, i.e. X accesses graphic card via /dev/fb0.

If X uses xf86-video-siliconmotion, then sm712 kernel driver will not be used at
all.

Hope I've made it clear, :).

[Zhang Le]

On 21:18 Tue 14 Jul , Wu Zhangjin wrote:
>
> Hi,
>
> > > > I just tried your allinone branch, the rtl8187B driver failed in linking.
> > > > Because some of the .c files should be standalone modules, they have their own
> > > > module_init calls. When linking together, there will be multiple definition
> > > > errors.
> > >
> > > just fixed it, thanks for your report.
> >
> > I just checked the fix:
> > http://dev.lemote.com/git?p=rt4ls.git;a=blobdiff;f=drivers/net/wireless/rtl8187b/ieee80211/ieee80211_crypt.c;h=85e00874a304e413c017f3dc7e0345bdba490276;hp=7e8a3ca565268e613acf1bfcd783d9b00c5ff412;hb=e25a98f50a7a1e9788003480087383181d6c35a2;hpb=ad7a3421ac4696c8f9a36a2c8521a2075a4a0ff3
> >
> > I'd rather call it a workaround.
> >
> > However, I agree that a "proper fix" maybe doesn't make sense at this time,
> > because this driver needs an overhaul anyway.
> >
>
> yes, that is only a workaround for this driver is very hard to maintain,
> so, currently, I don't want to touch it a lot.

Have you tried it after fixing it?

It doesn't work here. Here is some log from dmesg:

rtl8187: rtl8187_open process
rtl8187: Now Radio ON!
rtl8187: Card successfully reset
rtl8187: DIG is enabled, set default initial gain index to 4
rtl8187: RTL8187 + 8225 Initial Gain State 4: -74 dBm
rtl8187: WIRELESS_MODE_G
rtl8187: rtl8187_open process complete
rtl8187: IPSEnter(): Turn off RF.
rtl8187: Now Radio OFF!
rtl8187: Setting SW wep key
wlan0: could not initialize WEP: load module ieee80211_crypt_wep
rtl8187: Setting SW wep key
rtl8187: ISLeave(): Turn on RF.

[Wu Zhangjin]

get it, thanks! I will try xf86-video-siliconmotion later.

Regards,
Wu Zhangjin

[Wu Zhangjin]

To make it work as a module, a new patch is needed, just test and commit
it, thanks very much for your test and report(sorry to forget to test it
before committing)!

Regards,
Wu Zhangjin

[yanhua]

Zhang Le 写道:

the official kernel have the rtl8187b support(test through to 2.6.29).
but it does not work properly. and it lack some functions.

--
晏华

[Zhang Le]

On 10:45 Wed 15 Jul , Wu Zhangjin wrote:
> To make it work as a module, a new patch is needed, just test and commit
> it, thanks very much for your test and report(sorry to forget to test it
> before committing)!

Thanks for taking care of this. It is now working perfectly.

But this patch actually is not only required for module.
And actually, I have tested both built-in and as a module, and neither worked.

And here is why, I just took a look around:

Previously, when

module_init(ieee80211_crypto_wep_init);

was not commented out, this function will be called either ieee80211_crypt_wep
is built into the kernel or exists as a separate module.

The reason I got that message is that WEP was never registered, which is a
consequence of ieee80211_crypto_wep_init() never being called (otherwise it
won't fail). And it is never been called is not because it is compiled as a
module. Please read on.

Now, thanks to the latest patch, ieee80211_crypto_wep_init() is now called in
rtl8187_usb_module_init(). And this is the only call in the whole driver, which
can be shown in the following grep result:

zhangle@2f ~/linux/drivers/net/wireless/rtl8187b (n32) $ grep -r ieee80211_crypto_wep_init *
ieee80211/ieee80211_crypt_wep.c:int __init ieee80211_crypto_wep_init(void)
ieee80211/ieee80211_crypt_wep.c:module_init(ieee80211_crypto_wep_init);
r8187_core.c:extern int ieee80211_crypto_wep_init(void);
r8187_core.c: ret = ieee80211_crypto_wep_init();
r8187_core.c: printk(KERN_ERR "ieee80211_crypto_wep_init() failed %d\n", ret);

Note the last second line, that's the call, and the only call.

Which means previously this is no call at all.

So that's why this patch is not only necessary for module.

[Erwan Lerale]

Wu Zhangjin a écrit :

Hello,

I'm trying to compile the kernel in the linux-loongson-2.6.30.1-STD+EC
branch, but the following occurs :

[...]
CC arch/mips/kernel/traps.o
cc1: warnings being treated as errors
arch/mips/kernel/traps.c: In function ‘set_uncached_handler’:
arch/mips/kernel/traps.c:1608: error: format not a string literal and no
format arguments
make[1]: *** [arch/mips/kernel/traps.o] Error 1
make: *** [arch/mips/kernel] Error 2
[...]

I have seen this post :
http://www.linux-mips.org/archives/linux-mips/2009-06/msg00338.html
but I don't have this patch on my system (gentoo n32 / gcc 4.4.0)

Any idea please ?

Cheers
Erwan

[Eric Fisher]

> CC arch/mips/kernel/traps.o
> cc1: warnings being treated as errors

Seems your platform (such as Ubuntu) has turned gcc flag '-Werror' on
in the default.

-Werror
Make all warnings into errors.

You can add '-Wno-error' into CFLAGS env variable.

Cheers,
Eric

[Wu Zhangjin]

Hi,

> I'm trying to compile the kernel in the linux-loongson-2.6.30.1-STD+EC
> branch, but the following occurs :
>

did you try linux-loongson-2.6.30.1-allinone? it includes the rtl8187b
wifi driver from realtek(just merged it about 2 or 3 days ago).

and perhaps the patch from Zhang Le is what you need to fix the
following compiling error.

Regards,
Wu Zhangjin

----------------

diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c
index 08f1edf..0e9922b 100644
--- a/arch/mips/kernel/traps.c
+++ b/arch/mips/kernel/traps.c
@@ -1601,7 +1601,7 @@ void __cpuinit set_uncached_handler(unsigned long
offset, void *addr,
#endif

if (!addr)
- panic(panic_null_cerr);
+ panic("%s", panic_null_cerr);

memcpy((void *)(uncached_ebase + offset), addr, size);

[Zhang Le]

On 10:52 Thu 16 Jul , Erwan Lerale wrote:
>
> Hello,
>
> I'm trying to compile the kernel in the linux-loongson-2.6.30.1-STD+EC
> branch, but the following occurs :
>
> [...]
> CC arch/mips/kernel/traps.o
> cc1: warnings being treated as errors
> arch/mips/kernel/traps.c: In function ‘set_uncached_handler’:
> arch/mips/kernel/traps.c:1608: error: format not a string literal and no
> format arguments
> make[1]: *** [arch/mips/kernel/traps.o] Error 1
> make: *** [arch/mips/kernel] Error 2
> [...]
>
> I have seen this post :
> http://www.linux-mips.org/archives/linux-mips/2009-06/msg00338.html
> but I don't have this patch on my system (gentoo n32 / gcc 4.4.0)
>
> Any idea please ?

You are just one step away from the solution:
http://www.linux-mips.org/archives/linux-mips/2009-06/msg00339.html

[Erwan Lerale]

Zhang Le wrote:
> On 10:52 Thu 16 Jul , Erwan Lerale wrote:
>
>> Hello,
>>
>> I'm trying to compile the kernel in the linux-loongson-2.6.30.1-STD+EC
>> branch, but the following occurs :
>>
>> [...]
>> CC arch/mips/kernel/traps.o
>> cc1: warnings being treated as errors
>> arch/mips/kernel/traps.c: In function ‘set_uncached_handler’:
>> arch/mips/kernel/traps.c:1608: error: format not a string literal and no
>> format arguments
>> make[1]: *** [arch/mips/kernel/traps.o] Error 1
>> make: *** [arch/mips/kernel] Error 2
>> [...]
>>
>> I have seen this post :
>> http://www.linux-mips.org/archives/linux-mips/2009-06/msg00338.html
>> but I don't have this patch on my system (gentoo n32 / gcc 4.4.0)
>>
>> Any idea please ?
>>
>
> You are just one step away from the solution:
> http://www.linux-mips.org/archives/linux-mips/2009-06/msg00339.html
>
>

Thanks that was the solution.

I should stop drinking :)

Cheers
Erwan