SJA1000 loopback feature

SJA1000 loopback feature

[Nikita Edward Baruzdin]

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

Hello.

We have several logical units working on the same CAN interface of a
SJA1000-based CAN controller. We need them to communicate with each other even
in a situation of one physical node on the bus. Thus we need some kind of a
loopback functionality for that. Software loopback works fine aside from the
fact it is performed only after an actual transmission has happened (which is a
problem with a one-node bus).

There is a CAN_CTRLMODE_LOOPBACK netlink option, but I didn't find any
description of its semantics. And as far as I understand every controller
interpretes it in its own way. For example, MCP2510 implies the loopback mode is
a silent (listen-only) mode and Bosch C_CAN controller disregards actual
rx-input in this mode according to the documentation. Hence the first question
is: what does CAN_CTRLMODE_LOOPBACK mean precisely?

I've also found out that this option is not implemented for SJA1000. Actually,
SJA1000 has nothing called a "loopback" feature but instead it has a Self Test
Mode, that seems like a reasonable solution for our problem. In this mode no
acknowledgement is required for the successful transmission, so software
loopback is working. However, it is not in the SJA1000 driver at the moment.

It is also possible to have the hardware loopback for SJA1000 with the Self
Reception Request feature (a message is transmitted and received simultaneously,
not implemented in sja1000 module as well), although we don't need it for our
specific case.

So the next question is: how should we implement those features for SJA1000?

I attached a patch that adds support for the Self Test Mode using the
CAN_CTRLMODE_LOOPBACK netlink option. As it is not exactly a loopback mode we
enable with that option, it might be a better idea to have a separate one for
that, smth like CAN_CTRLMODE_SELF_TEST. What do you think?

Regards,
Nikita

[-- Attachment #2: 0001-can-sja1000-add-Self-Test-Mode-support.patch --]
[-- Type: text/x-patch, Size: 1799 bytes --]

From 15d7abec6d72c207a742b00c1b50a6b32f42717d Mon Sep 17 00:00:00 2001
From: Nikita Edward Baruzdin <nebaruzdin@lvk.cs.msu.su>
Date: Mon, 16 Jun 2014 17:34:10 +0400
Subject: [PATCH] can: sja1000: add Self Test Mode support

This adds support for SJA1000 Self Test Mode (mode in which CAN controller will
perform a successful transmission, even if there is no acknowledge received)
through the use of CAN_CTRLMODE_LOOPBACK netlink option.

Signed-off-by: Nikita Edward Baruzdin <nebaruzdin@lvk.cs.msu.su>
---
 drivers/net/can/sja1000/sja1000.c | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/net/can/sja1000/sja1000.c b/drivers/net/can/sja1000/sja1000.c
index 7164a99..6526a46 100644
--- a/drivers/net/can/sja1000/sja1000.c
+++ b/drivers/net/can/sja1000/sja1000.c
@@ -160,6 +160,8 @@ static void set_normal_mode(struct net_device *dev)
 		/* set chip to normal mode */
 		if (priv->can.ctrlmode & CAN_CTRLMODE_LISTENONLY)
 			priv->write_reg(priv, SJA1000_MOD, MOD_LOM);
+		else if (priv->can.ctrlmode & CAN_CTRLMODE_LOOPBACK)
+			priv->write_reg(priv, SJA1000_MOD, MOD_STM);
 		else
 			priv->write_reg(priv, SJA1000_MOD, 0x00);
 
@@ -622,9 +624,11 @@ struct net_device *alloc_sja1000dev(int sizeof_priv)
 	priv->can.do_set_bittiming = sja1000_set_bittiming;
 	priv->can.do_set_mode = sja1000_set_mode;
 	priv->can.do_get_berr_counter = sja1000_get_berr_counter;
-	priv->can.ctrlmode_supported = CAN_CTRLMODE_3_SAMPLES |
-		CAN_CTRLMODE_BERR_REPORTING | CAN_CTRLMODE_LISTENONLY |
-		CAN_CTRLMODE_ONE_SHOT;
+	priv->can.ctrlmode_supported = CAN_CTRLMODE_LOOPBACK
+				     | CAN_CTRLMODE_LISTENONLY
+				     | CAN_CTRLMODE_3_SAMPLES
+				     | CAN_CTRLMODE_ONE_SHOT
+				     | CAN_CTRLMODE_BERR_REPORTING;
 
 	spin_lock_init(&priv->cmdreg_lock);
 
-- 
2.0.0

Re: SJA1000 loopback feature

[Oliver Hartkopp]

Hello Nikita,

On 16.06.2014 18:20, Nikita Edward Baruzdin wrote:

> We have several logical units working on the same CAN interface of a
> SJA1000-based CAN controller. We need them to communicate with each other even
> in a situation of one physical node on the bus. Thus we need some kind of a
> loopback functionality for that. Software loopback works fine aside from the
> fact it is performed only after an actual transmission has happened (which is a
> problem with a one-node bus).
> 
> There is a CAN_CTRLMODE_LOOPBACK netlink option, but I didn't find any
> description of its semantics. And as far as I understand every controller
> interpretes it in its own way. For example, MCP2510 implies the loopback mode is
> a silent (listen-only) mode and Bosch C_CAN controller disregards actual
> rx-input in this mode according to the documentation. Hence the first question
> is: what does CAN_CTRLMODE_LOOPBACK mean precisely?

CAN_CTRLMODE_LOOPBACK means, that the controller is able to 'shortcut' the TX
line with the RX line.

This means that you send a CAN frame to your own input pin without the need
for external CAN nodes (including acks).

> I've also found out that this option is not implemented for SJA1000. Actually,
> SJA1000 has nothing called a "loopback" feature but instead it has a Self Test
> Mode, that seems like a reasonable solution for our problem. In this mode no
> acknowledgement is required for the successful transmission, so software
> loopback is working. However, it is not in the SJA1000 driver at the moment.
> 
> It is also possible to have the hardware loopback for SJA1000 with the Self
> Reception Request feature (a message is transmitted and received simultaneously,
> not implemented in sja1000 module as well), although we don't need it for our
> specific case.
> 
> So the next question is: how should we implement those features for SJA1000?

Oh, yes - why not :-)

