[[PageOutline]]
= V2X - Vehicle to Anything

V2X is a technology to allow a vehicle to communicate with other items. This uses a special RF Radio. 

More details are provided in the [https://www.gateworks.com/vehicle-v2x/ Gateworks V2X Guide]

[[Image(som301.png,200px)]]

== Venice GW72xx & GW73xx V2X

The Gateworks Venice GW72xx & GW73xx Single Board Computer (SBC) can be used to host the Unex V2X Radio. The SOM-301x radio requires 5V, 3.3V and USB 2.0. The 3.3V and USB 2.0 are provided by default but the 5V is not. A UART is also required for development.  

To enable 5V access on the J10 Mini-PCIe slot, the following resistors need to be loaded at the Gateworks factory before ordering. Note that a 100 piece minimum order is required for special configurations. 

GW72xx: 
 * Load R152, R153, R144, R145 for 5V (use 02240128 which is a 0402 0-Ohm resistor)
  * This enables 5V on pins 3, 5, 45, 47

The below resistors are for the UART and are by default unloaded on the GW72xx to avoid any conflicts: 
 * R164, R165 for UART3 (use 02240128) (Pins 17 & 19)


GW73xx:
 * Load R5, R6, R102, R101 for 5V (use 02240128 which is a 0402 0-Ohm resistor)
  * This enables 5V on pins 3, 5, 45, 47

The below resistors are for the UART and are by default unloaded on the GW73xx to avoid any conflicts: 
 * R104, R103 for UART3 (use 02240128) *Note UART3 is also used for the onboard !WiFi/BLE and will conflict

An example schematic snippet is shown below.

[[Image(v2xpoweranduart.png,300px)]]

== GPS PPS Signal
The GPS PPS Signal uses pin 49.

== SOM-301x Datasheet / Manual
 * [https://www.unex.com.tw/products/v2x/v2xsolution/v2xmodule]
 * [https://www.unex.com.tw/guide/SOM-301x.pdf Manual]

== UART Information for GW73xx

The UART3 (/dev/ttymxc2) on J10 on a GW73xx board is shared with the onboard Bluetooth module. 

This is defined in the device tree here:
[https://github.com/Gateworks/linux-venice/blob/v5.15.15-venice/arch/arm64/boot/dts/freescale/imx8mm-venice-gw73xx.dtsi#L218]

{{{
/* bluetooth HCI */
&uart3 {
     pinctrl-names = "default";
     pinctrl-0 = <&pinctrl_uart3>, <&pinctrl_bten>;
     cts-gpios = <&gpio5 8 GPIO_ACTIVE_LOW>;
     rts-gpios = <&gpio5 9 GPIO_ACTIVE_LOW>;
     status = "okay";

     bluetooth {
            compatible = "brcm,bcm4330-bt";
            shutdown-gpios = <&gpio1 3 GPIO_ACTIVE_HIGH>;
     };
};

}}}

To understand this better, think of how it works: UART devices don't have any sort of magic device 'auto-detection' like enumerated busses such as PCI and USB do (which have a bus infrastructure to provide things like a class, manufacturer, and device ID). Therefore device-tree must be used to explain to the OS what is there and map it to a driver. This is what the 'compatible = "brcm,bcm4330-bt"' string does; there is a driver that matches that compatible string.

It is possible to not see a /dev/ttymxc2 corresponding to schematic UART3 (NXP references hardware blocks as 1 based, Linux references them as 0 based) is indeed because the bluetooth HCI driver (hci_bcm) claims the UART such that Linux removes access from it to not conflict with it. The 'hci_bcm' driver won't fail to recognize the UART (ie if on a GW7300 which doesn't load that part) and remove it's claim on the device. Gateworks will not typically try to do things like removing that dynamically in the boot firmware via a dt fixup based on the model (because mapping model strings to what parts are loaded is a really bad idea).

To remedy this, one can either comment out the 'bluetooth' node in the device-tree if using a custom kernel/dt or use a 'fix_fdt' script.

- In Linux find the device path
{{{
# find /proc/device-tree/ -name "bluetooth"
/proc/device-tree/soc@0/bus@30800000/spba-bus@30800000/serial@30880000/bluetooth
}}}

- In U-Boot create a fixfdt script as documented on our wiki [http://trac.gateworks.com/wiki/linux/devicetree#fixfdtscript]
{{{
u-boot=> setenv fixfdt 'fdt addr $fdt_addr_r; fdt resize; fdt set /soc@0/bus@30800000/spba-bus@30800000/serial@30880000/bluetooth status disabled'
}}}

If the V2X support requires a kernel driver then it will need a device-tree binding of its own in which case one can use a dt overlay or customize the device tree.