跳至主要内容

【转】vivi开发笔记(十六):vivi源代码分析3

文章说明:calmarrow(lqm)原创

文章引自:http://piaoxiang.cublog.cn

 
    继续分析vivi源代码。
 
step 5:
 
    MTD设备初始化。
 
    关于什么是MTD,为什么要使用MTD,MTD技术的架构是什么,等等,可以参考《Linux MTD源代码分析》(作者:Jim Zeus,2002-04-29)。这份文档的参考价值比较大,猜想作者在当时可能研究了很长时间,毕竟2002年的时候资料还比较缺乏。当然,因为完全分析透彻,方方面面都点透,这份文档还是没有做到。
 
    vivi采用Linux kernel的架构,所以把Linux kernel的MTD子系统借用过来了,做了一些裁减。可以简单地看成:Flash硬件驱动层和MTD设备层。这样,最终以抽象的统一的接口向vivi提供。
 
    还是以nand flash启动这个情景为主线,对MTD初始化流程进行分析。下面先从入口开始。
 

ret = mtd_dev_init();

 
    利用source insight跟踪,看一下此函数的接口定义部分:
 

/*
 * VIVI Interfaces
 */

#ifdef CONFIG_MTD
int write_to_flash(loff_t ofs, size_t len, const u_char *buf, int flag);
int mtd_dev_init(void);
#else
#define write_to_flash(a, b, c, d) (int)(1)
#define mtd_dev_init() (int)(1)
#endif

 
    可见,vivi在配置的时候是必须配置MTD功能部分的。如果不配置MTD,那么CONFIG_MTD就不存在定义。由此导致写flash的动作实际上是没有的。也就是说,无法完成写flash的动作。当然,在这里可以做测试,就是使用MTD子系统的vivi把分区等都设置好。然后重新编译一下vivi,把mtd功能去除,做简单的修改(把bon_cmd部分从【lib/command.c】中去掉,否则编译不通过),生成大小为35152字节。给开发板重新上电,利用老的vivi烧写nand flash的vivi分区,完成后做一下reset,于是没有MTD功能的vivi就跑起来了。但是,这样的bootloader仅仅适合于最终的产品阶段,不适合开发,没什么太大的价值。有兴趣倒是可以据此研究一下配置部分,整个引导时间相应的缩短。我的最小配置文件如下:
 
文件: config.rar
大小: 0KB
下载: 下载
 
    下面【drivers/mtd/mtdcore.c】,看看mtd_dev_init函数,核心部分就是调用mtd_init函数(【drivers/mtd/maps/s3c2410_flash.c】)。
 

