serial driver for imx28

serial driver for imx28

[Julien Blanc]

Hi,

We’re currently trying to make the serial port working on a custom
board based on an imx28 som.

The serial port is correctly handled by the linux mxs-uart driver.
However, under (slightly) heavy xenomai loads, we experience data loss
(we suspect xenomai is delaying interrupts for too long for the linux
kernel to handle them, resulting in the data loss).

To fix this issue, we’re trying to migrate from the linux non-rt driver
to the xenomai rt_imx_uart driver (other suggestions welcome).

Our kernel is 4.9.24, and xenomai is 3.0.5. An upgrade to 3.0.7 fixes
the compilation issue.

However, we can't manage to make this driver recognize the uart, nor to
find any documentation / pointers on how to configure it for our needs.

So, the questions are :
- is the imx28 supported ?
- are there any pointers / samples as to how to configure it (correct
address / irq, etc.).

Regards,

Julien

RE: serial driver for imx28

[Lange Norbert]

> -----Original Message-----
> From: Xenomai <xenomai-bounces@xenomai.org> On Behalf Of Julien Blanc
> via Xenomai
> Sent: Freitag, 14. Juni 2019 13:54
> To: Xenomai@xenomai.org
> Subject: serial driver for imx28
>
> E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
> EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
> ATTACHMENTS.
>
>
> Hi,
>
> We’re currently trying to make the serial port working on a custom board
> based on an imx28 som.

Are you using the Debug uart or the Application UART?
The debug uart has incredibly slow register accesses, and can't do DMA, you would not be happy about that in an RT application.

Further what interfaces are you planning to use? Ethernet is rather horrible to use aswell, as you need to byteswap *all* data (hardware bug, I am not talking about the Ethernet heads using BigEndian).

Sorry, don’t know the state of Xenomai in regards to this SOC, (but I know the Chip and its warts pretty well).

Regards, Norbert

________________________________

This message and any attachments are solely for the use of the intended recipients. They may contain privileged and/or confidential information or other information protected from disclosure. If you are not an intended recipient, you are hereby notified that you received this email in error and that any review, dissemination, distribution or copying of this email and any attachment is strictly prohibited. If you have received this email in error, please contact the sender and delete the message and any attachment from your system.

ANDRITZ HYDRO GmbH


Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You
________________________________

Re: serial driver for imx28

[Julien Blanc]

Le vendredi 14 juin 2019 à 12:26 +0000, Lange Norbert via Xenomai a
écrit :
> > -----Original Message-----
> > From: Xenomai <xenomai-bounces@xenomai.org> On Behalf Of Julien
> > Blanc
> > via Xenomai
> > Sent: Freitag, 14. Juni 2019 13:54
> > To: Xenomai@xenomai.org
> > Subject: serial driver for imx28
> > 
> > 
> > We’re currently trying to make the serial port working on a custom
> > board
> > based on an imx28 som.
> 
> Are you using the Debug uart or the Application UART?
> The debug uart has incredibly slow register accesses, and can't do
> DMA, you would not be happy about that in an RT application.

I’m talking about the application uart. Also, note that the UART does
not need to be realtime (the reason we are using it from plain linux in
the first place), but the issues we encounter make us reconsider this
decision.

> Further what interfaces are you planning to use? Ethernet is rather
> horrible to use aswell, as you need to byteswap *all* data (hardware
> bug, I am not talking about the Ethernet heads using BigEndian).

We’re not planning to do any rtnet, and the linux driver seems fine
(frow a user pov). RT is required for CAN and gpios (both handled by
xenomai drivers) which work fine. Our only issues are with uart, called
from linux domain (issues which were unfortunately not seen during the
qualification phase).

> Sorry, don’t know the state of Xenomai in regards to this SOC, (but I
> know the Chip and its warts pretty well).

Switching to another chip is not an option (we need to solve this issue
for existing boards).

Thanks for your reply,

Regards,

Julien

RE: serial driver for imx28

[Lange Norbert]

