嵌入式linux的移植的理论问题.docx
- 文档编号:3424700
- 上传时间:2022-11-22
- 格式:DOCX
- 页数:6
- 大小:17.31KB
嵌入式linux的移植的理论问题.docx
《嵌入式linux的移植的理论问题.docx》由会员分享,可在线阅读,更多相关《嵌入式linux的移植的理论问题.docx(6页珍藏版)》请在冰豆网上搜索。
嵌入式linux的移植的理论问题
嵌入式linux的移植的理论问题
移植的基本概念:
移植是指将软件从一个平台迁移到另一个平台
*从一个硬件平台移植到另一个硬件平台
*从一个操作系统移植到另一个操作系统
*从一种软件库环境移植到另一个软件库环境
软件进行移植的容易程度即可移植性
Linux硬件平台:
在Linux内核里,每一个处理器指令集对应一个独立的体系结构architecture,比如alpha,arm,i386,mips,ppc
每个体系结构可以有若干变种variant,或不同配置的硬件machine
统称sub-architecture。
以arm体系结构举例
*variants包括arm7tdmi,arm926ejs,strongarm,xscale
*machine包括edb7312,smdk2410,omap-h2
硬件平台对C程序的影响:
处理器字长,定义为处理器一次能处理的数据位数。
字长等于处理器内部数据通路的宽度,一般可以通过通用寄存器的宽度来判断
处理器字长会影响int,long等C类型的长度
C代码当中需要使用确定大小的数据类型,可以使用显式长度的类型u8,s8,u16,s16,u32,s32,u64,s64
数据对齐:
数据对齐是指数据块的地址是某个特定大小的整数倍
*32位处理器字对齐n*4
*页对齐n*PAGESIZE
*Cacheline对齐n*CLINESIZE
数据访问要求至少是字对齐的,多数情况下编译器会处理数据访问的对齐。
不对齐访问的例子
*chara[10];
*unsignedlong*pl=(unsignedlong*)(a+1);
*unsignedl=*pl;
字节顺序:
字节顺序byteorder是指一个字中字节排列的顺序
不同硬件可能采用不同byteorder
*x86little-endian
*ppcbig-endian
Linux内核将硬件的byteorder放在
在include/linux/byteorder/里面有几个头文件,定义了
*u23__cpu_to_be32(u32);
*u32__cpu_to_le32(u32);
*u32__be32_to_cpu(u32);
*u32__le32_to_cpus(u32);
时间:
软件中的与时间相关的代码也会影响移植
采用平台无关的时间表达方法可以提高代码可移植性
Linux内核里面采用HZ来表示每秒钟有多少个内部时钟滴答,以下对时间的描述是平台无关的
*HZ
*(2*HZ)
*(HZ/2)
*(HZ/100)
*(2*HZ/100)
内存页面大小:
Linux使用虚拟内存机制来管理内存,内存的使用基于页面。
不同的体系结构有不同的页面大小
常用的32位处理器使用4kB页面大小
部分体系结构可以支持多种页面大小
内核在
*PAGE_SIZE表示页面大小
*PAGE_SHIFT表示页面号在地址中的偏移量
*PAGE_SIZE=2^PAGE_SHIFT
Linux操作系统移植:
工具链移植
*binutils(assembler,linker..)
*gcc(compiler,libgcc)
*glibc/uclibc
内核移植
*archimplementation
*driversporting
应用程序移植
*Cprogramrecompile
*Implementabsentlibrary
Linux内核的平台相关代码:
Linux内核对多平台有很好的支持内核的对外部接口是统一的,并且与平台无关
内核的大多数代码也是与平台无关的主要的体系结构相关代码存在于
*arch/architecture
*include/asm-architecture
比如arm体系的平台相关代码主要是
*arch/arm
*include/asm-arm
已有代码向Linux内核移植:
将已有代码向内核中移植有一些限制
*内核中没有标准C库支持
*内核中没有象用户程序那样的内存保护
*内核中不便使用浮点操作
*内核的堆栈是固定大小的,并且比较有限
*在内核中需要编程者考虑并发带来的竞争与冒险,以及同步问题
Linux内核移植:
Linux内核代码可以分为平台相关部分和平台无关部分
Linux内核绝大部分代码是平台无关的,
可以被各种平台所共享
*调度算法
*存储器管理
*I/O子系统
*网络协议栈
依赖于特定硬件的代码在Linux中采用条件编译的方式区分
*ARCH=x86即打开x86特有的代码
*ARCH=arm即打开arm特有的代码
Linux内核的arch目录:
进入arch目录,每个体系结构代码都有一个子目录
进入arm目录,在arm体系结构下我们可以看到很多sub-arch的子目录
实现sub-arch:
在sub-arch子目录下,以mach-s3c2410为例一个硬件平台支持需要实现以下几个硬件相关的文件
*mach-s3c2410.c,irq.c,clock.c,dma.c,gpio.c,pm.c,sleep.c,time.c
*同时在include/asm-arm/arch-s3c2410要实现
Low-levelIRQhelpermacros
Debugoutputmacros
Irqnumberdefinations
DMAdefinations
Memorymapping/translation
Resetoperation
IDLEfunction
mach-smdk2410.c:
在mach-smdk2410.c中,我们要定义以下几个内容
smdk2410_iodesc,描述了所有保留的设备io地址。
这个描述符是我们移植一个特定目标板非常重要的地方
在这个板描述文件中还要定义
.phys_ram
.phys_io
.io_pg_offst
.boot_params
.map_io
.init_irq
.timer
map_io:
map_io里面需要实现设备io的初始化
在这里要用到smdk2410_iodesc描述符。
该描述符是一个数组,其中每一项都描述了一个设备的IO映射
时钟pll的设置、uart的设置都可以在map_io中调用
init_irq:
在这个调用里面,关于中断的初始化将会被完成
*清除中断pending寄存器
*注册主要的中断处理程序
*设置系统中的设备中断
timer:
timer是一个sys_timer类型的结构,它包含以下成员
-init调用执行硬件相关的timer初始化
-offset调用返回自从上次timer中断以来经过的微秒数
-resume调用执行系统唤醒后的timer恢复操作,一般实现上和init里面的初始化一样
应用程序移植:
最理想情况下,程序可以不作更改,或仅仅打一些补丁,然后告诉编译环境按照目标环境要求编译即可
*busybox
*bash
*sysvinit
依赖某些平台特性的应用程序移植起来往往难度更大
*图形库
*为速度进行优化的代码,比如编解码器
软件编程语言的跨平台性直接影响软件的可移植性。
此外还有其他因素
软件协议/源代码的开放程度
应用程序移植常见问题:
1依赖软件造成移植性问题
*C库版本问题
*图形库带来的问题
*软件依赖某些服务带来问题
2网络应用在little-endian平台上的处理
*网络传递数据是big-endian的
3软件依赖特定平台的特性
4平台的数据一致性模型差异
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 嵌入式 linux 移植 理论 问题
![提示](https://static.bdocx.com/images/bang_tan.gif)