嵌入式中的移植是什么意思,移植系统呢 20
4个回答
展开全部
与其它操作系统相比,Linux最大的特点:它是一款遵循GPL的操作系统,我们可以自由
地使用、修改、和扩展它。正是由于这一特色,Linux受到越来越多人士的青睐。于是,
一个经常会被探讨的问题出现了,即关于Linux系统的移植。对于操作系统而言,这种移
植通常是跨平台的、与硬件相关的,即硬件系统结构、甚至CPU不同。下面就让我们来看
看在Linux系统移植方面,我们都需要做些什么。
一、Linux系统移植的两大部分
对于系统移植而言,Linux系统实际上由两个比较独立的部分组成,即内核部分和系
统部分。通常启动一个Linux系统的过程是这样的:一个不隶属于任何操作系统的加载程
序将Linux部分内核调入内存,并将控制权交给内存中Linux内核的第一行代码。加载程
序的工作就完了,此后Linux要将自己的剩余部分全部加载到内存(如果有的话,视硬件
平台的不同而不同),初始化所有的设备,在内存中建立好所需的数据结构(有关进程
、设备、内存等)。到此为止Linux内核的工作告一段落,内核已经控制了所有硬件设备
。至于操作和使用这些硬件设备,则轮到系统部分上场了。内核加载根设备并启动init
守护进程,init守护进程会根据配置文件加载文件系统、配置网络、服务进程、终端等
。一旦终端初始化完毕,我们就会看到系统的欢迎界面了。小结一下:
(1)内核部分初始化和控制所有硬件设备(严格说不是所有,而是绝大部分),为内存
管理、进程管理、设备读写等工作做好一切准备。
(2)系统部分加载必需的设备,配置各种环境以便用户可以使用整个系统。
二、系统移植所必需的环境
在进一步叙述之前,我们有必要提一下做系统移植所必需的环境。
首先,需要一个新版本的gcc。对于一个准备系统移植的程序员而言,“新”到什么
程度应该心里有数。做跨平台编译,gcc也许是最好的选择。另外,Linux内核依赖许多
gcc特有的特性,非它不可。如果你已经会使用gcc并实地操练过多回,那你只需要再进
一步巩固一下跨平台编译的操作即可。两种编译环境是可用的:非目标平台上的Linux或
目标平台上的非Linux系统,除非你的开发平台过于特殊,否则你一定能够找到你能用的
gcc。
其次,编译链接库是必需的,而且必须是目标平台的编译链接库。通常这是一个枯
燥、繁琐、又丝毫没有成就感的过程。幸运的话,会有现成的链接库可以用。否则,你
需要自己用gcc建立它。
最后,需要目标平台的所有文档,越多越好。如果有一定的开发支持/仿真环境,L
oader(加载程序)则最好,这些可以帮助你减少移植过程中浪费在琐事上的时间。
三、Linux系统移植
接下来我们从内核和系统两个方面描述一下移植中的关键。
(1) 内存移植
Linux系统采用了相对来说并不是很灵活的单一内核机制,但这丝毫没有影响Linux
系统的平台无关性和可扩展性。Linux使用了两种途径分别解决这些问题,很干净利落,
丝毫不拖泥带水,而且十分清晰易懂。分离硬件相关代码和硬件无关代码,使上层代码
永远不必关心低层换用了什么代码,如何完成了操作。不论对x86上还是在Alpha平台上
分配一块内存,对上层代码而言没什么不同。硬件相关部分的代码不多,占总代码量的
很少一部分。所以对更换硬件平台来说,没有什么真正的负担。另一方面,Linux使用内
核机制很好地解决了扩展的问题,一堆代码可以在需要的时候轻松地加载或卸下,象随
身听,需要的时候带上,不需要时则锁在抽屉里。
Linux内核可以视为由五个功能部分组成:进程管理(包括调度和通信)、内存管理
、设备管理、虚拟文件系统、网络。它们之间有着复杂的调用关系,但幸运的是,在移
植中不会触及到太多,因为Linux内核良好的分层结构将硬件相关的代码独立出来。何谓
硬件相关,何谓无关?以进程管理为例,对进程的时间片轮转调度算法在所有平台的Li
nux中都是一样的,它是与平台无关的;而用来在进程中切换的实现在不同的CPU上是不
同的,因此需要针对该平台编写代码,这就是平台相关的。上面所讲的五个部分的顺序
不是随便排的,从前到后分别代表着它们与硬件设备的相关程度。越靠前越高,后面的
两个虚拟文件系统和网络则几乎与平台无关,它们由设备管理中所支持的驱动程序提供
底层支持。因此,在做系统移植的时候,需要改动的就是进程管理、内存管理和设备管
理中被独立出来的那部分即硬件相关部分的代码。在Linux代码树下,这部分代码全部在
arch目录下。
如果你的目标平台已经被Linux核心所支持的话,那么你是幸运的,因为已经没有太
多的工作让你去做。只要你的交叉编译环境是正确的,你只需要简单的配置、编译就可
以得到目标代码。否则,需要你去编写,或修改一些代码。只需修改平台相关部分的代
码即可。但需要对目标平台,主要是对CPU的透彻理解。在Linux的代码树下,可以看到
,这部分的典型代码量为:2万行左右C代码和2千行左右的汇编(C代码中通常包含许多
伪汇编指令,因此实际上纯C代码要少很多),这部分工作量是不可小看的。它包含了对
绝大多数硬件的底层操作,涉及IRQ、内存页表、快表、浮点处理、时钟、多处理器同步
等问题,频繁的端口编程意味着需要你将目标平台的文档用C语言重写一遍。这就是为什
么说目标平台的文档极其重要。
代码量最大的部分是被核心直接调用的底层支持部分,这部分代码在arch/xxx/ker
nel下(xxx是平台名称)。这些代码重写了内核所需调用的所有函数。因为接口函数是固
定的,所以这里更象是为硬件平台编写API。不同的系统平台,主要有以下几方面的不同
:
进程管理底层代码:从硬件系统的角度来看,进程管理就是CPU的管理。在不同的硬
件平台上,这有很大的不同。CPU中用的寄存器结构不同,上下文切换的方式、现场的保
存和恢复、栈的处理都不同,这些内容主要由CPU开发手册所描述。通常来说,CPU的所
有功能和状态对于Linux不一定有意义。实现时,需要在最小的开发代价和最好的系统性
能之间加以权衡。
* BIOS接口代码:这一名称似乎并不太准确,因为它沿用了PC一贯的叫法。但在不致引
起混淆的情况下我们还是这么叫它。在通用平台上,通常有基本输入输出系统供操作系
统使用,在PC上是BIOS,在SPARC上是PROM,在很多非通用系统上甚至并没有这样的东西
。多数情况下,Linux不依赖基本输入输出系统,但在某些系统里,Linux需要通过基本
输入输出系统中得到重要的设备参数。移植中,这部分代码通常需要完全改写。
* 时钟、中断等板上设备支持代码:即使在同一种CPU的平台上,也会存在不同的板上外
设,异种CPU平台上更是如此。不同的系统组态需要不同的初始化代码。很典型的例子就
是MIPS平台,看看arc/mips/的代码,与其它系统比较一下就知道。因为MIPS平台被OEM
得最广,在嵌入式领域应用最多(相对其它几种CPU而言)。甚至同一种MIPS芯片被不同
厂家封装再配上不同的芯片组。因此要为这些不同的MIPS平台分别编写不同的代码。
* 特殊结构代码:如多处理器支持等。其实每一种CPU都是十分特殊的,熟悉x86平台的
人都知道x86系列CPU著名的实模式与虚模式的区别,而在SPARC平台上根本就没有这个概
念。这就导致了很大的不同:PC机上的Linux在获得控制权后不久就开始切换到虚模式,
SPARC机器上则没有这段代码。又如电源管理的支持更是多种多样,不同的CPU有着不同
的实现方式(特殊的电源管理方式甚至被厂商标榜)。在这种情况下,除非放弃对电源
管理的支持,否则必须重写代码。
还有一部分代码量不多,但不能忽视的部分是在arch/xxx/mm/下的内存管理部分。
所有与平台相关的内存管理代码全部在这里。这部分代码完成内存的初始化和各种与内
存管理相关的数据结构的建立。Linux使用了基于页式管理的虚拟存储技术,而CPU发展
的趋势是:为了提高性能,实现内存管理的功能单元统统被集成到CPU中。因此内存管理
成为一个与CPU十分相关的工作。同时内存管理的效率也是最影响系统性能的因素之一。
内存可以说是计算机系统中最频繁访问的设备,如果每次内存访问时多占用一个时钟周
期,那就有可能将系统性能降低到不可忍受。在Linux系统里,不同平台上的内存管理代
码的差异程度是令人吃惊的,可以说是差异最大的。不同的CPU有不同的内存管理方式,
同一种CPU还会有不同的内存管理模式。Linux是从32位硬件平台上发展起来的操作系统
,但是现在已经有数种64位平台出现。在64位平台上,可用内存范围增大到原来的232倍
,其间差异可略窥一斑了。鉴于这部分代码的重要性和复杂性,移植工作在这里变得相
当谨慎。有些平台上甚至只是用最保守的内存管理模式。如在SPARC平台上的页面大小可
以是多种尺寸,为了简单和可靠起见,SPARC版的Linux只是用了8K页面这一种模式。这
一状况直到2.4版才得以改善。
除了上面所讲的之外,还有一些代码需要考虑,但相对来说次要一些。如浮点运算
的支持。较完美的做法是对FPU编程,由硬件完成浮点运算。但在某些时候,浮点并不重
要,甚至CPU根本就不支持浮点。这时候就可以根据需求来取舍。
对于内核移植的讨论到此为止。实际上,还有一些移植工作需要同时考虑,但很难
说这是属于内核范畴还是属于驱动程序范畴,比如说显示设备的支持,和内核十分相关
,但在逻辑上又不属于内核,并且在移植上也更像是驱动程序的开发。因此不在这里讨
论。
(2)系统移植
当内核移植完毕后,可以说所有的移植工作就已经完成大半了。就是说,当内核在
交叉编译成功后,加载到目标平台上正常启动,并出现类似VFS: Can抰 mount root fi
le system的提示时,则表示可以开始系统移植方面的工作了。系统移植实际上是一个最
小系统的重建过程。许多Linux爱好者有过建立Linux系统应急盘的经验,与其不同的是
,你需要使用目标平台上的二进制代码生成这个最小系统。包括:init、libc库、驱动
模块、必需的应用程序和系统配置脚本。一旦这些工作完成,移植工作就进入联调阶段
了。
一个比较容易的系统部分移植办法是:先着手建立开发平台上的最小系统,保证这
套最小系统在开发平台上正确运行。这样可以避免由于最小系统本身的逻辑错误而带来
的麻烦。由于最小系统中是多个应用程序相互配合工作,有时出现的问题不在代码本身
而在系统的逻辑结构上。
Linux系统移植工作至少要包括上述的内容,除此之外,有一些看不见的开发工作也
是不可忽视的,如某个特殊设备的驱动程序,为调试内核而做的远程调试工作等。另外
,同样的一次移植工作,显然符合最小功能集的移植和完美移植是不一样的;向16位移
植和向64位移植也是不一样的。
在移植中通常会遇见的问题是试运行时锁死或崩溃,在系统部分移植时要好办些,
因为可以容易地定位错误根源,而在核心移植时确实很让人头疼。虽然可以通过串口对
运行着的内核进行调试,但是在多任务情况下,有很多现象是不可重现的。又如,在初
始化的开始,很多设备还没法确定状态,甚至串口还没有初始化。对于这种情况没有什
么很好的解决办法,好的开发/仿真平台很重要,另外要多增加反映系统运行状态的调试
代码;再者要吃透硬件平台的文档。硬件平台厂商的专业支持也是很重要的。
还有一点很重要:Linux本身是基于GPL的操作系统,移植时,可以充分发挥GPL的优
势,让更多的爱好者参与进来,向共同的目标前进。
地使用、修改、和扩展它。正是由于这一特色,Linux受到越来越多人士的青睐。于是,
一个经常会被探讨的问题出现了,即关于Linux系统的移植。对于操作系统而言,这种移
植通常是跨平台的、与硬件相关的,即硬件系统结构、甚至CPU不同。下面就让我们来看
看在Linux系统移植方面,我们都需要做些什么。
一、Linux系统移植的两大部分
对于系统移植而言,Linux系统实际上由两个比较独立的部分组成,即内核部分和系
统部分。通常启动一个Linux系统的过程是这样的:一个不隶属于任何操作系统的加载程
序将Linux部分内核调入内存,并将控制权交给内存中Linux内核的第一行代码。加载程
序的工作就完了,此后Linux要将自己的剩余部分全部加载到内存(如果有的话,视硬件
平台的不同而不同),初始化所有的设备,在内存中建立好所需的数据结构(有关进程
、设备、内存等)。到此为止Linux内核的工作告一段落,内核已经控制了所有硬件设备
。至于操作和使用这些硬件设备,则轮到系统部分上场了。内核加载根设备并启动init
守护进程,init守护进程会根据配置文件加载文件系统、配置网络、服务进程、终端等
。一旦终端初始化完毕,我们就会看到系统的欢迎界面了。小结一下:
(1)内核部分初始化和控制所有硬件设备(严格说不是所有,而是绝大部分),为内存
管理、进程管理、设备读写等工作做好一切准备。
(2)系统部分加载必需的设备,配置各种环境以便用户可以使用整个系统。
二、系统移植所必需的环境
在进一步叙述之前,我们有必要提一下做系统移植所必需的环境。
首先,需要一个新版本的gcc。对于一个准备系统移植的程序员而言,“新”到什么
程度应该心里有数。做跨平台编译,gcc也许是最好的选择。另外,Linux内核依赖许多
gcc特有的特性,非它不可。如果你已经会使用gcc并实地操练过多回,那你只需要再进
一步巩固一下跨平台编译的操作即可。两种编译环境是可用的:非目标平台上的Linux或
目标平台上的非Linux系统,除非你的开发平台过于特殊,否则你一定能够找到你能用的
gcc。
其次,编译链接库是必需的,而且必须是目标平台的编译链接库。通常这是一个枯
燥、繁琐、又丝毫没有成就感的过程。幸运的话,会有现成的链接库可以用。否则,你
需要自己用gcc建立它。
最后,需要目标平台的所有文档,越多越好。如果有一定的开发支持/仿真环境,L
oader(加载程序)则最好,这些可以帮助你减少移植过程中浪费在琐事上的时间。
三、Linux系统移植
接下来我们从内核和系统两个方面描述一下移植中的关键。
(1) 内存移植
Linux系统采用了相对来说并不是很灵活的单一内核机制,但这丝毫没有影响Linux
系统的平台无关性和可扩展性。Linux使用了两种途径分别解决这些问题,很干净利落,
丝毫不拖泥带水,而且十分清晰易懂。分离硬件相关代码和硬件无关代码,使上层代码
永远不必关心低层换用了什么代码,如何完成了操作。不论对x86上还是在Alpha平台上
分配一块内存,对上层代码而言没什么不同。硬件相关部分的代码不多,占总代码量的
很少一部分。所以对更换硬件平台来说,没有什么真正的负担。另一方面,Linux使用内
核机制很好地解决了扩展的问题,一堆代码可以在需要的时候轻松地加载或卸下,象随
身听,需要的时候带上,不需要时则锁在抽屉里。
Linux内核可以视为由五个功能部分组成:进程管理(包括调度和通信)、内存管理
、设备管理、虚拟文件系统、网络。它们之间有着复杂的调用关系,但幸运的是,在移
植中不会触及到太多,因为Linux内核良好的分层结构将硬件相关的代码独立出来。何谓
硬件相关,何谓无关?以进程管理为例,对进程的时间片轮转调度算法在所有平台的Li
nux中都是一样的,它是与平台无关的;而用来在进程中切换的实现在不同的CPU上是不
同的,因此需要针对该平台编写代码,这就是平台相关的。上面所讲的五个部分的顺序
不是随便排的,从前到后分别代表着它们与硬件设备的相关程度。越靠前越高,后面的
两个虚拟文件系统和网络则几乎与平台无关,它们由设备管理中所支持的驱动程序提供
底层支持。因此,在做系统移植的时候,需要改动的就是进程管理、内存管理和设备管
理中被独立出来的那部分即硬件相关部分的代码。在Linux代码树下,这部分代码全部在
arch目录下。
如果你的目标平台已经被Linux核心所支持的话,那么你是幸运的,因为已经没有太
多的工作让你去做。只要你的交叉编译环境是正确的,你只需要简单的配置、编译就可
以得到目标代码。否则,需要你去编写,或修改一些代码。只需修改平台相关部分的代
码即可。但需要对目标平台,主要是对CPU的透彻理解。在Linux的代码树下,可以看到
,这部分的典型代码量为:2万行左右C代码和2千行左右的汇编(C代码中通常包含许多
伪汇编指令,因此实际上纯C代码要少很多),这部分工作量是不可小看的。它包含了对
绝大多数硬件的底层操作,涉及IRQ、内存页表、快表、浮点处理、时钟、多处理器同步
等问题,频繁的端口编程意味着需要你将目标平台的文档用C语言重写一遍。这就是为什
么说目标平台的文档极其重要。
代码量最大的部分是被核心直接调用的底层支持部分,这部分代码在arch/xxx/ker
nel下(xxx是平台名称)。这些代码重写了内核所需调用的所有函数。因为接口函数是固
定的,所以这里更象是为硬件平台编写API。不同的系统平台,主要有以下几方面的不同
:
进程管理底层代码:从硬件系统的角度来看,进程管理就是CPU的管理。在不同的硬
件平台上,这有很大的不同。CPU中用的寄存器结构不同,上下文切换的方式、现场的保
存和恢复、栈的处理都不同,这些内容主要由CPU开发手册所描述。通常来说,CPU的所
有功能和状态对于Linux不一定有意义。实现时,需要在最小的开发代价和最好的系统性
能之间加以权衡。
* BIOS接口代码:这一名称似乎并不太准确,因为它沿用了PC一贯的叫法。但在不致引
起混淆的情况下我们还是这么叫它。在通用平台上,通常有基本输入输出系统供操作系
统使用,在PC上是BIOS,在SPARC上是PROM,在很多非通用系统上甚至并没有这样的东西
。多数情况下,Linux不依赖基本输入输出系统,但在某些系统里,Linux需要通过基本
输入输出系统中得到重要的设备参数。移植中,这部分代码通常需要完全改写。
* 时钟、中断等板上设备支持代码:即使在同一种CPU的平台上,也会存在不同的板上外
设,异种CPU平台上更是如此。不同的系统组态需要不同的初始化代码。很典型的例子就
是MIPS平台,看看arc/mips/的代码,与其它系统比较一下就知道。因为MIPS平台被OEM
得最广,在嵌入式领域应用最多(相对其它几种CPU而言)。甚至同一种MIPS芯片被不同
厂家封装再配上不同的芯片组。因此要为这些不同的MIPS平台分别编写不同的代码。
* 特殊结构代码:如多处理器支持等。其实每一种CPU都是十分特殊的,熟悉x86平台的
人都知道x86系列CPU著名的实模式与虚模式的区别,而在SPARC平台上根本就没有这个概
念。这就导致了很大的不同:PC机上的Linux在获得控制权后不久就开始切换到虚模式,
SPARC机器上则没有这段代码。又如电源管理的支持更是多种多样,不同的CPU有着不同
的实现方式(特殊的电源管理方式甚至被厂商标榜)。在这种情况下,除非放弃对电源
管理的支持,否则必须重写代码。
还有一部分代码量不多,但不能忽视的部分是在arch/xxx/mm/下的内存管理部分。
所有与平台相关的内存管理代码全部在这里。这部分代码完成内存的初始化和各种与内
存管理相关的数据结构的建立。Linux使用了基于页式管理的虚拟存储技术,而CPU发展
的趋势是:为了提高性能,实现内存管理的功能单元统统被集成到CPU中。因此内存管理
成为一个与CPU十分相关的工作。同时内存管理的效率也是最影响系统性能的因素之一。
内存可以说是计算机系统中最频繁访问的设备,如果每次内存访问时多占用一个时钟周
期,那就有可能将系统性能降低到不可忍受。在Linux系统里,不同平台上的内存管理代
码的差异程度是令人吃惊的,可以说是差异最大的。不同的CPU有不同的内存管理方式,
同一种CPU还会有不同的内存管理模式。Linux是从32位硬件平台上发展起来的操作系统
,但是现在已经有数种64位平台出现。在64位平台上,可用内存范围增大到原来的232倍
,其间差异可略窥一斑了。鉴于这部分代码的重要性和复杂性,移植工作在这里变得相
当谨慎。有些平台上甚至只是用最保守的内存管理模式。如在SPARC平台上的页面大小可
以是多种尺寸,为了简单和可靠起见,SPARC版的Linux只是用了8K页面这一种模式。这
一状况直到2.4版才得以改善。
除了上面所讲的之外,还有一些代码需要考虑,但相对来说次要一些。如浮点运算
的支持。较完美的做法是对FPU编程,由硬件完成浮点运算。但在某些时候,浮点并不重
要,甚至CPU根本就不支持浮点。这时候就可以根据需求来取舍。
对于内核移植的讨论到此为止。实际上,还有一些移植工作需要同时考虑,但很难
说这是属于内核范畴还是属于驱动程序范畴,比如说显示设备的支持,和内核十分相关
,但在逻辑上又不属于内核,并且在移植上也更像是驱动程序的开发。因此不在这里讨
论。
(2)系统移植
当内核移植完毕后,可以说所有的移植工作就已经完成大半了。就是说,当内核在
交叉编译成功后,加载到目标平台上正常启动,并出现类似VFS: Can抰 mount root fi
le system的提示时,则表示可以开始系统移植方面的工作了。系统移植实际上是一个最
小系统的重建过程。许多Linux爱好者有过建立Linux系统应急盘的经验,与其不同的是
,你需要使用目标平台上的二进制代码生成这个最小系统。包括:init、libc库、驱动
模块、必需的应用程序和系统配置脚本。一旦这些工作完成,移植工作就进入联调阶段
了。
一个比较容易的系统部分移植办法是:先着手建立开发平台上的最小系统,保证这
套最小系统在开发平台上正确运行。这样可以避免由于最小系统本身的逻辑错误而带来
的麻烦。由于最小系统中是多个应用程序相互配合工作,有时出现的问题不在代码本身
而在系统的逻辑结构上。
Linux系统移植工作至少要包括上述的内容,除此之外,有一些看不见的开发工作也
是不可忽视的,如某个特殊设备的驱动程序,为调试内核而做的远程调试工作等。另外
,同样的一次移植工作,显然符合最小功能集的移植和完美移植是不一样的;向16位移
植和向64位移植也是不一样的。
在移植中通常会遇见的问题是试运行时锁死或崩溃,在系统部分移植时要好办些,
因为可以容易地定位错误根源,而在核心移植时确实很让人头疼。虽然可以通过串口对
运行着的内核进行调试,但是在多任务情况下,有很多现象是不可重现的。又如,在初
始化的开始,很多设备还没法确定状态,甚至串口还没有初始化。对于这种情况没有什
么很好的解决办法,好的开发/仿真平台很重要,另外要多增加反映系统运行状态的调试
代码;再者要吃透硬件平台的文档。硬件平台厂商的专业支持也是很重要的。
还有一点很重要:Linux本身是基于GPL的操作系统,移植时,可以充分发挥GPL的优
势,让更多的爱好者参与进来,向共同的目标前进。
展开全部
我们先看看移植是什么意思:指将植物移动到其他地点种植,后引申为将生命体或生命体的部分转移,将身体的某一部分,通过手术或其他途径迁移到同一个体或另一个体的特定部位。
我们再来看看嵌入式中的移植,我的程序在电脑上写好后,一般编译链接后在自己电脑(我们称之“通用PC机”)上运行。可我现在想把它搞到其它非通用PC机的CPU上运行,比如单片机,ARM,DSP,POWERPC等,把刚刚编译链接好,并运行在通用PC机上的程序直接写到这些嵌入式CPU上能运行吗?当然不能,这样做好比移植松树时,只把已长出来的树枝或树干砍到另一地方种下,结果是活不成。必须得要有树根,我们程序的源码就是树根,我们用一种特殊的编译器编译源码并链接成可执行二进制文件,这个程序就能拿到相应的CPU上去跑了,当然,这时这个程序不能在通用PC上运行。这种特殊的编译器在通用PC机上运行,但编译的程序运行于其它CPU,我们一般称为交叉编译器。
程序推广到系统,则相应的有了”移植系统“,如移植linux操作系统。
希望对你有帮助!
我们再来看看嵌入式中的移植,我的程序在电脑上写好后,一般编译链接后在自己电脑(我们称之“通用PC机”)上运行。可我现在想把它搞到其它非通用PC机的CPU上运行,比如单片机,ARM,DSP,POWERPC等,把刚刚编译链接好,并运行在通用PC机上的程序直接写到这些嵌入式CPU上能运行吗?当然不能,这样做好比移植松树时,只把已长出来的树枝或树干砍到另一地方种下,结果是活不成。必须得要有树根,我们程序的源码就是树根,我们用一种特殊的编译器编译源码并链接成可执行二进制文件,这个程序就能拿到相应的CPU上去跑了,当然,这时这个程序不能在通用PC上运行。这种特殊的编译器在通用PC机上运行,但编译的程序运行于其它CPU,我们一般称为交叉编译器。
程序推广到系统,则相应的有了”移植系统“,如移植linux操作系统。
希望对你有帮助!
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
展开全部
由于嵌入式系统所使用的芯片型号多种多样,很多芯片不能直接兼容,所以通过修改部分代码,把能在甲芯片上运行的程序,也能在与之不完 全兼容的乙芯片上正确运行,就叫移植.
系统移植的概念也差不多,只是涉及到的芯片可能更多而已.
这个也可以通过计算机主板驱动来理解,往往不能的操作系统会有不同的驱动程序,不同的芯片组也有不同的驱动程序,但这些驱动程序的核心操作是一样的,只需要修改少数地方,就可以把适用于A系统的驱动,改为适用于B系统的驱动
系统移植的概念也差不多,只是涉及到的芯片可能更多而已.
这个也可以通过计算机主板驱动来理解,往往不能的操作系统会有不同的驱动程序,不同的芯片组也有不同的驱动程序,但这些驱动程序的核心操作是一样的,只需要修改少数地方,就可以把适用于A系统的驱动,改为适用于B系统的驱动
本回答被网友采纳
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
推荐律师服务:
若未解决您的问题,请您详细描述您的问题,通过百度律临进行免费专业咨询