> 
> I attached a patch that adds support for the Self Test Mode using the
> CAN_CTRLMODE_LOOPBACK netlink option. As it is not exactly a loopback mode we
> enable with that option, it might be a better idea to have a separate one for
> that, smth like CAN_CTRLMODE_SELF_TEST. What do you think?

I think CAN_CTRLMODE_LOOPBACK still is the right description.

But when you read the SJA1000 spec, you would need to set CMD_SRR (self
reception request) instead of CMD_TR (transmission request) to have the
loopback functionality when the MOD_STM (self test mode) is enabled, right?

For the next patch post, please send the patch inline - so that is can be
reviewed and answered easier.

Many thanks,
Oliver

Re: SJA1000 loopback feature

[Nikita Edward Baruzdin]

On Mon, Jun 16, 2014 at 10:56 PM, Oliver Hartkopp <socketcan@hartkopp.net>
wrote:
> CAN_CTRLMODE_LOOPBACK means, that the controller is able to 'shortcut' the TX
> line with the RX line.

So that is what I called a hardware loopback. For SJA1000 it is done with the
SRR (Self Reception Request) feature. Note also that with SJA1000 you can't put
message from TX to RX buffer without actually sending it to the bus.

> This means that you send a CAN frame to your own input pin without the need
> for external CAN nodes (including acks).

And this is the STM (Self Test Mode) in SJA1000.

>> I attached a patch that adds support for the Self Test Mode using the
>> CAN_CTRLMODE_LOOPBACK netlink option. As it is not exactly a loopback mode we
>> enable with that option, it might be a better idea to have a separate one for
>> that, smth like CAN_CTRLMODE_SELF_TEST. What do you think?
>
> I think CAN_CTRLMODE_LOOPBACK still is the right description.
>
> But when you read the SJA1000 spec, you would need to set CMD_SRR (self
> reception request) instead of CMD_TR (transmission request) to have the
> loopback functionality when the MOD_STM (self test mode) is enabled, right?

Yes, but not necessarily. My point is: STM and SRR are in fact separate
features, so maybe they should be controlled separately. Of course, we can say
CAN_CTRLMODE_LOOPBACK = STM + SRR for SJA1000. But that is not what I wanted.

