arm 映像文件存储器映射调整 android ld link script

2024-02-28 02:08

本文主要是介绍arm 映像文件存储器映射调整 android ld link script,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

分散加载

scatter文件语法

scatter文件典型用法

等效的简单映射分散载入描述

How to convert from an armlink scatter file to a GNU ld linker script For some of my research projects, I use the Intel iMote (ISN100-BA) platform, provided by Intel research labs Cambridge. The default TinyOS platform code uses GNU gcc for compiling, but depends on the ARM developer suite (ADS 1.2 or Realview) linker for the final step. Replacing this with the GNU linker ld was a non-trivial task, and part of it was to convert the memory layout from the armlink scatter file to a GNU ld linker script. In the following, I use the ScatterFile.txt shipped with the iMote TinyOS platform, but the steps should be applicable to other files as well. Please email me when you have successfully converted other files, so that I can add more examples to this page. For brevity, I have removed all comments from the original file: -------------------------------------------------------------------------------- LoadFlashCode 0x004000 ABSOLUTE 0x7C000 { FlashCode2 +0 ; { * (FlashBoot) ; area is found in SU_FlashBoot.s } FlashCode3 +0 { * (+RO) } RomLinkV1 0x200000 OVERLAY { SU_ROMLinkV1.o (+RO) } RomLinkV2 0x200000 OVERLAY { SU_ROMLinkV2.o (+RO) } IRamStack +0 ABSOLUTE { * (Stacks) } IRamCode +0 ABSOLUTE { TM_FlashDrvAmend.o (+RO) TM_IRamCode.o (+RO) } IRamNI +0 { * (ResetFlags) SU_PowerUpCheckVar.o (+ZI) } IRamRW +0 { * ( +RW ) } IRamZI +0 { * ( +ZI ) } BRamNI 0x20CB00 ABSOLUTE { } BRamZI 0x20F900 ABSOLUTE 0x700 { BBD_BufferSramVar.o ( +ZI) LM_BufferSramVar.o ( +ZI) BP_BufferSramVar.o ( +ZI) } XRamZI 0x400000 ABSOLUTE { BP_DummyXramVar.o ( +ZI) } } -------------------------------------------------------------------------------- There are numerous examples for GNU ld linker scripts on the web, also for ARM7TDMI (which is used on the iMote). These can be used for the general structure. But to generate a working file, we first need to find out the segments used by the target platform, that is, start and end addresses for loading and executing code and data. Using the manual for armlink, these can be extracted from the above file (yes, reverse engineering). The first line LoadFlashCode 0x004000 ABSOLUTE 0x7C000(the name is ignored) tells us that the flash memory starts at 0x4000 with a size of 0x7C000 bytes; this is called the "load region" for armlink, and defines how the generated binary file will look like. In the first block (blocks inside the load region define the "exec region", which might have a different mapping), FlashCode2 +0 ; { * (FlashBoot) }a boot loader code is put at the beginning of the load region. The name is again arbitrary and can be ignored for the address layout, but the +0 is an offset for the block, relative to the preceeding section (as this is the first region, relative to the load region start address). Since the address offset is zero, this tells us that, for executing code, this platform uses the same start address during execution that we need to use for loading. That is, the load region and the exec region for initialization code start at the same absolute address. This is to be expected for most platforms. Although the name is not relevant for the linker itself, exec regions automatically generate Load$$Name symbols, which can be referenced in the code. This is typically used by the boot loader to set up the run-time environment before starting the custom code, i.e. for transforming the load segmentation into the exec segmentation. Since GNU ld does not generate these symbols automatically, we will need to do so explicitly, as described below. There are two components in the lines within these blocks: a module selector, which matches input file names (object or library files), and an (optional) input section selector in brackets, which matches the section that the compiler created. Both components need to match for the line to include anything in the output. The above line matches any input file (i.e. don't care) that defines a section named FlashBoot (which is, in this case, contained in the file SU_FlashBoot.o). Then the next block FlashCode3 +0 { * (+RO) }simply appends all the other executable code and constant values (which are marked read-only, i.e. as an RO section, by the compiler). Again, the +0 is an offset and tells us that our own executable code is mapped to the same addresses for loading and for execution. Now it gets slightly more complicated. The next two exec regions RomLinkV1 0x200000 OVERLAY { SU_ROMLinkV1.o (+RO) } RomLinkV2 0x200000 OVERLAY { SU_ROMLinkV2.o (+RO) }use the same absolute address during execution, namely 0x200000, and the OVERLAY keyword. This means that two different code blocks (code because the section matches are RO) can be available in the area starting at address 0x200000 and that the executed code somehow needs to select which one is used (in the iMote TinyOS case, this is done by the boot loader). For linking, this means that two code blocks that are separate in the load region (i.e. the binary file to be flashed) need to use the same start address when being referenced to for execution. The modules referenced by the module selectors, i.e. SU_ROMLinkV1.o and SU_ROMLinkV2.o (contained in the motelib.a file), are appended to the code area in the load region. Although this is not made explicit, the new base address tells us that a new segment was started. We can guess (taking into account the load region names...), the the segment starting at address 0x4000 is a flash memory, both during load and during execution time, and that the segment starting at address 0x200000 is RAM. The data sheet of the iMote tells us that it has a size of 64kB, or 0x10000, so we can use this for verification that the RAM area is sufficient for the executable. The following regions therefore define the RAM layout during execution. A small part at the start is already consumed by the overlaid regions, followed by IRamStack +0 ABSOLUTE { * (Stacks) }which defines our stack region. The +0 ABSOLUTE address modifier tells us that this exec region follows the preceding, but that it does not inherit its OVERLAY flag. As for the first load region, this matches a specific section name (defined in motelib.a). Then two more code modules (only the code and constant data parts marked RO of two specific modules, again contained in motelib.a) IRamCode +0 ABSOLUTE { TM_FlashDrvAmend.o (+RO) ;//Ammendments to Flash driver code TM_IRamCode.o (+RO) }are appended and need to be copied from the load address to the execution address by the boot loader (these are different by now, since the modules need to be appended to the generated binary that is loaded to the flash, but will be executed in RAM addresses). The next exec region IRamNI +0 { * (ResetFlags) SU_PowerUpCheckVar.o (+ZI) }defines another part identified by section name and room for some variables that should be initialized with zero (the ZI attribute, which indicates that this is "BSS" data, i.e. uninitialized static variables). Finally, the next two exec regions IRamRW +0 { * ( +RW ) } IRamZI +0 { * ( +ZI ) }define the RAM areas for all other initialized (RW) and uninitialized (ZI) variables that have not been added by previous regions. These are the normal "DATA" and "BSS" segments. Then seemingly nonsensical, an emtpy exec region BRamNI 0x20CB00 ABSOLUTE { }that only defines the matching symbols at address 0x20CB00 but does not reserve any further space (in neither the load nor the exec areas). At the very end of the available RAM block, the exec region BRamZI 0x20F900 ABSOLUTE 0x700 { BBD_BufferSramVar.o ( +ZI) LM_BufferSramVar.o ( +ZI) BP_BufferSramVar.o ( +ZI) }reserves space for uninitialized variables (ZI) defined in three modules within the last 0x700 bytes, starting at address 0x20F900. Taking module names into account, we can guess that this is a small buffered SRAM area, possibly used for performance reasons (a detailed data sheet would make this guessing unnecessary...). Note that this does again not consume any space in the load region, because this exec region only defines uninitialized variables. The above description of "all other variables that have not been added by previous regions" is not completely correct. Not order matches, but most specific lines. Finally, the last exec region XRamZI 0x400000 ABSOLUTE { BP_DummyXramVar.o ( +ZI) }defines yet another segment, starting at address 0x400000. It also doesn't append anything to the load region, but reserves space for uninitialized variables (ZI) of a specific module. Summarizing this analysis, the scatter file defines three regions: •Start address 0x4000 with a length of 0x7C000: This is mapped in both the load and the execution areas and defines the flash memory. Some code (marked RO) is executed in-place, and other code and constants (marked RO) and start values for initialized variables (marked RW) are stored in the load area (in the binary file and loaded into the flash memory) and need to be copied to the other, writable segments by the boot loader before executing the main program. •Start address 0x200000 with a length of 0x10000: This is the normal RAM for the execution area, and the linker reserves space for defined variables here. •Start address 0x400000 with unknown length: Contains only some uninitialized variables. This means that the linker only needs to set resolve some symbols to lie within this segment, but does not need to put anything in there. Now we need to write an ld linker scripts that creates the same layout. A complete reference for ld linker scripts can be found here. The initial definition of the three regions is simple: MEMORY { FLASH (rx) : ORIGIN = 0x004000, LENGTH = 0x7C000 RAM (rwx) : ORIGIN = 0x200000, LENGTH = 0x10000 RAM2 (rwx) : ORIGIN = 0x400000, LENGTH = 0x10000 }As we don't really know the length of the second RAM region but the LENGTH attribute is mandatory, we need to guess something. As it is just used to check for overflowing regions, this should not lead to any problems. Note that the addresses specified in the MEMORY layout refer to the executable area, i.e. exec regions in armlink terms. The main part of an ld linker script is its SECTIONS block, which we start with the code area that is mapped to the same address in the load and execution areas, i.e. the flash: SECTIONS { .text : { * (FlashBoot) __end_of_boot__ = ABSOLUTE(.); * (.text) * (.rodata) * (.rodata*) * (.glue_7) * (.glue_7t) } > FLASH __end_of_text__ = .; This first output section is named .text, which is the standard name for ELF format files, and first includes the section named FlashBoot from any of the input files and then all remaining .text, .rodata, and special glue code segments from any of the input files. The addresses are set automatically, because the whole output section is put into the defined FLASH memory region. Additionally, we define the symbol __end_of_boot__ to contain the end address of the boot loader code, for later use. ..

这篇关于arm 映像文件存储器映射调整 android ld link script的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/754170

相关文章

Android WebView无法加载H5页面的常见问题和解决方法

《AndroidWebView无法加载H5页面的常见问题和解决方法》AndroidWebView是一种视图组件,使得Android应用能够显示网页内容,它基于Chromium,具备现代浏览器的许多功... 目录1. WebView 简介2. 常见问题3. 网络权限设置4. 启用 JavaScript5. D

Android如何获取当前CPU频率和占用率

《Android如何获取当前CPU频率和占用率》最近在优化App的性能,需要获取当前CPU视频频率和占用率,所以本文小编就来和大家总结一下如何在Android中获取当前CPU频率和占用率吧... 最近在优化 App 的性能,需要获取当前 CPU视频频率和占用率,通过查询资料,大致思路如下:目前没有标准的

JavaScript中的Map用法完全指南

《JavaScript中的Map用法完全指南》:本文主要介绍JavaScript中Map用法的相关资料,通过实例讲解了Map的创建、常用方法和迭代方式,还探讨了Map与对象的区别,并通过一个例子展... 目录引言1. 创建 Map2. Map 和对象的对比3. Map 的常用方法3.1 set(key, v

Javascript访问Promise对象返回值的操作方法

《Javascript访问Promise对象返回值的操作方法》这篇文章介绍了如何在JavaScript中使用Promise对象来处理异步操作,通过使用fetch()方法和Promise对象,我们可以从... 目录在Javascript中,什么是Promise1- then() 链式操作2- 在之后的代码中使

Python批量调整Word文档中的字体、段落间距及格式

《Python批量调整Word文档中的字体、段落间距及格式》这篇文章主要为大家详细介绍了如何使用Python的docx库来批量处理Word文档,包括设置首行缩进、字体、字号、行间距、段落对齐方式等,需... 目录关键代码一级标题设置  正文设置完整代码运行结果最近关于批处理格式的问题我查了很多资料,但是都没

javaScript在表单提交时获取表单数据的示例代码

《javaScript在表单提交时获取表单数据的示例代码》本文介绍了五种在JavaScript中获取表单数据的方法:使用FormData对象、手动提取表单数据、使用querySelector获取单个字... 方法 1:使用 FormData 对象FormData 是一个方便的内置对象,用于获取表单中的键值

前端知识点之Javascript选择输入框confirm用法

《前端知识点之Javascript选择输入框confirm用法》:本文主要介绍JavaScript中的confirm方法的基本用法、功能特点、注意事项及常见用途,文中通过代码介绍的非常详细,对大家... 目录1. 基本用法2. 功能特点①阻塞行为:confirm 对话框会阻塞脚本的执行,直到用户作出选择。②

Android开发中gradle下载缓慢的问题级解决方法

《Android开发中gradle下载缓慢的问题级解决方法》本文介绍了解决Android开发中Gradle下载缓慢问题的几种方法,本文给大家介绍的非常详细,感兴趣的朋友跟随小编一起看看吧... 目录一、网络环境优化二、Gradle版本与配置优化三、其他优化措施针对android开发中Gradle下载缓慢的问

JavaScript中的reduce方法执行过程、使用场景及进阶用法

《JavaScript中的reduce方法执行过程、使用场景及进阶用法》:本文主要介绍JavaScript中的reduce方法执行过程、使用场景及进阶用法的相关资料,reduce是JavaScri... 目录1. 什么是reduce2. reduce语法2.1 语法2.2 参数说明3. reduce执行过程

Android 悬浮窗开发示例((动态权限请求 | 前台服务和通知 | 悬浮窗创建 )

《Android悬浮窗开发示例((动态权限请求|前台服务和通知|悬浮窗创建)》本文介绍了Android悬浮窗的实现效果,包括动态权限请求、前台服务和通知的使用,悬浮窗权限需要动态申请并引导... 目录一、悬浮窗 动态权限请求1、动态请求权限2、悬浮窗权限说明3、检查动态权限4、申请动态权限5、权限设置完毕后