【NanoPi2试用体验】-6 S5PV4418的启动过程分析-（结合原理图&datasheet)

众所周知，学习任何开发语言，大家写的第一个程序总是“Hello world”，打印出了这个字符串，也就证明，这个编译环境、语言的语法都没问题了。

从此也就开始了苦逼的码农生涯。

从51时代，写程序总是先是从写裸机代码开始，一般都是从点亮led开始，让它跑闪烁、跑走马灯，这就是俗称的点灯大法。

即使进入到ARM+os时代，程序员们养成的这个习惯也没有改变，就像学习语言时代打印的那行“hello world”。

最近看大家在应用上玩的五花八门、妙招叠出的，我也有点着急了。早想就移植个上层应用，或者拷贝个app上去演示一下了。那不符合我的性格，因为我的还有东西没交代完。

本来我的初衷是看看s5pv4418这颗心到底有多强大。所以裸机开发避免不了。

那裸机开发从哪里开始？点灯大法。

哟呵！都知道啊！那下一个问题，你就不得都知道了吧！

要点灯了，我们的cpu从哪里开始执行的？我们怎么才能让这颗4核的心裸奔起来！

咳咳！天空飘过五个字，那都不是事！

为什么我这么有底气？

因为咱有九阳真经啊！

老规矩先上图，

去datasheet看第14章第3节。

内存映像图。

眼尖的一下就看到了。

对了，这就是s5pv4418的内存分布图。

有了它，好多后面介绍的内容会迎刃而解。

什么？看不懂，那没关系！我也看不大懂。

在那就先这些术语混个脸熟就行了。

知道有sdram和nand flash之类的static之类的区分就行了

认识一下什么internal SRAM,0XFFFF0000，internalrom，0x34000000，static#0static#1…….

好了，铺垫完了，开始进入正题。

通过上一篇文章的分析，我们知道了，通过电路板上的硬件引脚配置，s5pv4418支持从u***、uart、spi eeprom、sdhc、nand引导。硬件配置是硬件开发人员设置好了的。板子已经生产出来，就定死了。

那么，后面的事情就全部交给软件了，由软件来引导硬件开始工作。

到底哪个硬件来完成这么神圣而伟大的使命呢？

内存，rom，sram，sd，nand。。。。。。

毫无头绪，一团浆糊。

别急，慢慢来。

根据我们以前玩三星开发板的经验，应该有个bootloader 来干这个苦差事。

玩过4412的朋友肯定有印象，4412这货有个内部bootlaoder，叫做irom的，由他来执行系统上电后的第一行代码的执行工作。让后他找到BL1，执行BL1，执行权交给BL1。再由BL1找到BL2，执行权交给BL2，由BL2在加载os，再把执行权交给os。

那我们的4418呢？和4412会是一样的吗？

循着4412的思路，我们打开datasheet，O ,Mygod！在第三章第4节还真有irom的描述。

怎一个爽字了得！

虽然英语很烂，还是要硬着头皮翻译一下，要不很难说明问题。大意是 4418有20k的内部rom，就是我们简称的irom。它可以通过系统配置CfgBOOTMODE“3-7”设置为0地址。复位后，4418执行从0地址取出的irom中的指令。Irom中有代码支持各种引导模式。这段代码执行它从各种介质读取的用户引导代码并把它拷贝到指定的内存地址。这个引导模式就被定义为内部rom引导模式，即IROMBOOT.

特征如下：

IROMBOOT.使用内部SRAM存储堆栈数据。因此IROMBOOT被执行后，内部sram的数据可能被改变。

IROMBOOT支持u***、uart、spi eeprom、sdhc、nand共5种引导模式。

IROMBOOT支持不带MMU的os异常向量重定向。

IROMBOOT支持 快速电源控制。

IROMBOOT支持u***、uart、spi eeprom、sdhc、nand（带错误效验）共5种引导模式。每种引导模式都支持来自SD[15：0]HE1SDEX[7：0]的复位状态标志位指示的引导方式。

根据前面的分析，我们知道小pi2 是从SD卡引导的。

下面我们就来看看它的引导过程。

这种引导模式，在datasheet中被称为：SDHC模式。

从图上不难看出：

板子上电复位后，IROM执行，从sdhc #0模块从存储介质里面读出 user bootlaoder 并拷贝到内部sram里面。

具体是如何实现的呢？还是接着看datasheet图：

当CfgSDHCBM=0或者eMMC引导失败的时候。常规的SDMMC引导开始执行。

--系统进入idle

--SDHCBOOT识别引导介质类型并初始化

