RTEMS 的 AT91SAM9260 移植(7): 链接脚本

到上一连载为止,RTEMS 4.9.4的相关代码部分的修改就算结束了。

有些细心的朋友会注意到,第三个连载中列出了所有的文件,我们一些文件并没有修改;还有一些文件AT91RM9200中是没有的。如

c/src/lib/libcpu/arm/at91sam9260/memcpy/memcpy.S,这个文件是我找来的一个ARM下memcpy的优化版本,效率应该高于普通的memcpy。库里本来就有memcpy,所以编译不编译都无所谓。

另外就是网络驱动,网络驱动可有可无,如果运行相关的以太网代码,那必须有的。这里以后再弄吧。

以太网驱动可以先屏蔽一下,只是为了编译通过就好,反正在最中的代码中也不使用。全部做成哑函数就行了。

 

我们先讲讲链接脚本的修改:

 

AT91SAM9260的内存构成:

 

RTEMS 的 AT91SAM9260 移植(7): 链接脚本_第1张图片

 

 

开始的 0x0到0x100000的空间为boot memory。它可以把ROM和SRAM0映射到该地址来。

我们的代码在 SDRAM 中运行,64MB,地址从0x2000 0000 开始。

 

ARM规定,异常向量必须从0x0的地方开始,系统启动时默认是将ROM映射成从0x0地址开始,显然,ROM不能写入东西。

Bootloader 可能会改变这个ROM 的映射,只是可能。但操作系统不能以为这个工作Bootloader 一定做了,必须将SRAM0映射成从0x0地址开始,并将异常向量拷贝到0x0开始的位置。

 

所以为什么start.S中要在拷贝异常向量之前执行memroy remap的函数了。

 

我在调试网络的时候,学习AT91RM9200的脚本,将网络的缓冲区全部放在SRAM0或SRAM1中。发现代码跑一段时间就死机,跑一段时间就完蛋,后来干脆将所有的内存缓冲区全部放在SDRAM中,只有异常向量放在SRAM0中,一下问题就解决了。所以这个脚本也就变为全部都在SDRAM中的了。

 