int mtd_init(void)
{
    int ret;

#ifdef CONFIG_MTD_CFI
    ret = cfi_init();
#endif
#ifdef CONFIG_MTD_SMC
    ret = smc_init();
#endif
#ifdef CONFIG_S3C2410_AMD_BOOT
    ret = amd_init();
#endif

 
    可见,vivi现在支持三种类型的存储接口,一种是CFI,也就是Intel发起的一个flash的接口标准,主要就是intel的nor flash系列;一种是smc,智能卡系列接口,nand flash就是通过这个接口实现读写的;一种是AMD的flash系列。选择什么启动方式,就要选择相应的配置项。
 
    核心部分根据配置应该调用smc_init函数。-->【drivers/mtd/maps/s3c2410_flash.c】。这里最为核心的就是两个数据结构,一个是mtd_info,位于【include/mtd/mtd.h】,如下:
 
    mtd_info是表示MTD设备的结构,每个分区也被表示为一个mtd_info,如果有两个MTD设备,每个设备有三个分区,那么在系统中就一共有6个mtd_info结构。关于mtd_info,在《Linux MTD源代码分析》中讲解非常透彻,不过需要注意的是,在vivi的实现中没有使用mtd_table,另外priv指向的是nand_info,这些都是与Linux下不同的地方,主要是为了简化。另一个是nand_info,这个结构则包含了nand flash的所有信息。
 
    所谓的初始化,其实就是填充处理上述两个数据结构的过程。填充完毕之后,后续的工作都会基于此展开。下面开始看smc_init的代码。
 

mymtd = mmalloc(sizeof(struct mtd_info) + sizeof(struct nand_chip));
this = (struct nand_chip *)(&mymtd[1]);

 
    在这里,第一句参考前面heap的实现代码,重点看第二句代码。这句代码是有一定的技巧性,但是也存在着很大的风险。其中,mymtd是指向struct mtd_info的指针,那么mymtd[1]实际上是等效于*(mymtd + 1)的数学计算模式,注意mymtd并非数组,这里仅仅利用了编译器翻译的特点。对于指针而言,加1实际上增加的指针对应类型的值,在这里地址实际上增加了sizeof(struct mtd_info),因为前面分配了两块连续的地址空间,所以&(*(mymtd + 1))实际上就是mtd_info数据结构结束的下一个地址,然后实现强制转换,于是this就成为了nand_chip的入口指针了。但是,这里必须要把握好,因为这个地方是不会进行内存的检查的,也就是说,如果你使用了mymtd[2],那么仍然按照上述公式解析,虽然可以运算,可是就是明显的指针泄漏了,可能会出现意料不到的结果。写了一个测试程序,对这点进行了探讨,要小心内存问题。
 
文件: array_test.tar.gz
大小: 0KB
下载: 下载
 
    了解清楚了,mymtd指向mtd_info的入口,this指向nand_chip的入口。
 

    memset((char *)mymtd, 0, sizeof(struct mtd_info));
    memset((char *)this, 0, sizeof(struct nand_chip));

 

mymtd->priv = this;

 
    上述代码首先初始化这两个结构体,即均为0.然后利用priv把二者联系起来,也就是mymtd通过其成员priv指向this,那么mymtd中的抽闲操作函数,比如read、write等,真正的是通过this来实现的。很明显,this的实现部分属于flash硬件驱动层,而mymtd部分则属于MTD设备层,二者的联系就是通过成员priv实现的。
 
    接下来首先是初始化nand flash设备,这跟前面的基础实验一致。
 

    /* set NAND Flash controller */
    nfconf = NFCONF;
    /* NAND Flash controller enable */
    nfconf |= NFCONF_FCTRL_EN;

    /* Set flash memory timing */
    nfconf &= ~NFCONF_TWRPH1;     /* 0x0 */
    nfconf |= NFCONF_TWRPH0_3;    /* 0x3 */
    nfconf &= ~NFCONF_TACLS;      /* 0x0 */

    NFCONF = nfconf;

 
    然后填充nand flash的数据结构的一个实例this,分成了两个部分,nand flash基本操作函数成员的初始化、其余信息的填写。
 

    /* Set address of NAND IO lines */
    this->hwcontrol = smc_hwcontrol;
    this->write_cmd = write_cmd;
    this->write_addr = write_addr;
    this->read_data = read_data;
    this->write_data = write_data;
    this->wait_for_ready = wait_for_ready;

    /* Chip Enable -> RESET -> Wait for Ready -> Chip Disable */
    this->hwcontrol(NAND_CTL_SETNCE);
    this->write_cmd(NAND_CMD_RESET);
    this->wait_for_ready();
    this->hwcontrol(NAND_CTL_CLRNCE);

    smc_insert(this);

 
    上面这些都不难理解,感觉在结构体设计上还是比较出色的,把成员和相应的操作封装起来,面向对象的一种方法。下面看smc_insert,无非还是按照结构体填写相应的信息,细节部分就不深入探讨了。
 


inline int
smc_insert(struct nand_chip *this) {
    /* Scan to find existance of the device */
    if (smc_scan(mymtd)) {
        return -ENXIO;
    }
    /* Allocate memory for internal data buffer */
    this->data_buf = mmalloc(sizeof(u_char) *
             (mymtd->oobblock + mymtd->oobsize));

    if (!this->data_buf) {
        printk("Unable to allocate NAND data buffer for S3C2410.\n");
        this->data_buf = NULL;
        return -ENOMEM;
    }

    return 0;
}

 
    第一部分扫描填充mymtd数据结构。后面主要用于nand flash的oob缓冲处理。具体部分可以参考《s3c2410完全开发》。
 
    这里重点是学习一种结构体的构造技巧。
 
    首先构造一级数据结构,表示抽象实体。例如:
 

struct nand_flash_dev {
    char * name;
    int manufacture_id;
    int model_id;
    int chipshift;
    char page256;
    char pageadrlen;
    unsigned long erasesize;
};

 
    然后构造实例集合,表现形式就是一个大的数组。
 

static struct nand_flash_dev nand_flash_ids[] = {
    {"Toshiba TC5816BDC", NAND_MFR_TOSHIBA, 0x64, 21, 1, 2, 0x1000},    
// 2Mb 5V

    ... ....

    {"Samsung K9D1G08V0M", NAND_MFR_SAMSUNG, 0x79, 27, 0, 3, 0x4000},    // 128Mb

    {NULL,}
};

   
    这样修改扩展等等后续的操作就简便多了。抽象的能力及其训练在读代码的时候是可以很好的学习的,在vivi中,多处都采用了这种设计原则,应该掌握并利用。
 
step 6:
 
    此部分的功能是把vivi可能用到的所有私有参数都放在预先规划的内存区域,大小为48K,基地址为0x
33df0000。在内存的分配示意图方面,《s3c2410完全开发》已经比较详尽,就不放在这里了。到此为止,vivi作为bootloader的三大核心任务:initialise various devices, and eventually call the Linux kernel,passing information to the kernel.,现在只是完成第一方面的工作,设备初始化基本完成,实际上step 6是为启动Linux内核和传递参数做准备的,把vivi的私有信息,内核启动参数,mtd分区信息等都放到特定的内存区域,等待后面两个重要工作使用(在step 8完成,后面的step 7也是为step 8服务的)。这48K区域分为三个组成部分:MTD参数、vivi parameter、Linux启动命令。每块的具体内容框架一致,以vivi param tlb这个情景为主线进行分析:
 
入口:
 

init_priv_data();

 
进入【lib/priv_data/rw.c】--init_priv_data()
 

int
init_priv_data(void)
{
    int ret_def;
#ifdef CONFIG_PARSE_PRIV_DATA
    int ret_saved;
#endif
    ret_def = get_default_priv_data();
#ifdef CONFIG_PARSE_PRIV_DATA
    ret_saved = load_saved_priv_data();
    if (ret_def && ret_saved) {
        printk("Could not found vivi parameters.\n");
        return -1;
    } else if (ret_saved && !ret_def) {
        printk("Could not found stored vivi parameters.");
        printk(" Use default vivi parameters.\n");
    } else {
        printk("Found saved vivi parameters.\n");
    }
#else
    if (ret_def) {
        printk("Could not found vivi parameters\n");
        return -1;
    } else {
        printk("Found default vivi parameters\n");
    }
#endif
    return 0;

 
    下面分为两步:首先读取默认设置到特定的内存区域,然后读取nand flash的param区域的信息,如果读取成功,就覆盖掉前面的默认设置。首先看第一步,get_default_priv_data--get_default_param_tlb-->
 

int get_default_param_tlb(void)
{
    char *src = (char *)&default_vivi_parameters;
    char *dst = (char *)(VIVI_PRIV_RAM_BASE + PARAMETER_TLB_OFFSET);
    int num = default_nb_params;

    if (src == NULL) return -1;

    /*printk("number of vivi parameters = %d\n", num); */
    *(nb_params) = num;

    //参数表的长度不可以超过预设内存的大小

    if ((sizeof(vivi_parameter_t)*num) > PARAMETER_TLB_SIZE) {
        printk("Error: too large partition table\n");
        return -1;
    }

    //首先复制magic number
    memcpy(dst, vivi_param_magic, 8);

    //预留下8个字节作为扩展
    dst += 16;

    //复制真正的parameter
    memcpy(dst, src, (sizeof(vivi_parameter_t)*num));
    return 0;
}

 
    内存的入口地址为VIVI_PRIV_RAM_BASE+PARAMETER_TLB_OFFSET,开始的8个字节放magic number,这里vivi定义为"VIVIPARA",后面空下8个字节,留作扩展,从第17个字节开始放置真正的param。这里用到了多处技巧,第一处就是上面刚刚介绍过的数据结构构造技巧,这里的vivi_parameter_t就是一级数据结构:
 

typedef struct parameter {
    char name[MAX_PARAM_NAME];
    param_value_t value;
    void (*update_func)(param_value_t value);
} vivi_parameter_t;    

 
    利用其构造了默认的成员表:
 

vivi_parameter_t default_vivi_parameters[] = {
    { "mach_type",            MACH_TYPE,    NULL },
    { "media_type",            MT_S3C2410,    NULL },
    { "boot_mem_base",        0x30000000,    NULL },
    { "baudrate",            UART_BAUD_RATE,    NULL },
    { "xmodem_one_nak",        0,        NULL },
    { "xmodem_initial_timeout",    300000,        NULL },
    { "xmodem_timeout",        1000000,    NULL },
    { "ymodem_initial_timeout",    1500000,    NULL },
    { "boot_delay",            0x1000000,    NULL }
};

 
    我们这时就可以很清楚的看到param show列出的配置参数了。
 
    另外一个技巧就是利用宏计算数组长度。
 

int default_nb_params = ARRAY_SIZE(default_vivi_parameters);

 
    其中ARRAY_SIZE为:
 

#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))

 
    这是从Linux kernel中拿来的,也是值得学习和利用的地方。
 
    在load阶段内无非就是找到param分区,然后根据配置,找到相应的flash硬件驱动(这就是MTD层的作用所在,不过可以看出nand chip的databuf确实没有起到作用,现在也未看出这部分究竟用在何处)。然后就是读操作。当然,读取出来的信息先放到临时缓冲区,判断头部的magic number,如果符合则说明是正确的分区信息,然后把信息从临时缓冲区复制到对应的默认配置区,这样就完成了真正的配置。
 
    其实这个地方可以改进。首先看看param分区是否有合适的分区信息,如果有,直接读取到vivi parameter区域,不需要再读取默认的配置信息;如果没有合适的分区信息,然后读取默认的配置信息。这样在用户修正了分区信息时,不必再读取默认的配置信息,这也算是一处优化。
 
step 7:
 
    调用add_command()函数,增加vivi作为终端时命令的相应处理函数。其实,这种机制还是比较简单的,就是利用了链表。
 
    整个命令处理机制及其初始化的实现是在【lib/command.c】中完成的,包括添加命令、查找命令、执行命令、解析命令行等等。具体的命令函数则在相应的模块里面,这样形成了一个2层的软件架构:顶部管理层+底部执行层。维护的核心就是一个数据结构user_command:
 

typedef struct user_command {
    const char *name;
    void (*cmdfunc)(int argc, const char **);
    struct user_command *next_cmd;
    const char *helpstr;
} user_command_t;

 
    第一个成员是指向name字符串的指针,第二个成员就是命令的处理函数,第三个成员是指向下一个命令,第四个成员是帮助信息。如果你想添加一个命令,那么首先需要构造一个数据结构user_command的实例,比如:
 

user_command_t help_cmd = {
    "help",
    command_help,
    NULL,
    "help [{cmds}] \t\t\t-- Help about help?"
};

 
    然后实现命令的真正处理函数command_help。
 

void command_help(int argc, const char **argv)
{
    user_command_t *curr;

    /* help <command>. invoke <command> with 'help' as an argument */
    if (argc == 2) {
        if (strncmp(argv[1], "help", strlen(argv[1])) == 0) {
            printk("Are you kidding?\n");
            return;
        }
        argv[0] = argv[1];
        argv[1] = "help";
        execcmd(argc, argv);
        return;
    }

    printk("Usage:\n");
    curr = head_cmd;
    while(curr != NULL) {
        printk(" %s\n", curr->helpstr);
        curr = curr->next_cmd;
    }
}

 
    构造好之后,需要把它加入链表,也就是在init_builtin_cmds中增加add_command(&help_cmd);,其中add_command的实现如下:
 

void add_command(user_command_t *cmd)
{
    if (head_cmd == NULL) {
        head_cmd = tail_cmd = cmd;
    } else {
        tail_cmd->next_cmd = cmd;
        tail_cmd = cmd;
    }
    /*printk("Registered '%s' command\n", cmd->name);*/
}

 
    这样,自己如果增加新的程序,就按照如上的步骤添加即可。
 
    其余具体命令的实现暂时不做解释。
 
step 8:
 
    根据情况,要么进入vivi的命令行交互界面,要么直接启动内核。关于此部分的流程分析,有了前面的基础和经验,是不难理解的。很容易通过vivi的打印信息得知进行到了第几步,《s3c2410完全开发》在过程上讲解的也很清楚。所以不打算具体分析了。现在翻阅网上资料,有一个问题实际上模模糊糊,如下:
 
    vivi作为bootloader的一个重要的功能就是向Linux kernel传递启动参数,这个情景究竟是如何完成的呢?虽然网上讨论很多,但是因为vivi具有一点特殊性,所以使得理解上有一定的困难。现在已经比较清晰了,算是回答网友的一个问题,也算是总结,就bootloader如何于kernel传递参数,作为一个情景进行详尽的分析。事先需要说明的是,我们假定vivi为A,Linux kernel为B,A要传给B东西,这就是一个通信的过程。要想通信,至少我们得有一个约定,那就是协议。现在存在的协议有两种,一种是基于struct param_struct,不过这种因为其局限性即将作废;一种是基于tags技术。基本的情景框架就是A必须按照协议设置好参数,B呢,就需要来读取解析这些参数。它们之间必须配合好,如果配合不好,那么,kernel是无法引导成功的。现在嵌入式系统的移植,很多时候kernel引导不起来,部分原因就直接来自于参数传递问题。但是设计到这个问题,不能不分析Linux kernel的引导过程。现在还不想细致到代码层,只是根据部分代码把Linux kernel启动至获取引导参数的过程从整体上了解清楚,必要的时候辅助相应的代码。这部分内容的详细分析,专门在下篇总结中完成。
 

 
学习总结:
 
    学习一种技术,采用历史的观点是很好的方法。我们现在学习的技术并非最新的理论研究,所以有大量前人的工作经验可以借鉴。站在巨人的肩上,不做无谓的工作,是好的学习方法。我现在的学习观点就是事先要分析阅读前人的相关经验,包括经典书籍、网上资料、网友的经验等等,然后呢,需要对这些知识理解消化,深入,深入再深入,形成自己的认识,转化成自己的经验。正像网友所说,这些都是现成的技术,只要静下心来肯学,就一定能够学好。
 
    另外,一定要多思考,多动手,多给自己提出问题。没有问题说明你根本就没有深入,有问题才能在解决的过程中提升自己!学习首先从整体上把握流程,然后呢,需要具体的细节。只看整体,不看细节,容易"眼高手低";只看细节,不看整体,容易"只见树木,不见森林",提高不到一定的层次。
 
    这些都是学习过程中的经验总结。欢迎交流!

评论

此博客中的热门博文

【转】AMBA、AHB、APB总线简介

AMBA 简介 随着深亚微米工艺技术日益成熟,集成电路芯片的规模越来越大。数字IC从基于时序驱动的设计方法,发展到基于IP复用的设计方法,并在SOC设计中得到了广泛应用。在基于IP复用的SoC设计中,片上总线设计是最关键的问题。为此,业界出现了很多片上总线标准。其中,由ARM公司推出的AMBA片上总线受到了广大IP开发商和SoC系统集成者的青睐,已成为一种流行的工业标准片上结构。AMBA规范主要包括了AHB(Advanced High performance Bus)系统总线和APB(Advanced Peripheral Bus)外围总线。   AMBA 片上总线        AMBA 2.0 规范包括四个部分:AHB、ASB、APB和Test Methodology。AHB的相互连接采用了传统的带有主模块和从模块的共享总线,接口与互连功能分离,这对芯片上模块之间的互连具有重要意义。AMBA已不仅是一种总线,更是一种带有接口模块的互连体系。下面将简要介绍比较重要的AHB和APB总线。 基于 AMBA 的片上系统        一个典型的基于AMBA总线的系统框图如图3所示。        大多数挂在总线上的模块(包括处理器)只是单一属性的功能模块:主模块或者从模块。主模块是向从模块发出读写操作的模块,如CPU,DSP等;从模块是接受命令并做出反应的模块,如片上的RAM,AHB/APB 桥等。另外,还有一些模块同时具有两种属性,例如直接存储器存取(DMA)在被编程时是从模块,但在系统读传输数据时必须是主模块。如果总线上存在多个主模块,就需要仲裁器来决定如何控制各种主模块对总线的访问。虽然仲裁规范是AMBA总线规范中的一部分,但具体使用的算法由RTL设计工程师决定,其中两个最常用的算法是固定优先级算法和循环制算法。AHB总线上最多可以有16个主模块和任意多个从模块,如果主模块数目大于16,则需再加一层结构(具体参阅ARM公司推出的Multi-layer AHB规范)。APB 桥既是APB总线上唯一的主模块,也是AHB系统总线上的从模块。其主要功能是锁存来自AHB系统总...

【转】GPIO编程模拟I2C入门

ARM编程:ARM普通GPIO口线模拟I2C  请教个问题: 因为需要很多EEPROM进行点对点控制,所以我现在要用ARM的GPIO模拟I2C,管脚方向我设 置的是向外的。我用网上的RW24C08的万能程序修改了一下,先进行两根线的模拟,SDA6, SCL6,但是读出来的数不对。我做了一个简单的实验,模拟SDA6,SCL6输出方波,在示波 器上看到正确方波,也就是说,我的输出控制是没问题的。 哪位大哥能指点一下,是否在接收时管脚方向要设为向内?(不过IOPIN不管什么方向都可 以读出当前状态值的阿) 附修改的RW24C08()程序: #define  SomeNOP() delay(300); /**/ /* *********************************  RW24C08   **************************************** */ /**/ /* ----------------------------------------------------------------------------- ---  调用方式:void I2CInit(void)   函数说明:私有函数,I2C专用 ------------------------------------------------------------------------------- -- */ void  I2CInit( void ) ... {  IO0CLR  =  SCL6;      // 初始状态关闭总线  SomeNOP();  // 延时   I2CStop();  // 确保初始化,此时数据线是高电平 }   /**/ /* ---------------------------------------------------------------------------- ----  调用方式:void I2CSta...

【转】cs8900网卡的移植至基于linux2.6内核的s3c2410平台

cs8900网卡的移植至基于linux2.6内核的s3c2410平台(转) 2008-03-11 20:58 硬件环境:SBC-2410X开发板(CPU:S3C2410X) 内核版本:2.6.11.1 运行环境:Debian2.6.8 交叉编译环境:gcc-3.3.4-glibc-2.3.3 第一部分 网卡CS8900A驱动程序的移植 一、从网上将Linux内核源代码下载到本机上,并将其解压: #tar jxf linux-2.6.11.1.tar.bz2 二、打开内核顶层目录中的Makefile文件,这个文件中需要修改的内容包括以下两个方面。 (1)指定目标平台。 移植前:         ARCH?= $(SUBARCH) 移植后: ARCH            :=arm (2)指定交叉编译器。 移植前: CROSS_COMPILE ?= 移植后: CROSS_COMPILE   :=/opt/crosstool/arm-s3c2410-linux-gnu/gcc-3.3.4-glibc-2.3.3/bin/arm-s3c2410-linux-gnu- 注:这里假设编译器就放在本机的那个目录下。 三、添加驱动程序源代码,这涉及到以下几个方面。(1)、从网上下载了cs8900.c和cs8900.h两个针对2.6.7的内核的驱动程序源代码,将其放在drivers/net/arm/目录下面。 #cp cs8900.c ./drivers/net/arm/ #cp cs8900.h ./drivers/net/arm/ 并在cs8900_probe()函数中,memset (&priv,0,sizeof (cs8900_t));函数之后添加如下两条语句: __raw_writel(0x2211d110,S3C2410_BWSCON); __raw_writel(0x1f7c,S3C2410_BANKCON3); 注:其原因在"第二部分"解释。 (2)、修改drivers/net/arm/目录下的Kconfig文件,在最后添加如...