---
title: "GeMRTOS Nios: Fix 256MB Compile Boundary with -relax-all"
description: "When building a GeMRTOS project with the Nios II toolchain, the linker may fail if functions are located in memory addresses more than **256MB apart**. This occurs because the Nios II compiler uses the `call` instruction, which has a 256MB…"
url: "https://rcayssials.hopto.org/gemrtosdocs/compiling-beyond-256mb/"
updated: "2026-06-01"
category: General
tags:
  - Avalon MM
  - GeMRTOS
  - Nios 2
  - Nios V
  - "RISC-V"
---

# GeMRTOS Nios: Fix 256MB Compile Boundary with -relax-all

When building a GeMRTOS project with the Nios II toolchain, the linker may fail if functions are located in memory addresses more than **256MB apart**. This occurs because the Nios II compiler uses the `call` instruction, which has a 256MB address boundary limitation. The fix is to use the `-relax-all` option, which switches to the `callr` instruction that has no such boundary constraint.

## Issue Description

This error occurs when functions are located in a memory region more than 256MB apart from the main memory. The Nios II compiler's `call` instruction cannot reach across this boundary, causing a link failure. Note that using `callr` instead may slightly impact software performance, as it requires more assembly instructions than `call`.

## How to Fix It

In ACDS version 13.1 and later, the `-relax-all` option is available to force the use of the `callr` instruction. In Software Build Tools for Eclipse, add the **`-Wa,-relax-all`** option in the Application and/or BSP properties as user flags.

For GeMRTOS, the BSP is configured with `-Wa,-relax-all` as follows:

```
nios2-bsp hal $1 qsysgrtos.sopcinfo --cpu-name GeMRTOS_Multiprocessor_0_gemrtos_proc_1 --cmd "set_setting hal.enable_reduced_device_drivers true" --cmd "set_setting hal.stderr GeMRTOS_Multiprocessor_0_jtag_uart_1" --cmd "set_setting hal.stdin GeMRTOS_Multiprocessor_0_jtag_uart_0" --cmd "set_setting hal.stdout GeMRTOS_Multiprocessor_0_jtag_uart_0" --cmd "add_section_mapping rstaux GeMRTOS_Multiprocessor_0_rstaux_memory" --cmd "delete_memory_region GeMRTOS_Multiprocessor_0_onchip_memory2_2" --cmd "add_memory_region onchipdata GeMRTOS_Multiprocessor_0_onchip_memory2_2 0 512" --cmd "add_memory_region onchipcode GeMRTOS_Multiprocessor_0_onchip_memory2_2 512 15872" --cmd "add_section_mapping onchipdata onchipdata" --cmd "add_section_mapping onchipmem onchipcode" --cmd "set_setting hal.make.bsp_cflags_user_flags -Wa,-relax-all"
```

And for the application:

```
nios2-app-generate-makefile.exe --bsp-dir ./${SOFTWARE_DIR_NAME}/${BSP_NAME} --app-dir ./${SOFTWARE_DIR_NAME}/${APP_NAME} --elf-name ${APP_NAME}.elf --set APP_CFLAGS_USER_FLAGS "-Wa,-relax-all" --inc-rdir ./${SOFTWARE_DIR_NAME}/${APP_NAME} --src-rdir ./${SOFTWARE_DIR_NAME}/${APP_NAME}
```

## Key Takeaways

- The **256MB compile boundary** is a Nios II `call` instruction hardware limitation — it is not a software or toolchain bug.
- The fix is adding **`-Wa,-relax-all`** to BSP and application user flags, which switches the compiler to the `callr` instruction with no address boundary limit.
- GeMRTOS's `gemrtos_build.sh` script already includes `-Wa,-relax-all` in both the BSP and application build commands shown above.
- There is a minor performance trade-off: `callr` uses more assembly instructions than `call`, which may slightly increase code size and execution time.

**Reference:** Intel Support, [Article 000079417](https://www.intel.com/content/www/us/en/support/programmable/articles/000079417.html).