[[PageOutline]] = Ventana Errata The below errata only affects certain models and certain revisions. Please contact support@gateworks.com with any questions. [=#hw1] == HW1 GW54xx-B Analog Video Input non functional Issue: * The three analog video inputs available at connector J27 are not functional on GW54xx products with PCB 02210121-01 (rev B product) because of a pixel bus swap between the video decoder and the i.MX6 processor. Resolution: * This is resolved on PCB 02210121-02 (rev C) Affected Product: * GW54xx-B (PCB 02210121-01) [=#hw2] == HW2 GW54xx-B GPS Antenna Short Protection Not Operational Issue: * The GPS antenna short protection circuit is bypassed on the GW54xx products with PCB 02210121-01 (rev B product ). Active antennas are fully functional but not protected against a short circuit. Resolution: * This is resolved on PCB 02210121-02 (rev C) Affected Product: * GW54xx-B (PCB 02210121-01) products with GPS loaded [=#hw4] == HW4 Tamper switch non-functional Issue: * Early revision GW54xx/GW53xx/GW52xx boards have a capacitor loaded on the tamper circuit which makes it un-usable for the GSC tamper feature (Note that it still works as a GSC GPIO). Resolution: * GW52xx: remove C68 * GW53xx: remove C110 * GW54xx: remove C473 Fixed in: * GW52xx-C (PCB 02210119-02) * GW53xx-C (PCB 02210120-02) * GW54xx-E (PCB 02210121-04) Affected Products: * GW52xx-A/B (PCB 02210119-00, 02210119-01) * GW53xx-A/B (PCB 02210120-00, 02210120-01) * GW54xx-A/B/C/D (PCB 02210121-00, 02210121-01, 02210121-02, 02210121-03) [=#hw5] == HW5 GW52xx-A USB OTG routing select through mux inverted Issue: * The GW52xx uses a 1-to-2 mux to route USB OTG to either the front-panel micro-USB or to one of the PCI sockets (which the USB EHCI host routes to the other PCI socket). The initial revision of the GW52xx (GW52xx-A) defaulted this to route to the miniPCIe socket when the desire is to have it routed by default on power-up to the front panel connector. Resolution: * Ground OTG_ID via a buffer that is active-high enabled by the USBOTG_SKT GPIO so that when USBOTG_SKT GPIO is high to select PCI SKT, ID gets grounded and forces it to host mode Add a 1k pulldown to USBOTG_SKT which is stronger than the 100k pullup at powerup so that the power-on default is front-panel Work-around: * steer GPIO2 manually in software: {{{#!bash echo 2 > /sys/class/gpio/export echo out > /sys/class/gpio/gpio2/direction # will default to output low }}} Fixed in: * GW52xx-B (PCB 02210119-01) Affected Products: * GW52xx-A (PCB 02210119-00) [=#hw6] == HW6 GW53xx-A/B 5V insufficient for maximum peripheral expansion Issue: * The 800mA 5V supply on the intial GW53xx revisions is not sufficient to power the variety of peripherals that are possible such as: two USB devices (potentially 500mA ea), CAN transceiver (70mA max), LVDS connector (varies per display but est 500mA), HDMI termination (50mA max) Work-around: * Limit peripheral expansion Fixed in: * GW53xx-C (PCB 02210120-02) - 5V supply replaced with 1.5A supply. Each USB port can supply a max of 500mA each and the additional peripherals have 500mA allocated for them to share (typically most of this is optional for an LVDS display device). Affected Products: * GW53xx-A/B (PCB 02210120-00, PCB 02210120-01) [=#hw7] == HW7 GW51xx-A/B pre-mature Watchdog resets Issue: * The GW51xx-A and GW51xx-B is susceptible to pre-mature IMX6 CPU watchdog timeouts due to the RTC XTAL input not being grounded. Noise on this signal which can occur at higher temperatures can cause this to be used as the xtal source instead of the intended internal oscillator. Work-around: * Disable IMX6 CPU watchdog (this is done in the current Ventana bootloader by removing the device-node entry for the CPU watchdog). Use GSC CPU watchdog if a watchdog is necessary (this is available with GSC firmware v44) Fixed in: * GW51xx-C (PCB 02210118-02) Affected Products: * GW51xx-A/B (PCB 02210118-00, 02210118-01) [=#hw8] == HW8 Power backfeed when board powered down while OTG connected to PC host Issue: * When an affected board is connected to a powered PC Host over USB OTG and the board is powered down, an unusual amount of current is allowed to backfeed through the IMX6 CPU and can potentially cause the 3.3V primary supply to provide partial voltage affecting the 3.3V power LED. Work-around: * Remove OTG connection when powering down Fixed in: * GW51xx-C (PCB 02210118-02) * GW52xx-B (PCB 02210119-01) * GW53xx-C (PCB 02210120-02) * GW54xx-E (PCB 02210121-04) Affected Products: * GW51xx-A/B (PCB 02210118-00, 02210118-01) * GW52xx-A (PCB 02210119-00) * GW53xx-A/B (PCB 02210120-00, PCB 02210120-01) * GW54xx-A/B/C/D (PCB 02210121-00, PCB 02210121-01, PCB 02210121-02, PCB 02210121-03) [=#hw9] == HW9 GW551x-A YUV422 semi-planar capture not supported (does not support 1080p@60Hz) Issue: * The GW551x-A is missing some signals required for 'gated clock' capture mode and as such only YUV422 BT656 capture from the HDMI receiver is possible. In this mode any resolution over 1080p@30Hz is not supported. See [wiki:Yocto/Video_In#hdmi here] for more info. Work-around: * Use default YUV422 BT656 capture mode (which will be the default when using the latest bootloader/kernel). Fixed in: * GW551x-B (PCB 02210161-01) Affected Products: * GW551x-A (PCB 02210161-00) [=#hw10] == HW10 GW551x-A USB OTG Device Mode non-functional Issue: * The GW551x-A does not connect the USBOTG_VBUS signal which is needed by the USB OTG host controller in order to go into device mode. This also causes hot-swap events to not trigger a bus re-enumeration when a device is hot-swapped in host mode. Work-around: * Do not use USB OTG device mode * Force a re-enumeration manually on a hot-swap event, or hot-swap at the microAB connector (thus causing ID to change state) Fixed in: * GW551x-B (PCB 02210161-01) Affected Products: * GW551x-A (PCB 02210161-00) [=#hw11] == HW11 GW16111-A I2C buffer is not enabled Issue: * The GW16111-A does not enable the I2C buffer properly making the 3pin I2C header non-functional Work-around: * None Fixed in: * GW16111-B (PCB 02210162-01) Affected Products: * GW16111-A (PCB 02210162-00) [=#hw12] == HW12 IMX Watchdog reset can result in a board hang with IMX6Q Issue: * The Power Management IC (PMIC) on the Ventana boards does not get reset in the event of an IMX watchdog reset. This can cause a board hang under certain circumstances: If the processor was running at 400MHz at the time the reset occurred and a PMIC driver is being used for dynamic voltage scaling which has reduced the IMX voltage rails for 400MHz operation (referred to as ldo-bypass mode). In this specific case, the IMX will come out of reset at 800MHz (per OTP fuse configuration) and the voltage rails to the IMX will be insufficient for that frequency and the board will hang in the BOOT ROM. The voltage rail differential has been found to not cause an issue on IMX6S or IMX6DL cpus and it only causes an issue on the IMX6Q. Because this is an internal reset the GSC boot watchdog (not to be confused with the standard GSC watchdog) does not get enabled. Note that an IMX watchdog reset that can cause this occurs in the following situations: watchdog timeout when using the IMX watchdog (instead of the GSC watchdog), a kernel crash, a soft reboot. Work-arounds: * Use the GSC watchdog (which is a more robust means of watchdog protection as it power cycles the entire board) instead of the IMX watchdog. This means you would enable the GSC watchdog (see gsc) as well as use the GSC to reboot the board (see [http://trac.gateworks.com/wiki/gscreboot here]). * Disable PMIC dynamic voltage scaling below the 800MHz operating point by either: - disabling Dynanmic Voltage and Scaling completely by disabling the cpufreq driver (voltage rails will always be at their maximum value) - disabling the PMIC driver (voltage rails will always be at their maximum value but CPU frequency is allowed to shift) - disable the 400MHz operating point (thus ensuring the PMIC voltage rails are always sufficient for powerup at 800MHz) - adjusting the 400MHz operating point voltage rails up to the 800Mhz values Resolution: * A change has been made at the PCB level to allow the IMX6 external watchdog reset signal to reset the PMIC. This requires a kernel update (pending) as well as a bootloader update: ​cf7e51ea * All Ventana BSP's are now using ldo-enabled mode which means the PMIC rails are always set at a safe-maximum and the internal IMX6 LDO further regulates the voltage as needed. This avoids the potential issue of the PMIC rails being too low at reset time. Fixed in: * GW51xx*-E (PCB 02210118-04) * GW520x*-D (PCB 02210119-03) * GW5220*-B (PCB 02210166-01) * GW53xx*-E (PCB 02210120-04) * GW54xx*-D (PCB 02210121-03) * GW551x*-C (PCB 02210161-02) * GW552x*-C (PCB 02210147-02) [=#hw13] == HW13 PCIe bus errors Issue: * An out-of-spec DC bias of the clock output on the IMX6 to the PCI clock buffer input can result in noise from the processor being coupled to the PCIe clock ultimately causing PCIe bus errors. This can result in hangs during PCI enumeration and PCI device configuration as well as unexpected errors during device operation. It has been found that this occurs on newer silicon IMX6S/IMX6DL r1.2 and IMX6Q r1.3 (reported as r1.5 by the bootloader which is technically the ROM version) and has not been found on earlier silicon revisions. Work-arounds: * a board-level rework adding a 100ohm resistor across the CLK-/+ inputs to the clock buffer eliminates the issue. Affected Products: * Boards using PCIe bridge and clock buffer: - GW52xx - GW53xx - GW552x Resolution: * Next revision product will incorporate clock generators in order to fully support PCIe Gen2 which will also resolve this clock coupling issue. * Current product will be bumped to a new BOM level (dot level) that adds the 100ohm resistor across the CLK-/+ inputs. Fixed in: * GW51xx*-E (PCB 02210118-04) * GW52xx: - GW520x*-D (PCB 02210119-03) - GW5200-C.2 (PCB 02210119-02) - GW5201-B.2 (PCB 02210119-01) - GW5204-C.1 (PCB 02210119-02) * GW522x: - GW5220*-C (PCB 02210166-02) - GW5220-B.1 (PCB 02210166-01) * GW53xx: - GW53xx*-E (PCB 02210120-04) - GW5300-C.1 (PCB 02210120-02) - GW5301-B.1 (PCB 02210120-01) - GW5304-C.2 (PCB 02210120-02) - GW5304-D.2 (PCB 02210120-04) - GW5310-D.1 (PCB 02210120-04) - GW5311-B.1 (PCB 02210120-01) * GW551x*-C (PCB 02210161-02) * GW552x*-C (PCB 02210147-02) [=#hw14] == HW14 PCIe Gen2 compliance (enhancement) Issue: * The IMX6 LVDS clock commonly used as a PCIe clock does not meet the clock jitter requirements of PCIe Gen2. Note that Gen2 link training is currently disabled in the Gateworks BSP's so that we are within spec. Work-around: * Disable Gen2 PCIe link in the kernel. Note that this has been done in the Gateworks OpenWrt 14.08 and Yocto v1.6-v1.8 kernels. Enhancement: * Next revision product will incorporate clock generators in addition to providing the IMX6 with a clock input from the generator. A software update will be required to configure PCIe clock input on the IMX6 and re-enable Gen2 link training. Without the software update older software will keep Gen2 disabled without any adverse affects. Added in: * GW51xx*-E (PCB 02210118-04) * GW520x*-D (PCB 02210119-03) * GW5220*-C (PCB 02210166-02) * GW53xx*-E (PCB 02210120-04) * GW54xx*-E (PCB 02210121-03) * GW551x*-C (PCB 02210161-02) * GW552x*-C (PCB 02210147-02) [=#hw16] == HW16: micro-SD UHS-I enhanced clock support (enhancement) Issue: * micro-SD UHS-I compliant cards allow for clock frequencies above the 50MHz High Speed (HS) standard resulting in improved bus bandwidth. This requires the I/O rail to be switched from 3.3V to 1.8V. * Note that both card and controller (IMX6) need to support this switchable I/O rail in order for cards to be used with the higher clock. If both do not support UHS-I then traditional HS clock is used and you gain no performance advantage. * Note that a software update may be required for board revisions that incorporate UHS-I support for microSD to work at all as one of the unused NAND chip-select signals is routed to the microSD host controller voltage select. Older Gateworks kernels pinmuxed this signal to a 2nd NAND chip-select which puts the microSD voltage select in an invalid state. Change: * A switchable I/O rail has been added to baseboard products that support micro-SD card slots. Added in: * GW520x*-D (PCB 02210119-03) * GW5220*-B (PCB 02210166-01) * GW53xx*-E (PCB 02210120-04) * GW54xx*-E (PCB 02210121-03) [=#hw17] == HW17 GW520x-C USB routing to miniPCIe J7 socket Issue: * The USB sideband signals on Mini-PCIe site J7 are non-functional. Work-around: * Use J8 USB: Note the J8 site must be configured in software to support USB since it shares the signals with the front panel OTG port. See: - [wiki:ventana/bootloader#USBFront-panelvsPCIesocketrouting ​bootloader USB routing config] - [wiki:ventana/gw5200usb ​GW5200 USB] * If USB signaling is required on both sites, a wire-mod can be performed to the board by the factory. Contact support@… for more information. Affected Product: * GW520x-C (PCB 02210119-02) Fixed in: * GW520x-D (PCB 02210119-03) [=#hw18] == HW18 GW53xx-C/D/E 5V inrush current limited at 100mA Issue: * In order to address HW6, the 5V boost was updated to allow a max current of 1.5A. This new device was found to have an inrush current limitation of around 100mA which causes the device to go into a current limit fault condition when exceeded. Devices, such as LVDS displays, that pull more than this on power on will not reliably power on. Work-around: * Isolate the 5V from the LVDS cable and wire it to VUSB from the front-panel USB connector. In the bootloader you need to execute usb start in order to turn on VUSB but this is not needed once the kernel boots. Affected Product: * GW53xx-C (PCB 02210120-02) * GW53xx-D (PCB 02210120-03) * GW53xx-E (PCB 02210120-04) Fixed in: * GW53xx-F (PCB 02210120-05) - New 5V supply added for CAN transceiver, HDMI DDC, and LVDS. [=#hw19] == HW19: GW16082 irq mapping Issue: * The TI XIO2001 PCIe-to-PCI bridge on the GW16082 has its interrupt mapping reversed with regards to the PCI specification: ||= Slot =||= proper pin1 irq =||= GW16082 pin1 irq =|| || 12 || INTA || INTD || || 13 || INTA || INTC || || 14 || INTA || INTB || || 15 || INTA || INTA || Work-around: * for kernels that obtain irqs through device-tree mapping, a device-tree fixup can be implemented in the bootloader that provides the actual irq mapping for the XIO2001 bridge. This fixup is present in Gateworks bootloader intended for kernels based on Linux 3.18+ (PCI needs to be enabled in the bootloader for this fixup: setenv pcidisable; saveenv * for kernels that do not obtain irqs through device-tree mapping, a custom swizzle function can be implemented in the kernel for use when mapping interrupts to devices downstream from the XIO2001 bridge. This fixup is present in Gateworks downstream vendor kernels based on Linux 3.10 and 3.14. Affected Product: * GW16082-A (PCB 02210130-00) * GW16082-B (PCB 02210130-01) [=#hw20] == HW20: 16bit YUV HDMI capture not supported Issue: * The GW551x-C is missing HS/VS/PCK/DE signalling and can not capture HDMI video in 16bit synchronous mode. Work-around: * Use bt656 mode. A [https://github.com/Gateworks/u-boot-imx6/commit/0b60446ef8345b15c2014a7fb7655de76e587bc5 ​bootloader fixup] is available in the latest Gateworks bootloader which configures GW551x-C to use yuv422bt656 mode instead of the default yuv422smp mode. This work-around lowers the max resolution that can be captured to 1080p@30Hz. Fixed in: * GW551x-D (PCB 02210161-03) Affected Products: * GW551x-C (PCB 02210161-02) [=#hw21] == HW21: 1st Generation QCA 802.11n PCIe devices may not enumerate properly Issue: * Recent revision Ventana boards with PCIe bridges may not enumerate 1st generation QCA 802.11n PCIe devices properly resulting in devices showing up as VendorID 0x168c and DeviceID 0xff1c. This has been observed on AR9280 (168c:002a) and AR9285 (168c:002b) and is caused by the PERST# line being de-asserted on power-up before PCIe clock is stable. Even though PERST# is later asserted and de-asserted these 1st generation QCA 802.11n PCIe devices can get stuck and not complete their initialization. Work-around: * A 1kohm pull-down resistor can be added to the PERST# signal. Fixed in: * GW5200-E (PCB 02210119-04) * GW5300-G (PCB 02210120-06) * GW5400-G (PCB 02210121-06) * GW5520-D (PCB 02210147-03) * GW5904-D (PCB 02210184-03) Affected Products: * GW5200-C/D (PCB 02210119-02 02210119-03) * GW5300-C/D/E/F (PCB 02210120-02 02210120-03 02210120-04 02210120-05) * GW5400-E/F (PCB 02210121-04 02210121-05) * GW5520-B/C (PCB 02210147-01 02210147-02) * GW5904-A/B/C (PCB 02210184-00 02210184-01 02210184-02) [=#hw22] == HW22: EOL Micron 2GiB NAND FLASH replaced with Cypress 2GiB NAND FLASH (geometry and performance change) Issue: * End of Life of the Micron 2GiB NAND FLASH device used on Ventana GW5xx4 board models (and customer specials) has caused a change to a different FLASH device that has a differing geometry (page size, block size), ECC strength, and performance. These changes can cause a code change in firmware (bootloader and ubi image) as well as an update to the Gateworks {{{jtag_usbv4}}} JTAG programming software. Work-around: * To support the ECC change: - Use the Gateworks 2015.04 Bootloader with [https://github.com/Gateworks/u-boot-imx6/commit/a8572c2d12714a29113dbc90cc12e5fbef387bc7 a85742c] or the Gateworks 2017.05 Bootloader branch or newer - Use the latest {{{jtag_usbv4}}} (v4.1) programming software * To support the FLASH geometry change: - Use and create FLASH ubi images that were created with the 'normal' FLASH geometry (2K block size and a max-leb-count of 16384): see [wiki:linux/ubi#flashgeometry here for details] * To support the performance change: - Use the Gateworks 2017.05 Bootloader with [https://github.com/Gateworks/linux-imx6/commit/f3fbc0ec02a04ed1eb7bdb7f6ba6b65eb86a1ea9 f3fbc0e] for best performance (supports new Flash in EDO mode 4) - Use the Gateworks 4.20 kernel for best Linux performance (supports new Flash in EDO mode 4) - Use the Gateworks 4.4 OpenWrt kernel with [https://github.com/Gateworks/openwrt/commit/1937a7cbc834de3dc249d8f0dc7f6390da1c9716 1937a7c] (supports new Flash in EDO mode 4) - Use the latest Gateworks 4.20 and OpenWrt 16.02 bootscripts which enable UBI fastmap support (for decreased boot time). * To identify the model number and revision, review this [wiki:modelserialnumber#ModelNumber wiki page] Affected Products that have moved to the new NAND FLASH geometry: * GW5104-F.1+ * GW5204-D.1+ * GW5224-F.1+ * GW5304-F.1+ * GW5314-F.1+ * GW5404-F.2+ * GW5514-D.1+ * GW5524 TBD * GW5534-B.1+ * Any customer specials utilizing the 2GiB MT29F16G08 NAND Flash [=#hw23] == HW23: EOL ADV7180 Analog Video Decoder replaced with ADV7280A Issue: * End of Life of the ADV7180 Analog video decoder device used on Ventana GW51xx, GW52xx, GW53xx, GW54xx, GW553x board models (and customer specials) has caused a change to an ADV7280A. While the ADV7280A has the same features as the ADV7180 it requires driver support. Work-around: * Use the Gateworks 2017.05 Bootloader with [https://github.com/Gateworks/u-boot-imx6/commit/348a052e0c7d00dead5439de7d6ba6a579b5b42e 348a052 (GW53xx)], [https://github.com/Gateworks/u-boot-imx6/commit/16ccf17599ae72643eba26cba056e1952c737c42 16ccf17 (GW53xx)],[https://github.com/Gateworks/u-boot-imx6/commit/97bb78bc0d7134d2b98e462c9e148f52c524104f 97bb78b (GW54xx)] * Use the Gateworks 3.14 kernel with [https://github.com/Gateworks/linux-imx6/commit/bc4e236209a80c9578246fb173f66566748bc3e8 bc42236] * Use the Gateworks 4.20 kernel or greater with [TODO] Affected Products that have moved to the new ADV7280A: * GW54xx-G+ * GW53xx-G+ [=#hw24] == HW24: EOL Wi2Wi W2SG0008i GPS receiver replaced with ublox ZOE-M8Q GPS receiver Issue: * End of Life of the Wi2Wi GPS receiver used on Ventana GW51xx, GW52xx, GW53xx, GW54xx, GW553x board models (and customer specials) has caused a change to the ublox ZOE-M8Q GPS receiver. While both GPS receivers output NMEA 0183 messages at 1Hz the W2SG0008i GPS came up at 4800baud and the ZOE-M8Q comes up at 9600baud. Work-around: * Make sure your software can auto-baud and is compatible with the NMEA sentences of the ZOE-M8Q * If your hardware makes use of the GPS PPS signal routed to miniPCIe sockets make sure your hardware is compatible with a 3.3V TTL signal. Affected Products that have moved from the Wi2Wi W2SG0008i to ublox ZOE-M8Q: * GW53xx-G+ * GW54xx-G+ [=#hw25] == HW25: EOL Marvell 88E1510 RGMII phy replaced with TI DP83867 phy Issue: * End of Life of the Marvell 88E1510 RGMII phy used on Ventana GW51xx, GW52xx, GW53xx, GW54xx board models (and customer specials) attached the the IMX6 FEC internal MAC has caused a change to the TI DP83867 phy. Work-around: * Use the Gateworks 2017.05 Bootloader with [https://github.com/Gateworks/u-boot-imx6/commit/f904fbd2cc5b33ed6f8f2583d0b711d770858996 f904fbd]. Affected Products that have moved from the Marvell 88E1510 to TI DP83867 RGMII phy: * GW53xx-G+ * GW54xx-G+ [=#hw26] == HW26: EOL Marvell 88E8057 GbE MAC/PHY replaced with Intel I210 GbE MAC/PHY Issue: * End of Life of the Marvell 88E8057 GbE MAC/PHY used on Ventana GW54xx and GW53xx as the eth1 GbE has caused a change to the Intel I210 GbE MAC/PHY. Work-around: * Make sure the kernel has support for the igb driver. Affected Products that have moved from the Marvell 88E8057 GbE MAC/PHY to the I210 GbE MAC/PHY: * GW53xx-G+ * GW54xx-G+ [=#hw27] == HW27: Reverse Current Susceptibility Issue: * While 'reverse polarity' protection exists on most Gateworks boards allowing Vin polarity reversal to not damage boards, 'reverse current' protection does not exist on certain boards which could cause board damage under specific situations. A condition which would allow for such damage is if a board was connected to a Power-Over-Ethernet supply (regardless of if it is enabled for Active PoE) as well as at the same time powered with a lower voltage supply connected to board input power (ie barrel jack or 2-pin Vin aux connector). For example powering a board with 48V PoE at the same time as a 24V supply on the barrel jack would cause power to flow from the higher PoE positive rail back through the supply connected to the barrel jack which could put the supply in an over-current failure mode that sinks current directly to ground damaging the Gateworks board. Affected Products: * GW5908-A (PCB 02210189-00) * GW5912-A (PCB 02210200-00) * GW54xx-G/H (PCB 02210121-06, 02210121-07) * GW53xx-G (PCB 02210120-06) [=#hw28] == HW28: MAC Address ETH1 GW53xx/GW54xx Issue: * The MAC address of ETH1 is programmed the same as ETH0(MAC0). Thus, duplicate MAC's exist on both ETH interfaces. * Note, it is very rare this would be encountered. It would require both ethernet ports to be connected into identical network segments. This is a specialized case. Even in a case where a failover is being used, everything would still work as the failover port wouldn't be active until the primary port fails. Performing things like bonding or assigning a port to a virtual server are scenarios where this errata may affect the system. Work-around: * Manually set the ETH1 to MAC1 at runtime each time the board boots with the following script: * {{{ # Obtain the 2nd MAC address from the Gateworks System Controller EEPROM mac1=$(i2cdump -f -y 0 0x51 | grep "00: " | cut -c 23-39 | tr " | " ":") # set the address ip link set dev eth1 down ip link set dev eth1 address $mac1 ip link set dev eth1 up ip link show eth1 }}} * Return the SBC to Gateworks via an RMA to have the board reprogrammed. Affected Products: * GW53xx-G * GW54xx-G.1 Fixed In: * GW53xx-G.1 * GW54xx-G.2