[U-Boot-Users] How To Register Interrupt Routines in ARM920T?

[U-Boot-Users] How To Register Interrupt Routines in ARM920T?

[Rodel Miguel]

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

[U-Boot-Users] How To Register Interrupt Routines in ARM920T?

[Anders Larsen]

Rodel Miguel <rodelfmiguel@gmail.com> schreibt:
>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.

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

[U-Boot-Users] How To Register Interrupt Routines in ARM920T?

[Wolfgang Denk]

In message <698a2fda0412072241b442444@mail.gmail.com> you wrote:
> 
> 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

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

> board can support only < 19200 baudrates.  At 19200 baudrate, I have a

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.

> 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.

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 ?).

> How do I register my interrupt routine that would send XOFF data to

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