Re: Hardware Loopback on RT-Socket-CAN Needed

Re: Hardware Loopback on RT-Socket-CAN Needed

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 2586 bytes --]

On 12/17/2015 03:13 PM, Stephen Marshall wrote:
> I am looking for some information on Loopback functionality for the
> RT-Socket-CAN.

You mean RT-Socket-CAN as in Xenomai? This is, as far as i know dead.

> In Socket-CAN, we used to test the loopback functionality on own socket
> using the flag *CAN_RAW_RECV_OWN_MSGS *using *MSG.CONFIRM* flag. However
> in RT-Socket CAN we see that this option has been disabled purposefully.
> 
> Could someone please clarify us on the below questions?
> 
> 1)      How we can do a hardware loopback (i.e., message from the
> transmit socket has to reach the same socket through the bus) on
> RT-Socket CAN?

Some CAN controllers have a bit to enable HW Loopback, e.g. flexcan has:

/* FLEXCAN module configuration register (CANMCR) bits */
#define FLEXCAN_MCR_SRX_DIS             BIT(17)

for this.

> 2)      If receive own messages is not supported, how is address claim
> handled in J1939 applications for other RT-Socket-CAN programs?

I don't know anyone using j1939 on RT-Socket-CAN. However there are some
companies, especially in the last 3 month interested in bringing j1939
to mainline linux-can.

> 3)      How do we patch the RT-Socket-CAN with the CAN_RAW_RECV_OWN_MSGS
> fix at kernel level? Any details on fix that should be taken and GIT
> repo details would be helpful. Would patching have any impact on the
> real-time capability?

Don't know. Sorry, I'm interested in mainline linux-can only.

> We use the SJA1000 CAN Controller and Xenomai 2.6. We tried setting the
> SRR (Self Reception Request) bit at driver using *CAN_CTRLMODE_LOOPBACK*
> <http://www.xenomai.org/documentation/xenomai-2.4/html/api/group__rtcan.html#ga19ec0cc4379e80c32cbd333cf7c145e9>*,
> *however it was doing a software loopback where the looped back message
> would not have actually gone in the bus. We needed the
> CAN_RAW_RECV_OWN_MSGS fix at RT-Socket-CAN, could someone help?

We do a software loopback in linux-can, too. But we do the actual
loopback-send in the TX-completion handler. This means no sent frame, no
loopback. You can do this in the Xenomai driver probably, too. However,
an increase of interrupts might have slight impact on the overall RT
performance, but I this this is unelectable.

regards,
Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: Hardware Loopback on RT-Socket-CAN Needed

[Wolfgang Grandegger]

Hello,

for RT-CAN related questions the Xenomai ML is maybe more appropriate.

Am 17.12.2015 um 15:43 schrieb Marc Kleine-Budde:
> On 12/17/2015 03:13 PM, Stephen Marshall wrote:
>> I am looking for some information on Loopback functionality for the
>> RT-Socket-CAN.
>
> You mean RT-Socket-CAN as in Xenomai? This is, as far as i know dead.

It's not dead! Just little contributions.

>> In Socket-CAN, we used to test the loopback functionality on own socket
>> using the flag *CAN_RAW_RECV_OWN_MSGS *using *MSG.CONFIRM* flag. However
>> in RT-Socket CAN we see that this option has been disabled purposefully.

Can't remember why it was not implemented. I think there was just no 
use-case,

[snip]

>> We use the SJA1000 CAN Controller and Xenomai 2.6. We tried setting the
>> SRR (Self Reception Request) bit at driver using *CAN_CTRLMODE_LOOPBACK*
>> <http://www.xenomai.org/documentation/xenomai-2.4/html/api/group__rtcan.html#ga19ec0cc4379e80c32cbd333cf7c145e9>*,

Are you still using Xenommai 2.4?

>> *however it was doing a software loopback where the looped back message
>> would not have actually gone in the bus. We needed the
>> CAN_RAW_RECV_OWN_MSGS fix at RT-Socket-CAN, could someone help?

IIRC, on the SJA1000 the hw loopback is redirecting tx messages to the 
rx unit (in hardware) without sending something out to the bus,

Have a look to:

 
https://git.xenomai.org/xenomai-2.6.git/tree/ksrc/drivers/can/rtcan_raw.c#n196

If you remove the "if" statement I think it already does what you want. 
But maybe I have missed something... it's a long time that I looked to 
that code.

Wolfgang.

Re: Hardware Loopback on RT-Socket-CAN Needed

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 678 bytes --]

