639 lines · plain
1.. SPDX-License-Identifier: GPL-2.0-or-later2 3CTU CAN FD Driver4=================5 6Author: Martin Jerabek <martin.jerabek01@gmail.com>7 8 9About CTU CAN FD IP Core10------------------------11 12`CTU CAN FD <https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core>`_13is an open source soft core written in VHDL.14It originated in 2015 as Ondrej Ille's project15at the `Department of Measurement <https://meas.fel.cvut.cz/>`_16of `FEE <http://www.fel.cvut.cz/en/>`_ at `CTU <https://www.cvut.cz/en>`_.17 18The SocketCAN driver for Xilinx Zynq SoC based MicroZed board19`Vivado integration <https://gitlab.fel.cvut.cz/canbus/zynq/zynq-can-sja1000-top>`_20and Intel Cyclone V 5CSEMA4U23C6 based DE0-Nano-SoC Terasic board21`QSys integration <https://gitlab.fel.cvut.cz/canbus/intel-soc-ctucanfd>`_22has been developed as well as support for23`PCIe integration <https://gitlab.fel.cvut.cz/canbus/pcie-ctucanfd>`_ of the core.24 25In the case of Zynq, the core is connected via the APB system bus, which does26not have enumeration support, and the device must be specified in Device Tree.27This kind of devices is called platform device in the kernel and is28handled by a platform device driver.29 30The basic functional model of the CTU CAN FD peripheral has been31accepted into QEMU mainline. See QEMU `CAN emulation support <https://www.qemu.org/docs/master/system/devices/can.html>`_32for CAN FD buses, host connection and CTU CAN FD core emulation. The development33version of emulation support can be cloned from ctu-canfd branch of QEMU local34development `repository <https://gitlab.fel.cvut.cz/canbus/qemu-canbus>`_.35 36 37About SocketCAN38---------------39 40SocketCAN is a standard common interface for CAN devices in the Linux41kernel. As the name suggests, the bus is accessed via sockets, similarly42to common network devices. The reasoning behind this is in depth43described in `Linux SocketCAN <https://www.kernel.org/doc/html/latest/networking/can.html>`_.44In short, it offers a45natural way to implement and work with higher layer protocols over CAN,46in the same way as, e.g., UDP/IP over Ethernet.47 48Device probe49~~~~~~~~~~~~50 51Before going into detail about the structure of a CAN bus device driver,52let's reiterate how the kernel gets to know about the device at all.53Some buses, like PCI or PCIe, support device enumeration. That is, when54the system boots, it discovers all the devices on the bus and reads55their configuration. The kernel identifies the device via its vendor ID56and device ID, and if there is a driver registered for this identifier57combination, its probe method is invoked to populate the driver's58instance for the given hardware. A similar situation goes with USB, only59it allows for device hot-plug.60 61The situation is different for peripherals which are directly embedded62in the SoC and connected to an internal system bus (AXI, APB, Avalon,63and others). These buses do not support enumeration, and thus the kernel64has to learn about the devices from elsewhere. This is exactly what the65Device Tree was made for.66 67Device tree68~~~~~~~~~~~69 70An entry in device tree states that a device exists in the system, how71it is reachable (on which bus it resides) and its configuration –72registers address, interrupts and so on. An example of such a device73tree is given in .74 75::76 77 / {78 /* ... */79 amba: amba {80 #address-cells = <1>;81 #size-cells = <1>;82 compatible = "simple-bus";83 84 CTU_CAN_FD_0: CTU_CAN_FD@43c30000 {85 compatible = "ctu,ctucanfd";86 interrupt-parent = <&intc>;87 interrupts = <0 30 4>;88 clocks = <&clkc 15>;89 reg = <0x43c30000 0x10000>;90 };91 };92 };93 94 95.. _sec:socketcan:drv:96 97Driver structure98~~~~~~~~~~~~~~~~99 100The driver can be divided into two parts – platform-dependent device101discovery and set up, and platform-independent CAN network device102implementation.103 104.. _sec:socketcan:platdev:105 106Platform device driver107^^^^^^^^^^^^^^^^^^^^^^108 109In the case of Zynq, the core is connected via the AXI system bus, which110does not have enumeration support, and the device must be specified in111Device Tree. This kind of devices is called *platform device* in the112kernel and is handled by a *platform device driver*\ [1]_.113 114A platform device driver provides the following things:115 116- A *probe* function117 118- A *remove* function119 120- A table of *compatible* devices that the driver can handle121 122The *probe* function is called exactly once when the device appears (or123the driver is loaded, whichever happens later). If there are more124devices handled by the same driver, the *probe* function is called for125each one of them. Its role is to allocate and initialize resources126required for handling the device, as well as set up low-level functions127for the platform-independent layer, e.g., *read_reg* and *write_reg*.128After that, the driver registers the device to a higher layer, in our129case as a *network device*.130 131The *remove* function is called when the device disappears, or the132driver is about to be unloaded. It serves to free the resources133allocated in *probe* and to unregister the device from higher layers.134 135Finally, the table of *compatible* devices states which devices the136driver can handle. The Device Tree entry ``compatible`` is matched137against the tables of all *platform drivers*.138 139.. code:: c140 141 /* Match table for OF platform binding */142 static const struct of_device_id ctucan_of_match[] = {143 { .compatible = "ctu,canfd-2", },144 { .compatible = "ctu,ctucanfd", },145 { /* end of list */ },146 };147 MODULE_DEVICE_TABLE(of, ctucan_of_match);148 149 static int ctucan_probe(struct platform_device *pdev);150 static int ctucan_remove(struct platform_device *pdev);151 152 static struct platform_driver ctucanfd_driver = {153 .probe = ctucan_probe,154 .remove = ctucan_remove,155 .driver = {156 .name = DRIVER_NAME,157 .of_match_table = ctucan_of_match,158 },159 };160 module_platform_driver(ctucanfd_driver);161 162 163.. _sec:socketcan:netdev:164 165Network device driver166^^^^^^^^^^^^^^^^^^^^^167 168Each network device must support at least these operations:169 170- Bring the device up: ``ndo_open``171 172- Bring the device down: ``ndo_close``173 174- Submit TX frames to the device: ``ndo_start_xmit``175 176- Signal TX completion and errors to the network subsystem: ISR177 178- Submit RX frames to the network subsystem: ISR and NAPI179 180There are two possible event sources: the device and the network181subsystem. Device events are usually signaled via an interrupt, handled182in an Interrupt Service Routine (ISR). Handlers for the events183originating in the network subsystem are then specified in184``struct net_device_ops``.185 186When the device is brought up, e.g., by calling ``ip link set can0 up``,187the driver’s function ``ndo_open`` is called. It should validate the188interface configuration and configure and enable the device. The189analogous opposite is ``ndo_close``, called when the device is being190brought down, be it explicitly or implicitly.191 192When the system should transmit a frame, it does so by calling193``ndo_start_xmit``, which enqueues the frame into the device. If the194device HW queue (FIFO, mailboxes or whatever the implementation is)195becomes full, the ``ndo_start_xmit`` implementation informs the network196subsystem that it should stop the TX queue (via ``netif_stop_queue``).197It is then re-enabled later in ISR when the device has some space198available again and is able to enqueue another frame.199 200All the device events are handled in ISR, namely:201 202#. **TX completion**. When the device successfully finishes transmitting203 a frame, the frame is echoed locally. On error, an informative error204 frame [2]_ is sent to the network subsystem instead. In both cases,205 the software TX queue is resumed so that more frames may be sent.206 207#. **Error condition**. If something goes wrong (e.g., the device goes208 bus-off or RX overrun happens), error counters are updated, and209 informative error frames are enqueued to SW RX queue.210 211#. **RX buffer not empty**. In this case, read the RX frames and enqueue212 them to SW RX queue. Usually NAPI is used as a middle layer (see ).213 214.. _sec:socketcan:napi:215 216NAPI217~~~~218 219The frequency of incoming frames can be high and the overhead to invoke220the interrupt service routine for each frame can cause significant221system load. There are multiple mechanisms in the Linux kernel to deal222with this situation. They evolved over the years of Linux kernel223development and enhancements. For network devices, the current standard224is NAPI – *the New API*. It is similar to classical top-half/bottom-half225interrupt handling in that it only acknowledges the interrupt in the ISR226and signals that the rest of the processing should be done in softirq227context. On top of that, it offers the possibility to *poll* for new228frames for a while. This has a potential to avoid the costly round of229enabling interrupts, handling an incoming IRQ in ISR, re-enabling the230softirq and switching context back to softirq.231 232See :ref:`Documentation/networking/napi.rst <napi>` for more information.233 234Integrating the core to Xilinx Zynq235-----------------------------------236 237The core interfaces a simple subset of the Avalon238(search for Intel **Avalon Interface Specifications**)239bus as it was originally used on240Alterra FPGA chips, yet Xilinx natively interfaces with AXI241(search for ARM **AMBA AXI and ACE Protocol Specification AXI3,242AXI4, and AXI4-Lite, ACE and ACE-Lite**).243The most obvious solution would be to use244an Avalon/AXI bridge or implement some simple conversion entity.245However, the core’s interface is half-duplex with no handshake246signaling, whereas AXI is full duplex with two-way signaling. Moreover,247even AXI-Lite slave interface is quite resource-intensive, and the248flexibility and speed of AXI are not required for a CAN core.249 250Thus a much simpler bus was chosen – APB (Advanced Peripheral Bus)251(search for ARM **AMBA APB Protocol Specification**).252APB-AXI bridge is directly available in253Xilinx Vivado, and the interface adaptor entity is just a few simple254combinatorial assignments.255 256Finally, to be able to include the core in a block diagram as a custom257IP, the core, together with the APB interface, has been packaged as a258Vivado component.259 260CTU CAN FD Driver design261------------------------262 263The general structure of a CAN device driver has already been examined264in . The next paragraphs provide a more detailed description of the CTU265CAN FD core driver in particular.266 267Low-level driver268~~~~~~~~~~~~~~~~269 270The core is not intended to be used solely with SocketCAN, and thus it271is desirable to have an OS-independent low-level driver. This low-level272driver can then be used in implementations of OS driver or directly273either on bare metal or in a user-space application. Another advantage274is that if the hardware slightly changes, only the low-level driver275needs to be modified.276 277The code [3]_ is in part automatically generated and in part written278manually by the core author, with contributions of the thesis’ author.279The low-level driver supports operations such as: set bit timing, set280controller mode, enable/disable, read RX frame, write TX frame, and so281on.282 283Configuring bit timing284~~~~~~~~~~~~~~~~~~~~~~285 286On CAN, each bit is divided into four segments: SYNC, PROP, PHASE1, and287PHASE2. Their duration is expressed in multiples of a Time Quantum288(details in `CAN Specification, Version 2.0 <http://esd.cs.ucr.edu/webres/can20.pdf>`_, chapter 8).289When configuring290bitrate, the durations of all the segments (and time quantum) must be291computed from the bitrate and Sample Point. This is performed292independently for both the Nominal bitrate and Data bitrate for CAN FD.293 294SocketCAN is fairly flexible and offers either highly customized295configuration by setting all the segment durations manually, or a296convenient configuration by setting just the bitrate and sample point297(and even that is chosen automatically per Bosch recommendation if not298specified). However, each CAN controller may have different base clock299frequency and different width of segment duration registers. The300algorithm thus needs the minimum and maximum values for the durations301(and clock prescaler) and tries to optimize the numbers to fit both the302constraints and the requested parameters.303 304.. code:: c305 306 struct can_bittiming_const {307 char name[16]; /* Name of the CAN controller hardware */308 __u32 tseg1_min; /* Time segment 1 = prop_seg + phase_seg1 */309 __u32 tseg1_max;310 __u32 tseg2_min; /* Time segment 2 = phase_seg2 */311 __u32 tseg2_max;312 __u32 sjw_max; /* Synchronisation jump width */313 __u32 brp_min; /* Bit-rate prescaler */314 __u32 brp_max;315 __u32 brp_inc;316 };317 318 319[lst:can_bittiming_const]320 321A curious reader will notice that the durations of the segments PROP_SEG322and PHASE_SEG1 are not determined separately but rather combined and323then, by default, the resulting TSEG1 is evenly divided between PROP_SEG324and PHASE_SEG1. In practice, this has virtually no consequences as the325sample point is between PHASE_SEG1 and PHASE_SEG2. In CTU CAN FD,326however, the duration registers ``PROP`` and ``PH1`` have different327widths (6 and 7 bits, respectively), so the auto-computed values might328overflow the shorter register and must thus be redistributed among the329two [4]_.330 331Handling RX332~~~~~~~~~~~333 334Frame reception is handled in NAPI queue, which is enabled from ISR when335the RXNE (RX FIFO Not Empty) bit is set. Frames are read one by one336until either no frame is left in the RX FIFO or the maximum work quota337has been reached for the NAPI poll run (see ). Each frame is then passed338to the network interface RX queue.339 340An incoming frame may be either a CAN 2.0 frame or a CAN FD frame. The341way to distinguish between these two in the kernel is to allocate either342``struct can_frame`` or ``struct canfd_frame``, the two having different343sizes. In the controller, the information about the frame type is stored344in the first word of RX FIFO.345 346This brings us a chicken-egg problem: we want to allocate the ``skb``347for the frame, and only if it succeeds, fetch the frame from FIFO;348otherwise keep it there for later. But to be able to allocate the349correct ``skb``, we have to fetch the first work of FIFO. There are350several possible solutions:351 352#. Read the word, then allocate. If it fails, discard the rest of the353 frame. When the system is low on memory, the situation is bad anyway.354 355#. Always allocate ``skb`` big enough for an FD frame beforehand. Then356 tweak the ``skb`` internals to look like it has been allocated for357 the smaller CAN 2.0 frame.358 359#. Add option to peek into the FIFO instead of consuming the word.360 361#. If the allocation fails, store the read word into driver’s data. On362 the next try, use the stored word instead of reading it again.363 364Option 1 is simple enough, but not very satisfying if we could do365better. Option 2 is not acceptable, as it would require modifying the366private state of an integral kernel structure. The slightly higher367memory consumption is just a virtual cherry on top of the “cake”. Option3683 requires non-trivial HW changes and is not ideal from the HW point of369view.370 371Option 4 seems like a good compromise, with its disadvantage being that372a partial frame may stay in the FIFO for a prolonged time. Nonetheless,373there may be just one owner of the RX FIFO, and thus no one else should374see the partial frame (disregarding some exotic debugging scenarios).375Basides, the driver resets the core on its initialization, so the376partial frame cannot be “adopted” either. In the end, option 4 was377selected [5]_.378 379.. _subsec:ctucanfd:rxtimestamp:380 381Timestamping RX frames382^^^^^^^^^^^^^^^^^^^^^^383 384The CTU CAN FD core reports the exact timestamp when the frame has been385received. The timestamp is by default captured at the sample point of386the last bit of EOF but is configurable to be captured at the SOF bit.387The timestamp source is external to the core and may be up to 64 bits388wide. At the time of writing, passing the timestamp from kernel to389userspace is not yet implemented, but is planned in the future.390 391Handling TX392~~~~~~~~~~~393 394The CTU CAN FD core has 4 independent TX buffers, each with its own395state and priority. When the core wants to transmit, a TX buffer in396Ready state with the highest priority is selected.397 398The priorities are 3bit numbers in register TX_PRIORITY399(nibble-aligned). This should be flexible enough for most use cases.400SocketCAN, however, supports only one FIFO queue for outgoing401frames [6]_. The buffer priorities may be used to simulate the FIFO402behavior by assigning each buffer a distinct priority and *rotating* the403priorities after a frame transmission is completed.404 405In addition to priority rotation, the SW must maintain head and tail406pointers into the FIFO formed by the TX buffers to be able to determine407which buffer should be used for next frame (``txb_head``) and which408should be the first completed one (``txb_tail``). The actual buffer409indices are (obviously) modulo 4 (number of TX buffers), but the410pointers must be at least one bit wider to be able to distinguish411between FIFO full and FIFO empty – in this situation,412:math:`txb\_head \equiv txb\_tail\ (\textrm{mod}\ 4)`. An example of how413the FIFO is maintained, together with priority rotation, is depicted in414 415|416 417+------+---+---+---+---+418| TXB# | 0 | 1 | 2 | 3 |419+======+===+===+===+===+420| Seq | A | B | C | |421+------+---+---+---+---+422| Prio | 7 | 6 | 5 | 4 |423+------+---+---+---+---+424| | | T | | H |425+------+---+---+---+---+426 427|428 429+------+---+---+---+---+430| TXB# | 0 | 1 | 2 | 3 |431+======+===+===+===+===+432| Seq | | B | C | |433+------+---+---+---+---+434| Prio | 4 | 7 | 6 | 5 |435+------+---+---+---+---+436| | | T | | H |437+------+---+---+---+---+438 439|440 441+------+---+---+---+---+----+442| TXB# | 0 | 1 | 2 | 3 | 0’ |443+======+===+===+===+===+====+444| Seq | E | B | C | D | |445+------+---+---+---+---+----+446| Prio | 4 | 7 | 6 | 5 | |447+------+---+---+---+---+----+448| | | T | | | H |449+------+---+---+---+---+----+450 451|452 453.. kernel-figure:: fsm_txt_buffer_user.svg454 455 TX Buffer states with possible transitions456 457.. _subsec:ctucanfd:txtimestamp:458 459Timestamping TX frames460^^^^^^^^^^^^^^^^^^^^^^461 462When submitting a frame to a TX buffer, one may specify the timestamp at463which the frame should be transmitted. The frame transmission may start464later, but not sooner. Note that the timestamp does not participate in465buffer prioritization – that is decided solely by the mechanism466described above.467 468Support for time-based packet transmission was recently merged to Linux469v4.19 `Time-based packet transmission <https://lwn.net/Articles/748879/>`_,470but it remains yet to be researched471whether this functionality will be practical for CAN.472 473Also similarly to retrieving the timestamp of RX frames, the core474supports retrieving the timestamp of TX frames – that is the time when475the frame was successfully delivered. The particulars are very similar476to timestamping RX frames and are described in .477 478Handling RX buffer overrun479~~~~~~~~~~~~~~~~~~~~~~~~~~480 481When a received frame does no more fit into the hardware RX FIFO in its482entirety, RX FIFO overrun flag (STATUS[DOR]) is set and Data Overrun483Interrupt (DOI) is triggered. When servicing the interrupt, care must be484taken first to clear the DOR flag (via COMMAND[CDO]) and after that485clear the DOI interrupt flag. Otherwise, the interrupt would be486immediately [7]_ rearmed.487 488**Note**: During development, it was discussed whether the internal HW489pipelining cannot disrupt this clear sequence and whether an additional490dummy cycle is necessary between clearing the flag and the interrupt. On491the Avalon interface, it indeed proved to be the case, but APB being492safe because it uses 2-cycle transactions. Essentially, the DOR flag493would be cleared, but DOI register’s Preset input would still be high494the cycle when the DOI clear request would also be applied (by setting495the register’s Reset input high). As Set had higher priority than Reset,496the DOI flag would not be reset. This has been already fixed by swapping497the Set/Reset priority (see issue #187).498 499Reporting Error Passive and Bus Off conditions500~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~501 502It may be desirable to report when the node reaches *Error Passive*,503*Error Warning*, and *Bus Off* conditions. The driver is notified about504error state change by an interrupt (EPI, EWLI), and then proceeds to505determine the core’s error state by reading its error counters.506 507There is, however, a slight race condition here – there is a delay508between the time when the state transition occurs (and the interrupt is509triggered) and when the error counters are read. When EPI is received,510the node may be either *Error Passive* or *Bus Off*. If the node goes511*Bus Off*, it obviously remains in the state until it is reset.512Otherwise, the node is *or was* *Error Passive*. However, it may happen513that the read state is *Error Warning* or even *Error Active*. It may be514unclear whether and what exactly to report in that case, but I515personally entertain the idea that the past error condition should still516be reported. Similarly, when EWLI is received but the state is later517detected to be *Error Passive*, *Error Passive* should be reported.518 519 520CTU CAN FD Driver Sources Reference521-----------------------------------522 523.. kernel-doc:: drivers/net/can/ctucanfd/ctucanfd.h524 :internal:525 526.. kernel-doc:: drivers/net/can/ctucanfd/ctucanfd_base.c527 :internal:528 529.. kernel-doc:: drivers/net/can/ctucanfd/ctucanfd_pci.c530 :internal:531 532.. kernel-doc:: drivers/net/can/ctucanfd/ctucanfd_platform.c533 :internal:534 535CTU CAN FD IP Core and Driver Development Acknowledgment536---------------------------------------------------------537 538* Odrej Ille <ondrej.ille@gmail.com>539 540 * started the project as student at Department of Measurement, FEE, CTU541 * invested great amount of personal time and enthusiasm to the project over years542 * worked on more funded tasks543 544* `Department of Measurement <https://meas.fel.cvut.cz/>`_,545 `Faculty of Electrical Engineering <http://www.fel.cvut.cz/en/>`_,546 `Czech Technical University <https://www.cvut.cz/en>`_547 548 * is the main investor into the project over many years549 * uses project in their CAN/CAN FD diagnostics framework for `Skoda Auto <https://www.skoda-auto.cz/>`_550 551* `Digiteq Automotive <https://www.digiteqautomotive.com/en>`_552 553 * funding of the project CAN FD Open Cores Support Linux Kernel Based Systems554 * negotiated and paid CTU to allow public access to the project555 * provided additional funding of the work556 557* `Department of Control Engineering <https://control.fel.cvut.cz/en>`_,558 `Faculty of Electrical Engineering <http://www.fel.cvut.cz/en/>`_,559 `Czech Technical University <https://www.cvut.cz/en>`_560 561 * solving the project CAN FD Open Cores Support Linux Kernel Based Systems562 * providing GitLab management563 * virtual servers and computational power for continuous integration564 * providing hardware for HIL continuous integration tests565 566* `PiKRON Ltd. <http://pikron.com/>`_567 568 * minor funding to initiate preparation of the project open-sourcing569 570* Petr Porazil <porazil@pikron.com>571 572 * design of PCIe transceiver addon board and assembly of boards573 * design and assembly of MZ_APO baseboard for MicroZed/Zynq based system574 575* Martin Jerabek <martin.jerabek01@gmail.com>576 577 * Linux driver development578 * continuous integration platform architect and GHDL updates579 * thesis `Open-source and Open-hardware CAN FD Protocol Support <https://dspace.cvut.cz/bitstream/handle/10467/80366/F3-DP-2019-Jerabek-Martin-Jerabek-thesis-2019-canfd.pdf>`_580 581* Jiri Novak <jnovak@fel.cvut.cz>582 583 * project initiation, management and use at Department of Measurement, FEE, CTU584 585* Pavel Pisa <pisa@cmp.felk.cvut.cz>586 587 * initiate open-sourcing, project coordination, management at Department of Control Engineering, FEE, CTU588 589* Jaroslav Beran<jara.beran@gmail.com>590 591 * system integration for Intel SoC, core and driver testing and updates592 593* Carsten Emde (`OSADL <https://www.osadl.org/>`_)594 595 * provided OSADL expertise to discuss IP core licensing596 * pointed to possible deadlock for LGPL and CAN bus possible patent case which lead to relicense IP core design to BSD like license597 598* Reiner Zitzmann and Holger Zeltwanger (`CAN in Automation <https://www.can-cia.org/>`_)599 600 * provided suggestions and help to inform community about the project and invited us to events focused on CAN bus future development directions601 602* Jan Charvat603 604 * implemented CTU CAN FD functional model for QEMU which has been integrated into QEMU mainline (`docs/system/devices/can.rst <https://www.qemu.org/docs/master/system/devices/can.html>`_)605 * Bachelor thesis Model of CAN FD Communication Controller for QEMU Emulator606 607Notes608-----609 610 611.. [1]612 Other buses have their own specific driver interface to set up the613 device.614 615.. [2]616 Not to be mistaken with CAN Error Frame. This is a ``can_frame`` with617 ``CAN_ERR_FLAG`` set and some error info in its ``data`` field.618 619.. [3]620 Available in CTU CAN FD repository621 `<https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core>`_622 623.. [4]624 As is done in the low-level driver functions625 ``ctucan_hw_set_nom_bittiming`` and626 ``ctucan_hw_set_data_bittiming``.627 628.. [5]629 At the time of writing this thesis, option 1 is still being used and630 the modification is queued in gitlab issue #222631 632.. [6]633 Strictly speaking, multiple CAN TX queues are supported since v4.19634 `can: enable multi-queue for SocketCAN devices <https://lore.kernel.org/patchwork/patch/913526/>`_ but no mainline driver is using635 them yet.636 637.. [7]638 Or rather in the next clock cycle639