Re: [microblaze-uclinux] Storage Device Driver Development

["Antti Lukats" <lukats@xxxxxxxxx>]

Hi Rudi,

I wonder why you talk so loong abotu so simple matter!

step by step:
1) make a new folder
2) copy the adapter.c from sysace into it
3) rename the #include that point to xilinx systemace libs in adapter.c
4) make copy of the xilinx systemace stuff
5) fix all file names
6) in xilinx systemace files remove all the systemace stuff leaving the file
like a template
7) insert you init-readsectore-writesector
8) compile and done!

easy.
takes less time that trying to find someone todo it for you.

antti


----- Original Message ----- 
From: "Rudolf Usselmann" <rudi@asics.ws>
To: <microblaze-uclinux@itee.uq.edu.au>
Sent: Wednesday, May 11, 2005 4:22 PM
Subject: Re: [microblaze-uclinux] Storage Device Driver Development


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

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