You see, we, for instance, don't really need hardware loopback for our case.
What we need is to have software loopback working. And for that STM is
necessary. If we enable SRR feature as well, we'll have each message loopbacked
twice: once by software (can_{put|get}_echo_skb() functions) and once by
hardware (message in controller's RX buffer). Thus we'll probably have to
disable the software loopback per socket (CAN_RAW_LOOPBACK option) which is not
really convenient.

Thanks for the quick response,
Nikita

Re: SJA1000 loopback feature

[Alexander GQ Gerasiov]

Tue, 17 Jun 2014 15:41:14 +0400
Nikita Edward Baruzdin <nebaruzdin@gmail.com> wrote:

> 
> You see, we, for instance, don't really need hardware loopback for
> our case. What we need is to have software loopback working. And for
> that STM is necessary. If we enable SRR feature as well, we'll have
> each message loopbacked twice: once by software
> (can_{put|get}_echo_skb() functions) and once by hardware (message in
> controller's RX buffer). Thus we'll probably have to disable the
> software loopback per socket (CAN_RAW_LOOPBACK option) which is not
> really convenient.

Just to clarify situation, Nikita is working on distributed system,
where N components are working on M physical hosts (N >> M) and should
be able to intercommunicate with each other via can bus even if M==1.
In such case, ACKs are absent on the bus, but frames are transmited
between several components within one host.

So we want to be able to tune CAN subsystem to ignore ACK absence.
As we understand, SJA1000 has the mode we are looking for (but lacks
support in driver/subsystem).

As LOOPBACK option for interface means that TX should be passed to RX,
thats not exactly what we need. (As for loopback we already have it
on the socket with CAN_RAW_LOOPBACK and CAN_RAW_RECV_OWN_MSGS.) I think
we could add one more interface mode "ignore-no-ack", but we'd like to
stay as much closer to vanilla kernel as possible and contribute our
modifications, so we need your opinion on

Is this the common situation? Do you interested in such mode and our
modifications? How should we realize thees modifications?

-- 
Alexander.

Re: SJA1000 loopback feature

[Oliver Hartkopp]

Hello Alexander,

On 17.06.2014 14:13, Alexander GQ Gerasiov wrote:
> Tue, 17 Jun 2014 15:41:14 +0400
> Nikita Edward Baruzdin <nebaruzdin@gmail.com> wrote:
> 
>>
>> You see, we, for instance, don't really need hardware loopback for
>> our case. What we need is to have software loopback working. And for
>> that STM is necessary. If we enable SRR feature as well, we'll have
>> each message loopbacked twice: once by software
>> (can_{put|get}_echo_skb() functions) and once by hardware (message in
>> controller's RX buffer). Thus we'll probably have to disable the
>> software loopback per socket (CAN_RAW_LOOPBACK option) which is not
>> really convenient.
> 
> Just to clarify situation, Nikita is working on distributed system,
> where N components are working on M physical hosts (N >> M) and should
> be able to intercommunicate with each other via can bus even if M==1.
> In such case, ACKs are absent on the bus, but frames are transmited
> between several components within one host.
> 
> So we want to be able to tune CAN subsystem to ignore ACK absence.
> As we understand, SJA1000 has the mode we are looking for (but lacks
> support in driver/subsystem).

If we would find a name for it, it could be:

#define CAN_CTRLMODE_PRESUME_ACK        0x40    /* ignore missing CAN ACKs */

> 
> As LOOPBACK option for interface means that TX should be passed to RX,
> thats not exactly what we need. (As for loopback we already have it
> on the socket with CAN_RAW_LOOPBACK and CAN_RAW_RECV_OWN_MSGS.) I think
> we could add one more interface mode "ignore-no-ack", but we'd like to
> stay as much closer to vanilla kernel as possible and contribute our
> modifications, so we need your opinion on
> 
> Is this the common situation? Do you interested in such mode and our
> modifications? How should we realize thees modifications?
> 

Just to give an example how I dealed with such situation:

1. Let all applications run on a virtual CAN interface (e.g. vcan0).
2. make a cross routing with can-gw netlink routes

E.g.
cangw -s vcan0 -d can0 -e
cangw -s can0 -d vcan0 -e

The cross routing can be done with netlink socket configuration (without using
the cangw tool). In any case the applications run in a stable CAN environment
on the virtual CAN interface. And when there's traffic on can0 it is forwarded
to vcan0 and vice versa.

Regards,
Oliver

Re: SJA1000 loopback feature

[Alexander GQ Gerasiov]

Hello, Oliver.

Wed, 18 Jun 2014 21:51:03 +0200
Oliver Hartkopp <socketcan@hartkopp.net> wrote:

> > So we want to be able to tune CAN subsystem to ignore ACK absence.
> > As we understand, SJA1000 has the mode we are looking for (but lacks
> > support in driver/subsystem).
> 
> If we would find a name for it, it could be:
> 
> #define CAN_CTRLMODE_PRESUME_ACK        0x40    /* ignore missing CAN
> ACKs */

Ok, what is the right git repository for linux-can kernel modules?
I can see
linux-can/can-modules
linux-can/linux-can
linux-can/linux-can-next

or may be there is any tree on git.kernel.org?

Where are the actual sources we need to patch?

> > As LOOPBACK option for interface means that TX should be passed to
> > RX, thats not exactly what we need. (As for loopback we already
> > have it on the socket with CAN_RAW_LOOPBACK and
> > CAN_RAW_RECV_OWN_MSGS.) I think we could add one more interface
> > mode "ignore-no-ack", but we'd like to stay as much closer to
> > vanilla kernel as possible and contribute our modifications, so we
> > need your opinion on
> > 
> > Is this the common situation? Do you interested in such mode and our
> > modifications? How should we realize thees modifications?
> > 
> 
> Just to give an example how I dealed with such situation:
> 
> 1. Let all applications run on a virtual CAN interface (e.g. vcan0).
> 2. make a cross routing with can-gw netlink routes

Yes, I was thinking about it. We strictly need the same order of
events on both buses (local/virtual and remote/hardware), but in case of
bridging (userspace, or even in-kernel one) race is possible. So we'd
better use one bus (to rule them all =)) 

-- 
Alexander.

Re: SJA1000 loopback feature

[Oliver Hartkopp]

On 19.06.2014 14:44, Alexander GQ Gerasiov wrote:

> Ok, what is the right git repository for linux-can kernel modules?
> I can see
> linux-can/can-modules
> linux-can/linux-can
> linux-can/linux-can-next

As it is a new feature linux-can/linux-can-next would be the right tree to
reference. According the CAN stuff it should be in sync with
http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git
which is the next step in the upstream process.


>>
>> Just to give an example how I dealed with such situation:
>>
>> 1. Let all applications run on a virtual CAN interface (e.g. vcan0).
>> 2. make a cross routing with can-gw netlink routes
> 
> Yes, I was thinking about it. We strictly need the same order of
> events on both buses (local/virtual and remote/hardware), but in case of
> bridging (userspace, or even in-kernel one) race is possible. So we'd
> better use one bus (to rule them all =)) 
> 

You have a strict order on vcan0. And this order is then transfered to the
real can0. OTOH the order on can0 is forwarded to vcan0. Where do you see a
problem here?

As your application does not use both CAN interfaces (vcan0/can0) at the same
time there should be no reordering when looking only at vcan0.

Due to the forwarding inside the same net-rx softirq you would no even notice
a delay.

Regards,
Oliver

Re: SJA1000 loopback feature

[Alexander GQ Gerasiov]

Thu, 19 Jun 2014 16:55:40 +0200
Oliver Hartkopp <socketcan@hartkopp.net> wrote:

> >> Just to give an example how I dealed with such situation:
> >>
> >> 1. Let all applications run on a virtual CAN interface (e.g.
> >> vcan0). 2. make a cross routing with can-gw netlink routes
> > 
> > Yes, I was thinking about it. We strictly need the same order of
> > events on both buses (local/virtual and remote/hardware), but in
> > case of bridging (userspace, or even in-kernel one) race is
> > possible. So we'd better use one bus (to rule them all =)) 
> > 
> 
> You have a strict order on vcan0. And this order is then transfered
> to the real can0. OTOH the order on can0 is forwarded to vcan0. Where
> do you see a problem here?
Correct me if I'm wrong, but if I'm quite sure, there will be the
following problem:

Application works on vcan and initiate transmit A on time T.
Another (hardware) node initiate transmit B on physical bus on the same
T.

On vcan you will see A (on T+dt1), B (on T+dt1+dt2).
On bus you will see B (on T+dt3), A (on T+dt3+dt4).

As we develop testbench environment, the order of events our software
see (and logs) should be the same as hardware nodes see.

-- 
Alexander.

Re: SJA1000 loopback feature

[Oliver Hartkopp]

On 19.06.2014 18:01, Alexander GQ Gerasiov wrote:
> Thu, 19 Jun 2014 16:55:40 +0200
> Oliver Hartkopp <socketcan@hartkopp.net> wrote:
> 
>>>> Just to give an example how I dealed with such situation:
>>>>
>>>> 1. Let all applications run on a virtual CAN interface (e.g.
>>>> vcan0). 2. make a cross routing with can-gw netlink routes
>>>
>>> Yes, I was thinking about it. We strictly need the same order of
>>> events on both buses (local/virtual and remote/hardware), but in
>>> case of bridging (userspace, or even in-kernel one) race is
>>> possible. So we'd better use one bus (to rule them all =)) 
>>>
>>
>> You have a strict order on vcan0. And this order is then transfered
>> to the real can0. OTOH the order on can0 is forwarded to vcan0. Where
>> do you see a problem here?
> Correct me if I'm wrong, but if I'm quite sure, there will be the
> following problem:
> 
> Application works on vcan and initiate transmit A on time T.
> Another (hardware) node initiate transmit B on physical bus on the same
> T.

So your hosts are absolutely synchronized (via ntp)??

> 
> On vcan you will see A (on T+dt1), B (on T+dt1+dt2).

How do you get the timestamp information then?
E.g. you can configute the routing rule with '-t' option to preserve the
src_dev rx timestamp. You would see the timestamp from the real CAN tnen.

> On bus you will see B (on T+dt3), A (on T+dt3+dt4).

Hm - i wonder if you would really see a difference as the networking stack is
not real-time anyway. When sending on vcan (which has no receive queue) the rx
is performed instantly which leads to en-queue the frame into the real CAN
interface immediately.

> 
> As we develop testbench environment, the order of events our software
> see (and logs) should be the same as hardware nodes see.
> 

Looks interesting. Your experiences are welcome :-)

