Nios® V/II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® V/II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
12627 Discussions

NIOS SDK tools don't see memory region

bob_bitchen
New Contributor I
3,147 Views

We use an Arrow LPDDR controller from the BeMicro designs back with Quartus 12.

 

I have a CIV E design in Quartus 21 lite with a NIOS II F.

In platform designer, the NIOS vector selection drop-down boxes have the selection for mddr_ctrl_0.avalon_slave, and appears to generate the system successfully along with the sopcinfo file appears to have all the necessary items. 

 

The tcl file is from a previous version, but it does have "is_memory_device" set to true.

 

The bsp generation scripts show the following:

 

Executing: wsl nios2-bsp hal . ../../Aggs.sopcinfo --cpu-name nios2_gen2_0 (D:\Altera\Kits\PCIe-AGGS\software\bsp)
nios2-bsp: Using /mnt/d/intelfpga_lite/21.1/nios2eds/sdk2/bin/bsp-set-defaults.tcl to set system-dependent settings.
nios2-bsp: Creating new BSP because ./settings.bsp doesn't exist.
nios2-bsp: Running "nios2-bsp-create-settings.exe --sopc d:/Altera/Kits/PCIe-AGGS/Aggs.sopcinfo --type hal --settings ./settings.bsp --bsp-dir . --script d:/intelfpga_lite/21.1/nios2eds/sdk2/bin/bsp-set-defaults.tcl --cpu-name nios2_gen2_0"
INFO: Creating BSP settings file...
INFO: nios2-bsp-create-settings --sopc d:/Altera/Kits/PCIe-AGGS/Aggs.sopcinfo --type hal --settings ./settings.bsp --bsp-dir . --script d:/intelfpga_lite/21.1/nios2eds/sdk2/bin/bsp-set-defaults.tcl --cpu-name nios2_gen2_0
INFO: Initializing SOPC project local software IP
INFO: [Info] <b>D:/Altera/Kits/PCIe-AGGS/*</b> matched 112 files in 0.10 seconds
INFO: [Info] <b>D:/Altera/Kits/PCIe-AGGS/*/*_sw.tcl</b> matched 0 files in 0.00 seconds
INFO: [Info] <b>D:/Altera/Kits/PCIe-AGGS/ip/**/*_sw.tcl</b> matched 0 files in 0.00 seconds
INFO: [Info] <b>D:/Altera/Kits/ip/**/*_sw.tcl</b> matched 0 files in 0.00 seconds
INFO: Finished initializing SOPC project local software IP. Total time taken = 2 seconds
INFO: Searching for BSP components with category: driver_element
INFO: Searching for BSP components with category: software_package_element
INFO: Found Flash Memory: epcs_flash_controller_0 for CPU: nios2_gen2_0
INFO: Loading drivers from ensemble report.
INFO: Finished loading drivers from ensemble report.
INFO: Tcl message: "STDIO character device is jtag_uart"
INFO: Tcl message: "System timer device is sys_clk_timer"
SEVERE: CPU "nios2_gen2_0" reset memory "mddr_ctrl_0" has no matching memory region.
WARNING: Tcl script "bsp-set-defaults.tcl " error: CPU "nios2_gen2_0" reset memory "mddr_ctrl_0" has no matching memory region.
SEVERE: [Error] altera_hal_linkerx_generator: Required linker section mappings do not exist: "[.entry, .exceptions, .rodata, .rwdata, .text, .bss, .heap, .stack]"
SEVERE: [Error] altera_hal_linkerx_generator: Required linker section mappings do not exist: "[.entry, .exceptions, .rodata, .rwdata, .text, .bss, .heap, .stack]"
SEVERE: nios2-bsp-create-settings failed.
nios2-bsp: nios2-bsp-create-settings.exe failed

 

 

I tried digging into the tcl files that print those messages, but I think the .exe is writing those errors.

 

Help!!

 

 


 

0 Kudos
34 Replies
bob_bitchen
New Contributor I
864 Views

I used Quartus 18.1 with the Cygwin Nios EDK tools, and it has the same bug. 

The tools were broken by Intel prior to WSL.

 

0 Kudos
Kenny_Tan
Moderator
843 Views

Hi,


Sorry to inform that it take longer time to do the investigation on this bug. Will get back to you more finding as soon as we can.


Thanks


0 Kudos
EBERLAZARE_I_Intel
819 Views

Hi,


Upon inspecting the design in Platform Designer, the error is related the reset in the Nios II, commonly resets are UFM, QSPI, EPCQ, OCRAM, CFI:

https://www.intel.com/content/www/us/en/docs/programmable/683689/current/processor-booting-methods.html


The mobile_ddr seems to be just a controller. For your device Cyclone IV you can either source the reset to EPCQ or OCRAM based on above link examples, you should adjust accordingly.


