Version 52 (modified by 7 years ago) ( diff ) | ,
---|
Gateworks Newport Family Support
Getting Started |
Newport Software |
Peripherals |
User Manuals |
Wireless / WiFi Radios |
Cellular Modems |
GPS |
3D Model |
The Gateworks Newport product family utilizes the Cavium ARM ThunderX CN80xx / CN81xx SoC (System On Chip) offering a large variety of peripherals with a focus on Networking, and Security. See here for a product comparison matrix.
Links
Please note: This is a subset of information for Newport, however, please visit our Main Wiki for all other information
Software
- Gateworks Newport Board Support Package
- Pre-built Firmware Images
- Newport Boot Firmware (up to and including the Bootloader)
- Newport U-Boot Bootloader
- Linux kernel support
- Booting Third Party Linux Distro's on Newport
- Newport JTAG Programming
Peripheral Support
- Gateworks Expansion Modules - GW16081, GW16082, GW16083
- SPI Support
- I2C Support
- GPIO Control
- LED Control
- Connector and Cable Information
- mSATA Information
- GPS Support
- CAN Bus Support
- PCI/PCIe information
- PCIe Accessory Cards
- MultiMediaCard (microSD/eMMC) Information
- Gateworks System Controller (GSC) - Temperature, voltage, RTC, GPIO, Digital IO, I/O, pushbutton, etc
- Gateworks Enclosures
Performance / Processor / Memory / Power / Thermal
Other Info
- Product Info
- Where to Buy
- Newport Board Ordering Options
- Newport Board Errata
- Linux Kernel Device-Tree info
User Manual
Processor Reference Manual / Datasheet / Errata
The Cavium Website contains details about the OCTEON TX Dual and Quad core 64bit ARM based SoC's.
Additional references:
Newport Ethernet
GW6300:
- Linux eth0, U-Boot vnic0, SGMII PHY port, J20 RJ45 inside port closest to USB port. Passive PoE.
- Linux eth1, U-Boot vnic1, RGMII PHY port, J19 RJ45 nearest panel mount LED. Active PoE.
Firmware Versioning
You can determine the firmware version of various portions of the firmware by looking for banners on the serial console. For example:
Gateworks Newport SPL (ea21abc Tue Dec 12 23:42:48 UTC 2017) GSC : v49 0x832c WDT:disabled board temp:61C RTC : 0 Model : GW6304-B ... NOTICE: BL1: v1.3(release):OCTEONTX_SDK_6_2_0_build_26 NOTICE: BL1: Built : 15:30:07, Dec 4 2017 ... U-Boot 2017.09-rc1-00023-g1fd1415 (Dec 12 2017 - 15:42:30 -0800) for Cavium OcteonTX CN81XX ARM V8 Core ... [ 0.000000] Linux version 4.14.4-00005-g9e5958b (tharvey@tharvey) (gcc version 5.3.0 (Cavium Inc. Version 0.99 build 440)) #141 SMP PREEMPT Fri Dec 15 10:18:19 PST 2017 ... Ubuntu 16.04 LTS xenial-newport ttyAMA0 ...
- The above output shows you:
- Secondary Program Loader (SPL) is 'ea21abc' built on Tue Dec 12 23:42:48 2017. The git sha of 'ea21abc'.
- GSC v49 0x832c
- ATF (ARM Trusted Firmware) is v1.3 built on Dec 4 2017.
- U-Boot is '2017.09-rc1-00023-g1fd1415' built on Dec 12 2017.
- Linux version 4.14.4-00005-g9e5958b built on Fri Dec 15 10:18:19 PST 2017
- Ubuntu 16.04 (aka xenial) OS (use
dpkg -l | grep "^ii"
to see what packages and versions are installed
If you want more detail on the versions of the various components of the Boot Firmware you can look at the version
file created/placed by the Newport BSP Makefile in the FAT12 filesystem. See newport/boot/version for details.
Updating Firmware
This section provides instructions for updating both GSC firmware as well as boot device firmware.
There are two methods for updating firmware:
- on a live board using Serial Console and Ethernet (Note that currently the eMMC FLASH can only be updated on a live board booted from either eMMC or microSD)
- on removable storage (ie recovery microSD)
- using a GW16099 JTAG dongle (see below) (Note that currently only the GSC firmware can be updated via JTAG)
The various items that can be updated:
- GSC Firmware - currently only JTAG updates are supported for Newport - see below
- Boot Firmware (Everything up to and including the Bootloader) - currently must be updated from U-Boot or Linux on a live system - see below
- Root Filesystem (Operating System) - currently must be updated from U-Boot or Linux on a live system - see below
Update Firmware via Serial Console and Ethernet
The quickest and easiest way to update your firmware is via Serial Console and Ethernet. You can do this either in the U-Boot bootloader (recommended) or within a Linux OS. If your primary boot device is corrupt, then you can boot via an alternate boot device (ie microSD) - see newport/recovery for details.
Update Firmware via Serial Console and Ethernet from Bootloader
If updating firmware via Bootloader/Serial/Ethernet (recommended for speed) you need to setup a TFTP server to host the files for transfer. Alternatively you could load firmware files from removable storage (microSD, mSATA, or USB for example) however the transfer rate is typically very slow compared to Gigabit Ethernet. For details on setting up a TFTP server see here.
The following instructions assume your board target IP address is 192.168.1.1 and you have a TFTP server at 192.168.1.146. Adjust environment according to your network via 'setenv ipaddr <ipaddr>' and 'setenv serverip <serverip>'.
Note that the dev
variable needs to be set to the MMC device you are updating:
- setenv dev 0 # boot device
- setenv dev 1 # secondary device
- use
mmc list
to see how they are configured
The methods you use to update the firmware depends on what specifically you are trying to update.
Update the entire device from a Compressed Disk Image ('boot firmware' as well as OS):
setenv dev 0 # use 'mmc list' to show which device to use for eMMC vs microSD tftpboot ${loadaddr} xenial-newport.img.gz && gzwrite mmc ${dev} ${loadaddr} ${filesize}
- If the image was created using a minimally sized filesystem you will want to resize it after booting to take advantage of the full partition space. For an
ext4
root filesystem on the primary MMC device runresize2fs /dev/mmcblk0p2
.
Updating just the kernel can be done with tftpboot
and fatwrite
:
# kernel tftpboot $loadaddr kernel.itb && fatwrite mmc $dev:1 $loadaddr kernel.itb $filesize # bootscript tftpboot $loadaddr newport.scr && fatwrite mmc $dev:1 $loadaddr newport.scr $filesize
Updating the Boot firmware (everything up to and including the Bootloader): On a Newport booted to the bootloader:
mmc dev 0 # use 'mmc list' to show which device to use for eMMC vs microSD tftpboot ${loadaddr} firmware-newport.img && mmc write ${loadaddr} 0 8000 # update first 16MB mmc rescan # re-scan the mmc devices in case the partition table changed
Update Firmware via Serial Console and Ethernet from Linux
If booted to Linux on a board you can also update the kernel and bootscript fairly easily by mounting the FAT12 filesystem and copying the file(s):
mount /dev/mmcblk0p1 /mnt cp kernel.itb /mnt cp newport.scr /mnt
You can also easily update the Boot Firmware. First prepare a boot image that contains your desired partition table, boot firmware, kernel, bootscript and U-Boot environment (see example above). Then on a booted Newport:
cd /tmp wget http://dev.gateworks.com/newport/boot_firmware/firmware-newport.img dd if=firmware-newport.img of=/dev/mmcblk0
- Note above we are writing to
/dev/mmcblk0
and not a partition - Use
/dev/mmcblk1
for the secondary MMC device (ie microSD) - Note that Newport boards only supports MMC based boot devices
- Note that this overwrites the partition-table, the U-Boot environment, and the FAT12 filesystem which are things you might have customizations in.
Note that if you want to update the root filesystem itself from within Linux you can only do this by either:
a) updating portions of the live filesystem that are not in use (ie package updates) b) booting to a kernel+ramdisk (ie [wiki:buildroot buildroot) and imaging the disk
Creating a microSD recovery image
If your primary boot won't boot for some reason (ie, you corrupted it during development) you can boot from a microSD (see here).
To create a bootable microSD meant for recovery purposes only needing the Bootloader you can use firmware-newport.img:
- On a Linux host:
DEVICE=/dev/sdc # set to the microSD on your host sudo dd if=firmware-newport.img of=$DEVICE
- Be careful to set the DEVICE above to the device the microSD appears as on your Linux host - you do not want to overwrite part of your hosts filesystem
- On a Newport board booted from eMMC from U-Boot:
mmc list # if booted from eMMC you should see microSD as dev 1 mmc dev 1 # select microSD tftpboot ${loadaddr} firmware-newport.img && mmc write ${loadaddr} 0 8000
JTAG Programming
The Gateworks JTAG adapter (GW16099) is available in the Newport Dev Kit as well as on the Gateworks web store here
All Newport boards have a 10-pin JTAG header which provides:
- JTAG Programming for embedded FLASH - see here for instructions
- Serial Console access via UART0 (/dev/ttyAMA0)
Please Note:
- Linux software is supported for programming Newport (jtag_usbv4 required). Windows is not supported at this time. (serial console through Windows does work).
- JTAG Programming of eMMC has not been made available yet. You must boot from a microSD image to program or re-program eMMC flash
- JTAG Programming of the GSC firmware is supported by the most recent version of jtag_usbv4 here
Update GSC Firmware via JTAG
To update the GSC firmware via JTAG download the jtag_usbv4
application on a Linux x86 host from here and execute as follows:
./jtag_usbv4 -m gsc_630x_v49.txt
Note that the ftdi_sio
kernel module must not be loaded (sudo rmmod ftdi_sio) and you may need to run this command as root by pre-pending a sudo depending on the configuration of your linux host.
For more details please see:
Boot Device
Some boards have multiple boot device and may allow selection of which one is the 'primary boot device':
board | Primary Boot Device | Alternate Boot Device |
---|---|---|
GW630x | on board eMMC | microSD |
To boot from the alternate boot device manually you can press-and-release the user pushbutton 5 times in a row and the board will power cycle primary power (the 3.3V LED will go off, then on again) and the board will boot from the alternate boot device.
Boards with an Alternate boot device also have a boot watchdog such that if the current boot device fails to boot within 30 seconds, the board will power cycle primary power and attempt boot from the other boot device.
The bootloader also has a notion of boot device, either the built in eMMC or an external microSD. This is controlled through the UBoot variable 'dev'. The dev variable is purely for the bootloader, and does not signify what device to boot the kernel/rootfs from.
Note if booting with the onboard eMMC as the primary boot device, “0/mmcblk0” is the U-Boot/Linux device node for eMMC and “1/mmcblk1” is the U-Boot/Linux device node for microSD. When booting from the alternate device (microSD) this is swapped.
Booting to a kernel/rootfs on the microSD
This assumes the bootloader will remain on the eMMC, but then we switch to the microSD for the kernel/rootfs.
Run the following commands in the uboot bootloader command prompt on the Newport SBC serial console:
#This tells the board to always get the bootloader from emmc, which is ok.
setenv dev 0
#now we are going to create a NEW script called boot_sd for booting from the microSD: #note the ext4load command grabs from 1:2, which means dev 1, which will be the microSD as long as you set #dev to 0 above (meaning dev 0 will be emmc, which will hold the bootloader, and then 1 would be the microSD)
setenv boot_sd "ext4load mmc 1:2 ${kernel_addr} boot/${kernel} && setenv root '/dev/mmcblk0p2 rw rootwait' && run setargs && booti ${kernel_addr} - ${fdtcontroladdr}"
#now save everything
saveenv
#now boot to microSD
run boot_sd
If you want to then start doing this automatically everytime, you would look at the variable called boot_cmd. It currently uses the built in script we have to boot from mmc (which means emmc)
GW6304-B> print bootcmd bootcmd=run boot_mmc
#if you want to modify this to boot from your new script:
setenv bootcmd 'run boot_sd' saveenv reset
Board Support Packages (BSP) Software
Choosing a BSP
Gateworks offers several Board Support Packages for the Newport Product family. Which one we recommend depends a bit upon what your goal is and what your experience level is.
- Ubuntu
- Recommended for developers trying to heavily leverage opensource software packages or libraries that are not supported by the other BSP's. This is the most user-friendly for developers new to Embedded Linux but will not produce a very trimmed down filesystem image.
- Uses mainline kernel.
- Supports all Newport features.
- Documentation provided to use Ubuntu pre-built packages and debootstrap to create a root filesystem in minutes
- Native compilation: no SDK or cross-toolchain needed
- OpenWrt - intended for wireless routers and access points (low flash and memory footprint)
- Recommended for networking users wanting to create a headless router, VPN, basestation, wireless access point and more. Produces by far the smallest storage and memory footprint but users new to Embedded Linux will have a bit of a learning curve
- Fairly up-to-date and/or vanilla kernel support
- Latest wireless drivers (via linux-backports)
- Custom application config and init system (nice for small footprint, but can make adding support for additional packages more work)
- Wide variety of packages (including a fairly nice web-admin)
- Console-based build system (expect 60mins to build BSP for a specific board family)
- Downloadable SDK and Toolchain available to build apps on a development host without building the entire BSP
- easy firmware upgrade (sysupgrade) and factory-default reset mechanism
- Pre-built images available
The following table may also help in choosing what BSP is right for you:
Feature | OpenWrt | Ubuntu | Notes |
---|---|---|---|
Pre-built images | Yes | Yes | |
Storage Needed | <256MB | 2GB or larger | |
Build-System | Yes | No | 1 |
Toolchain | SDK | Native | 2 |
Web-Admin | Yes | No | 3 |
- The OpenWrt BSP contain an integrated build-system. Ubuntu has step-by-step instructions on how to build an bootable system in 10 or so steps.
- The OpenWrt BSP provides a downloadable SDK for cross-compiling applications on a development hosts. For Ubuntu native development and compilation is supported.
- The OpenWrt BSP is designed to be a wireless router and has an integrated web-admin for configuration and control.
Ubuntu
Gateworks offers a pre-built Ubuntu distribution using the latest Gateworks kernel as well as instructions on how to build your own Ubuntu based distribution.
OpenWrt Board Support Package (BSP)
The Newport OpenWrt BSP provides the following:
- Linux 4.x kernel (fairly vanilla)
- latest wireless drivers (compat-wireless)
- tuned for minimal FLASH/memory footprint (entire distro fits on embedded 16MB FLASH)
- simple upgrades and factory-reset capability provided by overlay filesystem
Newport OpenWrt BSP:
- Pre-Built Image (see firmware-update for instructions on how to install)
- Source:
- https://github.com/Gateworks/bsp-newport - Newport BSP support scripts and Makefile (watch)
- https://github.com/Gateworks/openwrt - Gateworks OpenWrt BSP (watch)
- Additional Gateworks OpenWrt pages:
- OpenWrt
- OpenWrt/Configuration
- OpenWrt/GPS
- OpenWrt/Packages
- OpenWrt/Patch
- OpenWrt/SDK
- OpenWrt/Video_Out
- OpenWrt/building
- OpenWrt/factoryreset
- OpenWrt/gpio
- OpenWrt/hotplug
- OpenWrt/init
- OpenWrt/kernelconfig
- OpenWrt/logging
- OpenWrt/network_config
- OpenWrt/swconfig
- OpenWrt/sysupgrade
- OpenWrt/webadmin
- OpenWrt/webserver
- OpenWrt/wireless
- OpenWrt/wireless/access_point
- OpenWrt/wireless/client
- OpenWrt/wireless/relayd
- OpenWrt/wireless/wireless_bridge
- join the openwrt-devel mailing list to follow upstream OpenWrt activity
Third Party Linux Distros
While Gateworks cannot fully support all Linux distros, it is relatively simple to overlay a Gateworks Newport kernel onto any non-Gateworks third party Linux distro rootfs image.
The following links will describe what is needed:
- Linux kernel supporting Newport: linux/kernel
- Root Filesystem: see below
- Bootable media: linux/blockdev
Root filesystem Sources
There are several sources of pre-built root filesystems that are compatible with Newport. As Newport uses an ARM 64bit based SoC, you need to use something that is compatible with an ARMv8 instruction set. Many pre-built distributions will reference 'arm64' which means 'ARM 64-bit' which is appropriate for the CN80XX / CN81XX SoC.
Some popular third-party sources:
- Ubuntu Core - this is a minimal filesystem that you can build off of at runtime by adding packages from various repositories.
- Linaro - Linaro has several root filesystems including server, nano, developer, core, and ALIP. Each root filesystem will have different things installed for different purposes. Choose carefully which will work for you.
Notes:
- some root filesystems may require you to manually add a user before booting (ie Ubuntu Core)
- the default Newport bootloader expects to find the Image in the /boot directory on the 2nd partition of type ext2/3/4
Mainline Linux Kernel support
Gateworks actively participates in the development of the Linux kernel.
Cavium licenses CPU core IP from ARM and the name they give the CPU core within the OCTEON-TX CN80XX / CN81XX is the Cavium 'ThunderX'. Therefore many of the peripheral drivers within the Linux kernel have 'thunderx' in their name and more often then not the 'OCTEON' name refers to the older OCTEON MIP64 core.
The following table shows what OCTEON-TX CN80XX / CN81XX peripherals support is available in the mainline kernel starting from 4.13:
Feature | Support | Notes |
---|---|---|
SMP | Yes | ARCH_THUNDER |
serial UART (SBSA) | Yes | SERIAL_AMBA_PL011 drivers/tty/serial/amba-pl011.c |
watchdog Watchdog (SBSA) | Yes | ARM_SBSA_WATCHDOG drivers/watchdog/sbsa_gwdt.c |
I2C | Yes (4.9+) | I2C_THUNDERX drivers/i2c/busses/i2c-{octeon-core,thunderx-pcidrv}.c |
Networking BGX (SGMII) | Yes (4.2+) | THUNDER_NIC_BGX drivers/net/ethernet/cavium/thunder/thunder_bgx.c |
Networking RGX (RGMII) | Yes (4.9+) | THUNDER_NIC_RGX drivers/net/ethernet/cavium/thunder/thunder_xcv.c |
Networking MDIO (PHY) | Yes (4.6+) | MDIO_CAVIUM/MDIO_THUNDER drivers/net/phy/mdio-{cavium,thunder}.c |
PCI | Yes (4.6+) | PCI drivers/pci/host/pci-thunder-{ecam,pem}.c |
SPI | Yes (4.9+) | SPI_THUNDERX drivers/spi/spi-thunderx.c |
MMC eMMC / microSD | Yes (4.12+) | MMC_CAVIUM_THUNDERX drivers/mmc/host/thunderx-mmc.c |
HW RNG (Hardware Random Number Generator) | Yes (4.9+) | HW_RANDOM_CAVIUM drivers/char/hw_random/cavium-rng*.c |
HW Compressions offload | Yes (4.12+) | DEV_CAVIUM_ZIP drivers/crypto/cavium/zip.c |
Crypto | Yes (4.11+) | DEV_CAVIUM_CPT drivers/crypto/cavium |
RTC | Yes | RTC_DRV_DS1672 drivers/rtc/rtc-ds1672.c |
LED/GPIO | Yes (4.14+) | GPIO_THUNDERX drivers/gpio/gpio-thunderx.c |
USB 3.0 | Yes | USB_XHCI_PCI |
mSATA | Yes | SATA_AHCI |
The following kernel configs should be enabled for the OCTEON-TX CN80XX / CN81XX:
- SERIAL_AMBA_PL011 - ARM SBSA UART
- MMC_CAVIUM_THUNDERX - MMC
- EDAC_THUNDERX - Error Detection and Correction (works with 'edac-util' app from 'edac-utils' package)
- GPIO_THUNDERX - General Purpose I/O
- SPI_THUNDERX - SPI Controller
- I2C_THUNDERX - I2C Controller
- THUNDERX_NIC_VF - NIC virtual function
- THUNDERX_NIC_PF - NIC physical function
- THUNDERX_NIC_BGX - Network Controller (selects MDIO_CAVIUM/MDIO_THUNDER)
- THUNDERX_NIC_RGX - RGMII Network Controller (selects MDIO_CAVIUM/MDIO_THUNDER)
- MDIO_THUNDER (selected automatically by THUNDERX_NIC*)
- MDIO_CAVIUM (selected automatically by THUNDERX_NIC*)
- PCI_HOST_THUNDER_PEM - PCI host controller
- PCI_HOST_THUNDER_ECAM - Enhanced Configuration Access Mechanism for PCIe memory mapped I/O
- ARM_SBSA_WATCHDOG - ARMv8 Watchdog
- CRYPTO_DEV_CAVIUM_ZIP - Hardware Compression / Decompression off-load
- HW_RANDOM_CAVIUM - Hardware accelerated random number generator
Note that there are many kernel drivers using the name 'Octeon' but they typically refer to a different chipset and the CN80XX / CN81XX have more in common with the Cavium 'ThunderX' architecture as that is the SoC core.
For details on building a Linux kernel see here
Attachments (3)
-
openwrt_logo.jpg
(26.0 KB
) - added by 7 years ago.
openWrt logo
- openwrt_logo.png (13.5 KB ) - added by 6 years ago.
- ubuntu-logo-small.png (6.2 KB ) - added by 6 years ago.
Download all attachments as: .zip