________________________________
From: Jan Kiszka <[email protected]>
Sent: Wednesday, July 1, 2020 9:43 PM
To: Josh Karch <[email protected]>; [email protected] <[email protected]>
Subject: Re: Receiving "Operation Not Permitted" when setting
RTCAN_RTIOC_RCV_TIMEOUT and reading from CAN over cobalt pthread
On 01.07.20 16:55, Josh Karch via Xenomai wrote:
> Hello,
>
> So a quick update, I was able to get the CAN drivers working, the issue as
> was suggested is that Linux did not register the interrupts for the Zynq, and
> I had to make a fake "generic-uio" module in the device tree to receive a
> valid IRQ number, and now the CAN core registers properly.
>
> Now, I'm trying to create an application using the POSIX skin, based on the
> rtcanrecv.c example. Rather than using rt_task_shadow, I'm using
> pthread_create. My Makefile uses xeno-config with --skin=posix and sets
> --cflags and --ldflags, while wrap-link uses the POSIX ldflags. We are using
> libcobalt.
>
> When I don't set the timeout IOCTL, my application runs, but it blocks
> indefinitely until messages are received, however when I set the IOCTL (0.1
> sec)
> ret = ioctl(can_fd, RTCAN_RTIOC_RCV_TIMEOUT, &timeout);
> then make the read in my pthread
>
> ret = recvfrom(can_fd, (void *)&can_msg_frame, sizeof(can_frame_t), 0,
> (struct sockaddr *)&can_address,
> &address_length);
>
> I receive -EPERM rather than -ETIMEDOUT as a return. The application is run
> as root, and works normally unless the TIMEOUT ioctl above is triggered;
> thoughts on where to look?
>
> Here are the lines of interest for the Makefile:
> CFLAGS := $(shell $(DESTDIR)$(XENO_DIR)/$(XENO_CONFIG) --skin=posix --cflags)
> LDFLAGS := $(shell $(DESTDIR)$(XENO_DIR)/$(XENO_CONFIG) --skin=posix
> --ldflags)
>
> $(PROGNAME):
> $(CC) -c $(PROGNAME).c $(CFLAGS)
> $(DESTDIR)$(XENO_DIR)/$(WRAP_LINK) -v $(CC) -o $(PROGNAME) $(PROGNAME).o
> $(LDFLAGS)
>
> My guess is if I make the application run as an rt_task it would work.
> Are there any special parameters needed to be set for pthread_create in order
> to run in RT mode?
>
If wrapping is worked fine (check the symbols that your application is
actually calling: __wrap_ioctl? Also __wrap_socket?), you do not need
special parameters to the thread creation, also SCHED_OTHER threads will
be able to RTDM drivers then.
Besides that offline check, you can also look if that thread shows up
/proc/xenomai/sched/threads while it is existing.
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
Hi Jan, looks like two things were going on: (1) I did not set the pthread to
operate in the primary domain. I went back and looked at the xddp example.
(2) this is a fat fingered mistake, I was looking at ret vs errno. The timeout
was actually occuring, but since I looked at ret rather than errno I
misinterpreted it as "operation not permitted!"
Thank you!
-Josh
