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
