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

[John Williams <jwilliams@xxxxxxxxxxxxxx>]

Hi Scott,

Scott Thibault wrote:
>>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...
> 
> In the absence of an OS, we recommend FSL because it doesn't interfere
> with the memory bus and provides the best performance.  Since, you are
> not using the blocking instructions does that mean it is interrupt
> based?

It's sort of polled, but in a reasonably efficient manner:  On the 
output side, there's a software buffer, into which the write() syscall 
dumps data.  The driver schedules a tasklet (like a kernel thread) that 
pulls data from the SW buffer and pushes it to the FSL port.  If the FSL 
fills before the SW buffer is empty, the tasklet reschedules itself to 
run again "later". Tasklets generally run on the back of interrupts, so 
"later" generally means "soon, but not immediately".  The inverse 
happens on the read side.

So, it's sort of demand scheduled / multi threaded or something.  It 
would be simple to make it interrupt driven (basically just register the 
tasklet as an interrupt handler instead), but I'm not sure how much 
efficiency gain would actually be achieved, since the tasklets are only 
scheduled on demand anyway.

Another thought - if there's an FSL device producing data, the 
microblaze won't actually spend any cycles looking at that FSL port 
until a user process actually does a read() on the FIFO device.  If it 
were interrupt driven, then this situation would cause massive interrupt 
load on the processor, unless you masked it beforehand.

> If I use your driver, and my process is blocked waiting on FSL data,
> what does the kernel do?  Will the memory bus be idle?

 From the application perspective it's blocking IO, so a user process 
that does a read on an empty FSL fifo will schedule the read tasklet 
then sleep.  The tasklet runs later, if there's any data in the FSL it 
will put it into the software read buffer, and signal the kernel to wake 
your process.  Otherwise, the tasklet will reschedule itself to check 
again later.

Since it's a multithreaded/multiprocessing OS, the memory bus will never 
be truly idle, however when blocked your particular user process will be 
causing little or no bus activity.  It's certainly not a busy-wait at 
the user level.  There is some activity from the tasklet waking up and 
polling, which would be avoided in an interrupt driven approach.

The reason I didn't make it interrupt driven originally is because that 
would have required changes to the FSL bus hardware itself - I wanted 
this to work with standard EDK cores.  The newer version of FSL (2.00.a) 
does have some status flags (full, empty etc) that could be tied to an 
IRQ, but that needs some thought before diving into an implementation.

> On a sort of related topic, I just did an experiment with a core that
> operates as a bus master to transfer an image directly to memory, and
> the system crashed.  There were a bunch of messages from the ethernet
> driver indicating that it was resetting the device.  I'm guessing that
> perhaps the crash is because the system couldn't get the bus enough.
> This is the first test of the core so it could be the core's fault as
> well.

Is this on the OPB bus?  I haven't played with DMA / multimastering yet 
on OPB - not sure what the rules and pitfalls are.

Probably not relevant in this instance, but one thing to watch for is 
that Microblaze cache will go incoherent if there is any other bus 
master writing into the cacheable address range.  You must be sure to 
invalidate the cache after a DMA or bus master transfer, else next time 
microblaze tries to read that range it may get stale values.

Cheers,

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/