Posts by broddo

Yes unfortunately the NIOS II tools have gotten worse over time and badly need updating. If it helps, I've had a lot more success running Quartus/Nios2 in a Ubuntu 20.04 VM. Any Ubuntu version newer than 18.04 appears to have most (if not all) of the libraries that Quartus needs out of the box so the installation is fairly painless.

Thank you. Yes, my linker file and stack symbols may indeed be the issue but I can't spot the reason myself. I'm happy to share them with you if that helps.

These additional details about my set-up might help:

The application's linker file has a defined .app_header section (32 bytes in size) that is situated at offset 0x0 of the external flash. It adds details that a bootloader needs during compile time. The exceptions table follows this, then the .text section.

The code for this is simple:

__attribute__((section(".app_header")))
const app_header_t app_header = {.s.magic = 0x2f2f2f2f, .s.app = _start};

The only other unusual thing about my linker file is that I've assigned the VIC table to the .exceptions section to ensure that it gets copied to RAM on boot - just to speed up context switching. In the mean time, I'll test placing this in the .text section and see if makes any difference.

Hi there - I'm currently evaluating embOS for use on a custom board. The board's main IC is a Intel MAX10 FPGA with a Nios2 soft core. I can get embOS to run (to an extent....) with certain BSP configurations and not for others. The most noticeable issue is when I deselect 'enable small c library' (in other words, when I'm using the large c library) in the BSP, then OS_Init() never exits. After debugging, I see that OS_Init() calls memset() to initialize the system stack - but a this contains an overflow error: memset() overwrites adjacent memory - the most obvious of which is the 3rd parameter of memset (size) which then causes memset to run indefinitely. Changing the size of the system stack doesn't change this behaviour.

In the attached screenshot, you can see what's going on a bit more clearly: memset is called with a start address of 0x432800 (m) and a size of 4044 bytes (n). However, as you can see from the gdb output, the address of n is 0x4337c8 which means its going to get overwritten as the end of the block that memset is working with is 0x4337cc.

If I enable the small c library, then this does not occur - but I do get other weird issues (some variables on the system stack seem to get overwritten during task switches).

Can someone look into this? I'm happy to provide more information if needed.

My setup:
Nios2/f processor with 79872 bytes on chip RAM using VIC
Nios2 boots/XIP from external flash (QSPI 1Gbit)
Clock: PLL 108Mhz
embOS: 5.8.2. I followed UM01035 guide for setup (hello world)
Dev environment: Nios2 Software Build Tools for Eclipse (Quartus 2 V20.1.0 Standard Edition)
It might be worth noting that this configuration and environment works fine without an OS.