On 12/17/2015 04:34 PM, Wolfgang Grandegger wrote:
> Am 17.12.2015 um 15:43 schrieb Marc Kleine-Budde:
>> On 12/17/2015 03:13 PM, Stephen Marshall wrote:
>>> I am looking for some information on Loopback functionality for the
>>> RT-Socket-CAN.
>>
>> You mean RT-Socket-CAN as in Xenomai? This is, as far as i know dead.
> 
> It's not dead! Just little contributions.

Ok. Sorry :D

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

RE: Hardware Loopback on RT-Socket-CAN Needed

[Stephen Marshall]

Thanks for the quick response Marc and Wolfgang.

What we basically need is a loopback message on the same socket after successful TX Done. We are not going with CAN_RAW_LOOPBACK because we have only one socket.

Wolfgang,
Could you confirm if I need to remove the "if" at https://git.xenomai.org/xenomai-2.6.git/tree/ksrc/drivers/can/rtcan_raw.c#n196 for what I am looking for? 

Is this how the code should look like? 

while (recv_listener != NULL) {
	dev->rx_count++;
	if (rtcan_accept_msg(frame->can_id, &recv_listener->can_filter)) // removed (dev->tx_socket != recv_listener->sock check)
             {
	    recv_listener->match_count++;
	    rtcan_rcv_deliver(recv_listener, &dev->tx_skb);
	}
	recv_listener = recv_listener->next;
    }

Also, if I do the modification, should we continue to use CAN_CTRLMODE_LOOPBACK?

Could you give us some reference on how to make the above modification at rtcan_raw.c file and build it? Sorry, a newbie here :) 

Thanks, 
Stephen Marshall


-----Original Message-----
From: Wolfgang Grandegger [mailto:wg@grandegger.com] 
Sent: Thursday, December 17, 2015 9:04 PM
To: Stephen Marshall; linux-can@vger.kernel.org
Cc: Marc Kleine-Budde
Subject: Re: Hardware Loopback on RT-Socket-CAN Needed

Hello,

for RT-CAN related questions the Xenomai ML is maybe more appropriate.

Am 17.12.2015 um 15:43 schrieb Marc Kleine-Budde:
> On 12/17/2015 03:13 PM, Stephen Marshall wrote:
>> I am looking for some information on Loopback functionality for the 
>> RT-Socket-CAN.
>
> You mean RT-Socket-CAN as in Xenomai? This is, as far as i know dead.

It's not dead! Just little contributions.

>> In Socket-CAN, we used to test the loopback functionality on own 
>> socket using the flag *CAN_RAW_RECV_OWN_MSGS *using *MSG.CONFIRM* 
>> flag. However in RT-Socket CAN we see that this option has been disabled purposefully.

Can't remember why it was not implemented. I think there was just no use-case,

[snip]

>> We use the SJA1000 CAN Controller and Xenomai 2.6. We tried setting 
>> the SRR (Self Reception Request) bit at driver using 
>> *CAN_CTRLMODE_LOOPBACK* 
>> <http://www.xenomai.org/documentation/xenomai-2.4/html/api/group__rtc
>> an.html#ga19ec0cc4379e80c32cbd333cf7c145e9>*,

Are you still using Xenommai 2.4?

>> *however it was doing a software loopback where the looped back 
>> message would not have actually gone in the bus. We needed the 
>> CAN_RAW_RECV_OWN_MSGS fix at RT-Socket-CAN, could someone help?

IIRC, on the SJA1000 the hw loopback is redirecting tx messages to the rx unit (in hardware) without sending something out to the bus,

Have a look to:

 
https://git.xenomai.org/xenomai-2.6.git/tree/ksrc/drivers/can/rtcan_raw.c#n196

If you remove the "if" statement I think it already does what you want. 
But maybe I have missed something... it's a long time that I looked to that code.

Wolfgang.

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely 
for the use of the addressee(s). If you are not the intended recipient, please 
notify the sender by e-mail and delete the original message. Further, you are not 
to copy, disclose, or distribute this e-mail or its contents to any other person and 
any such actions are unlawful. This e-mail may contain viruses. Infosys has taken 
every reasonable precaution to minimize this risk, but is not liable for any damage 
you may sustain as a result of any virus in this e-mail. You should carry out your 
own virus checks before opening the e-mail or attachment. Infosys reserves the 
right to monitor and review the content of all messages sent to or from this e-mail 
address. Messages sent to or from this e-mail address may be stored on the 
Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***

Re: Hardware Loopback on RT-Socket-CAN Needed

[Wolfgang Grandegger]

Hi Stephen,

Am 17.12.2015 um 18:25 schrieb Stephen Marshall:
> Thanks for the quick response Marc and Wolfgang.
>
> What we basically need is a loopback message on the same socket after successful TX Done. We are not going with CAN_RAW_LOOPBACK because we have only one socket.

