The client developed a custom PCB based on the Texas Instruments AM62Ax SoC for an aerospace-related application.

When they contacted us, the prototype board had already been manufactured, but their internal team was fully occupied and unable to bring up Embedded Linux on the hardware.

This created a critical blocker: without a working software environment, they could not start design verification or validate whether the hardware behaved as expected.

Linux was not intended as the final product software. At this stage, it was selected as the fastest practical way to bring up the board and create a usable environment for hardware verification and peripheral testing.

The main issue was related to the board’s memory architecture. The client’s custom PCB used NOR flash memory, while the Texas Instruments reference design was based on NAND flash. As a result, the standard boot flow and available reference materials could not be used directly.

The client had already tried to resolve the issue internally, including with support from Texas Instruments, but the bring-up remained blocked. As project deadlines became increasingly tight, they engaged us to support the software bring-up and help move the prototype into the verification phase.

The client remained responsible for hardware validation, while we took over the software bring-up required to make the board usable for testing.

The Challenge

The board had to boot U-Boot and Embedded Linux from NOR flash in a configuration that was not available as a ready-to-use reference setup. Supporting this required changes across several low-level parts of the software stack, including the bootloader, Linux configuration, flash layout, filesystem handling, and board-specific device descriptions.

There were also practical constraints at the beginning of the project.

Initially, we did not have access to the client’s custom PCB. Instead, the client provided a Texas Instruments development kit based on the same AM62Ax SoC, modified by replacing the original NAND flash with NOR flash.

This allowed us to start development, but it introduced two major risks:

• The configuration had not been proven before

There was no confirmed working example of this SoC booting from the same type of NOR flash in the required configuration. This created the possibility that a hardware limitation could prevent the approach from working at all.

• The modified development kit introduced uncertainty

Since the NOR flash had been manually added to the development kit, it was not clear whether potential issues were caused by software configuration, hardware limitations, or the physical modification of the board itself.

This made troubleshooting more complex. Every issue had to be analyzed carefully to determine whether it came from the boot flow, memory configuration, kernel support, filesystem setup, hardware wiring, or the modified development setup.

The deadline pressure added another layer of difficulty. With validation milestones approaching, the software bring-up became a critical dependency for progressing from manufactured prototype to active hardware verification.

Our Contribution

Our initial scope was focused on enabling the board to boot from NOR flash and preparing a basic Linux-based test environment.

Over time, as progress was made and additional blockers appeared, the scope expanded. The client needed support not only with the Linux boot process, but also with first-stage bootloader issues, debugging, peripheral enablement, test image generation, and development environment handover.

Our work covered several key areas.

1. Enabling U-boot and embedded Linux boot from NOR flash

This required adapting a software stack that was originally aligned with a NAND-based reference design. We modified and configured the bootloader and Linux environment so the system could recognize, access, and use the NOR flash correctly.

This included:

• adapting U-Boot configuration for the custom memory setup
• modifying device tree definitions to replace NAND-related configuration with NOR flash support
• adjusting Linux kernel configuration options
• patching the kernel to support the specific NOR flash device used on the board
• enabling the required flash access flow during boot
• configuring the system so the board could load the kernel, device tree, and root filesystem from NOR flash

The challenge was adapting the complete low-level boot chain to a memory architecture that differed from the reference design and had not been validated for this exact use case.

2. Preparing a NOR-based filesystem

Once basic flash access was enabled, the next step was preparing a filesystem suitable for the NOR flash setup.

We enabled and configured a UBIFS-based filesystem so the board could run a usable Linux environment from flash. This was important because the client needed more than a minimal boot. They needed a practical test system that could support hardware verification and peripheral testing.

This required:

• preparing the flash layout
• generating UBIFS images
• configuring the root filesystem
• ensuring the image was suitable for flashing to the target hardware
• validating that the system could boot into a usable Linux environment

By doing this, the prototype board became usable as a hardware verification platform, not just as a partially booting development target.

3. Troubleshooting and stabilizing the boot flow

A major part of the work involved debugging issues across the early boot stages.