--引导介质被改成数据传输模式

--SDHCBOOT通过CfgPARATION选择分区

--SDHCBOOT从Sector #1 读取用户引导代码，并把它拷贝到SRAM中执行。

至此，进入到用户自己的引导代码中。

  由此得出一个结论：我们的SDHCBOOT是存放在sd卡的第一号扇区的。

那这个地方存的是什么东西呢？这里

先卖个关子，后面在揭开谜底。

在介绍一下sd卡的通讯方式。

我们知道sd卡的通讯协议分为2种：sd模式和spi模式。

那我们的小pi2采用的什么模式呢？

看图，九阴真经在手，想要啥啊都有！

看到了吧！六根线全部用到了，典型的sd模式。

想想也能理解，sd里面存放的可是咱们的引导程序和操作系统啊！如果采用spi，那速度上说不过去。

硬件攻城狮还不得被嘲笑死了！

知道这个干什么？当然是为了分析sd卡上的文件做准备啊！

那么问题来了，SD卡上到底存放了什么东西呢？

要先知道这个问题，我们看看友善的攻城狮都对我们可怜的小SD干了些什么？

友善的攻城狮在下载好android的镜像后，他们干了这些事：

> tar xzvf android-lollipop-images.tgz-C android

boot.img

system.img

userdata.img

cache.img

partmap.txt

---------------------------------

2ndboot fusing

记录了32+0 的读入

记录了32+0 的写出

16384字节(16 kB)已复制，0.0733637 秒，223 kB/秒

---------------------------------

bootloader fusing

记录了1+0 的读入

记录了1+0 的写出

512字节(512 B)已复制，0.0610677 秒，8.4 kB/秒

记录了479+1 的读入

记录了479+1 的写出

245580字节(246 kB)已复制，0.508966 秒，483 kB/秒

---------------------------------

Bootloader image is fused successfully.

---------------------------------

Android filesystem fusing

Image root: ./android

Writing environment to /dev/sdb...

Done

-----------------------------------------------------------------------------

[/dev/sdb] capacity = 7580MB, 7948206080bytes

current /dev/sdb partition:

MBR.0 start : 0x0000100000 size0x0004000000  kB

MBR.1 start : 0x0004100000 size0x00e4654400  kB

-----------------------------------------------------------------------------

parsing ./android/partmap.txt:

part.0flash=mmc,0:2ndboot:2nd:0x200,0x8e00::[RAW]

part.1flash=mmc,0:bootloader:boot:0x8000,0x77000::[RAW]

part.2flash=mmc,0:boot:fat:0x100000,0x4000000:boot.img:[MBR] ./android/boot.img

part.3flash=mmc,0:system:ext4:0x4100000,0x2f200000:system.img:[MBR]./android/system.img

part.4flash=mmc,0:cache:ext4:0x33300000,0x1ac00000:cache.img:[MBR]./android/cache.img

part.5flash=mmc,0:misc:emmc:0x4e000000,0x800000::[MBR]

part.6flash=mmc,0:recovery:emmc:0x4e900000,0x1600000::[MBR]

part.7flash=mmc,0:userdata:ext4:0x50000000,0x0:userdata.img:[MBR]./android/userdata.img

-----------------------------------------------------------------------------

create new MBR 6:

[MBR.0] start : 0x0000100000 size0x0004000000

[MBR.1] start : 0x0004100000 size0x002f200000

[MBR.2] start : 0x0033300000 size0x001ac00000

[MBR.3] start : 0x004e000000 size0x0000800000

[MBR.4] start : 0x004e900000 size0x0001600000

[MBR.5] start : 0x0050000000 size0x0000000000

-----------------------------------------------------------------------------

copy from: ./android to /dev/sdb

[MBR.0] part.2 start : 0x100000 size0x4000000 (0xcc80dc) : ./android/boot.img : done.

[MBR.1] part.3 start : 0x4100000 size0x2f200000 (0x1d7c2450) : ./android/system.img : done.

[MBR.2] part.4 start : 0x33300000 size0x1ac00000 (0x88c130) : ./android/cache.img : done.

[MBR.5] part.7 start : 0x50000000 size0x189c00000 (0x27a6328) : ./android/userdata.img : done.

-----------------------------------------------------------------------------

/dev/sdb: msdos partitions 1 2 3 4 <5 67>

Update ext4fs for Android on/dev/sdb...

==> Executing: 'tune2fs /dev/sdb1 -U86086767-8164-4be2-ae49-540c967fc0bb -L boot'

tune2fs 1.42.9 (4-Feb-2014)

