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 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:



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

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?

Great! Many thanks for the link.

Now, there is something I do not understand:
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

I was able to make my GPRS card work with this kernel, so I'd say it does work.

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...

Click to view attachment

Hope this helps...

I will try (might need 2 weeks for an answer though).

-- hns

So, now I have had a chance to test the module. It does not complain about version mismatch on insmod but dmesg still says:

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.

Anton,
that would be great help for all GPRS/GPS users with a C1000/3x00 model!

I have read at http://qpegps.sourceforge.net/assets/gps_u...lux_gm_270.html 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 has patches only...

So, somebody out there with more knowledge what has to be pached?

-- hns

I now found how to download the full kernel packages from 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.

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...

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

Quite understandable...

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 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!)

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

Use the following link:

http://translate.google.com/translate?hl=e...hl%3Den%26lr%3D

And look for the part shown in the attached picture
Click to view attachment

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 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

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?

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:


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)!

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?

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.

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

Maybe the compiler. I used gcc-2.95.4

Or some other kernel configuration which includes one more statement?

-- hns

the default is 0 so it is not really required to add the 0.
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.
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

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.

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!

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!

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 says:

-- hns

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?

Sorry ! I have no bluetooth devices and I have just test with a HAICOM GPS CF