本文来自：http://blog.chinaunix.net/u2/66786/showart.php?id=601766
1.1史前的PIC
8259A是即我们通常说的PIC，如图1-1所示：
 
图1-1 8259A
其中最重要的管脚是IR0~IR7（Interrupt Request0~7，用于连接设备）、INT（连接CPU,当有中断请求时，拉高该管脚以通知CPU中断的到来）、INTA（连接CPU，CPU通过该管脚应答中断请求，并通知PIC提交中断的vector到数据线）。此外，由于一片8259A只能连接8个设备，对于现代PC架构来说显得过少，通常会通过CS（片选）将两个8259A连在一起构成一个可以连接15个设备（有一个管脚用于串联另一片8259A）的PIC。
既然是可编程的芯片，8259A当然少不了寄存器。除了ICW（Initialization Command Word，初始化命令寄存器，用于初始化8259A）和OCW（Operation Command Word，操作命令字，用于控制8259A）外，最重要的有3个寄存器：
u       IRR：Interrupt Request Register，中断请求寄存器，共8bit，对应IR0~IR7八个中断管脚。当某个管脚的中断请求到来后，若该管脚没有被屏蔽，IRR中对应的bit被置一。表示PIC已经收到设备的中断请求，但还未提交给CPU。
u       ......

1.2现代的APIC
APIC虽号称现代，但也出现10几年了，PC机市场总是很晚才能接触到新的技术，前面说了，我的T42用的还是PIC呢。APIC相较于PIC来说，最大的优点是能适用于MP平台，当然，管脚多是它另一个优点。APIC由两部分组成，一个称为LAPIC（Local APIC，本地高级中断控制器），一个称为IOAPIC（I/O APCI，I/O高级中断控制器）。前者位于CPU中，在MP平台，每个CPU都有一个自己的LAPIC。后者通常位于南桥上，像PIC一样，连接各个产生中断的设备。在一个典型的具有多个处理器的PC平台，通常有一个IOAPIC和多个LAPIC，它们相互配合，形成一个中断的分发网络，图1-3显示了这个典型的情况：
图1-3 APIC模式（摘自《深入理解Linux内核》）
图中的中断控制器通信总线，是IOAPIC和LAPIC通信的桥梁，在Intel的P6架构和Pentium系列CPU中，它是一条单独的APIC总线。时代在进步，Pentium4和Xeon系列CPU出现后，APIC Bus已经不存在，系统的前端总线代替了它。
1.2.1 IOAPIC
话分两头，让我们先来看看IOAPIC。和PIC对比，IOAPIC最大的作用在于中断分发。根据其内部的PRT（Programmable Redirection Table）表，IOAPIC可以格式化出一条中断消息，发送给某个CPU的LAPIC，由LAPIC通知CPU进 ......

1.2.2 LAPIC
收到来自IOAPIC的中断消息后，LAPIC会将该中断交由CPU处理。和IOAPIC比较，LAPIC具有更多的寄存器以及更复杂的机制。但对于处理来自IOAPIC的中断消息，最重要的寄存器还是IRR、ISR以及EOI。
图1-4显示了x86平台上，IRR和ISR的格式：
 
图1-4 IRR、ISR构成
与PIC中的IRR、ISR不同的是，LAPIC的ISR、IRR均为256bit寄存器，对应x86平台上的256个中断vector，其中0~15为架构预留。
u       IRR：功能和PIC的类似，代表LAPIC已接收中断，但还未交CPU处理。
u       ISR：功能和PIC类似，代表CPU已开始处理中断，但还未完成。与PIC有所不同的是，当CPU正在处理某中断时，同类型中断如果发生，相应的IRR bit会再次置一（PIC模式下，同类型的中断被屏蔽）；如果某中断被pending在IRR中，同类型的中断发生，则ISR中相应的bit被置一。这说明在APIC系统中，同一类型中断最多可以被计数两次（想不通什么意思？想不通就联想一下Linux可信信号）。超过两次时，不同架构处理不一样。对于Pentium系列CPU和P6架构，中断消息被LAPIC拒绝；对于Pentium4和Xeon系列，新来的中断和IRR中对应的bit重叠。
笔 ......

  今天终于把OmapL137的板子跑起了Linux和其带的demo。合众达对这个板子东西做的很少，把omapl137的特点都没有展示出来。可就苦了我们这些想要用这个片子的人了。国内玩这个的人还不多，所有资料就硬着头皮慢慢磨吧。
