6410 UBOOT 支持SD/SDHC卡启动 FAT32文件系统 yaffs2烧录 图片显示烧录状态

6410 UBOOT 支持SD/SDHC卡启动 FAT32文件系统  yaffs2烧录 图片显示烧录状态

开发板： 飞凌6410 256M DDR 2G nand (4K pagesize)

需要csdn帐号和资源分才可以下载，其它朋友有需要可以QQ 67016879 或 [email protected]

移植好的uboot下载地址：http://download.csdn.net/source/3561490

三星IROM boot 文档：http://download.csdn.net/source/3561602

烧录工具下载：http://download.csdn.net/source/3561492

Raw data bmp 转换工具（PIC2RAW）：http://www.mculee.cn/post/%E5%9B%BE%E7%89%87,bmp,raw,%E8%BD%AC%E6%8D%A2.html

移植说明：

1.支持SD/SDHC启动，相关文件:

include/confisg/smdk6410.h 定义  #define CONFIG_BOOT_MOVINAND 关掉 //#define CONFIG_BOOT_NAND

其它参考： cpu/s3c64xx/movi.c 主要功能是通过三星IROM code 函数CopyMMCtoMem(z,a,b,c,e) 拷贝BL2到DDR内存，

前8K（BL1）由CPU上电时自行拷贝，需要设置CPU启动跳线；

内存已经配置成256M了，飞凌提供的mmc.bin只支持128M（浪费了128M），烧大于126M的文件几乎很难烧录。

一般在加入越来越多的应用后，文件系统会越来越大，

最大文件支持为253M，uboot 2M（地址0x5FE00000） framebuffer 1M（0x5FD00000），

超过的话，可能需要改程序分块烧（目前uboot FAT不支持分块读文件）。

2.烧录bin到SD卡：

SD启动的bin文件会被分成BL1，BL2两块，移植好的uboot目录下有mkmovi脚本工具可以生成u-boot-movi.bin可供SD_Write.exe烧录；

也可以使用三星提供的IROM_Fusing_Tool工具（网上可以下载到源码，可以自己修改）烧录；

如果没有工具也可以使用WinHex工具直接写SD卡，注意SD ，SDHC写入的偏移不一样，都是写在SD尾部，

卡的块大小可通过IROM code 全局变量globalBlockSizeHide得到，

具体看三星IROM boot文档，这些uboot代码已经写好了；

到此，sd uboot 应该可以跑起来了，注意飞凌256M内存uboot中，include/configs/smdk6410.h文件

改了CFG_ENV_SIZE 的大小需要改回到0x4000，这个值会在include/movi.h中参与BL2地址的计算；

3.SD卡驱动：

cpu/s3c64xx/hs_mmc.c 此驱动文件比较旧，不支持SDHC卡和SD2.0协议，SD/MMC（2G或以下）可以；

需要修改初始化函数hsmmc_init（），

SD2.0初始化卡顺序

SD rest CMD0 -> SD_SEND_IF_COND CMD8 -> 选中SD ...    具体参考移植好的代码，

更详细可以搜索SD2.0协议

SDMA也有问题，它是大块一次读完，我测试当文件大于16M时，读取的数据就不正确了。需要修改movi_read（）函数，

改成每次按512Byte字节读，直到把block num读完为止，为什么要这样，我仔细看过datasheet，

原本程序应该也是没有问题，估计三星的SDMA没有做好或有BUG，网上也可以搜到，但不多。

4.uboot1.1.6的FAT文件系统支持：

fs/fat/fat.c 此文件也有BUG，读文件目录时有问题，去uboot官网下载最新代码，

替换fs/fat/fat.c 应该可以直接替换，我是用比较工具替换的；

支持FAT文件系统后，就可以将编译好的u-boot.bin,zImage,rootfs.yaffs2文件直接复制SD卡中（将SD卡格式化为FAT32），

可以使用 fatload mmc 0:1 0x50008000 u-boot.bin ; 首先将文件放到内存，再用 nand.write 命令烧写。

5.支持yaffs2烧录：

加入了nand write.yaffs 命令，这里一定要注意，yaffs文件直接烧录到nand中, kernel是不识别的（根本没有检测到文件数据），

因为yaffs文件是按 PageSize + OOB 格式存储的，OOB是用来识别文件信息的，直接烧录所以找不到文件。

还要注意mkyaffs2image工具生成的pagesize和oob一定要和uboot的对上，否则烧进去，也是白搭。

飞凌用的是K9GAG08U0D_2G 4K pagesize的nand，

需要修改 kernel/fs/yaffs2/utils/ mkyaffs2image.c

