Connecting to Boards

Overview

You’ve finished the Software Development Guide and built an ELF on your dev PC. You have NAI hardware powered up on a bench. This page covers everything between those two points — the cabling, network, terminal access, and file transfer needed to get your application onto the board and ready to launch.

This page does not cover:

How to write or build the application — see the Software Development Guide.
Code-free testing of modules through a GUI — see ESP2 Quick Start.
How to actually launch the transferred app, view output, and configure run modes — see Running Applications from Target.

Note

If you’re not sure which sub-section below applies to your setup, read The Workflow first. It is OS-agnostic and explains the steps every dev environment shares.

The Workflow

Every NAI hardware bring-up follows the same six conceptual phases, regardless of which operating system runs on the board. Recognizing which phase you’re in helps you find the right sub-section below — and the right page to jump to if you get stuck.

Power & physical link. The board is powered and connected to your host. For most NAI products this means an ethernet cable for data and a serial cable (or USB-to-serial adapter) for the console. Some configurations replace ethernet with direct PCIe (e.g., the 79G5) or VME.
Network reachability. The board has a known IP address that your host can reach. NAI boards store their IP in motherboard EEPROM and the utility naiMBEEPROMUtil is how you read or change it. See naiMBEEPROMUtil quick reference for the commands.
Terminal access. You open a serial terminal session to the board’s console — TeraTerm on Windows, minicom on Linux, or PuTTY. NAI’s standard settings (115200 / 8 / None / 1 / None) are in Serial terminal settings. The console is how you’ll log in, navigate the filesystem, and watch your app’s output later.
File transfer. Your built ELF lives on your dev PC. You move it onto the board’s filesystem. For PetaLinux this is typically WinSCP over SCP/SFTP, or Vitis’s Remote System Explorer if you’re already in the IDE. For VxWorks it’s FTP/TFTP; DEOS uses a different model entirely (image-based deploy).
Execution. The transferred file is marked executable and launched. On PetaLinux this is chmod 777 then ./your_app.elf. The launch step itself lives in Running Applications from Target — this page hands off at the moment your file is on the board and your terminal is open.
Observation. The app prints its output back to your serial terminal. You confirm it ran, interact with any menus it presents, and either continue developing or move on to ESP2 / sample apps for the next phase of your work.

Tools at a glance

Tool	What it is	Where it runs	Phase(s)
NAI SSK (1.x / 2.x)	NAI’s Software Support Kit — the library APIs (`naibrd_*`) your application links against to talk to NAI hardware.	Linked into your app on the dev PC; runtime calls happen on the board.	Built in SDG, used at phase 5-6
Xilinx Vitis / SDK	The IDE you build your ELF in for ARM Linux / PetaLinux targets.	Dev PC.	4-5 (build artifact)
Wind River Workbench	The IDE for VxWorks 7 targets.	Dev PC.	4-5 (build artifact)
Visual Studio (with CMake)	The IDE for Windows-host applications targeting NAI boards over ethernet.	Dev PC (Windows).	4-5 (build artifact)
DDC-I OpenArbor	The IDE for DEOS targets.	Dev PC.	4-5 (build artifact)
PetaLinux	The embedded Linux that runs on NAI ARM boards.	Board.	1-6 (it’s the OS)
TeraTerm (or minicom / PuTTY)	The serial terminal application that gives you a console to the board.	Dev PC.	3, 5-6
WinSCP (or `scp` / Vitis RSE)	File-transfer client that copies your ELF from dev PC to board over SCP/SFTP.	Dev PC.	4
`naiMBEEPROMUtil`	Board-side utility that reads and writes the motherboard EEPROM, including IP/network settings.	Board.	2

Set up your dev environment

PetaLinux / ARM Linux

This is the full inline procedure for NAI ARM Linux boards running PetaLinux. If you’re on a different OS, see VxWorks, DEOS, or Windows host / CMake below. The steps below assume you’ve already finished the Software Development Guide and have a built .elf on your dev PC.

1. Cable up power, ethernet, and serial

Place the motherboard into its chassis (or, for a bare-board development setup, mount it on a bench fixture) and connect:

Power — using NAI’s MIL-DTL-38999 power cable, or via a benchtop power supply on the banana-jack ends.
Ethernet — RJ-45 to your host network. Most NAI ARM boards have two ethernet ports (eth0 / eth1); start with eth0.
Serial — DB-9 or USB-to-serial cable to your host PC’s serial port.

For exact connector pinouts and cable part numbers, see Connectors and Cabling Info. For a development setup with breakout access to module I/O, NAI’s 44-pin breakout boards are documented on the same page.

2. Open a serial terminal

