没有什么前因后果，就是有空拿出几片屏幕玩玩。都是典型的无控制器STN单色液晶，反正程序也是以前用过很多次的，再拿出来用用。第一片是LM081HB1T，8.1英寸640x240 STN负显，其实以前也点过，但是一直没仔细点亮背光看过效果，这次也是拿出来拍拍照。由于STM32F1的RAM容量限制（64KB），我只能使用320x240x4bit模式或者640x240x3bit模式。头图就是全分辨率的效果。
于是拿之前一直在用的程序拿来点了一下，效果如头图。（第二块屏幕请点详情）
没有什么前因后果，就是有空拿出几片屏幕玩玩。都是典型的无控制器STN单色液晶，反正程序也是以前用过很多次的，再拿出来用用。第一片是LM081HB1T，8.1英寸640x240 STN负显，其实以前也点过，但是一直没仔细点亮背光看过效果，这次也是拿出来拍拍照。由于STM32F1的RAM容量限制（64KB），我只能使用320x240x4bit模式或者640x240x3bit模式。头图就是全分辨率的效果。
于是拿之前一直在用的程序拿来点了一下，效果如头图。（第二块屏幕请点详情）
在上一篇中，我已经给KPW2焊上了新的8GB eMMC，并且验证了通过MfgTools直接把U-Boot加载到内存中运行是可行的，这次就完成主板的修复。
其实在上一步完成时，U-Boot的启动记录是这样的：
Board: Unknown Boot Reason: [ POR ] Boot Device: NAND Board Id: S/N: I2C: ready Invaild board id! Can't determine system type for RAM init.. bailing! DRAM: 0 kB Using default environment
这是因为换上全新的eMMC，KPW2也就像失忆了一样，忘记了一些比如自己的型号之类的重要参数以至于无法顺利初始化RAM……这里是我的失误，实际上在拆除原来的eMMC前，应该在U-Boot中输入idme查看NVRAM变量并记录下来（注：虽然名为NVRAM变量，但是实际上是存储在eMMC当中的）。但是我没有做过，所以现在只能自己恢复。在U-Boot中输入idme可以看见一共有5个变量，分别为serial、mac、sec、pcbsn、bootmode和postmode。只要恢复serial mac pcbsn并把其它清空即可。serial是机器的序列号，在“Kindle需要维修的界面”或者包装盒上有写，但是据说会不一样，我是按照需要维修界面上的DSN填写的（使用idme serial XXXXX命令设置）。MAC地址在包装盒上是没有写的，如果要找回可能需要登陆路由器管理界面看下DHCP分配，如果Kindle连接过WiFi应该有记录。如果没有，那么就随便编一个吧，比如把自己电脑的MAC地址+1然后写上去。pcbsn可以在主板的贴纸上找到，如下图：
注：本记录并非教程！操作前请确定你清楚自己在做什么！
起因呢，大致就是@ntzyz有天发现他的Kindle Paperwhite 2（下文简称KPW2）复制不进东西了（复制到一半出错），重刷系统也是因为一样的原因失败（没法完整复制刷机包），考虑到网上的救砖教程大多要求拆机飞线使用TTL串口操作，怕自己手残搞坏就寄给了我。随后折腾就开始了……
到手的时候发现完全开不开机，原来是没电了，先接上USB充电。大约半小时后尝试开机，卡死在大树界面，进度条走到30%或者70%卡住，接上电脑只会提示需要进行格式化，然而如果尝试格式化，则是格式化完成后复制不进东西，再次连接则是又提示需要格式化。其实这里已经基本猜到是eMMC坏了，但是还是先祈祷下不是那样，接上TTL看bootlog才能下定论。首先是拆机，Kindle的拆机不复杂，前面板是一片比较软的塑料片，可以撕下来。接着拧掉螺丝，角度合适就可以直接把后盖拿下来了。主板上不难发现在三个未焊接的按键焊盘上方有一个3脚的连接器焊盘：
最近在研究HP 39gs的裸跑问题，之前一直用的Keil RealView MDK，然而由于个人喜好问题，想把工程移植到IAR Embedded Workbench上。网上2410/2440+IAR裸跑的先例不多，质量参差不齐，于是我就参考MDK的官方2410启动文件以及IAR的官方某ARM7启动文件重新写了一份，拿出来和大家分享以下，也算是加深一下对ARM启动过程的认识。
在解决启动代码问题之前，首先要写一份icf文件，这个是IAR独有的一种配置文件，MDK下是直接在工程选项里面设置的。这个ICF一般不用关注太多内容，按照以下模板修改即可。
/*###ICF### Section handled by ICF editor, don't touch! ****/
/*-Editor annotation file-*/
/* IcfEditorFile="$TOOLKIT_DIR$\config\ide\IcfEditor\a_v1_0.xml" */
/*-Specials-*/
define symbol __ICFEDIT_intvec_start__ = 0x00000000;
/*-Memory Regions-*/
define symbol __ICFEDIT_region_ROM_start__ = 0x00000000;
define symbol __ICFEDIT_region_ROM_end__ = 0x0007FFFF;
define symbol __ICFEDIT_region_RAM_start__ = 0x08000000;
define symbol __ICFEDIT_region_RAM_end__ = 0x08037FFF;
/*-Sizes-*/
define symbol __ICFEDIT_size_cstack__ = 0x2000;
define symbol __ICFEDIT_size_svcstack__ = 0x100;
define symbol __ICFEDIT_size_irqstack__ = 0x100;
define symbol __ICFEDIT_size_fiqstack__ = 0x100;
define symbol __ICFEDIT_size_undstack__ = 0x100;
define symbol __ICFEDIT_size_abtstack__ = 0x100;
define symbol __ICFEDIT_size_heap__ = 0x8000;
/**** End of ICF editor section. ###ICF###*/
define memory mem with size = 4G;
define region ROM_region = mem:[from __ICFEDIT_region_ROM_start__ to __ICFEDIT_region_ROM_end__];
define region RAM_region = mem:[from __ICFEDIT_region_RAM_start__ to __ICFEDIT_region_RAM_end__];
define block CSTACK with alignment = 8, size = __ICFEDIT_size_cstack__ { };
define block SVC_STACK with alignment = 8, size = __ICFEDIT_size_svcstack__ { };
define block IRQ_STACK with alignment = 8, size = __ICFEDIT_size_irqstack__ { };
define block FIQ_STACK with alignment = 8, size = __ICFEDIT_size_fiqstack__ { };
define block UND_STACK with alignment = 8, size = __ICFEDIT_size_undstack__ { };
define block ABT_STACK with alignment = 8, size = __ICFEDIT_size_abtstack__ { };
define block HEAP with alignment = 8, size = __ICFEDIT_size_heap__ { };
initialize by copy { readwrite };
do not initialize { section .noinit };
place at address mem:__ICFEDIT_intvec_start__ { readonly section .intvec };
place in ROM_region { readonly };
place in RAM_region { readwrite,
block CSTACK, block SVC_STACK, block IRQ_STACK, block FIQ_STACK,
block UND_STACK, block ABT_STACK, block HEAP };
需要修改的就是RAM、ROM的起始地址，注意比如这里ROM的容量为0x80000，那么ROM的终止地址应该为0x7FFFF而不是0x80000！（网上下载到的某开发板例程里面的ICF文件就犯了这个错误）另外如果自己有单独安排RAM的使用，比如LCD的Framebuffer、MMU的TranslationTable之类的，那么已经分配掉的部分不应该被写入这个范围。（某ICF又犯了错误）。然后上面的stack只要自己设置尺寸即可，不需要设定地址，linker会自动分配。
DPI（Display Pixel Interface），一般也被称为并行RGB接口。这类接口的信号很简单，16-24位的RGB数据线（刚好一个像素），行场同步信号，像素时钟信号，还有数据使能信号，就够了。主机需要不停的通过这个接口向液晶刷新显示数据，这个显示数据并非向DBI屏幕一样送向控制器内部的RAM，而是直接送向屏幕的行列驱动器驱动液晶面板，这样也就从根源上杜绝了出现上面那种糟糕情况的可能性。而且这样设计显示控制器里就无需集成RAM，成本可以更低。这类显示器其实非常常见，一般3.5 – 10.1英寸之间的屏幕都是用了这类的显示接口，一般的ARM微处理器也都会集成这种显示接口。包括第一种方案的HDMI显示器，基本都是把HDMI转换为DPI信号再驱动液晶，就连官方的DSI液晶其实也是使用了一片桥接芯片把DSI转换为DPI驱动了一块7英寸800*480的液晶。但是近几年这类接口也在逐渐遭到淘汰，一方面是因为3.3V的信号电平比较费电，另一方面则是这类接口由于干扰通常难以传输超过720p的信号。
在之前，树莓派官方没有提起过树莓派可以支持DPI液晶，很多爱好者也在抱怨缺少必要的液晶驱动接口，因为DBI效果差，DSI不可用，HDMI太贵。而就在去年，树梅派的官方博客上写了这么一款产品：Gert’s VGA adapter for Raspberry Pi。而且这个VGA转接板并非使用HDMI转VGA的方案，而是使用了GPIO接口，通过一些电阻（不难猜出是一个电阻网络实现的DAC）直接产生VGA信号，并且支持1080p，支持3D加速。考虑到VGA所具有的信号完全可以从DPI接口加个DAC来生成（事实上很多ARM9的开发板都使用了这种方法来实现VGA视频输出的功能），基本可以确定这个神奇的转接板就是使用了树梅派的DPI接口。
既然如此，那么把电阻网络去掉要驱动液晶也不是不可能了。目前树莓派社区已经开发出了完善的驱动方法，基本可以兼容各类DPI液晶。具体的讨论可见https://www.raspberrypi.org/forums/viewtopic.php?f=100&t=86658，这里感谢Gert van Loo开发的VGA转接板以及高通工程师Dom Cobley对VideoCore IV固件（不开源）的修改以及在树莓派社区中提供的支持，没有他们就不可能实现在树莓派上这类屏幕的驱动。以下就来讲讲一般情况下的使用方法。