#define chunkSize 4096//2048
#define spareSize 128//64

如果使用其它mkyaffs2image.c版本，注意oob格式

关掉内核nand驱动ECC硬件检测

6.烧录uboot：

三星6410从nand启动时，控制器只支持2K pagesize，所以换成4K pagesize nand后，直接烧uboot后，

导致uboot跑不起来，可以将uboot分成每2K分别烧录4K page  size的每页，

可以参考这个牛人的方法：http://bbs.witech.com.cn/archiver/?tid-3743.html

本来想用IROM boot启动nand（直接支持4K Pagesize），

可是bin文件需要ECC校验（其实完全不需要的，nand第1个block是有保证的），否则启动不了，取消ECC也设置不了，

还没有找到写ECC的资料，就没有搞定；

后来还是增加了 nand write.uboot  命令，也是2K一烧，4K 一跳；

修改 commom/cmd_nand.c do_nand() 函数

7.LCD显示支持：

实际生产中，不可能每个工作人员接一台电脑用串口看烧录状态，

加入了 LCD显示烧录状态（6410支持5层windows framebuffer，我用了2层，0层背景，1层OSD同时显示串口打印信息，颜色用的565），

烧录状态显示的图片存放在SD卡中(burnIcon.bin 565 raw data bmp)，因为uboot很难存下480*272*2Byte的图片，烧录前nand也没法存图片，

存在SD卡是最好的。

烧录完成蜂呜器响10声。

common/lcd.c 

include/confisg/smdk6410.h 定义  #define CONFIG_LCD

修改void lcd_ctrl_init(void *lcdbase) LCD控制器时序

注意：图片的字节序，我用的565是小端（低字节在前），6410 LCD控制器默认是大端（高字节在前），所以要倒序否则图片显示有些不正常：

S3C_WINCON0 = S3C_WINCONx_BPPMODE_F_16BPP_565 |S3C_WINCONx_HAWSWP_ENABLE;

8.修改开机白屏，默认背光是关闭的，framebuffer写好后，再开背光；

我们修改了LCD电路板（加一个三极管和GPIO控制LT1937 SHDN (PIN4) ，上电时自动拉低，关背光）

图片显示后再开背光（GPIO拉高），主要是防闪，平滑过渡

9.u-boot自动执行烧录命令：

在include/configs/smdk6410.h中修改 CONFIG_BOOTCOMMAND 宏，让u-boot自动执行命令

#define CONFIG_BOOTCOMMAND    "fatload mmc 0:1  0x5FD00000 burnIcon.bin;                  "\
                            "nand scrub       0x00000000 0x00100000;                    "/*u-boot*/\
                            "nand erase       0x00000000 0x00100000;                    "\
                            "fatload mmc 0:1  0x50008000 u-boot.bin;                    "\
                            "nand write.uboot 0x50008000 0x00000000 $filesize;          "\
                            "nand scrub       0x00100000 0x00300000;                    "\
                            "nand erase       0x00100000 0x00300000;                    "\
                            "fatload mmc 0:1  0x50008000 zImage;                        "/*kernel zImage*/\
                            "nand write.e     0x50008000 0x00100000 $filesize;          "\
                            "nand scrub       0x00400000;                               "\
                            "nand erase       0x00400000;                               "\
                            "fatload          mmc 0:1 0x50008000 rootfs.yaffs2;         "/*root filesystem yaffs2*/\
                            "nand write.yaffs 0x50008000 0x00400000 $filesize;          "\
                            "nand ok                                                    "/*beep sound ok*/

0x5FD00000 为背景层windows framebuffer的地址, burnIcon.bin为565 raw data bmp图片，直接丢到framebuffer就可以显示图片了。

注意： $filesize 代表文件的大小，所以文件大小不要超过kernel nand分区表，否则会错误。

飞凌烧cramfs时烧写大小直接写的是32M，所以大于32M时，就容易出错，并且飞凌烧yaffs2还要跑到内核去烧，不实用。

补充：之前版本是按512字节每块读的，现在改为256K每块读，速度从读100M文件需要100秒提升到只需20秒，进5倍提示，

但是我设置成512K每块读，会出现数据丢失现象。

更新代码 cpu/s3c64xx/hs_mmc.c 

