First Boot and Validation
Once the board boots up successfully, the immediate next step is making sure the system is stable and reliable before you start pushing code or doing heavy development.
Don't worry about multimedia or application testing just yet. At this stage, the sole focus is the basics: verifying a clean boot, making sure networking comes up, checking that essential services start properly, and ensuring reliable access to the board before moving on to advanced validation.
Initial Validation
To consider this first boot a success, we need to sanity-check four key areas:
| Area | Expected Result |
|---|---|
| Boot process | Kernel and root filesystem start correctly without critical failures |
| Console access | The board can be accessed through serial console, SSH, or local display |
| Runtime services | Core services initialize successfully after boot |
| Network connectivity | The platform receives network connectivity and supports remote access |
Nailing down these checks gives you a solid, known-good baseline before you start messing with multimedia pipelines, hardware acceleration, or BSP-level customization.
Accessing the Board
Depending on where you are in the bring-up process, different access methods will make the most sense.
| Method | Description | Typical Usage |
|---|---|---|
| Serial console | Direct UART access with full boot logs | Early boot debugging and kernel validation |
| SSH | Remote shell access over the network | Main development and runtime interaction method |
| Ethernet | Network connectivity and remote communication | Required for SSH, package installation, and remote testing |
| HDMI / Display | Direct graphical access to the system | GUI and multimedia validation |
Serial Console
During early bring-up, the serial console is your best friend and the most reliable way to talk to the board. It hooks you directly into everything happening under the hood, giving you access to:
- Bootloader messages
- Kernel startup logs
- Early boot failures
- A login prompt before networking even initializes
You can use any standard terminal tool like minicom, screen, or picocom to connect.
For example:
sudo screen /dev/ttyUSB0 115200
If everything went well, you'll see the bootloader output, the kernel scrolling by, and eventually a login prompt. If the system panics or crashes before networking comes up, this is exactly where you'll catch it.
SSH Access
As soon as the board grabs a valid IP address, switching over to SSH makes life a lot easier for day-to-day work.
ssh root@<board-ip>
From here on out, you'll likely do most of your validation and development remotely through this shell—whether that's digging through logs, validating packages, spinning up multimedia pipelines, or debugging runtime issues.
Network Validation
Before moving any further, take a second to confirm that the network link is actually solid.
First, check your interfaces and make sure an IP was correctly assigned:
ip a
Then, run a quick ping to verify external connectivity:
ping -c 4 <known-host>
You need a dependable network connection for remote access, package management, and streaming tests. If SSH stops responding later on, this is the first place you should look before troubleshooting higher-level stack issues.
Basic System Checks
Once logged in, it’s time to verify that the deployed image is actually running as expected.
To check the active kernel version and OS release info:
uname -a cat /etc/os-release hostname
Take a look at how the filesystems were mounted:
mount
Make sure no critical services choked during the boot process:
systemctl --failed
And finally, scroll through the tail end of the kernel logs to rule out any glaring errors:
dmesg | tail -n 50
These quick checks let you know the image booted cleanly and that the environment is stable enough to start pushing the system.
Common First Boot Issues
It's completely normal to hit a few snags during initial deployment and bring-up. The usual suspects typically include:
- The Ethernet link isn't detected at all
- Missing or misconfigured IP setup
- Your host machine isn't detecting the USB-serial adapter
- Targeting the wrong UART device path
- Random services failing right at startup
If you get stuck, these commands are a good starting point to diagnose what's going on:
dmesg | grep tty ip route ethtool eth0
More often than not, keeping an eye on the serial console while checking dmesg outputs is enough to pinpoint the issue.
Recommended Validation Sequence
To avoid chasing your tail, follow this logical order of operations during a first boot:
- Connect via the serial console
- Watch the kernel boot to verify it finishes successfully
- Validate that Ethernet and network initialization worked
- Drop the serial line and connect over SSH
- Inspect your services and check the system logs
- Confirm the overall runtime environment feels stable
Once you've checked these boxes, the platform is officially ready for the fun stuff: multimedia validation, accelerated pipelines, and custom BSP work.