CTU CAN FD IP Core issueshttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues2021-05-17T12:30:31Zhttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/414Linux driver verification2021-05-17T12:30:31ZIlle, Ondrej, Ing.Linux driver verificationCurrently, there are no tests for Linux driver itself. Automated FPGA build
run in CTU synthesizes latest RTL and runs set of communication tests with SJA1000.
This is good basic sanity test that "communication works". This test will not...Currently, there are no tests for Linux driver itself. Automated FPGA build
run in CTU synthesizes latest RTL and runs set of communication tests with SJA1000.
This is good basic sanity test that "communication works". This test will not properly
test following conditions:
1. Error handling, REC/TEC readout towards proper value (there was a bug in driver where
REC/TEC readout was swapped).
2. Arbitration lost handling.
3. Fault-state changes (to active, passive and bus-off, reintegration and joining the bus
back-on).
This task deals with creating set of tests which will run as part of CI pipeline.
These tests shall verify the functionality of Linux driver and all its corner-cases.
Several approaches are possible:
1. Use Qemu + VPCIe framework and do co-simulation of GHDL + Qemu (virtual Linux + RTL simulation).
2. Use some framework for linux driver testing (e.g. SymDrive, Linux driver test...)Linux driverhttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/396Use kernel compliant register map in linux driver2021-09-25T09:46:44ZIlle, Ondrej, Ing.Use kernel compliant register map in linux driverLinux driver shall be able to use also Linux kernel compliant format for description of register map.
This task deals with extending register map generator with such target and swapping header with bit fields
for kernel compliant headers.Linux driver shall be able to use also Linux kernel compliant format for description of register map.
This task deals with extending register map generator with such target and swapping header with bit fields
for kernel compliant headers.Linux driverhttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/324Do not return TX_OK2019-10-23T18:24:54ZIlle, Ondrej, Ing.Do not return TX_OKModify Linux driver not to return NETDEV_TX_OK when failed to insert CAN frame!Modify Linux driver not to return NETDEV_TX_OK when failed to insert CAN frame!Linux driverhttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/322Linux driver review2019-10-30T21:51:43ZIlle, Ondrej, Ing.Linux driver reviewLinux driverhttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/319Fix flipped TXC, RXC in driver.2019-10-09T19:18:11ZIlle, Ondrej, Ing.Fix flipped TXC, RXC in driver.Linux driverhttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/308Remove tripple sampling mode from driver2019-10-30T21:58:47ZIlle, Ondrej, Ing.Remove tripple sampling mode from driverThis is a legacy feature and shall be removed as it is not present in HW anymore!This is a legacy feature and shall be removed as it is not present in HW anymore!Linux driverhttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/250Add SSP_CFG support to driver2019-11-12T07:11:39ZIlle, Ondrej, Ing.Add SSP_CFG support to driverImplement functions for accessing SSP_CFG configuration register in
low-level C driver.Implement functions for accessing SSP_CFG configuration register in
low-level C driver.Linux driverMartin JeřábekMartin Jeřábekhttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/233Add timestamp support to driver2019-01-20T17:24:55ZIlle, Ondrej, Ing.Add timestamp support to driverAdd Support for reading timestamp to low-level driver.
First rework in:
https://gitlab.fel.cvut.cz/illeondr/CAN_FD_IP_Core/merge_requests/179
must be merged so that we don't get more conflicts...Add Support for reading timestamp to low-level driver.
First rework in:
https://gitlab.fel.cvut.cz/illeondr/CAN_FD_IP_Core/merge_requests/179
must be merged so that we don't get more conflicts...Linux driverhttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/223driver: disabling DOI during RX handling in NAPI: to do or not to do2019-03-07T14:31:48ZMartin Jeřábekdriver: disabling DOI during RX handling in NAPI: to do or not to doAs I'm describing this particular bit of implementation in the thesis, I intended to write *why* this behavior (i.e. disabling DOI for RX handling) is necessary, but realized I can not justify it enough.
Originally it was introduced bec...As I'm describing this particular bit of implementation in the thesis, I intended to write *why* this behavior (i.e. disabling DOI for RX handling) is necessary, but realized I can not justify it enough.
Originally it was introduced because I thought it's the cause of #183, but that proved to be false (I just needed to clear DOR flag too). The argument that it is better to be reading the data than to handle DOI sounds weak to me - we're not on a slow high realtime cpu. Moreover, about the only place where the overrun could occur is between the RXBNEI and reading all the frames, and we would really want to be informed about the overrun. Plus some other process might take over the NAPI process, or the SW RX queue might become full, in which case the NAPI stays queued, but stopped.
It is now clear that the current approach is wrong. An alternative is to disable/reenable DOI in the polling routine. That does not sound too bad. The DOR flag would be checked after reading all the available frames, so that performance shouldn't be significantly hurt (one extra bus access).
There might be, however, a situation, when continuous data are streamed on CAN and DOR is used by the protocol to detect that a frame will be missing. Due to HW queuing, it can only be used to mean that "somewhere in the near future", a frame (or more) went missing, not "exactly after this frame" some went missing. IMHO this is an useless problem, as nobody sane would be leveraging this mechanism
On second reading, the "after reading all the frames, check for overrun" part sounds a bit ridiculous. It still might make sense when max work quota is reached, but would still be problematic if the thread is preempted (for a non-short time). That might not happen with current NAPI implementation, but who knows ...
**So in conclusion**: remove the special handling and keep it just in ISR, then test that it really works (it should)Linux driverMartin JeřábekMartin Jeřábekhttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/222driver: rx: skb alloc vs metadata fetch from fifo2019-03-07T14:31:46ZMartin Jeřábekdriver: rx: skb alloc vs metadata fetch from fifoIf the allocation fails, store the read word into driver's data. On next try, use the stored word instead of reading it again. Do not discard the partial frame.
This is a better solution to implementing RX FIFO peek register in HW, sugg...If the allocation fails, store the read word into driver's data. On next try, use the stored word instead of reading it again. Do not discard the partial frame.
This is a better solution to implementing RX FIFO peek register in HW, suggested by Mr. Pisa. I thought that we had an issue for the PEEK register, but I didn't find it.
To be implemented after the PCI driver is merged, which will probably be after I finish writing the thesis.Linux driverMartin JeřábekMartin Jeřábekhttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/216Interfacing CAN FD core to PCI Express bus2019-01-10T17:47:17ZPavel PisaInterfacing CAN FD core to PCI Express busThe goal of the work is to interface [CTU CAN FD core](https://gitlab.fel.cvut.cz/canbus/CAN_FD_IP_Core) to [PCI Express](https://en.wikipedia.org/wiki/PCI_Express) bus which allows
its use on regular PC hardware.
The Devboards Gmb [DB4...The goal of the work is to interface [CTU CAN FD core](https://gitlab.fel.cvut.cz/canbus/CAN_FD_IP_Core) to [PCI Express](https://en.wikipedia.org/wiki/PCI_Express) bus which allows
its use on regular PC hardware.
The Devboards Gmb [DB4CGX15](https://www.devboards.de/en/home/products/product-details/article/db4cgx15/) board has been used for the work. The board is based on Intel/Altera EP4CGX15
Cyclone IV FPGA. Addon IO expander with CAN FD transceiver has been used. It has been initially
designed at PiKRON Ltd. for A0B36APO course [semestral work](https://cw.fel.cvut.cz/old/courses/a0b36apo/en/tutorials/10/start).
Unmodified CTU CAN FD core has been included in separated project [PCIe CTU CAN FD](https://gitlab.fel.cvut.cz/canbus/pcie-ctu_can_fd). Quartus QSYS is used to
map the core over Avalon to External Bus Bridge to IP_Compiler for PCI Express hard PCIe
core to PCIe bus.
The project contains design files, configuration files and scripts to test PCIe design
and to program device by Qurtus and indepedently by commandline [UrJTAG](http://urjtag.org/)
open-source tool.
PCIe support has been implemented for CTU CAN FD driver and result has been integrated to main
CTU CAN FD repository.Linux driverPavel PisaPavel Pisahttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/177driver: bittiming min/max constraints for PROP/PH1 may be violated2018-08-13T16:16:37ZMartin Jeřábekdriver: bittiming min/max constraints for PROP/PH1 may be violated`struct can_bittiming_const` contains min/max only for `tseg1`, `tseg2`, `sjw`, `brp`.
In definition, it that `tseg1 = prop_seg + phase_seg1` and in the bitrate calculation,
there is
```c
bt->prop_seg = tseg1 / 2;
bt->phase_seg1 = tseg1 ...`struct can_bittiming_const` contains min/max only for `tseg1`, `tseg2`, `sjw`, `brp`.
In definition, it that `tseg1 = prop_seg + phase_seg1` and in the bitrate calculation,
there is
```c
bt->prop_seg = tseg1 / 2;
bt->phase_seg1 = tseg1 - bt->prop_seg;
```
PROP is 7 bits (max 127), PH1 is 6 bits (max 63), so further sanitization is required!Linux driverMartin JeřábekMartin Jeřábekhttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/161driver: cleanup, select names2019-10-16T19:54:24ZMartin Jeřábekdriver: cleanup, select namesThe final issue to be handled in the driver milestone.
Choose:
* function prefix
* name of device in device treeThe final issue to be handled in the driver milestone.
Choose:
* function prefix
* name of device in device treeLinux driverhttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/160driver: event logger support2019-03-14T19:55:27ZMartin Jeřábekdriver: event logger supportMust research this. How to pass events to userspace? As error frames? Or a file descriptor?Must research this. How to pass events to userspace? As error frames? Or a file descriptor?Linux driverhttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/159driver: message filter support2018-07-19T13:40:21ZMartin Jeřábekdriver: message filter supportMust research this.
* detect which HW msg filters are configured in the IP
* ...Must research this.
* detect which HW msg filters are configured in the IP
* ...Linux driverMartin JeřábekMartin Jeřábekhttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/158driver: support for retrieving RX frame timestamp2022-01-04T10:32:19ZMartin Jeřábekdriver: support for retrieving RX frame timestamp* [x] read to skbuf
* [ ] ~~configure support via ioctl~~
* [ ] configure where to sample: SOF/EOF (ioctl?)
* [ ] research drivers counters (time source?), how to pass the timestamp source via device tree
* will need defined bitwidth ...* [x] read to skbuf
* [ ] ~~configure support via ioctl~~
* [ ] configure where to sample: SOF/EOF (ioctl?)
* [ ] research drivers counters (time source?), how to pass the timestamp source via device tree
* will need defined bitwidth to correctly wrap around (few counters will implement full 64 bits)Linux driverMartin JeřábekMartin Jeřábekhttps://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/-/issues/157driver: handle SocketCAN mode switches2018-06-20T15:15:03ZMartin Jeřábekdriver: handle SocketCAN mode switches* [x] CAN_CTRLMODE_LISTENONLY
* [x] CAN_CTRLMODE_3_SAMPLES
* [x] CAN_CTRLMODE_FD (enable/disable FD)
* [x] CAN_CTRLMODE_PRESUME_ACK
* [x] CAN_CTRLMODE_FD_NON_ISO
* [x] CAN_CTRLMODE_ONE_SHOT* [x] CAN_CTRLMODE_LISTENONLY
* [x] CAN_CTRLMODE_3_SAMPLES
* [x] CAN_CTRLMODE_FD (enable/disable FD)
* [x] CAN_CTRLMODE_PRESUME_ACK
* [x] CAN_CTRLMODE_FD_NON_ISO
* [x] CAN_CTRLMODE_ONE_SHOTLinux driverMartin JeřábekMartin Jeřábek