void movi_read (uint addr, uint start_blk, uint blknum)
{
    uint dma=0,cmd,multi_blk,i,count,spare;

    /*Enable interrupt*/
    s3c_hsmmc_writew(s3c_hsmmc_readw(HM_NORINTSTSEN) & ~(DMA_STS_INT_EN | BLOCKGAP_EVENT_STS_INT_EN), HM_NORINTSTSEN);
    s3c_hsmmc_writew((HM_NORINTSIGEN & ~(0xffff)) | TRANSFERCOMPLETE_SIG_INT_EN, HM_NORINTSIGEN);

    /*clear interrupt*/
    ClearCommandCompleteStatus();

    ClearDMAStatus();
    ClearTransferCompleteStatus();

    spare = blknum;
    count = ( (blknum * Card_OneBlockSize_ver1) - 1 ) / (Card_OneBlockSize_ver1 * 512) + 1;

    for(i=0;i         while(!check_card_status());

        SetSystemAddressReg(addr);                           //AHB System Address For Write
        addr += Card_OneBlockSize_ver1 * 512;                //256K ++

        set_blksize_register(6,Card_OneBlockSize_ver1);      //Maximum DMA Buffer Size, Block Size
        set_blkcnt_register((spare > 512) ? 512 : spare);    //Block Numbers to read

        /*Card Start Block Address to read*/
        if (movi_hc){
            set_arg_register(start_blk);
        }else{
            set_arg_register(start_blk*Card_OneBlockSize_ver1);
        }

        start_blk += 512;

        dma = 1;
        multi_blk = (spare > 1);
        cmd = multi_blk ? 18 : 17;

        if(spare>512){
            spare -= 512;
        }

        /*CMD17 signle block, CMD18 mutil block read*/
        set_transfer_mode_register(multi_blk,1,1,multi_blk,dma);
        set_cmd_register(cmd,1,MMC_RSP_R1);

        if (wait_for_cmd_done()){
            printf("ERROR: Command NOT Complete\n");
            goto error;
        }

        /*wait for transfer complete*/
        check_dma_int();

error:
        ClearCommandCompleteStatus();

        ClearDMAStatus();
        ClearTransferCompleteStatus();
    }

    return;
}

对于普通的SD卡，我有个2g的sd卡，拿它作为例子：

（1）使用本站提供的windows工具完全格式化一次你的sd卡

（2）进到ubuntu的环境下查看SD卡扇区数量：

zswan@zswan-laptop-ubuntu:~/tmp$ sudo fdisk /dev/sdb1

WARNING: DOS-compatible mode is deprecated. It's strongly recommended to

         switch off the mode (command 'c') and change display units to

         sectors (command 'u').

Command (m for help): p

Disk /dev/sdb1: 2059 MB, 2059278848 bytes

64 heads, 62 sectors/track, 1013 cylinders

Units = cylinders of 3968 * 512 = 2031616 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk identifier: 0x00000000

计算扇区数量：

2059278848/512 = 4022029个扇区，按图1的结构，BL1应该烧写在第4022029-18=4022011个扇区当中。BL2应该烧写在第（4022011-BL2扇区数）的中。

飞凌提供的MMC启动的bin文件，其实就是个支持SD卡的uboot，其结构是这样的：

所以为了一次性烧写方便，MMC.bin其实应该是BL2的代码，BL2的前8k字节作为BL1的代码。但是由于BL2,BL1是分着烧写的，不大方便，所以干脆在BL2的后面再附上一个BL1的相同代码，这样结合出来的mmc.bin，我只需要把它烧写到：4022029-2-560（mmc.bin为280k=560个扇区）= 4021467起始的扇区中去，就可以了。

烧写方法：

Ubuntu环境下：

sudo dd of=/dev/sdb1 if=./mmc.bin count=560 seek=4021467

这样就可以了。

SDHC的类同，只是总的扇区数减去（1026+560）才是mmc bin烧写的位置。

（二）
拷贝的过程

BL1被拷贝到8k的steppingstone中这个是硬件就做好了的。但是BL2被拷贝到SDRAM中是BL1中的代码实现的。在BL1中也使用了IROM硬件code定义好了的copyMMCtoMEM函数,直接从MMC中拷贝BL2的代码。

两次拷贝执行完后MMC.BIN作为一个完整的uboot就已经被拷贝到SDRAM中了。

在ok6410的开发板上，SD卡boot主要的作用就是启动mmc.BIN的uboot去初始化NAND,把保存在sd
中的uboot.bin, zImage拷贝到内存中，然后写进NAND中，是为了从NANDboot做准备的。

实际上是将u-boot.bin内容重复一次后（为了保证达到256K，假如 这个bin更小，那么可能须要 重复3次、4次，直到超过256K 为止），将前256K制成u-boot_256k.bin，再将前8K制成u-boot_8k.bin，结尾 将u-boot_256k.bin +u-boot_8k.bin合并成一个256K+8K大小的文件u-boot_mmc.bin，这个文件前256K就是u-boot_256k.bin 而后8K就是u-boot_8k.bin。把这个u-boot_mmc.bin议决 IROM_Fusing_tools烧写到SD卡就能够 成功启动系统了。

