Nios® II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
Announcements
Intel Support hours are Monday-Fridays, 8am-5pm PST, except Holidays. Thanks to our community members who provide support during our down time or before we get to your questions. We appreciate you!

Need Forum Guidance? Click here
Search our FPGA Knowledge Articles here.
12409 Discussions

enable_alt_load_copy_rodata disabled in BSP Editor when using uC/OS-II

Broddo
New Contributor I
648 Views

Hi,

I'm using Quartus II standard 20.1. I have a simple system designed using Platform designer that incorporates standard stuff (Nios II, PLL, RAM, on-chip flash etc). I intend to execute code from the on-chip flash (UFM single uncompressed). 

When I try to configure hal.linker via the BSP editor I can enable all the required settings (enable_alt_load, enable_alt_load_copy_ro_data, enable_alt_load_copy_rwdata, etc) if I set the operating system to Altera HAL. 

If instead, I set the operating system to Micrium uc/OS-II then these options are disabled for some reason. 

Screenshots attached. 

Is this intended? Or am I doing something wrong? 

0 Kudos
6 Replies
Eliath_G_Intel
Employee
623 Views

Hi Barry!

Thanks for reaching us.

 

Is the operative System you're using Windows or Ubuntu to implement your design on Quartus and eclipse?

I did the test with Quartus 20.1 installed on Windows machine and the options aren't disabled after selecting Micrium MicroC/OS-II.

could you tell me which OS you are working with?

 

 

Regards,

 

 

Broddo
New Contributor I
609 Views

Thanks for the reply. I'm running Ubuntu 18.04 in a VM on MacOS. Everything else is working perfectly (including the USB blaster - I have completed a few projects using this set-up). I've tried configuring the BSP a few times with fresh projects and always get the same result. 

It is interesting that the moment I remove OS2 from the BSP, those alt_load functions become available again. 

It is also interesting Is there anything else I can try? A different configuration for example? 

Just FYI, I do appear to be able to edit the settings.bsp file in a text editor and change the 'enabled' tags to true by hand. (see below) However, I can't tell as of yet whether this change has resulted in the correct bsp being generated. 

 

 

<Setting>
                <SettingName>hal.linker.enable_alt_load_copy_rodata</SettingName>
                <Identifier>none</Identifier>
                <Type>Boolean</Type>
                <Value>0</Value>
                <DefaultValue>0</DefaultValue>
                <DestinationFile>none</DestinationFile>
                <Description>Causes the alt_load() facility to copy the .rodata section. If true, this setting defines the macro ALT_LOAD_COPY_RODATA in linker.h.</Description>
                <Restrictions>none</Restrictions>
                <Enabled>true</Enabled>
                <Group xsi:nil="true" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
        </Setting>

 

 

Eliath_G_Intel
Employee
562 Views

Hi Barry,


I've been trying to reproduce your issue but I haven't had any success.

in the tests I made, the alt_load functions never got disable.


Would you mind to share your *.sopcinfo file with me to see exactly the way you have configured it and then reproduce the issue?


Thanks in advance,

-Eliath Guzman


Broddo
New Contributor I
533 Views

Apologies for the delay - here is my sopcinfo file if it is any use to you. I changed the file's extension to .xml as the forum forbids uploading of files with extension .sopcinfo. 

DeanK77
Beginner
323 Views

Hey guys, did anyone solve this. I have the same issue. Thank you.

Broddo
New Contributor I
306 Views

Unfortunately, I never solved it - I ended up ditching uC/OS-II instead. The future of OS-II/OS-III looks very messy at the moment and it seems like Intel aren't keen to keep the relationship going (I wouldn't blame Intel for this).

I'm using Segger's embOS instead which has a fully functioning port available for NIOS II and works with the latest version of Quartus. It's a 'drop-in' replacement for OS-II (i.e. they've a nice compatibility layer that allows Altera HAL software that can make use of OS features will automatically use embOS). embOS also supports the vectored interrupt controller out of the box which was a huge benefit to me. 

 

The Zephyr Project also appears to support the NIOS2 (specifically a MAX10) but I never got around to evaluating it. 

Reply