lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e90cbad2467e2ef42db1e4a14ecdfd8c512965ea.camel@esd.eu>
Date:   Fri, 18 Jun 2021 15:55:04 +0000
From:   Stefan Mätje <Stefan.Maetje@....eu>
To:     "mailhol.vincent@...adoo.fr" <mailhol.vincent@...adoo.fr>,
        "mkl@...gutronix.de" <mkl@...gutronix.de>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-can@...r.kernel.org" <linux-can@...r.kernel.org>,
        "socketcan@...tkopp.net" <socketcan@...tkopp.net>,
        "thomas.kopp@...rochip.com" <thomas.kopp@...rochip.com>
Subject: Re: CAN-FD Transmitter Delay Compensation (TDC) on mcp2518fd

Am Freitag, den 18.06.2021, 23:27 +0900 schrieb Vincent MAILHOL:
> On Fri. 18 Jun 2021 at 21:44, Marc Kleine-Budde <mkl@...gutronix.de> wrote:
> > On 18.06.2021 20:17:51, Vincent MAILHOL wrote:
> > > > > I just noticed in the mcp2518fd data sheet:
> > > > > 
> > > > > > bit 14-8 TDCO[6:0]: Transmitter Delay Compensation Offset bits;
> > > > > > Secondary Sample Point (SSP) Two’s complement; offset can be
> > > > > > positive,
> > > > > > zero, or negative.
> > > > > > 
> > > > > > 011 1111 = 63 x TSYSCLK
> > > > > > ...
> > > > > > 000 0000 = 0 x TSYSCLK
> > > > > > ...
> > > > > > 111 1111 = –64 x TSYSCLK
> > > > > 
> > > > > Have you takes this into account?
> > > > 
> > > > I have not. And I fail to understand what would be the physical
> > > > meaning if TDCO is zero or negative.
> > 
> > The mcp25xxfd family data sheet says:
> > 
> > > SSP = TDCV + TDCO
> > > > TDCV indicates the position of the bit start on the RX pin.
> > 
> > If I understand correctly in automatic mode TDCV is measured by the CAN
> > controller and reflects the transceiver delay.
> 
> Yes. I phrased it poorly but this is what I wanted to say. It is
> the delay to propagate from the TX pin to the RX pin.
> 
> If TDCO = 0 then SSP = TDCV + 0 = TDCV thus the measurement
> occurs at the bit start on the RX pin.
> 
> > I don't know why you want
> > to subtract a time from that....
> > 
> > The rest of the relevant registers:
> > 
> > > TDCMOD[1:0]: Transmitter Delay Compensation Mode bits; Secondary Sample
> > > Point (SSP)
> > > 10-11 = Auto; measure delay and add TDCO.
> > > 01 = Manual; Do not measure, use TDCV + TDCO from register
> > > 00 = TDC Disabled
> > > 
> > > TDCO[6:0]: Transmitter Delay Compensation Offset bits; Secondary Sample
> > > Point (SSP)
> > > Two’s complement; offset can be positive, zero, or negative.
> > > 011 1111 = 63 x TSYSCLK
> > > ...
> > > 000 0000 = 0 x TSYSCLK
> > > ...
> > > 111 1111 = –64 x TSYSCLK
> > > 
> > > TDCV[5:0]: Transmitter Delay Compensation Value bits; Secondary Sample
> > > Point (SSP)
> > > 11 1111 = 63 x TSYSCLK
> > > ...
> > > 00 0000 = 0 x TSYSCLK
> 
> Aside from the negative TDCO, the rest is standard stuff. We can
> note the absence of the TDCF but that's not a blocker.
> 
> > > > If TDCO is zero, the measurement occurs on the bit start when all
> > > > the ringing occurs. That is a really bad choice to do the
> > > > measurement. If it is negative, it means that you are measuring the
> > > > previous bit o_O !?
> > 
> > I don't know...
> > 
> > > > Maybe I am missing something but I just do not get it.
> > > > 
> > > > I believe you started to implement the mcp2518fd.
> > 
> > No I've just looked into the register description.
> 
> OK. For your information, the ETAS ES58x FD devices do not allow
> the use of manual mode for TDCV. The microcontroller from
> Microchip supports it but ETAS firmware only exposes the
> automatic TDCV mode. So it can not be used to test what would
> occur if SSP = 0.
> 
> I will prepare a patch to allow zero value for both TDCV and
> TDCO (I am a bit sad because I prefer the current design, but if
> ISO allows it, I feel like I have no choice).  However, I refuse
> to allow the negative TDCO value unless someone is able to
> explain the rationale.

Hi,

perhaps I can shed some light on the idea why it is a good idea to allow
negative TDC offset values. Therefore I would describe the TDC register
interface of the ESDACC CAN-FD controller of our company (see 
https://esd.eu/en/products/esdacc).

Register description of TDC-CAN-FD register (reserved bits not shown):

bits [5..0], RO: TDC Measured (TDCmeas)
	Currently measured TDC value, needs baudrate to be set and CAN traffic

bits [21..16], R/W: TDC offset (TDCoffs)
	Depending on the selected mode (see TDC mode)
	- Auto TDC, automatic mode (default)
		signed offset onto measured TDC (TDCeff = TDCmeas + TDCoffs),
		interpreted as 6-bit two's complement value
	- Manual TDC
		absolute unsigned offset (TDCeff = TDCoffs),
		interpreted as 6-bit unsigned value
	- Other modes
		ignored
	In either case TDC offset is a number of CAN clock cycles.

bits [31..30], R/W: TDC mode
	00 = Auto TDC
	01 = Manual TDC
	10 = reserved
	11 = TDC off

So in automatic mode the goal is to be able to move the real sample point
forward and(!) backward from the measured transmitter delay. Therefore the
TDCoffs is interpreted as 6-bit two's complement value to make negative offsets
possible and to decrease the effective (used) TDCeff below the measured value
TDCmeas.

As far as I have understood our FPGA guy the TDCmeas value is the number of
clock cycles counted from the start of transmitting a dominant bit until the
dominant state reaches the RX pin.

During the data phase the sample point is controlled by the tseg values set for
the data phase but is moved additionally by the number of clocks specified by
TDCeff (or SSP in the mcp2518fd case).

Best regards,
    Stefan

PS: I'm interested in this topic because I'm in the process of preparing a
SocketCAN driver for our ESDACC base PCIe/402 CAN interface family.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