Getting bin size as 400+MB after adding new flash(NOR flash) section in linker script

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 
已解决

Getting bin size as 400+MB after adding new flash(NOR flash) section in linker script

跳至解决方案
1,804 次查看
BhargaviA
Contributor I

Hi All,

I'm trying to use some part of spifi NOR flash memory to execute the program(XIP). To do that I have changed the linker script as below.

MEMORY
{
...
m_text (RX) : ORIGIN = 0x00010400, LENGTH = 0x0006FC00
m_text_xip (RX) : ORIGIN = 0x17FF7FFF, LENGTH = 0x00008000
...
}

SECTIONS
{

.text :
{
. = ALIGN(4);
*(EXCLUDE_FILE(*spifi_xipFun.o) .text*)
*(.rodata) /* .rodata sections (constants, strings, etc.) */
*(.rodata*) /* .rodata* sections (constants, strings, etc.) */
*(.glue_7) /* glue arm to thumb code */
*(.glue_7t) /* glue thumb to arm code */
*(.eh_frame)
KEEP (*(.init))
KEEP (*(.fini))
. = ALIGN(4);
} > m_text

 

.text_xip :
{
text_xip_start = .;
*spifi_xipFun.o(.text*)
KEEP (*(.text_2));
text_xip_end = .;
} > m_text_xip

}

 

With the above changes I'm getting bin size as normal and spifi_xipFun.o text is going to m_text only even after being excluded from m_text and included in m_text_xip.

Did I do anything wrong in the exclusion and inclusion of the file?

If I move the .text_2 section before the .text section I'm seeing spifi_xipFun.o text in expected memory that is in range of m_text_xip but the bin size is coming as 400+MB.

Please, let me know as soon as possible if I'm doing something wrong.

 

 

 

标签 (1)
0 项奖励
1 解答
1,795 次查看
frank_m
Senior Contributor III

Don't use BIN files.

This format has no meta information like target addresses, so this format needs to fill any "hole" in the memory range to program with default data.

在原帖中查看解决方案

0 项奖励
7 回复数
1,777 次查看
converse
Senior Contributor V

Regarding your EXCLUDE_FILE problem: Try removing the first wildcard from the line. e.g.

EXCLUDE_FILE(*spifi_xipFun.o) .text*

0 项奖励
1,775 次查看
BhargaviA
Contributor I

I'm getting syntax error if I remove the wildcard.

0 项奖励
1,796 次查看
frank_m
Senior Contributor III

Don't use BIN files.

This format has no meta information like target addresses, so this format needs to fill any "hole" in the memory range to program with default data.

0 项奖励
1,790 次查看
BhargaviA
Contributor I

I'm not sure that I understand.

And I'm not using any BIN file names in the linker script.

If you don't mind. Can you please provide me with some examples?

0 项奖励
1,787 次查看
frank_m
Senior Contributor III

> I'm not sure that I understand.

Check the difference between the lowest address (probably internal Flash) and the highest address to program (external Flash). This will explain your 400MB space.

> And I'm not using any BIN file names in the linker script.

The output file type and format is not part of the linker script.

Check your project settings, and choose a format like HEX or SREC (S19) instead of binary.

0 项奖励
1,775 次查看
BhargaviA
Contributor I

I Agree that the difference between external flash and internal flash addresses is around 400MB, but, why the linker is taking that 400MB to link?

I try to generate a HEX file instead of BIN and saw the same issue but the size is 1MB this time (Without external flash sections the bin size is 350KB).

标记 (1)
0 项奖励
1,764 次查看
frank_m
Senior Contributor III

>... but, why the linker is taking that 400MB to link?

This is not a problem with the linker, but with your choice of an inappropriate output file format.

The BIN format has no means of specifying different parts of code for different sections/addresse, so it fills up all the unused space.

0 项奖励