如何移植电脑系统-怎样移植电脑系统

1.移植操作系统时需要修改操作系统中与处理器直接相关的程序吗

2.买了新的SSD，如何将现有电脑系统移植到新固态硬盘上？

3.有关单片机移植操作系统。

4.嵌入式中的移植是什么意思，移植系统呢

移植操作系统时需要修改操作系统中与处理器直接相关的程序吗

主要修改地方就是显示部分与输入部分,运行过程与算法基本上不需要修改.

1.要了解一下你这个应用程序的内存开销和代码大小

2.输入输出有那些量;

3.根据1,2情况选取合适的硬件处理器;

4.修改显示和输入部分代码

5.调试完善

嵌入式操作系统与通用操作系统的最显著的区别之一就是它的可移植性。 一款嵌入式操作系统通常可以运行在不同体系结构的处理器和开发板上。为了使嵌入式操作系统可以在某款具体的目标设备上运行，嵌入式操作系统的编写者通常无法一次性完成整个操作系统的代码，而必须把一部分与具体硬件设备相关的代码作为抽象的接口保留出来，让提供硬件的OEM厂商来完成。这样才可以保证整个操作系统的可移植性。这些代码通常是板级支持包(Board Support Package, BSP)的一部分。 例如：不同处理器和开发板通常都会提供实时钟支持，用来得到当前的时间日期，但是实时钟的实现方式却不胜枚举。如何告诉嵌入式操作系统当前的时间，就是操作系统移植者要完成的任务了。 系统移植人员不但要对嵌入式操作系统提供的接口了如指掌，还要对操作系统运行的硬件有极为深入的了解，此类开发人员可能同时会身兼软件工程师和硬件工程师的双重身份mdash;mdash;让嵌入式操作系统在自己设计的硬件平台上运行起来。 查看更多答案>>

麻烦采纳，谢谢!

买了新的SSD，如何将现有电脑系统移植到新固态硬盘上？

用gho备份现在的系统到U盘上（8GBHUO

32GB的），当然最好之前这个U盘也是系统启动盘，然后在给ssd安装系统之前，最好把原硬盘拔掉数据线在gho到ssd上。这样就可减少硬盘出错的几率。

有关单片机移植操作系统。

操作系统，是个庞然大物，但是大家都很喜欢，因为他能帮你做很多你不愿意面对的事。他能提供很好的底部的支持。就说楼上举的QQ的例子吧，QQ就是一款软件，你往对话框里写字，然后通过网络传到另一台用户端。如果你有操作系统，你跟操作系统说，我要个窗户，他就给你窗户，我要联网，改一改IP你就能上网了。中间的网络协议也不要你管了，什么TCP IP也不用你看的吐血了。

要是没有操作系统，你要生成一个对话框？只有你自己一条一条代码的写了，对话框写进去的字，你自己想办法变成文件，自己想办法打包，使之符合网络协议，自己做网孔，自己通信吧。

那感觉就是你要生火，一个人说（操作系统），我有打火机，你自己用。另一个说（没有操作系统），我这有铁矿，还有天然气矿，都给你了，你想做什么打火机都可以。

说到这里，两者的差别就很好说了。

1.操作系统是很方便，提供打火机耶！前提是你要开个小卖部，你才有打火机提供你丫。小卖部很占地方的！这里就会无情的占用你单片机少的可怜的地方，一般单片机可以存储的程序不会超过1M（外接存储设备的除外），而一个未裁剪的LINUX系统，200M，即使裁剪了，大小可能远远大于你能承受的范围，再者为了买一个打火机，你建一小卖部，不是吃多了么！

2.单片机提供的东西很少，只有原始材料，如果你要生火，做个打火机，的确困难了点。转木取火这时候就比较现实了。至少比建个小卖部好吧！

说这么多，看问题。

1.装上了操作系统（比如linux、uc/os-2、winCE等），与不装操作系统最大的区别是什么？

装了，你就是建了小卖部，占的地方大，如果你需要的功能很小，完全是白费力，还不如转木取火。

没装，你就是转木取火，占地少，找个角落一蹲，默默操作去吧。

2.也就是说，装上了系统，能实现什么更多的功能？

这是当然的，小卖部，绝对不止卖打火机，什么时候你要酱油了，跟老板说声，老板马上进货，

你要是单片机，孩子，火生好了，自己找个配方，自己配酱油去。

3.如果说完成了一个项目，如果这个项目以后的功能需要扩展，装上了系统的单片机对于不装系统的单片机来说有什么优势？

小卖部有了，最开始卖打火机，后来又卖酱油，以后你万一再要什么（功能扩展），跟老板说一句就好了。

要是单片机，酱油配好了，我还想要白糖呢。你给我种甘蔗去。

总结：如果是一个巨大的项目，操作系统是必备的，他能提供很多支持，做很多基层的工作，方便以后的升级。但是他的维护和他所消耗的资源（空间），也成为了它在单片机领域推广的致命伤。所以相反的如果你只要某个功能（生火），不装操作系统明显方便，而且易于维护（木头棒子坏了，再找一根呗！），如果你要这要那，我的天，我宁愿造个小卖部。

嵌入式中的移植是什么意思，移植系统呢

与其它操作系统相比，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的优

势，让更多的爱好者参与进来，向共同的目标前进。