The client had previously engaged an external consultant to enable the first-stage bootloader, but the implementation was incomplete and unstable. As a result, additional bring-up problems appeared later in the project, blocking further progress.

We took over debugging of these issues and helped stabilize the first-stage boot process.

This included:

• enabling JTAG debugging for the SoC
• debugging first-stage bootloader behavior
• identifying problems in the early boot sequence
• adjusting the boot configuration
• preparing supporting scripts to automate bootloader-related tasks
• validating that the system could reliably move from early boot into U-Boot and Linux

This was important because problems in the first-stage bootloader can be difficult to isolate. Failures happen before the full software stack is available, which means standard Linux debugging tools cannot be used. Reliable JTAG access and a clear understanding of the SoC boot sequence were essential for making progress.

4. Demonstrating Inter-Core communication on the AM62Ax SoC

As part of the original scope, we also developed a proof-of-concept for inter-processor communication between different processing cores on the AM62Ax SoC.

The goal was to demonstrate IPC communication between:

• A53 cores
• R5F cores
• C7x core

This was intended as a technical proof of concept. It allowed the client to confirm that the SoC’s heterogeneous processing architecture could support the required communication paths between the application processor, real-time cores and accelerator core.

For a complex aerospace platform, this kind of early validation helps reduce architecture risk before significant software development is built on top of the multicore processing model.

5. Enabling additional interfaces and test utilities

As the project progressed, the client needed additional peripherals and tools to support board-level testing.

We helped enable and prepare software support for interfaces and utilities required during validation, including:

• CAN support
• communication with FPGA-related logic
• Linux tools for peripheral testing and debugging
• utilities such as canutils, iproute2, and devmem2

These tools gave the client a practical Linux-based environment for testing hardware functionality, inspecting low-level behavior and validating peripheral access.

This was especially important because the client’s main objective at this stage was design verification. They needed a stable software platform that allowed them to exercise the board and confirm whether the hardware design worked as intended.

6. Creating automated test image generation and flashing scripts

To reduce manual effort and make the workflow repeatable, we created scripts for generating and deploying test images.

The scripts automated several steps that would otherwise have been time-consuming and error-prone, including:

• building U-Boot
• building the Linux kernel
• preparing a minimal root filesystem with the required test utilities
• generating UBIFS images
• preparing images for NOR flash
• flashing the board through UART or network-based workflows
• configuring device tree overlay loading through U-Boot

This gave the client a repeatable way to generate new test images, deploy them to the board, and continue validation without depending on manual image preparation each time.

This reduced the risk of inconsistent builds, incorrect flashing steps, and environment-related mistakes during testing.

7. Preparing a complete development environment for handover

Since the client needed to continue development after our involvement, we also prepared a virtual machine with the complete development environment already configured.

The goal was to make the handover practical and reduce setup friction for their internal team.

The virtual machine included the required build environment, tools, scripts, and configuration needed to continue working with the board. We also documented how to use the environment and the supporting tools.

This ensured that the client could reproduce the workflow, generate images, flash the target, and continue development independently.

Results

We helped the client to unblock the hardware verification process.

The custom AM62Ax-based board could boot U-Boot and Embedded Linux from NOR flash, allowing the client to start validating the prototype hardware and testing required peripherals.

The project outcomes:

• U-Boot and Linux boot enabled from NOR flash
• kernel and device tree adapted for the custom flash configuration
• UBIFS filesystem prepared for the target setup
• first-stage bootloader issues debugged and stabilized
• JTAG debugging enabled for low-level boot analysis
• IPC proof of concept demonstrated between A53, R5F, and C7x cores
• CAN and additional peripheral testing support enabled
• Linux test utilities added for hardware validation
• automated scripts created for image generation and flashing
• complete virtual machine prepared for development handover
• documentation delivered for continued use by the client’s team

Most importantly, the client moved from a blocked prototype to a usable software platform for design verification. They received a working, repeatable environment that allowed them to validate the hardware, test peripherals, and continue development with documented and reproducible setup.