Launch your terminal program (TeraTerm on Windows, minicom on Linux, or PuTTY). Configure it with NAI’s standard serial settings — see Serial terminal settings below. Once the board has power, you should see boot messages stream across the terminal within a few seconds. If you don’t, return to step 1 and check the serial cable.

3. Confirm or set the board’s IP

NAI ARM boards store their IP, subnet mask, gateway, and MAC addresses in motherboard EEPROM. The naiMBEEPROMUtil utility — preinstalled on the board’s PetaLinux image — reads and writes those values.

Check what’s currently configured. From the serial console after the board boots, log in as root (password root) and run:

root@68arm2-bsp:~# naiMBEEPROMUtil version

You should see version output similar to:

===================== MBCore ===================================================
  ExecutionContext:                 Platform ARM-P0 ULTRASCALE+ Master Linux
  Application Built For Target:     68ARM2
  Application Name:                 naiMBEEPROMUtil
  Application Revision:             1.0
  Application Build DateTime:       May 22 2025  10:26:58
  ...
---------------------------------------------------------------------------------

To display the full EEPROM contents including the configured IP:

root@68arm2-bsp:~# naiMBEEPROMUtil formatteddisplay

Look for the Eth-A IPv4Address and related rows in the output:

  0038:  Eth-A IPv4Address     :192.168.1.16:
  003c:  Eth-A IPv4SubnetMask  :255.255.255.0:
  0040:  Eth-A IPv4Gateway     :192.168.1.1:

Change the IP if needed. Use the set form for whichever field you need to update:

root@68arm2-bsp:~# naiMBEEPROMUtil set EthA_IPv4Address 192.168.1.16
root@68arm2-bsp:~# naiMBEEPROMUtil set EthA_IPv4SubnetMask 255.255.255.0
root@68arm2-bsp:~# naiMBEEPROMUtil set EthB_IPv4Address 192.168.2.16
root@68arm2-bsp:~# naiMBEEPROMUtil set EthB_IPv4SubnetMask 255.255.255.0

The new values take effect on the next system reset (shutdown -r now).

Warning

Do not use naiMBEEPROMUtil to erase the EEPROM or modify any fields other than IP/subnet/gateway. The MAC addresses and platform metadata stored in EEPROM are required for the board to function — overwriting them can brick the board.

Confirm reachability from your host. After the board reboots, from your dev PC:

> ping 192.168.1.16

Once ping succeeds, you have everything you need for phase 4 (file transfer).

4. Build the ELF on your dev PC

You did this in the Software Development Guide. The output is a .elf file in your project’s Debug/ (or Release/) folder — for example naiapp_mod_ad_basic_ops.elf.

If you haven’t built yet, go back to the SDG before continuing. For an end-to-end PetaLinux build walkthrough, see NAI ARM Linux Quick-Start Guide (PetaLinux 2023). For PetaLinux 2018 see the 2018 guide — the build process is similar with version-specific UI differences noted at the bottom of this section.

5. Transfer the ELF to the board

Two methods. Pick the one that fits your workflow:

Method A: WinSCP (recommended for most workflows).

WinSCP is a free SCP/SFTP client for Windows. Once your board’s IP is reachable from your dev PC:

Open WinSCP. Create a new session with:
- File protocol: SFTP (or SCP — either works)
- Host name: the board’s IP (e.g., 192.168.1.16)
- Port: 22
- User name: root
- Password: root
Click Login. WinSCP opens a two-pane file browser — your dev PC on the left, the board’s filesystem on the right.
Navigate the right pane to /home/root/ (or /tmp/ if you prefer ephemeral storage that clears on reboot).
Drag your .elf file from the left pane into the right pane. Transfer is a few seconds for a typical sample app.

Method B: Vitis Remote System Explorer (in-IDE alternative).

If you’re already in Vitis and want to avoid context-switching to a separate file-transfer tool:

Show Vitis RSE steps

In Vitis, switch to the Remote System Explorer perspective (top-right corner; or Window → Perspective → Open Perspective → Other → Remote System Explorer).
Right-click in the blank area → New → Connection… → SSH Only. Enter the board’s IP and credentials.
Navigate to Root/home/root on the remote connection.
Right-click → Export from Project → select your project’s Debug/ folder → check the .elf file → Finish.

See NAI ARM Linux Quick-Start Guide (PetaLinux 2023) section “Debugging a Sample App on Vitis” for the full screenshot-driven walkthrough.

You’re done. Your file is on the board and your terminal is open. To launch it, continue to Running Applications from Target.

Note