/* * AT91SAM9260 link script * Bacon Xu */ OUTPUT_FORMAT("elf32-littlearm", "elf32-bigarm", "elf32-littlearm") OUTPUT_ARCH(arm) ENTRY(_start) MEMORY { sdram : ORIGIN = 0x20000000, LENGTH = 64M } /* * Declare some sizes. */ _sdram_base = DEFINED(_sdram_base) ? _sdram_base : 0x20000000; _sdram_size = DEFINED(_sdram_size) ? _sdram_size : 64M; _irq_stack_size = DEFINED(_irq_stack_size) ? _irq_stack_size : 0x2000; _fiq_stack_size = DEFINED(_fiq_stack_size) ? _fiq_stack_size : 0x400; _abt_stack_size = DEFINED(_abt_stack_size) ? _abt_stack_size : 0x100; _svc_stack_size = DEFINED(_svc_stack_size) ? _svc_stack_size : 0x2000; SECTIONS { .init : { KEEP (*(.init)) } > sdram /*=0*/ .text : { _text_start = .; CREATE_OBJECT_SYMBOLS *(.text) *(.text.*) /* * Special FreeBSD sysctl sections. */ . = ALIGN (16); __start_set_sysctl_set = .; *(set_sysctl_*); __stop_set_sysctl_set = ABSOLUTE(.); *(set_domain_*); *(set_pseudo_*); /* .gnu.warning sections are handled specially by elf32.em. */ *(.gnu.warning) *(.gnu.linkonce.t*) *(.glue_7) *(.glue_7t) /* I think these come from the ld docs: */ ___CTOR_LIST__ = .; LONG((___CTOR_END__ - ___CTOR_LIST__) / 4 - 2) *(.ctors) LONG(0) ___CTOR_END__ = .; ___DTOR_LIST__ = .; LONG((___DTOR_END__ - ___DTOR_LIST__) / 4 - 2) *(.dtors) LONG(0) ___DTOR_END__ = .; _etext = .; PROVIDE (etext = .); } > sdram .fini : { KEEP (*(.fini)) } > sdram /*=0*/ .data : { *(.data) *(.data.*) *(.gnu.linkonce.d*) *(.jcr) SORT(CONSTRUCTORS) _edata = .; } > sdram .eh_frame : { *(.eh_frame) } > sdram .data1 : { *(.data1) } > sdram .eh_frame : { *(.eh_frame) } > sdram .gcc_except_table : { *(.gcc_except_table*) } > sdram .rodata : { *(.rodata) *(.rodata.*) *(.gnu.linkonce.r*) } > sdram .bss : { /* 256 byte aligned rx buffer header array */ /*. = ALIGN (0x100);*/ at91sam9260_emac_rxbuf_hdrs = .; . += (8 * 512 + 32); at91sam9260_emac_txbuf_hdrs = .; . += (8 * 1 + 32); /* 1 transmit buffer, 0x600 size */ at91sam9260_emac_txbuf = .; . += (2048 + 32); /* 24 receive buffers, 128 each */ at91sam9260_emac_rxbufs = .; . += (128 * 512 + 32); _bss_start_ = .; _clear_start = .; *(.bss) *(.bss.*) *(.gnu.linkonce.b.*) *(COMMON) . = ALIGN(64); _clear_end = .; . = ALIGN (256); _abt_stack = .; . += _abt_stack_size; . = ALIGN (256); _irq_stack = .; . += _irq_stack_size; . = ALIGN (256); _fiq_stack = .; . += _fiq_stack_size; . = ALIGN (256); _svc_stack = .; . += _svc_stack_size; _bss_end_ = .; _end = .; __end = .; /* * Ideally, the MMU's translation table would be in SRAM. But we need * 16K which is the size of SRAM. If we do the mapping right, the TLB * should be big enough that to hold all the translations that matter, * so keeping the table in SDRAM won't be a problem. */ . = ALIGN (16 * 1024); _ttbl_base = .; . += (16 * 1024); . = ALIGN (1024); _bss_free_start = .; } > sdram /* Debugging stuff follows? */ /* Stabs debugging sections. */ .stab 0 : { *(.stab) } .stabstr 0 : { *(.stabstr) } .stab.excl 0 : { *(.stab.excl) } .stab.exclstr 0 : { *(.stab.exclstr) } .stab.index 0 : { *(.stab.index) } .stab.indexstr 0 : { *(.stab.indexstr) } .comment 0 : { *(.comment) } /* DWARF debug sections. Symbols in the DWARF debugging sections are relative to the beginning of the section so we begin them at 0. */ /* DWARF 1 */ .debug 0 : { *(.debug) } .line 0 : { *(.line) } /* GNU DWARF 1 extensions */ .debug_srcinfo 0 : { *(.debug_srcinfo) } .debug_sfnames 0 : { *(.debug_sfnames) } /* DWARF 1.1 and DWARF 2 */ .debug_aranges 0 : { *(.debug_aranges) } .debug_pubnames 0 : { *(.debug_pubnames) } /* DWARF 2 */ .debug_info 0 : { *(.debug_info) } .debug_abbrev 0 : { *(.debug_abbrev) } .debug_line 0 : { *(.debug_line) } .debug_frame 0 : { *(.debug_frame) } .debug_str 0 : { *(.debug_str) } .debug_loc 0 : { *(.debug_loc) } .debug_macinfo 0 : { *(.debug_macinfo) } /* SGI/MIPS DWARF 2 extensions */ .debug_weaknames 0 : { *(.debug_weaknames) } .debug_funcnames 0 : { *(.debug_funcnames) } .debug_typenames 0 : { *(.debug_typenames) } .debug_varnames 0 : { *(.debug_varnames) } /* .stack 0x80000 : { _stack = .; *(.stack) }*/ /* These must appear regardless of . */ }

 

由于所有的东西都从0x20000000开始,不会覆盖到0x0,所以0x0放向量的位置也不需要出现在脚本里。

还有关于脚本中的 .init 段,这个段原来是存放系统中先于Main函数调用的代码。

因为先于main函数运行的代码全部被当成构造函数放在另外一个段了(.ctors)。

这个段只是存放调用.ctors段代码的框架代码。固定为 32 个字节,8条指令。

紧接着是代码段,入口地址 _start 从此处开始。所以 _start 地址应是:0x20000020。

Bootloader加载的位置应该是,0x2000 0000,加载完毕后,跳转的位置应该是:0x2000 0020

特别注意这一点。

 

脚本基本上就这么修改,其他部分没有什么太好说的,关于网络缓冲区的问题,我们讨论到网络的时候再说。脚本看不懂请参考<< using ld>>这个手册,或者别的大牛文章,如果您觉得有问题,请发帖直接找我讨论。谢谢。

 

 

你可能感兴趣的:(网络,脚本,table,FreeBSD,translation,debugging)