Re: [microblaze-uclinux] Blocking fsl instruction

[John Williams <jwilliams@xxxxxxxxxxxxxx>]

Hi Stephane,

Stephane Rousseau wrote:

> I'm trying to use the blocking version of the put and get on fslfifo.
> My component connected to the fifo always put data into the queue.
> I've adapted the driver to use the blocking version. But at some point
> the Linux freeze when trying to read.

> I'm trying to understand why the OS will freeze even if there is
> always data into the fsl.
>
> A similar test with the os, does work fine.

Do you mean *without* the OS?

> I know that in the paper "Programmable Parallel Coprocessonr 
> Architectures for
> reconfigurable SOC", Mr. Williams and Bergmann written the following :
> "The uClinux integration of the processor architecture forbids
> instruction-level blocking."
> But I was not able to get more details on this statement.

This is simply a reflection that the FSL blocking ops will lock up the 
CPU without any possibility for interrupts or recovery.  So, by design, 
in the driver discussed in that paper we don't uase real blocking ops. 
Rather, they are simulated by a tight loop of non-blocking operations.

To debug your modified driver you'll want to use XMD and the opb_mdm 
debuger, trap the CPU when the freeeze occurs, wee where it's locked up.

If XMD refuses to connect (as message like "processor stall") then it's 
quite likely that you've entered a blocking FSL op and there's no data 
on the channel. (even the HW debugger cannot interrupt a blocking FSL op!)

Regards,

John

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