Re: [microblaze-uclinux] Storage Device Driver Development

[Rudolf Usselmann <rudi@xxxxxxxx>]

On Wed, 2005-05-11 at 22:07 +1000, John Williams wrote:
> Hi Rudi,
> 
> Rudolf Usselmann wrote:
> 
> > On Tue, 2005-05-10 at 07:27 +0100, Aurash wrote:
> > 
> >>I have a driver (block) which works with MMC card, in a Microblaze 
> >>sytem, conected on opb with the opb_spi core, The card can be mounted as 
> >>a dos (FAT) drive and it performs read write.
> >>Aurash
> > 
> > Our IP Core does all the low level protocols in Hardware. The
> > cards come up as memory mapped. It will automatically select
> > the highest supported protocol, up to 8 bit for the new MMC
> > cards. I have written a boot loader based on the xilinx fat
> > fs libraries - basically just writing a read_sector function
> > and than opening a file using the xilinx library and copying
> > the file to SDRAM and executing it. Very trivial.
> 
> There are two approaches I would consider here - the first is to take an 
> existing MMC driver and port it into uClinux and across to your 
> hardware.  This would use the native MMC command set, and is probably 
> the most portable.  I know of at least two - there is one in the ARM 
> linux tree, and another in celinux.
> 
> The 2nd approach is to use the MTD driver/device layer, which could make 
> use of your memory mapped IO capability.  For example, the Disk-on-Chip 
> (DOC) devices are supported in this manner.

Hi John,

well in our case that would really not make sense since the
hardware does all the low level protocols (SPI, 1 bit, 4 bit,
8 bit, block transfers, streaming, ATA over MMC, etc.).

>From a users perspective our IP occupies a predefined window
in the MCUs memory space. This window can be moved across the]
cards actual memory space by changing the base address. Actually
we even support multiple windows ...

So I think a Device Driver with a simple Sector Interface
would make the most sense. it could be easily ported to
liner FLASH memories, or  even secondary SDRAM based memories ...

> Of course, cost and time are always factors, but you want to be careful 
> of the quick hack - time saved now may cost you later.

Right I totally agree with you. Thats why I am pushing for
the architecture I have described above !

> Cheers,
> 
> John

Best Regards,
rudi
=============================================================
Rudolf Usselmann,  ASICS World Services,  http://www.asics.ws
Your Partner for IP Cores, Design, Verification and Synthesis

___________________________
microblaze-uclinux mailing list
microblaze-uclinux@itee.uq.edu.au
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/