> -----Original Message-----
> From: Julien Blanc <julien.blanc@sprinte.eu>
> Sent: Freitag, 14. Juni 2019 14:46
> To: Lange Norbert <norbert.lange@andritz.com>; Xenomai
> (xenomai@xenomai.org) <xenomai@xenomai.org>
> Subject: Re: serial driver for imx28
>
> E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
> EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
> ATTACHMENTS.
>
>
> Le vendredi 14 juin 2019 à 12:26 +0000, Lange Norbert via Xenomai a écrit :
> > > -----Original Message-----
> > > From: Xenomai <xenomai-bounces@xenomai.org> On Behalf Of Julien
> > > Blanc via Xenomai
> > > Sent: Freitag, 14. Juni 2019 13:54
> > > To: Xenomai@xenomai.org
> > > Subject: serial driver for imx28
> > >
> > >
> > > We’re currently trying to make the serial port working on a custom
> > > board based on an imx28 som.
> >
> > Are you using the Debug uart or the Application UART?
> > The debug uart has incredibly slow register accesses, and can't do
> > DMA, you would not be happy about that in an RT application.
>
> I’m talking about the application uart. Also, note that the UART does not
> need to be realtime (the reason we are using it from plain linux in the first
> place), but the issues we encounter make us reconsider this decision.
>
> > Further what interfaces are you planning to use? Ethernet is rather
> > horrible to use aswell, as you need to byteswap *all* data (hardware
> > bug, I am not talking about the Ethernet heads using BigEndian).
>
> We’re not planning to do any rtnet, and the linux driver seems fine (frow a
> user pov). RT is required for CAN and gpios (both handled by xenomai
> drivers) which work fine. Our only issues are with uart, called from linux
> domain (issues which were unfortunately not seen during the qualification
> phase).

Ok, seems like you would need to increase buffers in the drivers, or try enable
DMA (need to set CRTSCTS in termios, otherwise no DMA is used in the driver).
If anything fails, use a thread to receive data from a pipe/unix socket and
forward that to the uart as fast as it will accept it.
If the issue is on the receive side you probably need HW flow-control via RTS/CTS
pins to make sure you don’t lose anything.

> > Sorry, don’t know the state of Xenomai in regards to this SOC, (but I
> > know the Chip and its warts pretty well).
>
> Switching to another chip is not an option (we need to solve this issue for
> existing boards).

Many chips have bugs, helps a lot knowing them.

Regards, Norbert.
________________________________

This message and any attachments are solely for the use of the intended recipients. They may contain privileged and/or confidential information or other information protected from disclosure. If you are not an intended recipient, you are hereby notified that you received this email in error and that any review, dissemination, distribution or copying of this email and any attachment is strictly prohibited. If you have received this email in error, please contact the sender and delete the message and any attachment from your system.

ANDRITZ HYDRO GmbH


Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You
________________________________

Re: serial driver for imx28

[Julien Blanc]

Le vendredi 14 juin 2019 à 13:19 +0000, Lange Norbert a écrit :

> If the issue is on the receive side you probably need HW flow-control 
> via RTS/CTS pins to make sure you don’t lose anything.

This proved to be a very good advice, as it seems to solve our issues.
Why we did not think about enabling it in the first place remains a
mystery to me.

Thank you very much,

Julien

Re: serial driver for imx28

[Wolfgang Denk]

Dear Julien,

In message <0881c8f094cabf8753b31f4899ce879658d204ae.camel@sprinte.eu> you wrote:
>
>
> > If the issue is on the receive side you probably need HW flow-control 
> > via RTS/CTS pins to make sure you don’t lose anything.
>
> This proved to be a very good advice, as it seems to solve our issues.
> Why we did not think about enabling it in the first place remains a
> mystery to me.

The i.MX28 is a special beast.

Your issue is most likely caused by a somewhat stup^H^H^H^Hsimple
implementation of the UART driver. When it receives the interrupt
after receiving a block of data, it stops DMA until the data has
been read from the RX buffer and pushed to the TTY layer.  Given the
tiny size of the UART RX FIFO, this will cause frequent overruns if
you don't enable or cannot use flow control.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
I can type faster than I can move a  mouse,  so  I  find  menu-driven
drawing packages time consuming and frustrating.      - W. R. Stevens

Re: serial driver for imx28

[Julien Blanc]

Le vendredi 21 juin 2019 à 14:14 +0200, Wolfgang Denk a écrit :
> Dear Julien,
> 
> The i.MX28 is a special beast.
> 
> Your issue is most likely caused by a somewhat stup^H^H^H^Hsimple
> implementation of the UART driver. When it receives the interrupt
> after receiving a block of data, it stops DMA until the data has
> been read from the RX buffer and pushed to the TTY layer.  Given the
> tiny size of the UART RX FIFO, this will cause frequent overruns if
> you don't enable or cannot use flow control.

Indeed.

The driver seems to be really buggy outside the simple use cases
(anything involving reconfiguring the transmission settings on the fly
is not recommended), but RTS/CTS definitely solved our data loss
issues. As a bonus we were even able to increase the baudrate up to
460800 bauds.

Best regards and thanks all for your answers,

Julien