Well, in Linux it's always active. CAN_RAW_RECV_OWN_MSGS is an extension 
of that.

>
> Wolfgang,
> Could you confirm if I need to remove the "if" at https://git.xenomai.org/xenomai-2.6.git/tree/ksrc/drivers/can/rtcan_raw.c#n196 for what I am looking for?
>
> Is this how the code should look like?
>
> while (recv_listener != NULL) {
> 	dev->rx_count++;
> 	if (rtcan_accept_msg(frame->can_id, &recv_listener->can_filter)) // removed (dev->tx_socket != recv_listener->sock check)
>               {
> 	    recv_listener->match_count++;
> 	    rtcan_rcv_deliver(recv_listener, &dev->tx_skb);
> 	}
> 	recv_listener = recv_listener->next;
>      }

This is a *HACK* just to prove that it's doing the job. A proper 
implementation would include the support and handling of 
CAN_RAW_RECV_OWN_MSGS.

> Also, if I do the modification, should we continue to use CAN_CTRLMODE_LOOPBACK?

This does something different. Message loopback in hardware (on the 
controller). And it's also hardware dependent.

> Could you give us some reference on how to make the above modification at rtcan_raw.c file and build it? Sorry, a newbie here :)

Well, you already use Xenomai with RTCAN support, I assume. Then make 
the modifications and build as usual.

Wolfgang.

> Thanks,
> Stephen Marshall
>
>
> -----Original Message-----
> From: Wolfgang Grandegger [mailto:wg@grandegger.com]
> Sent: Thursday, December 17, 2015 9:04 PM
> To: Stephen Marshall; linux-can@vger.kernel.org
> Cc: Marc Kleine-Budde
> Subject: Re: Hardware Loopback on RT-Socket-CAN Needed
>
> Hello,
>
> for RT-CAN related questions the Xenomai ML is maybe more appropriate.
>
> Am 17.12.2015 um 15:43 schrieb Marc Kleine-Budde:
>> On 12/17/2015 03:13 PM, Stephen Marshall wrote:
>>> I am looking for some information on Loopback functionality for the
>>> RT-Socket-CAN.
>>
>> You mean RT-Socket-CAN as in Xenomai? This is, as far as i know dead.
>
> It's not dead! Just little contributions.
>
>>> In Socket-CAN, we used to test the loopback functionality on own
>>> socket using the flag *CAN_RAW_RECV_OWN_MSGS *using *MSG.CONFIRM*
>>> flag. However in RT-Socket CAN we see that this option has been disabled purposefully.
>
> Can't remember why it was not implemented. I think there was just no use-case,
>
> [snip]
>
>>> We use the SJA1000 CAN Controller and Xenomai 2.6. We tried setting
>>> the SRR (Self Reception Request) bit at driver using
>>> *CAN_CTRLMODE_LOOPBACK*
>>> <http://www.xenomai.org/documentation/xenomai-2.4/html/api/group__rtc
>>> an.html#ga19ec0cc4379e80c32cbd333cf7c145e9>*,
>
> Are you still using Xenommai 2.4?
>
>>> *however it was doing a software loopback where the looped back
>>> message would not have actually gone in the bus. We needed the
>>> CAN_RAW_RECV_OWN_MSGS fix at RT-Socket-CAN, could someone help?
>
> IIRC, on the SJA1000 the hw loopback is redirecting tx messages to the rx unit (in hardware) without sending something out to the bus,
>
> Have a look to:
>
>
> https://git.xenomai.org/xenomai-2.6.git/tree/ksrc/drivers/can/rtcan_raw.c#n196
>
> If you remove the "if" statement I think it already does what you want.
> But maybe I have missed something... it's a long time that I looked to that code.
>
> Wolfgang.
>
> **************** CAUTION - Disclaimer *****************
> This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely
> for the use of the addressee(s). If you are not the intended recipient, please
> notify the sender by e-mail and delete the original message. Further, you are not
> to copy, disclose, or distribute this e-mail or its contents to any other person and
> any such actions are unlawful. This e-mail may contain viruses. Infosys has taken
> every reasonable precaution to minimize this risk, but is not liable for any damage
> you may sustain as a result of any virus in this e-mail. You should carry out your
> own virus checks before opening the e-mail or attachment. Infosys reserves the
> right to monitor and review the content of all messages sent to or from this e-mail
> address. Messages sent to or from this e-mail address may be stored on the
> Infosys e-mail system.
> ***INFOSYS******** End of Disclaimer ********INFOSYS***
>