[U-Boot] Rx FIFO: more than 64 bytes receive error

[Albert ARIBAUD]

Hi lokesh,

On Mon, 31 Dec 2012 14:59:36 +0530, lokesh nijalinge
<lokesh1kumar2nijalinge at gmail.com> wrote:
> Hi ,
> 
> Thank you very much ,for the quick response albert
> 
> The detailed explanation about the project is as below:
> 
> I have a fingerprint module(FPC-AM3) which works fine and can receive whole
> fingerprint template data at kernel on UART2 of the processor. The same i
> am trying to implement at u-boot. I am trying to receive almost 1Kb of
> fingerprint template.
> 
> Fingerprint template is received once we transmit a command of 6 bytes to
> fingerprint over UART2 to Fingerprint module, and then the response is 948
> bytes of template data over UART2 on the Receive side.
> 
> I went through the "*loads*" command too. If i am not wrong it takes the
> file from remote location and loads on to the address mentioned in the
> argument, which is not the idea. As explained before we are trying to
> receive 948 bytes of data from the UART2 port (Fingerprint module).

I mentioned 'loads', not to suggest a workaround, but to point you to
a case where large quantities of data can be read at the client level
despite the driver level only processing small quantities.

> Attaching the patch as suggested  :patch includes our finger print code and
> the UART2 initialization change.

Please do not send patches to the list unless you intend them for
inclusion into mainline U-Boot; or at least tag the mail subject "RFC"
so that we know it is only posted for comments, and then, post them
using 'git format-patch' and 'git send-email'.

> Please help us in getting the 948 bytes of data over UART2. Let us know the
> code changes.
> 
> *NOTE: we have even modified the hardware for a loopback connection and
> then ran the same code on it, but we could not receive more than 64 bytes.
> We are receiving the first 64 bytes and then rest of the bytes are not seen.
> *

This patch contains code outside the mainline tree, and I suspect there
is more non-mainline code in your tree, as for instance your version
of NS16550_getc() seems to be able to return on time-out, which
the mainline NS16550_getc() does not do AFAIK.

You are thus the only person on this list who has both the full source
code and the relevant hardware, hence the only person able to debug it.
I suggest placing hardware breakpoints on code executed upon time-out
condition to begin with.

Amicalement,
-- 
Albert.