　　为什么要做这样的处理这个bin文件呢？下面议决 剖析 IROM_Fusing_tools、uboot的源码来揭示其中的由来。

　　从网上能够 下载到IROM_Fusing_tools的源码，在按下这个软件的start控件后，先是读取这个SD卡的第一个扇区，也就是这个硬盘 的MBR 扇区，判断是不是FAT32格式的硬盘 （这也是为什么用来做启动的SD必须格式化为FAT32格式），接着获取总的扇区数目TOTAl_SECOTR，并将所要烧写的bin文件烧写到硬盘 的这个扇区：TOTAL_SECTOR – 2 - SIZE_OF_IMAGE/512。其中TOTAl_SECTOR是这个硬盘 总的扇区数目；SIZE_OF_IMAGE/512是这个bin文件将要占据的扇区数（这里是以512为扇区大小的，因此对于扇区更大的SD卡也就没要领 运用 了，而现在的大容量SD都可能运用 了2K甚至4K的扇区，除非修改这个程序，并同步地在uboot中修改程序）；至于2则是保存 的2个扇区，至于为什么要保存 这2个扇区，须要 剖析 uboot的源码情况，下面将做进一步的阐述。

　　在SD启动方式下，S3C6410内部的IROM程序BL0最先 运行，并将SD中的结尾 18个扇区开始的16个扇区内容复制到片内的8K SRAM，也就是SteppingStone，接着跳转到这块SRAM的开始地址开始运行，这8K的代码实际上就是上面u-boot_mmc.bin这个文件的结尾 8K，也是u-boot.bin的最开始8K代码，这段代码也叫BL1。从BL0跳转到BL1的时刻 uboot也就接管了CPU。

　　Uboot的入口在start.S这个文件，cpu/s3c64x0/start.S中有这样一段代码：

　　#ifdef CONFIG_BOOT_MOVINAND

　　ldr   sp, _TEXT_PHY_BASE

　　bl     movi_bl2_copy

　　b     after_copy

#endif

　　这段代码是实现SD启动的首要 。到了这里后就执行movi_bl2_copy，这个函数负责将SD内的uboot完整地复制到SDRAM，这时刻 完整的uboot也叫BL2，而这个函数实际上是调用了以下函数：

　　CopyMovitoMem(HSMMC_CHANNEL, MOVI_BL2_POS, MOVI_BL2_BLKCNT, (uint *)BL2_BASE, MOVI_INIT_REQUIRED);

　　HSMMC_CHANNEL这是SD/MMC通道号，手上板子运用 的是CH1，而默认是CH0，所以须要 对这个实行 修改。

　　MOVI_BL2_POS 是须要 拷贝的数据位于SD的起始扇区，其计算要领 是这样的，先得到这个SD的总扇区数TOTAL，再减去256K的BL2和8K的BL1所占的扇区数，结尾 减去0.5K 的eFuse和0.5K的保存 区所占的扇区数，而这里还定义SD的扇区为512B。从这里能够 看到和IROM_Fusing_tools对SD卡的处理是完全对应的。这里还有一个疑问 ，总扇区数TOTAL是如何 得到的？从程序来看是从(TCM_BASE - 0x4)这个地址读取到的，至于TOTAL是如何 被放到这里的就只好 从BL0的代码找答案了。

　　MOVI_BL2_BLKCNT是须要 复制的扇区数目，这里就是定义为256K，这也是为什么必须把u-boot.bin转换成256K的文件。

　　BL2_BASE是目标 地址，也就是SDRAM中的地址。这里定义为0x57E00000，就是128M 的SDRAM的结尾 2M，因为到这里为止MMU尚未打开，因此这里运用 的是物理地址。

　　MOVI_INIT_REQUIRED这个参数的意义是什么暂时没有任何资料表明 。

　　而CopyMovitoMem这个函数的定义是这样的：

　　#define CopyMovitoMem(a,b,c,d,e)     (((int(*)(int, uint, ushort, uint *, int))(*((uint *)(TCM_BASE + 0x8))))(a,b,c,d,e))

　　这个定义实际上是调用了位于TCM_BASE + 0x8这个地址的函数指针，其中TCM_BASE的值为0x0C004000，至于这个地址放的是什么，也没资料表明 。

　　当复制完BL2后便会跳转到BL2的start_armboot这个C语言函数中运行了，此后的运行流程 就不须要 再剖析 了。