Regards,
Oliver

Re: SJA1000 loopback feature

[Alexander GQ Gerasiov]

Thu, 19 Jun 2014 19:43:15 +0200
Oliver Hartkopp <socketcan@hartkopp.net> wrote:
> So your hosts are absolutely synchronized (via ntp)??
Offtopic: yes, ntp for dirty synchronization and then LinuxPPS
for +/-5 microseconds precision.

> > On vcan you will see A (on T+dt1), B (on T+dt1+dt2).
> 
> How do you get the timestamp information then?

I put timestamps here just for example.

I just need that events traced by testbench software (on vcan in your
example) should go in the same order as events real hardware (we are
testing) will see on its interface.

> E.g. you can configute the routing rule with '-t' option to preserve
> the src_dev rx timestamp. You would see the timestamp from the real
> CAN tnen.
> 
> > On bus you will see B (on T+dt3), A (on T+dt3+dt4).
> 
> Hm - i wonder if you would really see a difference as the networking
> stack is not real-time anyway.

Timestamps are not a problem (in real life they are :) ). I'm speaking
about event's order 

> When sending on vcan (which has no
> receive queue) the rx is performed instantly which leads to en-queue
> the frame into the real CAN interface immediately.

Yes, after frame will be transmitted via vcan our soft will trace
successfull send, but then this frame will go into tx-queue and here it
could stuck because another (e.g. high prio) frame is transmitted by
other host (real hardware) the same time.