PetaLinux 2018 vs PetaLinux 2023 — what’s different. The two SDK generations use different versions of Xilinx’s IDE (Xilinx SDK 2018.2 vs Vitis Classic 2023.2) and different SSK packages. The conceptual workflow is identical — the differences are entirely in menu paths, project-import wizards, and environment-variable setup inside the IDE. If you’re on PetaLinux 2018, follow NAI ARM Linux Quick-Start Guide (PetaLinux 2018) for the IDE-specific steps; if you’re on 2023, follow the 2023 guide. Either way, the transfer + terminal + launch portions of the workflow on this page apply unchanged.

VxWorks

NAI’s VxWorks 7 support uses Wind River Workbench as the IDE and ships a board-specific BSP (e.g., naiNIU3A) that you copy into your Workbench installation. Instead of producing a standalone ELF for transfer, the VxWorks workflow builds a complete VxWorks Image Project (the OS image) plus separate downloadable kernel modules for NAI BSP, NAI BRD, and your application. These are loaded onto the target via Wind River’s deployment mechanisms.

How the six phases map to VxWorks:

Power & physical link (phase 1) — same as PetaLinux. See step 1.
Network reachability (phase 2) — VxWorks reads its IP from the boot parameters configured in Workbench / the VxWorks bootloader rather than from NAI EEPROM. naiMBEEPROMUtil does not apply.
Terminal access (phase 3) — same serial settings as PetaLinux (see Serial terminal settings). The VxWorks shell takes the place of the Linux shell.
File transfer (phase 4) — typically FTP or TFTP for module/image downloads, or via Workbench’s target-connection dialog. There is no chmod-style mark-executable step; the file format already encodes executability.
Execution (phase 5) — kernel modules are loaded via the VxWorks shell or Workbench’s “Download” action; the application’s entry point is then called from the shell.
Observation (phase 6) — output streams to the same serial console.

For the full VxWorks workflow — BSP installation, VSB and VIP project creation, kernel-module project setup, sample app deployment — see NAI VxWorks 7 Quick-Start Guide.

DEOS

NAI’s DEOS support uses DDC-I’s OpenArbor IDE and ships a kismet workspace (deos_kismet) containing NAI’s libraries and sample apps configured as DEOS projects. DEOS is a partition-based RTOS, so the deployment model is fundamentally different from PetaLinux: there is no “drop an ELF and run.” Instead, you build a composite image (composite.darc) that bundles the kernel, configuration, and application code — that image is what gets loaded onto the target.

How the six phases map to DEOS:

Power & physical link (phase 1) — same as PetaLinux. See step 1.
Network reachability (phase 2) — set via U-Boot environment variables on the target (setenv ipaddr <value>; setenv serverip <value>; saveenv). OpenArbor’s lwip.config separately stores the platform’s IP for the IDE’s connection. naiMBEEPROMUtil does not apply.
Terminal access (phase 3) — same serial settings as PetaLinux (see Serial terminal settings).
File transfer (phase 4) — composite image is loaded via OpenArbor’s Target Manager and “Update Target Load” — not via SCP.
Execution (phase 5) — applications run as DEOS partition dependencies; adding a sample app means adding it as a dependency on the platform project, rebuilding the image, and reloading with “Force Cold Start” checked.
Observation (phase 6) — output streams to the serial console; some DEOS apps also surface through OpenArbor’s Status Monitor and Video Stream tools.

For the full DEOS workflow, see NAI UltraScale Deos Quick-Start Guide.

Windows host / CMake

This sub-section applies when your application runs on a Windows host PC and reaches the NAI board over ethernet or via direct PCIe (e.g., 79G5, 79C3). The “transfer + chmod + launch” model of phases 4-6 does not apply the same way — your app runs on the host, and what you’re doing is configuring the host to find the board.

How the six phases map:

Power & physical link (phase 1) — same as PetaLinux (or PCIe slot insertion for 79G5/79C3). See step 1.
Network reachability (phase 2) — if you’re using ethernet, the board still needs an IP set via naiMBEEPROMUtil (or via the board’s master-controller path); see step 3. For PCIe-connected boards, this phase doesn’t apply — the host enumerates the card via the PCI bus.
Terminal access (phase 3) — you may still want a serial terminal for board diagnostics during bring-up, but day-to-day operation is from the Windows host directly. NAI’s standard serial settings apply (Serial terminal settings).
File transfer (phase 4) — not applicable. Your application is a Windows executable; it stays on the host.
Execution (phase 5) — run the Windows executable directly from Visual Studio or from the command line. The NAI SSK library is linked into your app and handles board communication via the configured transport (ethernet TCP, PCI, VME).
Observation (phase 6) — your app’s output appears in the Visual Studio console or wherever you launched it from.