前段时间uboot是由dsp那边用nandwrite工程写进来的，其校验方式和uboot的ecc校验似乎有冲突，uboot老报错，最后去掉ecc后才能写入env。uImage的烧写在uboot没有去掉ecc校验之前，虽然能够写进去，但是相应参数无法保存，uboot不知道去哪里找uImage，最后去掉ecc校验后就Ok 了。合众达提供的uImage似乎没有加入热拔插的支持，所以把文件系统烧入NandFlash后，启动跟文件系统时会有以下报错：/etc/init.d/rcS: line 26: can't create /proc/sys/kernel/hotplug: Permission denied。打开/etc/init.d/rcS可以看到在26行： echo /sbin/mdev > /proc/sys/kernel/hotplug。这是个支持热拔插的命令好像是内核不支持热拔插引起的吧，但是在加载nfs时却没有这样的报错，不清楚是为什么。有待研究。
在qtembedded例子中，没有激活触摸屏，需要进一步确认是否有触摸屏的驱动。 ......

嵌入式Linux启动分为两个部分，系统引导与Linux启动。系统引导将完成Linux装入内存前，初始化CPU和相关I/O设备，并将Linux调入内存的工作。系统引导主要由BootLoader实现。在BootLoader将Linux内核调入内存之后，将权力交给LinuxKernel，进入Linux的启动部分。以下详细分析启动的过程与使用的文件。
一、系统引导与BootLoader
        BootLoader因嵌入式系统的不同与PC机有很大不同，这里将以Hyper250(Inter Xscale GDPXA250)的启动为例来分析。由于没有BIOS驱动主板，EnbeddedOS必须由bootloader驱动所有的硬件，并完成硬件的初始化工作。
        所有的初始化文件在hyper250/Bootloader目录下。
       
        首先分析开机运行的分件：
                hyper250/Bootloader/X-Hyper250R1.1-Boot/src/start_xscale.S
        文件包含两个库文件：
      &nb ......

今天拷贝了虚拟机在另外一台电脑上使用，发现MAC地址冲突，于是去网上找修改方法。可按照所说的，我并没有很顺利修改成功。
下面我将过程写出来，里面有些地方需要注意一下。
下面是我从网上搜索到大部分的做法如下，红色部分是我注释的，需要注意的地方：
VMware虚拟机中修改Linux MAC地址的方法：
1、修改虚拟机的*.vmx文件.
这种方法最值得推荐，因为这样就类似于重新“烧录”了VMware虚拟机的“物理网卡ROM”。
方法是：
分两种情况：
a：
ethernet0.addressType="static"
ethernet0.Address="00:50:56:0A:0B:0C"
"static"说明VM的"物理网卡"的MAC是静态设定的，你可以改成一个以005056开头的另外一个MAC即可。改完启动VM时如果问你SSID的话，选择“KeepAlways”。
这种方法我没有试验成功，严格按照这个方法修改都一直未修改成功，我也不知道为什么，如果有人知道为什么请告诉我，谢谢！
b：
ethernet0.addressType="generated"
uuid.location="564ddcf1ffaa75ea-f1b9ee0d689c655c"
uuid.bios="564ded23138c9691-7c68b2098baabbcc"
ethernet0.generatedAddress="00:0c:29:aa:bb:cc"
"generated"说明VM的"物理网卡"的MAC ......