xlinix_can: bug when sending two RTR frames

xlinix_can: bug when sending two RTR frames

[Oliver Hartkopp]

Hi xilinx_can maintainers,

Hartley Sweeten reported a bug when sending RTR frames with the 
xilinx_can driver here:

https://github.com/linux-can/can-utils/issues/405#

The problem: When sending a single RTR frame (e.g. with 'cansend can0 
001#R') nothing happens.

Only after sending a *second* RTR frame with 'cansend can0 001#R' the 
two (pending) RTR-frames are sent directly after each other.

This faulty behavior of RTR frame sending is independent of the time gap 
between the two cansend attempts.

Best regards,
Oliver

Re: xlinix_can: bug when sending two RTR frames

[Marc Kleine-Budde]

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

On 07.02.2023 21:45:20, Oliver Hartkopp wrote:
> Hi xilinx_can maintainers,
> 
> Hartley Sweeten reported a bug when sending RTR frames with the xilinx_can
> driver here:
> 
> https://github.com/linux-can/can-utils/issues/405#
> 
> The problem: When sending a single RTR frame (e.g. with 'cansend can0
> 001#R') nothing happens.
> 
> Only after sending a *second* RTR frame with 'cansend can0 001#R' the two
> (pending) RTR-frames are sent directly after each other.
> 
> This faulty behavior of RTR frame sending is independent of the time gap
> between the two cansend attempts.

More info:

| Also, this is with a kernel/rootfs created using Petalinux 2020.2.
| Linux s6 5.4.0-xilinx-v2020.2 #1 SMP PREEMPT Fri Feb 3 17:27:45 UTC 2023 armv7l GNU/Linux

Marc

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: xlinix_can: bug when sending two RTR frames

[Oliver Hartkopp]

+ Michael Simek

Missed Michael when checking the responsible people with 
scripts/get_maintainer.pl

Best regards,
Oliver

On 2/7/23 21:45, Oliver Hartkopp wrote:
> Hi xilinx_can maintainers,
> 
> Hartley Sweeten reported a bug when sending RTR frames with the 
> xilinx_can driver here:
> 
> https://github.com/linux-can/can-utils/issues/405#
> 
> The problem: When sending a single RTR frame (e.g. with 'cansend can0 
> 001#R') nothing happens.
> 
> Only after sending a *second* RTR frame with 'cansend can0 001#R' the 
> two (pending) RTR-frames are sent directly after each other.
> 
> This faulty behavior of RTR frame sending is independent of the time gap 
> between the two cansend attempts.
> 
> Best regards,
> Oliver

Re: xlinix_can: bug when sending two RTR frames

[Michal Simek]

Hi,

On 2/9/23 18:53, Oliver Hartkopp wrote:
> 
> + Michael Simek
> 
> Missed Michael when checking the responsible people with
> scripts/get_maintainer.pl
> 
> Best regards,
> Oliver
> 
> On 2/7/23 21:45, Oliver Hartkopp wrote:
>> Hi xilinx_can maintainers,
>>
>> Hartley Sweeten reported a bug when sending RTR frames with the
>> xilinx_can driver here:
>>
>> https://github.com/linux-can/can-utils/issues/405#
>>
>> The problem: When sending a single RTR frame (e.g. with 'cansend can0
>> 001#R') nothing happens.
>>
>> Only after sending a *second* RTR frame with 'cansend can0 001#R' the
>> two (pending) RTR-frames are sent directly after each other.
>>
>> This faulty behavior of RTR frame sending is independent of the time gap
>> between the two cansend attempts.

I read that thread and I am missing details about Zynq board.
Are you using any custom zynq board or any xilinx standard evaluation board?

Can you please c&p dt fragment you use?

You are using 5.4 kernel which is quite old. Can you please switch to the latest 
upstream or 5.15 xilinx?

Thanks,
Michal

RE: xlinix_can: bug when sending two RTR frames

[Hartley Sweeten]

On Thursday, February 16, 2023 4:19 AM, Michal Simek wrote:
>> On 2/7/23 21:45, Oliver Hartkopp wrote:
>> Hi xilinx_can maintainers,
>>>
>>> Hartley Sweeten reported a bug when sending RTR frames with the 
>>> xilinx_can driver here:
>>>
>>> https://github.com/linux-can/can-utils/issues/405#
>>>
>>> The problem: When sending a single RTR frame (e.g. with 'cansend can0
>>> 001#R') nothing happens.
>>>
>>> Only after sending a *second* RTR frame with 'cansend can0 001#R' the 
>>> two (pending) RTR-frames are sent directly after each other.
>>>
>>> This faulty behavior of RTR frame sending is independent of the time 
>>> gap between the two cansend attempts.
>
> I read that thread and I am missing details about Zynq board.
> Are you using any custom zynq board or any xilinx standard evaluation board?

The system is a Trenz TE0720 SoM on a custom carrier board.

CAN0 is routed to EMIO.
	Tx -> pin E16 (LVCMOS33)
	Rx -> pin F16 (LVCMOS33)

The CAN implementation on the carrier board is like on the ZC702 (TXS0104 buffer / TJA1040T transceiver).

> Can you please c&p dt fragment you use?

All of the can@e0008000 node information is from what is created automatically by PetaLinux.

This is the node info from 'dtc -I fs /sys/firmware/devicetree/base'

                can@e0008000 {
                        compatible = "xlnx,zynq-can-1.0";
                        clocks = <0x01 0x13 0x01 0x24>;
                        tx-fifo-depth = <0x40>;
                        clock-names = "can_clk\0pclk";
                        status = "okay";
                        interrupt-parent = <0x04>;
                        interrupts = <0x00 0x1c 0x04>;
                        phandle = <0x1a>;
                        reg = <0xe0008000 0x1000>;
                        rx-fifo-depth = <0x40>;
                };

> You are using 5.4 kernel which is quite old. Can you please switch to the latest upstream or 5.15 xilinx?

Uh.. Difficult.

I'm using PetaLinux 2020.2 right now and _finally_ have something working with it after spending the last year trying to figure it out.

I'm a bit nervous about installing a newer version of Vivado/Vitis/PetaLinux right now. And I don't know how to make PetaLinux 2020.2 use a different kernel version.

Thanks,
Michal

Re: xlinix_can: bug when sending two RTR frames

[Oliver Hartkopp]

Hi Michal,

On 2/16/23 16:34, Hartley Sweeten wrote:
> On Thursday, February 16, 2023 4:19 AM, Michal Simek wrote:
>>> On 2/7/23 21:45, Oliver Hartkopp wrote:
>>> Hi xilinx_can maintainers,
>>>>
>>>> Hartley Sweeten reported a bug when sending RTR frames with the
>>>> xilinx_can driver here:
>>>>
>>>> https://github.com/linux-can/can-utils/issues/405#
>>>>
>>>> The problem: When sending a single RTR frame (e.g. with 'cansend can0
>>>> 001#R') nothing happens.
>>>>
>>>> Only after sending a *second* RTR frame with 'cansend can0 001#R' the
>>>> two (pending) RTR-frames are sent directly after each other.
>>>>
>>>> This faulty behavior of RTR frame sending is independent of the time
>>>> gap between the two cansend attempts.
>>
>> I read that thread and I am missing details about Zynq board.
>> Are you using any custom zynq board or any xilinx standard evaluation board?
> 
> The system is a Trenz TE0720 SoM on a custom carrier board.
> 
> CAN0 is routed to EMIO.
> 	Tx -> pin E16 (LVCMOS33)
> 	Rx -> pin F16 (LVCMOS33)
> 
> The CAN implementation on the carrier board is like on the ZC702 (TXS0104 buffer / TJA1040T transceiver).
> 
>> Can you please c&p dt fragment you use?
> 
> All of the can@e0008000 node information is from what is created automatically by PetaLinux.
> 
> This is the node info from 'dtc -I fs /sys/firmware/devicetree/base'
> 
>                  can@e0008000 {
>                          compatible = "xlnx,zynq-can-1.0";
>                          clocks = <0x01 0x13 0x01 0x24>;
>                          tx-fifo-depth = <0x40>;
>                          clock-names = "can_clk\0pclk";
>                          status = "okay";
>                          interrupt-parent = <0x04>;
>                          interrupts = <0x00 0x1c 0x04>;
>                          phandle = <0x1a>;
>                          reg = <0xe0008000 0x1000>;
>                          rx-fifo-depth = <0x40>;
>                  };
> 
>> You are using 5.4 kernel which is quite old. Can you please switch to the latest upstream or 5.15 xilinx?
> 
> Uh.. Difficult.
> 
> I'm using PetaLinux 2020.2 right now and _finally_ have something working with it after spending the last year trying to figure it out.
> 
> I'm a bit nervous about installing a newer version of Vivado/Vitis/PetaLinux right now. And I don't know how to make PetaLinux 2020.2 use a different kernel version.
> 

Thanks for picking up this topic!

I double-checked the code and commits from either

- 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/drivers/net/can/xilinx_can.c?h=linux-5.15.y

- 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/drivers/net/can/xilinx_can.c?h=linux-5.4.y

- 
https://github.com/Xilinx/linux-xlnx/blob/xlnx_rebase_v5.15_LTS/drivers/net/can/xilinx_can.c

- xilinx_can.c from the latest 6.2-rc8

And the code sections relevant for this bug report (in the tx path) - 
especially xcan_write_frame() 
https://github.com/Xilinx/linux-xlnx/blob/xlnx_rebase_v5.15_LTS/drivers/net/can/xilinx_can.c#L569 
- do not differ.

So the bug should show up with all the Linux versions and you should be 
able to see it whatever setup you have on your desk.

Best regards,
Oliver

RE: xlinix_can: bug when sending two RTR frames

[Hartley Sweeten]

On Thursday, February 16, 2023 10:10 AM, Oliver Hartkopp wrote:
> On 2/16/23 16:34, Hartley Sweeten wrote:
>> On Thursday, February 16, 2023 4:19 AM, Michal Simek wrote:
>>>> On 2/7/23 21:45, Oliver Hartkopp wrote:
>>>> Hi xilinx_can maintainers,
>>>>>
>>>>> Hartley Sweeten reported a bug when sending RTR frames with the 
>>>>> xilinx_can driver here:
>>>>>
>>>>> https://github.com/linux-can/can-utils/issues/405#
>>>>>
>>>>> The problem: When sending a single RTR frame (e.g. with 'cansend 
>>>>> can0
>>>>> 001#R') nothing happens.
>>>>>
>>>>> Only after sending a *second* RTR frame with 'cansend can0 001#R' 
>>>>> the two (pending) RTR-frames are sent directly after each other.
>>>>>
>>>>> This faulty behavior of RTR frame sending is independent of the 
>>>>> time gap between the two cansend attempts.
>>>
>>> I read that thread and I am missing details about Zynq board.
>>> Are you using any custom zynq board or any xilinx standard evaluation board?
>>
>> The system is a Trenz TE0720 SoM on a custom carrier board.
>>
>> CAN0 is routed to EMIO.
>>       Tx -> pin E16 (LVCMOS33)
>>       Rx -> pin F16 (LVCMOS33)
>>
>> The CAN implementation on the carrier board is like on the ZC702 (TXS0104 buffer / TJA1040T transceiver).
>>

Just some more info in case it helps.

I have a logic analyzer connected to the Tx/Rx signals going to the TJA1040T transceiver and an oscilloscope connected to the CANH/L signals.

If I try doing the following:

$ cansend can0 001#R
$ cansend can0 003#R

I only see the 001#R message and response on the logic analyzer and oscilloscope. The 003#R message is never sent.

But non RTR messages are always sent immediately.

Hartley

Re: RE: xlinix_can: bug when sending two RTR frames

[Marc Kleine-Budde]

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

On 17.02.2023 15:52:33, Hartley Sweeten wrote:
> But non RTR messages are always sent immediately.

| https://github.com/linux-can/can-utils/issues/405#issuecomment-1438257809

Neeli Srinivas says:

| Thanks for letting us know,
| We are able to reproduce the issue on our end.
| we are looking into it. Will get back to you.

Thanks,
Marc

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]