Re: Missing CAN-XL XL data bit timing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Robert,

I've seen your interesting article in the CAN Newsletter:
https://can-newsletter.org/uploads/media/raw/9b65ce48915450ad8463848124762907.pdf

Did you join the iCC 2024 in Baden-Baden this year?

On 05.11.24 10:13, Robert Nawrath wrote:
@Vincent, thank you for the answer. Are there any plans to add the CAN
XL driver and the netlink interface for CAN XL?

The current state of my CAN XL driver for the DE1_SoC FPGA setup:

The board has an Ubuntu 22.04.4 LTS with the latest Linux mainline kernel. There are three Bosch XCANB IP cores on the FPGA and I'm using the Bosch glue code which was provided to access the CAN XL controllers via /dev/mem (!) in a polling(!) access as user root.

I moved the glue code into kernel space to be able to create a real CAN network interface driver and added some hrtimer code to poll the registers as I wasn't able to make the hardware interrupt working. I assume the interrupt routing was never implemented/tested between the FPGA and the ARM cores ¯\_(ツ)_/¯

The settings of the bittimming registers for CC/FD/XL are currently hard-coded following some CAN-CiA recommendations for integration tests, e.g. plug-fests.

I will restart my work very soon to upgrade the Kernel to the latest 6.12-rc version and I will remove the Bosch glue code, so that I can push my frankenstein out-of-tree code to GitHub for further discussions. I doubt my driver will ever reach the mainline kernel, as the XCANB IP core is not intended to become a real Bosch product IIRC.

But it is a simple core for testing and building netlink APIs.

I will take a closer look - but the netlink bittiming just seems to be a third setting for CAN XL and whether the CAN XL transceiver is switched to the CAN XL physical layer in the fast mode via PWM.

I assume there are similar configurations for your DCAN XL IP core?

Best regards,
Oliver



I use the DCAN XL implemented in FPGA. I work for Digital Core Design
and it's one of our latest IP cores. I know the CAN-XL controller is a
rare product for now.

Best regards,

Robert Nawrath


On Fri, Nov 1, 2024 at 3:27 PM Vincent Mailhol
<mailhol.vincent@xxxxxxxxxx> wrote:

+cc: Oliver

On Thu. 31 Oct. 2024 at 20:55, Robert Nawrath <mbro1689@xxxxxxxxx> wrote:
Hi,
I'm working on a kernel module for CAN-XL device. I can see in
/linux/can/dev.h that there are structures and methods for setting
bittiming and data_bittiming. The bittiming refers to CAN nominal bit
time, data_bittiming refers to CAN data bit time (using ISO/FDIS
11898-1:2024 nomenclature). But in CAN-XL the data bit rate has two
values: FD data bit rate and XL data bit rate. This values are
different and the device shall have separate configuration register
sets for them. So for separate configuration registers there shall be
separate methods and structs.
Am I right that the current implementation in kernel is incomplete? Or
am I missing something?

Yes, you are right. There is not yet a netlink interface for CAN XL,
mostly because there is not yet a CAN XL driver in linux-can and
because, before you, no one manifested a need for this.

@Oliver, in this message:

   https://lore.kernel.org/linux-can/2540406e-8da3-4cb8-bd1a-30271dd6cc67@xxxxxxxxxxxx/

you mentioned that you were working on the bitrate configuration. Any
update? Seems that this is time to make this live! I did some work on
the netlink and the iproute2 tool in the past when I added the TDC, so
eventually, I can help a bit if needed.

@Robert, out of curiosity, what is the name of your CAN XL device?


Yours sincerely,
Vincent Mailhol

Le jeu. 31 oct. 2024 à 20:55, Robert Nawrath <mbro1689@xxxxxxxxx> a écrit :

Hi,
I'm working on a kernel module for CAN-XL device. I can see in
/linux/can/dev.h that there are structures and methods for setting
bittiming and data_bittiming. The bittiming refers to CAN nominal bit
time, data_bittiming refers to CAN data bit time (using ISO/FDIS
11898-1:2024 nomenclature). But in CAN-XL the data bit rate has two
values: FD data bit rate and XL data bit rate. This values are
different and the device shall have separate configuration register
sets for them. So for separate configuration registers there shall be
separate methods and structs.
Am I right that the current implementation in kernel is incomplete? Or
am I missing something?
Robert






[Index of Archives]     [Automotive Discussions]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]     [CAN Bus]

  Powered by Linux