How To Register Interrupt Routines in ARM920T?

Hi All,

I am porting U-Boot to a custom board (ARM920T) and I have to do something about the UART (ns16550.c) driver to support (I know WD would disagree with this :p) XON/XOFF. I have to do this because my board can support only < 19200 baudrates. At 19200 baudrate, I have a functional serial console but downloading binaries using loadb, kermit would always say that the remote host is not reponding (ERROR: Remote Kermit Not Responding). I debugged this on the getc level and verified that my board's U-Boot can accept the first few data from my PC's kermit and then the loadb function hangs, i.e. does not accept any data. I think this is because my UART's FIFO is not handled well, and probably needs software flow control.

How do I register my interrupt routine that would send XOFF data to the PC's kermit whenever an UART trigger (probably when RXRDY pin from NS16550 becomes LOW) occurs. The trigger is of course asserted when the FIFO buffer reaches a certain threshold. I saw the interrupt.c implementation in cpu/arm920t/ but didn't get the information I was looking for, i.e. registering my interrupt routine. Please help me with this.

Thank you very much for your time.

Best Regards,

Rodel Miguel

Rodel Miguel <[email protected]> schreibt:

Are you sure the problem is on the receiving side (i.e., did your PC Kermit continue sending after your board stopped receiving)?

It could also be a synchronization problem (i.e., the UART in your PC is clocked slightly faster than the UART on your board); you can relax that by setting the PC (but not your board) to two stop-bits.

Anyway, if you really need flow-control, then I'd strongly recommend hardware (RTS/CTS) over software (XON/XOFF) for reliability reasons (an XOFF (or worse, an XON) might get lost on the line).

Cheers
Anders

There are certain situations where you actually may have to do something like this, like when your serial connectionis over modem or so.

This is NOT a valid reson. We use many boards@ 9600 bps, without any flow control. The baud rate has NOTHING to do with this.

You are wrong. This has NOTHING to do with flow control. Even slow systems are fast enought to pick up characters loss-free at high baud rates like 115200 bps - remember that we are single tasking, so the CPU really has nothing more to do than wait for the characters. So a _slow_ connection is only _easier_ to handle. If you have problems, these have other reasons (like a misconfigured kermit ?).

You don't.

First, you're wrong when you think that flow control would improve this problem.

Second, you are wrong when you think you need interrupts to implement flow control.

Don't waste your time, you're on a wrong track.

Best regards,

Wolfgang Denk

Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Faith: not *wanting* to know what is true."    - Friedrich Nietzsche