For environment setup (CMake invocation, Visual Studio solution generation, sample-app builds, project-from-scratch walkthrough), see Windows CMake Quick-Start Guide.

Reference

Serial terminal settings

These are NAI’s standard serial-console settings. They apply to every NAI ARM Linux, VxWorks, and DEOS board unless the specific hardware manual says otherwise.

Setting	Value
Baud rate	115200
Data bits	8
Parity	None
Stop bits	1
Flow control	None

These settings work in TeraTerm on Windows, minicom on Linux, PuTTY on either, and any other terminal program that exposes the same fields. If you see garbled characters on the console after the board powers up, the most common cause is a baud-rate mismatch — re-check this table first.

naiMBEEPROMUtil quick reference

naiMBEEPROMUtil is a board-side utility (preinstalled on NAI ARM Linux PetaLinux images) for reading and writing motherboard EEPROM — the persistent store for the board’s IP, MAC, and platform metadata. Run it from the board’s serial console as root.

Command	Purpose
`naiMBEEPROMUtil version`	Print utility and BSP version info
`naiMBEEPROMUtil formatteddisplay`	Print all EEPROM fields in a human-readable layout
`naiMBEEPROMUtil set EthA_IPv4Address <ip>`	Set the IP address on ethernet port A
`naiMBEEPROMUtil set EthA_IPv4SubnetMask <mask>`	Set the subnet mask on port A
`naiMBEEPROMUtil set EthA_IPv4Gateway <ip>`	Set the gateway on port A
`naiMBEEPROMUtil set EthB_IPv4Address <ip>`	Set the IP address on ethernet port B
`naiMBEEPROMUtil set EthB_IPv4SubnetMask <mask>`	Set the subnet mask on port B

Changes take effect on the next system reset.

Warning

Do not modify fields other than the IP / subnet / gateway entries. The EEPROM also stores MAC addresses and platform metadata required for the board to boot — corrupting those can brick the board.

For a full walkthrough including example output, see step 3 above or the corresponding section in Software Development Guide (SSK 2.x).

Troubleshooting

Common symptoms and where to look

Symptom	Likely cause	Where to check
Host can’t ping the board after boot	IP is not set in EEPROM, or set to a different subnet from the host	naiMBEEPROMUtil quick reference — read with `naiMBEEPROMUtil formatteddisplay`; set with `naiMBEEPROMUtil set`
WinSCP refuses connection (“connection refused” / timeout)	SSH service not yet up on the board, or wrong port / wrong credentials	Confirm board has booted via serial console; verify `root`/`root`; try port 22
Serial terminal shows garbled characters or nothing	Wrong baud rate or wrong COM port selected	Serial terminal settings — confirm 115200 / 8 / None / 1 / None and that you’re on the right serial port
Vitis or Workbench can’t find the build target / can’t deploy	Network / IP not configured, or BOARD environment variable not set in the IDE	naiMBEEPROMUtil quick reference (for IP); see PetaLinux Quick-Start step 4 (for the `BOARD` env var)
Transferred ELF won’t execute on the board	Architecture mismatch — ELF was built for a different target than the board you transferred it to	Rebuild with the correct `BOARD` value; see Software Development Guide
`chmod` returns “permission denied” or “read-only filesystem”	You’re logged in as a non-root user, or the target directory is on a read-only mount	Log in as `root`; transfer to `/home/root/` or `/tmp/` instead

Where to go next

You’ve covered the connection and transfer steps. Continue along the intended docs path:

ESP2 Quick Start — NAI’s Embedded Soft Panel 2 is a host-side GUI that lets you exercise modules on your board without writing any code. This is the easiest way to confirm your hardware is working end-to-end before you run your own applications.
Running Applications from Target — The launch step (chmod and ./your_app.elf), how to read output, and advanced run modes like running from boot or via startup scripts.
Opening a Software Handle to Your Board — When you start writing your own applications instead of running the NAI sample apps, this is where you’ll learn how to open a handle to the board programmatically (instead of relying on the sample-app menu prompts).
Sample App Guides — Function-by-function walkthroughs of every NAI sample application, with code snippets you can lift into your own project.

NAI Documentation

Explorer

Connecting to Boards

Overview

The Workflow

Tools at a glance

Set up your dev environment

PetaLinux / ARM Linux

1. Cable up power, ethernet, and serial

2. Open a serial terminal

3. Confirm or set the board’s IP

4. Build the ELF on your dev PC

5. Transfer the ELF to the board

VxWorks

DEOS

Windows host / CMake

Reference

Serial terminal settings

naiMBEEPROMUtil quick reference

Troubleshooting

Where to go next

Table of Contents