- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Everything was working fine, compiles ok, runs ok, then I added more code and suddenly:
[ 98%] Linking CXX executable app_free.elf
/quartus/V23.1-STD/riscfree/toolchain/riscv32-unknown-elf/bin/../lib/gcc/riscv32-unknown-elf/12.1.0/../../../../riscv32-unknown-elf/bin/ld: app_free.elf section `.entry' will not fit in region `reset'
/quartus/V23.1-STD/riscfree/toolchain/riscv32-unknown-elf/bin/../lib/gcc/riscv32-unknown-elf/12.1.0/../../../../riscv32-unknown-elf/bin/ld: region `reset' overflowed by 4 bytes
collect2: error: ld returned 1 exit status
make[3]: *** [CMakeFiles/app_free.elf.dir/build.make:115: app_free.elf] Error 1
make[2]: *** [CMakeFiles/Makefile2:104: CMakeFiles/app_free.elf.dir/all] Error 2
make[1]: *** [Makefile:91: all] Error 2
This is not the first time we have seen this error, but it magically comes and goes.
What goes into the .entry section?
Why is it overflowing by 4 bytes?
Why cant I just increase the reset region in bsp-editor?
Thanks for your time,
-Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I think I found an answer. My Nios Reset was pointing to on-chip memory, with base 0xc000000.
.text was in external ddr3 at base 0x0, and __start was at 0x804.
Generating the linker map I see:
.entry 0x000000000c000000 0x24
*(.entry)
.entry 0x000000000c000000 0x24 freertos_bsp/libfreertos_bsp.a(crt0.S.obj)
0x000000000c000000 __reset
Which tells me the only thing in the .entry section is __reset, and this is __reset in crt0.S:
.section .entry, "xa"
.align 5
.globl __reset
.type __reset, @function
__reset:
/*
* Jump to the _start entry point in the .text section if reset code
* is allowed or if optimizing for RTL simulation.
*/
/* Jump to the _start entry point in the .text section. */
tail _start
.size __reset, . - __reset
I'm wondering if the "tail _start" instruction had to be encoded with extra bits because I'm jumping from 0xc000000 to 0x804?
When I switched my Nios reset to also point to external ddr3, then my C++ compiled ok.
Now my .entry is at 0x0, and _start is still 0x804.
Does that seem like a reasonable explanation?
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I think I found an answer. My Nios Reset was pointing to on-chip memory, with base 0xc000000.
.text was in external ddr3 at base 0x0, and __start was at 0x804.
Generating the linker map I see:
.entry 0x000000000c000000 0x24
*(.entry)
.entry 0x000000000c000000 0x24 freertos_bsp/libfreertos_bsp.a(crt0.S.obj)
0x000000000c000000 __reset
Which tells me the only thing in the .entry section is __reset, and this is __reset in crt0.S:
.section .entry, "xa"
.align 5
.globl __reset
.type __reset, @function
__reset:
/*
* Jump to the _start entry point in the .text section if reset code
* is allowed or if optimizing for RTL simulation.
*/
/* Jump to the _start entry point in the .text section. */
tail _start
.size __reset, . - __reset
I'm wondering if the "tail _start" instruction had to be encoded with extra bits because I'm jumping from 0xc000000 to 0x804?
When I switched my Nios reset to also point to external ddr3, then my C++ compiled ok.
Now my .entry is at 0x0, and _start is still 0x804.
Does that seem like a reasonable explanation?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
If you're using the OCRAM as reset vector, have you tried to increase the OCRAM size? Also, are you using the OCRAM II IP?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
My OCRAM is 86K. It did not say region reset couldnt fit into region OCRAM. It said:
section `.entry' will not fit in region `reset'
The region reset is 32 bytes and fit inside OCRAM fine.
Its .entry that didnt fit into region reset.
Max10 does not have OCRAM II IP, so, no, I'm not using it.
-Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Yeah, I did got the same error previously.
But for your case is the Max 10, I need to check on that, my apologies for the late response, I will get back to you soon.
Thank you for your patience.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Ok I got the issue on my side too, so I was using the Nios V GSFI + XIP:
The issue was with my BSP's .text, by default it was set to OCRAM, by right it should be set to the Nios V reset vector set in the Nios V IP(GSFI) in Platform Designer.
After changing from OCRAM to GSFI, now everything is OK too.
So things to check on the "region `reset' overflowed by 4 bytes":
- Check your Nios V reset vector
- BSP editor ".text" in "Linker Section Name" list need to be the same as your Nios V reset vector
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Do you have further questions?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Thanks for the update.
I’m glad that your question has been addressed, I now transition this thread to community support. If you have a new question, Please login to ‘https://supporttickets.intel.com’, view details of the desire request, and post a feed/response within the next 15 days to allow me to continue to support you. 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.
p/s: If any answer from the community or Intel Support are helpful, please feel free to give best answer or rate 4/5 survey.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page