==> Executing: 'tune2fs /dev/sdb2 -U97d5a066-38c4-4f76-a2c4-c6549b111764 -L system'

tune2fs 1.42.9 (4-Feb-2014)

==> Executing: 'tune2fs /dev/sdb3 -U2e69d9ef-0a95-417d-a05c-23b3c5a3481e -L cache'

tune2fs 1.42.9 (4-Feb-2014)

==> Executing: 'resize2fs /dev/sdb7 -f'

resize2fs 1.42.9 (4-Feb-2014)

Resizing the filesystem on /dev/sdb7 to1612800 (4k) blocks.

The filesystem on /dev/sdb7 is now 1612800blocks long.

==> Executing: 'tune2fs /dev/sdb7 -U9eaee93a-85cf-4a93-a946-8f09e5a4e3a4 -L userdata'

tune2fs 1.42.9 (4-Feb-2014)

...done.

---------------------------------

Android is fused successfully.

All done.

看到好色标记的部分了吧，sd卡上的镜像分布图：

按照先后顺序执行了

2ndboot fusing

bootloader fusing

Android filesystem fusing

由此产生的结果是：

镜像分布是：

part.0 flash=mmc,0:2ndboot:2nd:         0x200,               0x8e00:                           :   [RAW]

part.1 flash=mmc,0:bootloader:boot:    0x8000,             0x77000:                         :   [RAW]

part.2 flash=mmc,0:boot:fat:                 0x100000,         0x4000000:    boot.img   :  [MBR] ./android/boot.img

part.3 flash=mmc,0:system:ext4:           0x4100000,       0x2f200000:  system.img:   [MBR] ./android/system.img

part.4 flash=mmc,0:cache:ext4:              0x33300000,    0x1ac00000:  cache.img :   [MBR]./android/cache.img

part.5 flash=mmc,0:misc:emmc:             0x4e000000,    0x800000:                       :   [MBR]

part.6 flash=mmc,0:recovery:emmc:       0x4e900000,   0x1600000:                     :   [MBR]

part.7 flash=mmc,0:userdata:ext4:          0x50000000,    0x0 :         userdata.img   :  [MBR] ./android/userdata.img

  |（ 留下这些红色的记忆吧！将来有用。）

由此可知，sd卡上第 2块的位置上存放的是2ndboot。

那细心的人要问了为什么不是第一个块的位置啊？

你别忘了，SD卡是一个存储设备，根据以往的经验，存储设备一定要有个存放本身如何分区等信息的地方，这个地方最方便的位置就是第1个块，它存放的是sd卡的分区信息，类似硬盘分区表的信息。别问我为什么这样搞，这是专家定的。

还记得前面第二个图中的说明吗？就是关于sector#1的那一段，忘了的翻回去看看。

由于它是三星官方未公开源码的引导程序，所以我们无从知道他的源代码。

我们知道它的作用是把Iternal ROM中的程序加载到Internal SRAMM中并执行就够了。

在我们的小pi2方案中，2ndboot程序将SD卡里的数据从Block1开始拷贝到Internal SRAM并执行。

执行后把我们的u_boot在加载到ram中，然后把控制权交给u_boot.在由uboot来装载OS,并把控制权交给os。

完事了，折腾真么半天，就几句话就完事了。好无聊啊。

有细细读者可能会说，喂喂，说好的分析datasheet呢？

嘿嘿！没有拿datasheet讲解的真实原因是：我在datashaeet里面就没有找到关于引导更详细的资料，不知道是三星没放出来，还是什么原因。

想想友善的攻城狮比我聪明，另外小pi2明明白白的在那里运行着呢！

所以直接看他们的分析成果不是更省事吗？

哎哎！你说啥呢？这怎么能叫投机取巧呢？

这叫站在巨人的肩膀上，爬得更高而已！

好了，有了这些分析，我们就有可以为所欲为了！

悟空，你又淘气了！这怎么能叫胡来呢？

到底咱想干什么，且下先回分解！

赞一个，写的挺不错的，刚开始学，感觉启动特别乱，老是记不太清楚！

多谢回帖，慢慢来吧，我也是边查资料，边验证，边写帖子的。欢迎进群多交流

受教了，谢谢楼主，我的是nanopi m3的板子，自己买的，就是资料不多，我把你的上一篇帖子对照我的m3研究了一天，发现m3的也是改不了启动方式（我觉得应该能改，就是没看到其他人弄过）。================================
=
================================
楼主，我想请教一下，如果没有tf或者sd卡能启动吗？
我的卡已经被烧坏了（冒烟了），有没有其他的启动方法能试试的？