Re: [PATCH 2/2] lib/cobalt: set name for printf thread to help debugging
On 14.06.19 12:23, Norbert Lange via Xenomai wrote: Signed-off-by: Norbert Lange --- lib/cobalt/printf.c | 1 + 1 file changed, 1 insertion(+) diff --git a/lib/cobalt/printf.c b/lib/cobalt/printf.c index 33ff7f9ac..7426f2bda 100644 --- a/lib/cobalt/printf.c +++ b/lib/cobalt/printf.c @@ -648,6 +648,7 @@ static void spawn_printer_thread(void) pthread_sigmask(SIG_BLOCK, &sset, &oset); pthread_create(&printer_thread, &thattr, printer_loop, NULL); sigprocmask(SIG_SETMASK, &oset, NULL); + pthread_setname_np(printer_thread, "cobalt_printf"); } void cobalt_print_init_atfork(void) Thanks, both applied. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux
RE: serial driver for imx28
> -Original Message- > From: Julien Blanc > Sent: Freitag, 14. Juni 2019 14:46 > To: Lange Norbert ; Xenomai > (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 +, Lange Norbert via Xenomai a écrit : > > > -Original Message- > > > From: Xenomai 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
Le vendredi 14 juin 2019 à 12:26 +, Lange Norbert via Xenomai a écrit : > > -Original Message- > > From: Xenomai 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
> -Original Message- > From: Xenomai 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
serial driver for imx28
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
[PATCH 1/2] lib/cobalt: start helper thread with signals blocked
Delivery mechanisms like sigwait and signalfd require *all* threads
to block the relevant signals.
The cobalt init should not spawn a thread affecting the
signal-handling.
Signed-off-by: Norbert Lange
---
lib/cobalt/printf.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/lib/cobalt/printf.c b/lib/cobalt/printf.c
index e109deaec..33ff7f9ac 100644
--- a/lib/cobalt/printf.c
+++ b/lib/cobalt/printf.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -640,9 +641,13 @@ static void *printer_loop(void *arg)
static void spawn_printer_thread(void)
{
pthread_attr_t thattr;
+ sigset_t sset, oset;
pthread_attr_init(&thattr);
+ sigfillset(&sset);
+ pthread_sigmask(SIG_BLOCK, &sset, &oset);
pthread_create(&printer_thread, &thattr, printer_loop, NULL);
+ sigprocmask(SIG_SETMASK, &oset, NULL);
}
void cobalt_print_init_atfork(void)
--
2.20.1
[PATCH 2/2] lib/cobalt: set name for printf thread to help debugging
Signed-off-by: Norbert Lange --- lib/cobalt/printf.c | 1 + 1 file changed, 1 insertion(+) diff --git a/lib/cobalt/printf.c b/lib/cobalt/printf.c index 33ff7f9ac..7426f2bda 100644 --- a/lib/cobalt/printf.c +++ b/lib/cobalt/printf.c @@ -648,6 +648,7 @@ static void spawn_printer_thread(void) pthread_sigmask(SIG_BLOCK, &sset, &oset); pthread_create(&printer_thread, &thattr, printer_loop, NULL); sigprocmask(SIG_SETMASK, &oset, NULL); + pthread_setname_np(printer_thread, "cobalt_printf"); } void cobalt_print_init_atfork(void) -- 2.20.1
