Hi All,
We are developing a block device driver (2.4.x kernel) for Flash Media devices over one of our storage media controllers. I should admit that this is the first time we are developing a block device driver under Linux.
Sorry if the question becomes too obvious to some.
We are facing a peculiar problem. If the flash media card had been formatted under Linux (either ext2 or FAT) the card was mounted successfully and we could read its contents. However if the card had never been on a Linux box, the file system in the card was not recognized properly (Error: VFAT bogus partition). If we format the card under Linux just once with FAT, then it will continue to work for Windows and Linux.
We have been able to figure out why the problem actually occurs. The reason is that Linux (our driver?) does not recognize several partitions in a single FAT12/FAT16 Flash Media card. According to the FAT12/FAT16 file system, the card should have a valid Master Boot Sector in the first logical sector. This master boot sector indicates how many partitions are in the disk and the start and end addresses along with their respective size. FAT12/FAT16 disks must also have a Partition Boot Sector. The partition boot sector contains the parameters of each partition.
Brand new SM or SD cards come pre-formatted with a FAT12/FAT16 file system, which includes a Master Boot Sector and one Partition Boot Sector for one single partition. Linux does not recognize this partitioned card with just one active partition. Actually, when you format a card with FAT12 or FAT16 under Linux, the OS creates one single partition but without a Master Boot Sector. That is, the first logical sector contains the Partition Boot Sector instead of the Master Boot Sector.
Windows does not have a problem reading cards without a Master Boot Sector as long as they have a valid Partition Boot Sector. That is why once you format a card with 'mkfs -t msdos /dev/ourdev' or similar command under Linux, the card will continue to work under Windows and Linux as well.
However, this behavior is not acceptable for our customers since Digital cameras do not recognize Flashmedia cards after they have been formatted under Linux (with our driver). Besides, end customers do not want to format the cards before they can use them under Linux. For instance, a customer buys a new card and takes some pictures with a digital camera and then inserts it in our reader. This will force the user to format the card in order to be able to use it with Linux, therefore destroying all its data.
We are *not* doing a "register_disk()" and "struct gendisk" structure in our driver right now. This is a Flash Media device which should not be partitioned. Is a register_disk() call still mandatory? Are we missing out something in the driver?
Thanks,
-Jinu
On Thu, 2004-04-01 at 12:03, Jinu M. wrote:
> Hi All,
>
> We are developing a block device driver (2.4.x kernel) for Flash Media devices
why?
aren't the existing usb/IDE drivers working for you ??
On Thu, 2004-04-01 at 12:03, Jinu M. wrote:
> Hi All,
>
> We are developing a block device driver (2.4.x kernel) for Flash Media devices
why?
aren't the existing usb/IDE drivers working for you ??
[jinum] This is not a USB/IDE(ATA)/SCSI based device. The controller is directly mapped to the PCI Bus. So we basically write a device driver like the once which are in drivers/block/*.c (non-IDE).
On Thu, Apr 01, 2004 at 03:53:41PM +0530, Jinu M. wrote:
>
> On Thu, 2004-04-01 at 12:03, Jinu M. wrote:
> > Hi All,
> >
> > We are developing a block device driver (2.4.x kernel) for Flash Media devices
> why?
> aren't the existing usb/IDE drivers working for you ??
>
> [jinum] This is not a USB/IDE(ATA)/SCSI based device. The controller is directly mapped to the PCI Bus. So we basically write a device driver like the once which are in drivers/block/*.c (non-IDE).
cool; linux can use a GPL driver for such things...
cool; linux can use a GPL driver for such things...
[jinum] guess the question/clarification is not clear!
This is a driver for our own controller (PCI). Which is a PCI based
card.
This card is not based on the SCSI or IDE interface so how will some
other driver work for it unless we write ( or get it written sharing our
hardware spec) a driver for the interface?
-Jinu
Am Donnerstag, 1. April 2004 12:47 schrieb Jinu M.:
> cool; linux can use a GPL driver for such things...
>
> [jinum] guess the question/clarification is not clear!
> This is a driver for our own controller (PCI). Which is a PCI based
> card.
> This card is not based on the SCSI or IDE interface so how will some
> other driver work for it unless we write ( or get it written sharing our
> hardware spec) a driver for the interface?
It will not work. A block driver must be written for such hardware to make
it work.
Regards
Oliver
On Thursday 01 April 2004 14:13, Oliver Neukum wrote:
> Am Donnerstag, 1. April 2004 12:47 schrieb Jinu M.:
> > cool; linux can use a GPL driver for such things...
> >
> > [jinum] guess the question/clarification is not clear!
> > This is a driver for our own controller (PCI). Which is a PCI based
> > card.
> > This card is not based on the SCSI or IDE interface so how will some
> > other driver work for it unless we write ( or get it written sharing our
> > hardware spec) a driver for the interface?
>
> It will not work. A block driver must be written for such hardware to make
> it work.
Hmm, they are willing to release specs... that's good.
--
vda
Your mailer is broken and does not include 'References' headers, so your
message isn't associated with the message to which you're replying.
Please try to use a non-broken mail program when communicating in a
public forum.
Also, please make sure you quote properly, and keep your lines to under
80 characters.
On Thu, 2004-04-01 at 15:53 +0530, Jinu M. wrote:
> [jinum] This is not a USB/IDE(ATA)/SCSI based device. The controller is
Does the device perform translation internally to pretend to be a block
device, or does the host access the flash directly and perform the
translation itself?
If the translation is done by the host, it sounds like your flash
controller should be implemented as an MTD device. There is a set of
helpers to allow a translation layer to be implemented simply -- see the
ftl, nftl and inftl code in the 2.6 kernel for examples.
--
dwmw2
On Thursday 01 April 2004 14:13, Oliver Neukum wrote:
> Am Donnerstag, 1. April 2004 12:47 schrieb Jinu M.:
> > cool; linux can use a GPL driver for such things...
> >
> > [jinum] guess the question/clarification is not clear!
> > This is a driver for our own controller (PCI). Which is a PCI based
> > card.
> > This card is not based on the SCSI or IDE interface so how will some
> > other driver work for it unless we write ( or get it written sharing our
> > hardware spec) a driver for the interface?
>
> It will not work. A block driver must be written for such hardware to make
> it work.
Hmm, they are willing to release specs... that's good.
[Jinum]
This going way off from the original question...
* NO SPECS * will be out ;)
I was just trying to prove how the existing drivers will not work for our controller unless of course we release the driver we are writing :)
Guess the problem is not well framed, sorry about my English.
Someone who has worked on a block driver would answer it straight away..
-Jinu
On Thursday 01 April 2004 16:07, Jinu M. wrote:
> On Thursday 01 April 2004 14:13, Oliver Neukum wrote:
> > Am Donnerstag, 1. April 2004 12:47 schrieb Jinu M.:
> > > cool; linux can use a GPL driver for such things...
> > >
> > > [jinum] guess the question/clarification is not clear!
> > > This is a driver for our own controller (PCI). Which is a PCI based
> > > card.
> > > This card is not based on the SCSI or IDE interface so how will some
> > > other driver work for it unless we write ( or get it written sharing
> > > our hardware spec) a driver for the interface?
> >
> > It will not work. A block driver must be written for such hardware to
> > make it work.
>
> Hmm, they are willing to release specs... that's good.
>
> [Jinum]
> This going way off from the original question...
>
> * NO SPECS * will be out ;)
Why? That's a good way to have driver written and debugged for free.
--
vda