Subject: Re: Serial port
To: None <port-arm32@NetBSD.ORG>
From: Mark Brinicombe <amb@physig.ph.kcl.ac.uk>
List: port-arm32
Date: 01/03/1997 17:01:12
On Mon, 23 Dec 1996, Mark Brinicombe wrote:

> Initially I had put this does to a fault  with my serial hardware but if 
> other people are experiencing it may be the problem lies else where.
> 
> One question .... Is this specific to SA110 kernels or not ?

Ok this problem was not specific to SA-110 kernels. I know what is going 
wrong and have found a fix. I cannot explain why it has only recently 
appeared.

The problem with the serial port hanging the machine is that the flag bit 
indicating received data is ready is being jammed on.
During the serial device open the driver tries to clear the receive FIFO 
and register and loops reading bytes from the serial port until the RX 
ready flag is deasserted.
Sometimes this flag bit appears jammed on and no matter how much data is 
read the bit is never cleared and thus the machine hangs in a loop.
If you limit the bytes you read to the FIFO size + a few the open 
continues until interrupts are enabled at which point you get continue 
serial interrupts from the RX ready bit being set.

So the bug is the serial hardware is going wrong.

WHY ? Well the latest kernels were using a newer version of the serial 
driver so I tried revering to the version from the CVS tree and still had 
the problem. In fact I appear to have suffered from the problem ever 
since I upgraded to RiscOS 3.7
This raised the question of whether there were changes in RiscOS that 
left the serial chip is a different state to earlier versions of RiscOS.
However this does not explain the problem as non SA110 kernels (an thus I 
assume non RO3.7 (unless soft loaded)) exhibit the problem.

Solution: A solution that appears to work for me is that during the 
opening of the serial device I first turn the serial FIFO's off. I then 
read consecutively all the serial registers. This has the effect of 
clearing the RX ready bit. I then re-enable the FIFO.

Doing this always seems to reset the chip into a known idle state.

I'll comming this fix to the serial driver later today.

Cheers,
				Mark


Mark Brinicombe				amb@physig.ph.kcl.ac.uk
Research Associate			http://www.ph.kcl.ac.uk/~amb/
Department of Physics			tel: 0171 873 2894
King's College London			fax: 0171 873 2716