vcan to can0 bridging

[Kurt Van Dijck]

Hey,

This idea just crossed my mind.

You have 2 orthogonal requirements for, I suppose, different applications.
Both requirement conflict when you're alone on the bus.
The key to success is to have each application require only 1 thing:
or you are able to communicate always,
or you receive exactly what is on physical CAN.

You can setup vcan & can0, as Oliver explained.
* applications that require permanent communication connect to vcan
* applications that require strict ordering connect to can0

If you're alone on the bus, your 'strict ordering' applications will
receive nothing, and that exactly what appears on the physical bus.
Your 'permanent communication' cannot receive strict ordering,
since nothing can be communicated then.

Kurt

On Thu, Jun 19, 2014 at 10:07:10PM +0400, Alexander GQ Gerasiov wrote:
> Thu, 19 Jun 2014 19:43:15 +0200
> Oliver Hartkopp <socketcan@hartkopp.net> wrote:
> > So your hosts are absolutely synchronized (via ntp)??
> Offtopic: yes, ntp for dirty synchronization and then LinuxPPS
> for +/-5 microseconds precision.
> 
> > > On vcan you will see A (on T+dt1), B (on T+dt1+dt2).
> > 
> > How do you get the timestamp information then?
> 
> I put timestamps here just for example.
> 
> I just need that events traced by testbench software (on vcan in your
> example) should go in the same order as events real hardware (we are
> testing) will see on its interface.
> 
> > E.g. you can configute the routing rule with '-t' option to preserve
> > the src_dev rx timestamp. You would see the timestamp from the real
> > CAN tnen.
> > 
> > > On bus you will see B (on T+dt3), A (on T+dt3+dt4).
> > 
> > Hm - i wonder if you would really see a difference as the networking
> > stack is not real-time anyway.
> 
> Timestamps are not a problem (in real life they are :) ). I'm speaking
> about event's order 
> 
> > When sending on vcan (which has no
> > receive queue) the rx is performed instantly which leads to en-queue
> > the frame into the real CAN interface immediately.
> 
> Yes, after frame will be transmitted via vcan our soft will trace
> successfull send, but then this frame will go into tx-queue and here it
> could stuck because another (e.g. high prio) frame is transmitted by
> other host (real hardware) the same time.
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-can" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html