Re: [microblaze-uclinux] uClinux support for FSL devices

[John Williams <jwilliams@xxxxxxxxxxxxxx>]

Hi Yashi,

Yasushi SHOJI wrote:

> At Mon, 01 Nov 2004 12:21:59 +1000,
> John Williams wrote:
> [...]
> 
>>First cab off the rank is a generic FSL FIFO driver.  FSL is one of the 
>>bus architectures supported by Microblaze, that provides register mapped 
>>streaming IO.  An FSL bus is essentially a hardware FIFO, with simple 
>>handshaking signals.  Interfacing to FSL is so easy it's almost trivial, 
>>particularly if you have an example to follow.  Read all about it in the 
>>Microblaze HW reference.
> 
> 
> Nice piece of work.  I've been thinking about using FSL to communicate
> multi-cpu on a fpga
> 
> +------------+        +-------------------------+
> |  uClinux   |        |    iTRON or uClinux     |
> |    on      == FSL ===           on            |
> | MicroBlaze |        | MicroBlaze or PicoBlaze |
> +------------+        +-------------------------+

Definitely possible - I tried the picoblaze experiment earlier this 
year, it works quite well.  I factored out the FSL driver abstraction 
and that's what became the fslfifo that this thread is about! :)

>>This driver create a linux device abstraction over the top of an FSL 
>>channel, providing software buffering and read/write/ioctl operations. 
>>If you have an  FSL-enabled core, you can simply cat (or write() ) data 
>>to the device node, and it is automagically buffered and streamed to the 
>>  FSL channel.  IOCTL calls are used to reset the buffers, send and read 
>>control words, that sort of thing.  I chose the misc device major number 
>>(10), with minor numbers 192-199.  If this is a horrible clash with some 
>>existing device let me know and we'll pick a different number.
> 
> If you are gonna reserve hard minor number, you might want to talk to
> people managing linux device numbers.  or just leave it dynamic.

I don't know if we'd get a lot of respect for reserving minor numbers 
for a device that will only work with one arch in the no-mmu 2.4 tree, 
... maybe I'm wrong?

As for dynamic, I guess the problem is that most uClinux targets mount 
the root FS as read only, so running mknod in /dev is not usually 
possible.  In my local vendors Makefile I added the fslfifo devs 
statically...

What do you think?

>>PPS For those who know about FSL - my personal policy in uClinux is that 
>>blocking FSL ops are strictly verboten...  Nothing locks microblaze 
>>harder than a blocking get on a non-existent FSL port!  Not even an NMI 
>>will save you - it's reset-city...
> 
> agree.

There's definitely a place for blocking FSL ops, but a multiprocessing 
operating system isn't one of them! :)


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/