[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [microblaze-uclinux] Writing Drivers



Hi John,

John McGrath wrote:

> Does anyone here have experience with writing their own drivers for 
> uClinux. I have a peripheral on the OPB, and it is essentially a memory 
> interface - i.e. register style based. with no OS I can control it 
> directly by addressing the memory locations in the following way
> 
> int main()
> {
>   volatile int *my_device = BASE_ADDRESS;
>     my_device[0] = some_data;
> 
>   .....
> }
> 
> And this will work quite nicely.
> 
> However I'm sure this hackery will not work in uClinux. So how does 
> someone write a driver in a "standard way". I guess uClinux does things 
> like re-mapping the physical address, etc, for its own reasons, and the 
> driver would have to support this?
> I guess put more simply - if you wanted to write a driver for a bram 
> block, how would you do it?

In fact, under uClinux you can write directly to memory, IO space, 
whatever you like.  This is because there is no MMU.  However, the 
question is whether you should.

The ability for use-space direct-writes is certainyl conveninet when 
debugging new cores - I have even written myself trivial "peek" and 
"poke" applicatioss that I can run from the shell, for exactly that purpose.

For a purely memory mapped device (no interrupts or tricky kernel 
threads etc) you can just use the mmap() system call in userspace, then 
just write directly to the opinter returned.  Under uClinux, mmap() is 
doing essentially nothing, however at least it is one level "cleaner" 
than direct writes like in your example.  Also, this approach would work 
under Linux with an MMU, should you ever migrate in that direction. 
For an example of accessing hardaware in this way, check out the custom 
hardware tutorial from Phillip Leong at the Chiniese University of Hong 
Kong - there is a link in the "news" section on the front paeg of the 
website.

> Once the basic driver interface is there, I can think about building the 
> more user-friendy functions around it.
> 
> Also, I would like to add interrupts, and a handler for it in the 
> driver. Its not necessary, but definalty a nice to have...is this 
> difficult?

If you need all of this, you must write a standard kernelmode device 
driver.  This is not necessarily difficult, but there's certainly a bit 
of a learning curve.  Corbet and Rubini's "Linux Device Drivers" (2nd 
edition) from O'Reilly is the one you want.  I think the full-text is 
available on-line.

The good nwes is there are thousands of examples in the sources already. 
  It's usually a case of finding one that has the same broad structure 
of what you are tring to achieev, then modifying to your needs.

> Btw - on a completly unrealted note - I got uclinux running under 7.1i - 
> with MB version 4.00a. I had the FPU enabled, but I guess the toolchain 
> doesnt support it.

The custom toolchain is still from EDK6.3 - so no it does not know about 
the FPU.  I am fionalisding support for uClinux builds under the 
"native" toolchain distributed with 7.1 - should be some updates soon on 
that.

Regards,

John

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