OESF Portables Forum
Everything Else => Sharp Zaurus => Model Specific Forums => Distros, Development, and Model Specific Forums => Archived Forums => C1000/3x00 General discussions => Topic started by: dhns on July 31, 2005, 03:54:06 pm
-
I am looking for a patched serial_cs.o like the one mentioned on http://64.233.183.104/search?q=cache:3PMhO...rus+serial_cs.c (http://64.233.183.104/search?q=cache:3PMhO9FzW3sJ:qpegps.sourceforge.net/assets/gps_units/holux_gm_270.html+bad+vcc+patch+zaurus+serial_cs.c) but compiled for Linux 2.4.20 which is used in the C3000 models.
The 2.4.18-rmk7-pxa3-embedix version I have for the C7/8x0 models does not load properly on a 2.4.20 kernel even if forced to:
# insmod -f serial_cs
Using /lib/modules/2.4.20/pcmcia/serial_cs.o
Warning: kernel-module version mismatch
    /lib/modules/2.4.20/pcmcia/serial_cs.o was compiled for kernel version 2.4.18-rmk7-pxa3-embedix
    while this kernel is version 2.4.20
/lib/modules/2.4.20/pcmcia/serial_cs.o: init_module: Invalid argument
Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters
Has anybody already compiled it, since I don't have the development system to do that?
I don't have source code of the patch, but I found reports that it is already patched in the 2.4.21 sources as mentioned in the URL above. So one would have to get the 2.4.21 (or later) source, just compile within the 2.4.20 environment and publish here.
Any support will be appreciated since some CF cards need the patched driver to work properly.
-- hns
-
You can try and have a look at this page: http://www.steyla.com/zaurus.html (http://www.steyla.com/zaurus.html)
There's a kernel in there which should have the serial stuff built-in. I found this while I was looking for a serial_cs module to use my GPRS CF card on the C3000, maybe it can help you?
-
You can try and have a look at this page: http://www.steyla.com/zaurus.html (http://www.steyla.com/zaurus.html)
There's a kernel in there which should have the serial stuff built-in. I found this while I was looking for a serial_cs module to use my GPRS CF card on the C3000, maybe it can help you?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=90405\"][{POST_SNAPBACK}][/a][/div]
Great! Many thanks for the link.
Now, there is something I do not understand:It might also work, if one would only provide a serial_cs.o module. But why not do it the 'right' way? Be aware, just providing a serial_cs.c from a newer > 2.4.21 Linux vanilla kernel will work, but it will lead to complete crashes as there have been some modifications made to serial_cs by Sharp.
So what: does it work or does it not work?
I would prefer to have just a matching serial_cs.o to install instead of a complete kernel...
-- hns
-
So what: does it work or does it not work?
I was able to make my GPRS card work with this kernel, so I'd say it does work.
I would prefer to have just a matching serial_cs.o to install instead of a complete kernel...
You might want to try this module I compiled back in February. Can't tell you if this one module does work or not, since (due to other problems) I wasn't succesfull at that time, and I've since switched to Tetsu's special kernel so I didn't try again after getting the rest in working order...
[ You are not allowed to view attachments ]
Hope this helps...
-
You might want to try this module I...
I will try (might need 2 weeks for an answer though).
-- hns
-
You might want to try this module I compiled back in February. Can't tell you if this one module does work or not, since (due to other problems) I wasn't succesfull at that time, and I've since switched to Tetsu's special kernel so I didn't try again after getting the rest in working order...
[ You are not allowed to view attachments ]
Hope this helps...
[div align=\"right\"][a href=\"index.php?act=findpost&pid=90560\"][{POST_SNAPBACK}][/a][/div]
So, now I have had a chance to test the module. It does not complain about version mismatch on insmod but dmesg still says:
pxa_pcmcia_init(0)
serial_cs: RequestConfiguration: Bad Vcc
#So, we still need somebody to compile a patched serial_cs for the 2.4.20 kernel...
Volunteers, links, pointers, everybody welcome!
-- hns
-
I can compile it if someone gives me the source code of the patched version.
-
I can compile it if someone gives me the source code of the patched version.
[div align=\"right\"][{POST_SNAPBACK}][/a][/div] (http://index.php?act=findpost&pid=92839\")
Anton,
that would be great help for all GPRS/GPS users with a C1000/3x00 model!
I have read at [a href=\"http://qpegps.sourceforge.net/assets/gps_units/holux_gm_270.html]http://qpegps.sourceforge.net/assets/gps_u...lux_gm_270.html[/url] that the serial_cs.c from Linux 2.4.21 should work (version 1.138). So, if you can get that somehow...
Others reported that there have been patches by Sharp to the serial_cs. So, it might have to become a mixture of the patched 2.4.20 and the patch applied to 2.4.21.
Unfortunately, I have no idea what has been changed to make the bad Vcc message disappear. And http://www.linuxhq.com/kernel/v2.4/21/drivers/char/serial.c (http://www.linuxhq.com/kernel/v2.4/21/drivers/char/serial.c) has patches only...
So, somebody out there with more knowledge what has to be pached?
-- hns
-
So, if you can get that somehow...
I now found how to download the full kernel packages from http://www.linuxhq.com/kernel/v2.4/ (http://www.linuxhq.com/kernel/v2.4/).
Attached are both source files from "official" 2.4.20 (1.128) and 2.4.21 (1.138) and a diff.
Comparing 2.4.20 to the Sharp kernel should reveal any changes they have made. And comparing to 2.4.21 should show what needs to be done for the Vcc issue. Indeed looking at diff shows some changes to the Vcc logic.
-- hns
-
OK, I will have a look
-
Actualy it turns out that Sharp kernel already includes a copy of serial_cs (version 1.138) form 2.4.21 with a bunch of patches.
-
Actualy it turns out that Sharp kernel already includes a copy of serial_cs (version 1.138) form 2.4.21 with a bunch of patches.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=93037\"][{POST_SNAPBACK}][/a][/div]
Interesting! But it fails for the Audiovox RTM8000... So, the Sharp patches might not be correct.
-
Did you try using another kernel, like for instance the latest hacked kernel for the C3000 on Tetsu's site? I'm using v18a, and the serial stuff is built-in (i.e. not in a module), and it handles my GSM/GPRS CF card gracefully. When looking a the dmesg output, I see a lot of stuff related to adjusting the voltage when I insert/remove the card in the Zaurus...
-
Did you try using another kernel, like for instance the latest hacked kernel for the C3000 on Tetsu's site?
No, because I want/need a module for the Original ROM because it is easier to install for everybody...
Is the source for the serial_cs.c for the Tetsu kernel available somewhere? Or a note what he did patch to make it work?
-- hns
-
No, because I want/need a module for the Original ROM because it is easier to install for everybody...
Quite understandable...
Is the source for the serial_cs.c for the Tetsu kernel available somewhere? Or a note what he did patch to make it work?
I think that all the patches Tetsu included in his kernel are available from the same page, you should be able to patch the stock Sharp kernel and recompile it, making the serial stuff a module.
I would gladly try to do this, but I'm almost deprived of free time for even such simple projects until mid October at least...
-
I think that all the patches Tetsu included in his kernel are available from the same page, you should be able to patch the stock Sharp kernel and recompile it, making the serial stuff a module.
I have tried to find my way through the translation of his page (having two Safari windows open - one with translation, original the other :-).
I found an .ipk (SL-C1000/C3000 kernel modules (v18a))for additional kernel modules (e.g. Bluetooth) for the C3000 but it does contain only the directory ./lib/modules/2.4.20/pcmcia/ but no patch. So, he must have patched that to the kernel, but I can't find.
-- hns
-
Hello!
I remember I had problems with GPS CF when I developed a software for Zaurus
I have cross-compiled the serial_cs.o from the Linux kernel 2.4.29 and it works!
I have done a memo for this
I have test on a Zaurus SL-C760 but I will try to see if it works on a my Zaurus SL-C3100
(sorry for my english, I'm french!)
-
I cross-compile the serial_cs.o from the Linux kernel 2.4.29 and it works!
I have test on a Zaurus SL-C760 but I will try to see if it works on a my Zaurus SL-C3100
That would be great! I already have a working serial_cs.o for the C7x0/860 models (Kernel 2.4.18) but couldn't find any one for the C3000/3100 models with 2.4.20 kernel.
-- hns
-
I have tried to find my way through the translation of his page (having two Safari windows open - one with translation, original the other :-).
I found an .ipk (SL-C1000/C3000 kernel modules (v18a))for additional kernel modules (e.g. Bluetooth) for the C3000 but it does contain only the directory ./lib/modules/2.4.20/pcmcia/ but no patch. So, he must have patched that to the kernel, but I can't find.
Use the following link:
http://translate.google.com/translate?hl=e...hl%3Den%26lr%3D (http://translate.google.com/translate?hl=en&sl=ja&u=http://tetsu.homelinux.org/zaurus/kernel/&prev=/search%3Fq%3Dc3000%2Bupdater%26hl%3Den%26lr%3D)
And look for the part shown in the attached picture
[ You are not allowed to view attachments ]
All the patches are available as text files from the main page (P01, P02, etc.) so it shouldn't be too hard to get them, apply them to the stock 3000 kernel sources and recompile it with serial as a module...
Happy compiling!
-
Try this
don't forget to run "cardctl resume 0 "
I see when I cross-compile my kernel that serial_cs is not compiled as module so you should cross-compile your own kernel and disable serial_cs than copy my serial_cs.o to /lib/modules/2.4.20/kernel/drivers/pcmcia (on the Zaurus)
-
I have tried to find my way through the translation of his page (having two Safari windows open - one with translation, original the other :-).
I found an .ipk (SL-C1000/C3000 kernel modules (v18a))for additional kernel modules (e.g. Bluetooth) for the C3000 but it does contain only the directory ./lib/modules/2.4.20/pcmcia/ but no patch. So, he must have patched that to the kernel, but I can't find.
Use the following link:
http://translate.google.com/translate?hl=e...hl%3Den%26lr%3D (http://translate.google.com/translate?hl=en&sl=ja&u=http://tetsu.homelinux.org/zaurus/kernel/&prev=/search%3Fq%3Dc3000%2Bupdater%26hl%3Den%26lr%3D)
And look for the part shown in the attached picture
[ You are not allowed to view attachments ]
All the patches are available as text files from the main page (P01, P02, etc.) so it shouldn't be too hard to get them, apply them to the stock 3000 kernel sources and recompile it with serial as a module...
Happy compiling!
[div align=\"right\"][a href=\"index.php?act=findpost&pid=93123\"][{POST_SNAPBACK}][/a][/div]
I already had translated that - but which one modifies the serial_cs for PCMCIA? If I want to just patch that, I can't apply any other patch to the kernel...
-- hns
-
Try this
Great!
This seems to work on the C3000! I just got the first ATI response!
Just wondering why there are so many kernels out there when installing a module is sufficient...
-- hns
-
So, te buttomline is to use the module from 2.4.29 kernel? What about Sharp patches? Does it work fine with stock modules without them?
-
I already had translated that - but which one modifies the serial_cs for PCMCIA? If I want to just patch that, I can't apply any other patch to the kernel...
Look in the (P11) bluetooth-mh18_041216 patch, it seems that the serial_cs file gets patched in there (didn't have an extensive look, it's just that at line #5644 you find this:
diff -Nur c3000_pre/linux/drivers/char/pcmcia/serial_cs.c c3000_work/linux/drivers/char/pcmcia/serial_cs.c
--- c3000_pre/linux/drivers/char/pcmcia/serial_cs.c 2004-08-21 09:48:33.000000000 +0900
+++ c3000_work/linux/drivers/char/pcmcia/serial_cs.c 2004-12-16 23:01:14.000000000 +0900
@@ -2,7 +2,7 @@
A driver for PCMCIA serial devices
- serial_cs.c 1.128 2001/10/18 12:18:35
+ serial_cs.c 1.138 2002/10/25 06:24:52
I'll leave it up to you to check if there's anything usefull for you in there (as for me, there isn't much I can make sense of, my C knowledge being very limited)!
-
Just wondering why there are so many kernels out there when installing a module is sufficient...
As far as I could make out from the Japanese stuff, Tetsu's kernel contains a lot of bug fixes and improvements that make it a valuable choice, and which couldn't necessarily be implemented as standalone modules... but then I may be wrong, I'm not a kernel guru.
-
Actualy I didn't see any difference between 2.4.21 and 2.4.31 versions of the serial_cs code. Maybe "cardctl resume 0" comamnd was the key?
-
Actualy I didn't see any difference between 2.4.21 and 2.4.31 versions of the serial_cs code. Maybe "cardctl resume 0" comamnd was the key?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=93211\"][{POST_SNAPBACK}][/a][/div]
I remember that I had troubles with my Audiovox-compatible card at the beginning. It wouldn't work at all, until I indeed issued that "cardctl resume 0" command (the key on the 3000 is to append the slot number to the resume command, as there are two slots unlike the older devices).
Then I was able to play with the card using minicom, and proceed to other things like getting PPP to work with it. That's when I discovered that I needed to resume the card for minicom to see it, but if it was resumed I coudln't use it with the GUI to connect to the net (using PPP), which required it to be suspended first. Go figure!
Right now I seem to have somehow damaged the card when transporting it along with my Zaurus, as I can't stay connected for more than 30 seconds or so, and I've (temporarily at least) put it aside while I have serious work to do... I'll play again with it in a few weeks/months.
-
Actualy I didn't see any difference between 2.4.21 and 2.4.31 versions of the serial_cs code. Maybe "cardctl resume 0" comamnd was the key?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=93211\"][{POST_SNAPBACK}][/a][/div]
Hm,
the two serial_cs.o files posted here differ in file length by 4 bytes. And the second one works (at least for my C3000 + Audiovox RTM 8000).
No Idea why.
-- hns
-
Actualy I didn't see any difference between 2.4.21 and 2.4.31 versions of the serial_cs code. Maybe "cardctl resume 0" comamnd was the key?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=93211\"][{POST_SNAPBACK}][/a][/div]
Hm,
the two serial_cs.o files posted here differ in file length by 4 bytes. And the second one works (at least for my C3000 + Audiovox RTM 8000).
No Idea why.
-- hns
[div align=\"right\"][a href=\"index.php?act=findpost&pid=93233\"][{POST_SNAPBACK}][/a][/div]
Maybe the compiler. I used gcc-2.95.4
-
Maybe the compiler. I used gcc-2.95.4
[div align=\"right\"][a href=\"index.php?act=findpost&pid=93294\"][{POST_SNAPBACK}][/a][/div]
Or some other kernel configuration which includes one more statement?
-- hns
-
I remember that I had troubles with my Audiovox-compatible card at the beginning. It wouldn't work at all, until I indeed issued that "cardctl resume 0" command (the key on the 3000 is to append the slot number to the resume command, as there are two slots unlike the older devices).
the default is 0 so it is not really required to add the 0.
Then I was able to play with the card using minicom, and proceed to other things like getting PPP to work with it. That's when I discovered that I needed to resume the card for minicom to see it, but if it was resumed I coudln't use it with the GUI to connect to the net (using PPP), which required it to be suspended first. Go figure!
That is some strange logic within cardctl and some cards. When inserting, some cards come up suspended and others resumed. And many programs assume that it is in the "right" state initially. And that will conflict.
Right now I seem to have somehow damaged the card when transporting it along with my Zaurus, as I can't stay connected for more than 30 seconds or so,
Hm. Is that for voice or for data calls or both? It might be the antenna - if it is broken the signal quality is very bad and it might be very dependent on small movements of the card (especially indoors). You could try to test that with AT+CSQ=?
-- hns
-
I have used serial_cs source from Linux-kernel 2.4.31
And I have replaced the directories of the zaurus's kernel source tree with this one and compile it as module
I have a kernel with Tetsu's patchs and used the .config file from arch/arm/def-config/borzoi-j
I have no other 'special configuration' except IPv6 and those from Tetsu's patchs
-
the default is 0 so it is not really required to add the 0.
Funny. When I issue a "cardctl resume" command, I always get a "ioctl(): Device or resource busy" error message (which I also get when performing a cardctl resume 1, i.e. when I resume the (already operating) microdrive).
Likewise, when I issue "cardctl suspend", it does suspend both slots, not just the #0 slot, and if I don't immediately resume the #1 slot the Zaurus crashes, of course, whenever it tries to access any file on the microdrive.
So with my setup, at least, the cardctl command doesn't default to 0. I'm using Cacko 1.23 beta ROM on the 3000.
That is some strange logic within cardctl and some cards. When inserting, some cards come up suspended and others resumed. And many programs assume that it is in the "right" state initially. And that will conflict.
Yeah, that's what I finally figured out... Not a big deal but back when I was trying to configure the card it didn't make my life easy!
Hm. Is that for voice or for data calls or both? It might be the antenna - if it is broken the signal quality is very bad and it might be very dependent on small movements of the card (especially indoors). You could try to test that with AT+CSQ=?
I'll try reinstalling minicom (haven't done so since I installed the latest beta of the Cacko ROM) and check. The card would work fine in "standby" (i.e. when not connected), but it woulnd't keep a GPRS connection for long, either in my Zaurus or in my laptop PC, with no particular movement of either device - although that last point might be harder to confirm as a bad electrical contact would suffer from the sligtest vibration... Thanks for your suggestion, anyway!
-
the default is 0 so it is not really required to add the 0.
Funny. When I issue a "cardctl resume" command, I always get a "ioctl(): Device or resource busy" error message (which I also get when performing a cardctl resume 1, i.e. when I resume the (already operating) microdrive).
Likewise, when I issue "cardctl suspend", it does suspend both slots, not just the #0 slot, and if I don't immediately resume the #1 slot the Zaurus crashes, of course, whenever it tries to access any file on the microdrive.
So with my setup, at least, the cardctl command doesn't default to 0. I'm using Cacko 1.23 beta ROM on the 3000.
You are right - I was mislead by the C860 which has only one slot in operation. The official manual entry http://pcmcia-cs.sourceforge.net/man/cardctl.8.html (http://pcmcia-cs.sourceforge.net/man/cardctl.8.html) says: If a socket number is specified, the command will be applied to just one socket; otherwise, all sockets will be affected.
-- hns
-
I have used serial_cs source from Linux-kernel 2.4.31
And I have replaced the directories of the zaurus's kernel source tree with this one and compile it as module
I have a kernel with Tetsu's patchs and used the .config file from arch/arm/def-config/borzoi-j
I have no other 'special configuration' except IPv6 and those from Tetsu's patchs
[div align=\"right\"][a href=\"index.php?act=findpost&pid=93298\"][{POST_SNAPBACK}][/a][/div]
OK, this means that Sharp's modifications to the serial_cs source add VCC problem to the driver.
Did you test this driver with other serial-based devices, such as bluetooth cards?
-
OK, this means that Sharp's modifications to the serial_cs source add VCC problem to the driver.
Did you test this driver with other serial-based devices, such as bluetooth cards?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=93661\"][{POST_SNAPBACK}][/a][/div]
Sorry ! I have no bluetooth devices and I have just test with a HAICOM GPS CF