0 Kudos
bob_bitchen
New Contributor I
809 Views
We use this ram as the boot vector for debugging purposes. The vector is set to the epcs for actual usage. Either way, this IS a functioning design in earlier versions of quartus. The new bug you introduced is trying to get any of the elf file into the DDR. The BSP editor refuses to use this ram from q18 and up. Whatever processes the sopcinfo file was broken as soon Intel changed it. Please read the whole problem here. Thank you
0 Kudos
EBERLAZARE_I_Intel
791 Views

Hi,


In that case, for workaround, we could add another EPCQ flash controller in the design as a workaround for the mddr?


With this are you okay, if we proceed to test this?



0 Kudos
bob_bitchen
New Contributor I
783 Views
Anything that you can do to get the mddr memory region to show up in the drop-down box in the linker script is a solution
0 Kudos
bob_bitchen
New Contributor I
772 Views

The SDK could care less about the function of each memory device. Confirmed.

All debugging can be done in a single memory device of R/W configuration.

 

0 Kudos
EBERLAZARE_I_Intel
768 Views

Hi,


I confirm with our internal team, that the Reset vector doesn't support external RAM, it must be a non-volatile memory. So you need to set it to the EPCQ, you need to follow the steps for EPCQ below to replace the old EPCQ IP with the Intel FPGA Serial Flash Controller II for your new designs:

https://www.intel.com/content/www/us/en/docs/programmable/683689/current/processor-booting-from-epcq-flash.html


Also, in the newer Quartus, you do no require the Pipeline bridge, you can direct connect as shown above example.


Your application can be stored in the RAM.


Supported memories as reset vectors:

https://www.intel.com/content/www/us/en/docs/programmable/683689/current/summary-of-processor-vector-configurations.html


0 Kudos
bob_bitchen
New Contributor I
762 Views

OK, but this doesn't make the ram available to the SDK. That is the problem I'm trying to solve here.

We used to be able to target the ddr device prior to Quartus 18, but 18 and above there is a bug introduced by Intel that doesn't allow the mddr to be a memory region for the linker.

 

 

0 Kudos
EBERLAZARE_I_Intel
756 Views

Hi,


What is the DDR that is use for your Cyclone IV board in your design?


And what was the IP that was used to make the "mddr" controller in the Quartus 12?


0 Kudos
bob_bitchen
New Contributor I
751 Views

From the first line:

"We use an Arrow LPDDR controller from the BeMicro designs back with Quartus 12."

You have the verilog file in all of the attachments.

Here is the top of that file:

/****************************************************************************/
/* */
/* Project: BeMicro SDK */
/* Module: mddr_ctrl (mobile DDR SDRAM controller) */
/* Author: Harald Fluegel */
/* Arrow Central Europe GmbH */
/* */
/****************************************************************************/
/* */
/* This module is a controller for the mobile DDR memory device mounted */
/* on the Arrow BeMirco SDK evaluation board. The device is a Micron */
/* MT46H32M16LFBF-5 low power DDR SDRAM with the properties listed below. */
/* o Configuration 8M x 16 x 4 banks */
/* o Refresh count 8K */
/* o Row addressing A[12:0] */
/* o Column addressing A[9:0] */
/* */
/* Note that this is a low-performance controller that runs the DRAM on */
/* a divided clock. */
/* */
/****************************************************************************/
/* */
/* History */
/* 2011-08-29: initial release */
/* */
/****************************************************************************/

 

 

0 Kudos
EBERLAZARE_I_Intel
742 Views

Dear customer,​


Thank you for reporting the issue, we have prioritized on investigating the bugs and getting the fix as quick as we could. However, we are unable to provide guidance when this bug will be addressed now. ​


With this, I now transition this thread to community support. After 15 days, this thread will be transitioned to community support. The community users will be able to help you on your follow-up questions. If you still need further assistance, you are welcome open a new case, please login to ‘https://supporttickets.intel.com’, someone will be right with you.


0 Kudos
EBERLAZARE_I_Intel
742 Views

Hi,


The alternate workaround is to use the EPCQ as reset vector and OCRAM as exception vector for newer Quartus, this worked. And set the BSP as following:


Again, thank you for reporting the issue, we have prioritized on investigating the bugs and getting the fix as quick as we could. However, we are unable to provide guidance when this bug will be addressed now. ​


With this, I now transition this thread to community support. After 15 days, this thread will be transitioned to community support. The community users will be able to help you on your follow-up questions. If you still need further assistance, you are welcome open a new case, please login to ‘https://supporttickets.intel.com’, someone will be right with you.


0 Kudos
bob_bitchen
New Contributor I
734 Views

On 9-14-22

community.intel.com/t5/Nios-II-Embedded-Design-Suite/NIOS-SDK-tools-don-t-see-memory-region/m-p/1414818#M51475

 

We moved the vectors to EPCQ and OCRAM a couple of months ago and successfully produced the elf. However, the MDDR still was not able to be used as a target for the linker.

 

I sent a screenshot of the functional MDDR being tested by entering its address on the command line of the memtest example.

 

Nothing has changed on the bug since then except for people asking the same questions.

 

I know that this level of support for your customers is acceptable to you, but our customers will not tolerate it.

 

 

 

 

 

0 Kudos
Reply