Hi,
Attached is a very experimental driver for a Ricoh SD Card reader that can be
found in some notebooks like the Samsung P35.
Whenever a sd card is inserted into one of these notebooks, a virtual pcmcia
card will show up:
Socket 0:
product info: "RICOH", "Bay1Controller", "", ""
manfid: 0x0000, 0x0000
In order to write this driver I hacked qemu to have access to the cardbus
bridge containing this card. I then logged the register accesses of the
windows xp driver and tryed to analyse them.
As the meanings of most of the register are still unknown to me, I consider
this driver very experimental. It is possible that this driver might destroy
your data or your hardware. Use at your own risk!
Other problems:
- I only implemented reading support
- I only tested with a 128 MB SD card, no idea what would be needed to support
other card types
- irqs are not supported
- dma is not supported
- it is very slow
- the registers can be found on the cardbus bridge and not on the virtual
pcmcia card. The cardbus bridge is already claimed by yenta_socket.
Therefore the driver currently uses pci_find_device to find the cardbus
bridge containing the sd card reader registers.
- it will probably crash when you remove the sd card without unmounting first
- the ios stuff is not really understood
- there are a bunch of extra MMC_APP_CMDs inside the driver
- only tested with kernel 2.6.18
apart from all these problems reading an image from my sd card seems to have
worked ;)
If you are still brave enough to try it out make at least a backup of the data
on your sd card.
Feedback is highly appreciated.
Regards
Sascha
Sascha Sommer wrote:
> Hi,
>
> Attached is a very experimental driver for a Ricoh SD Card reader that can be
> found in some notebooks like the Samsung P35.
>
> Whenever a sd card is inserted into one of these notebooks, a virtual pcmcia
> card will show up:
>
> Socket 0:
> product info: "RICOH", "Bay1Controller", "", ""
> manfid: 0x0000, 0x0000
>
> In order to write this driver I hacked qemu to have access to the cardbus
> bridge containing this card. I then logged the register accesses of the
> windows xp driver and tryed to analyse them.
>
> As the meanings of most of the register are still unknown to me, I consider
> this driver very experimental. It is possible that this driver might destroy
> your data or your hardware. Use at your own risk!
>
> Other problems:
> - I only implemented reading support
> - I only tested with a 128 MB SD card, no idea what would be needed to support
> other card types
> - irqs are not supported
> - dma is not supported
> - it is very slow
> - the registers can be found on the cardbus bridge and not on the virtual
> pcmcia card. The cardbus bridge is already claimed by yenta_socket.
> Therefore the driver currently uses pci_find_device to find the cardbus
- pci_find_device is no go today. Use pci_get_device (+ pci_dev_get, _put).
- ioremap->pci_iomap
- iobase should be __iomem.
- codingstyle (char* buffer, for(loop, if(data){, ...)
regards,
--
http://www.fi.muni.cz/~xslaby/ Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E
Hi,
Sascha Sommer, le Sun 07 Jan 2007 00:32:26 +0100, a ?crit :
> Attached is a very experimental driver for a Ricoh SD Card reader that can be
> found in some notebooks like the Samsung P35.
Yehaaaw! That reader can be found on DELL X300 too. It works almost fine
for me, see attached dmesg. These I/O errors didn't prevent me from
mounting a card, though.
> In order to write this driver I hacked qemu to have access to the cardbus
> bridge containing this card. I then logged the register accesses of the
> windows xp driver and tryed to analyse them.
Great to see people brave enough to do such tedious work :D
> - I only tested with a 128 MB SD card, no idea what would be needed to support
> other card types
Unfortunately, I don't have other cards either.
> - only tested with kernel 2.6.18
Tested with 2.6.19 without source change.
> apart from all these problems reading an image from my sd card seems to have
> worked ;)
The IO errors make dd stop on my box. I tried to set TIMEOUT to 1000
(this is a slow card) without better results. Tell me if there are
things I can test.
I'm not subscribed to linux-kernel, so please remember to Cc me when
posting updates, etc. so I can test them.
Samuel
Sascha Sommer wrote:
> Hi,
>
> Attached is a very experimental driver for a Ricoh SD Card reader that can be
> found in some notebooks like the Samsung P35.
>
Impressive. Keep up the good work. :)
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
Hi,
On Sunday 07 January 2007 10:56, Jiri Slaby wrote:
> Sascha Sommer wrote:
> > Hi,
> >
> > Attached is a very experimental driver for a Ricoh SD Card reader that
> > can be found in some notebooks like the Samsung P35.
> >
> > Whenever a sd card is inserted into one of these notebooks, a virtual
> > pcmcia card will show up:
> >
> > Socket 0:
> > product info: "RICOH", "Bay1Controller", "", ""
> > manfid: 0x0000, 0x0000
> >
> > In order to write this driver I hacked qemu to have access to the cardbus
> > bridge containing this card. I then logged the register accesses of the
> > windows xp driver and tryed to analyse them.
> >
> > As the meanings of most of the register are still unknown to me, I
> > consider this driver very experimental. It is possible that this driver
> > might destroy your data or your hardware. Use at your own risk!
> >
> > Other problems:
> > - I only implemented reading support
> > - I only tested with a 128 MB SD card, no idea what would be needed to
> > support other card types
> > - irqs are not supported
> > - dma is not supported
> > - it is very slow
> > - the registers can be found on the cardbus bridge and not on the virtual
> > pcmcia card. The cardbus bridge is already claimed by yenta_socket.
> > Therefore the driver currently uses pci_find_device to find the cardbus
>
> - pci_find_device is no go today. Use pci_get_device (+ pci_dev_get, _put).
> - ioremap->pci_iomap
> - iobase should be __iomem.
> - codingstyle (char* buffer, for(loop, if(data){, ...)
>
Thanks for your feedback and testing.
I fixed the above problems and ran the code through Lindent.
Apart from that I did the following changes:
- implemented suspend/resume support (not tested very much)
- named the registers
- fixed a bug that caused a major slowdown when modprobed without debug=1
- added writting support (disabled by default, modprobe with write=1)
Before you enable writting please make sure that you did a proper backup of
the data on the card. Do not use this driver to save important data.
I still consider this driver experimental, but without documentation this is
probably not going to change anytime soon.
The question is now what I should do with the driver?
Is it worth to be included in the kernel? If yes where and against what
kernelversion should I send the patch?
Thanks
Sascha
Sascha Sommer wrote:
> I still consider this driver experimental, but without documentation this is
> probably not going to change anytime soon.
> The question is now what I should do with the driver?
> Is it worth to be included in the kernel? If yes where and against what
> kernelversion should I send the patch?
>
>
That's up to you. The most important thing for any part of the kernel is
that it must have a maintainer. So if you are ready to keep the driver
up to date and handle the support requests that show, then you should
really submit it.
Patches should always be sent against the current version of the kernel
(i.e. git HEAD). Usually the latest packaged release will also do.
(Note that I haven't had time to review your latest version of the driver)
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
Pierre Ossman, le Tue 13 Feb 2007 06:47:41 +0100, a ?crit :
> Sascha Sommer wrote:
> > I still consider this driver experimental, but without documentation this is
> > probably not going to change anytime soon.
> > The question is now what I should do with the driver?
> > Is it worth to be included in the kernel? If yes where and against what
> > kernelversion should I send the patch?
>
> That's up to you. The most important thing for any part of the kernel is
> that it must have a maintainer. So if you are ready to keep the driver
> up to date and handle the support requests that show, then you should
> really submit it.
You can mark your Kconfig entry with EXPERIMENTAL for letting people
know about the status :)
Samuel
Hi,
On Tuesday 13 February 2007 06:47, Pierre Ossman wrote:
> Sascha Sommer wrote:
> > I still consider this driver experimental, but without documentation this
> > is probably not going to change anytime soon.
> > The question is now what I should do with the driver?
> > Is it worth to be included in the kernel? If yes where and against what
> > kernelversion should I send the patch?
>
> That's up to you. The most important thing for any part of the kernel is
> that it must have a maintainer. So if you are ready to keep the driver
> up to date and handle the support requests that show, then you should
> really submit it.
>
> Patches should always be sent against the current version of the kernel
> (i.e. git HEAD). Usually the latest packaged release will also do.
>
> (Note that I haven't had time to review your latest version of the driver)
>
Yes, I'm going to maintain it. There are still some bugs that need to be fixed
first, though. I also got a mail from someone else how also did some
reverseengineering work for this reader. I'm waiting for his feedback before
I will submit a patch that can be included.
Thanks.
Sascha
Hi!
> Apart from that I did the following changes:
> - implemented suspend/resume support (not tested very much)
> - named the registers
> - fixed a bug that caused a major slowdown when modprobed without debug=1
> - added writting support (disabled by default, modprobe with write=1)
> Before you enable writting please make sure that you did a proper backup of
> the data on the card. Do not use this driver to save important data.
Thank for the job you've done!
Your driver works with 1 Gb sd-card (x86_64 suse's 2.16.18.2 kernel).
Read rate for me was around 250 Kb/s, write - 28 Kb/s (using dd utility).
BTW, I get continuous flow of "sdricoh_cs: timeout waiting for data"
messages in dmesg.
Good luck!