3.移植uboot-使板卡支持nor、nand

本文详细介绍了如何修改U-Boot源码以支持Nor和Nand Flash,包括配置宏定义、添加Nor Flash型号、调整扇区数量限制及Nand Flash控制器初始化等步骤。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

         

上面的Flash: *** failed *** 是属于uboot第二阶段函数board_init_r()里的代码, 代码如下所示(位于arch/arm/lib/board.c):

/*第二阶段*/
void board_init_r(gd_t *id, ulong dest_addr)        //gd    uboot重定位地址
{
     ... ...
  puts("Flash: ");                        //打印flash:
  flash_size = flash_init();                    //初始化nor_flash
  if (flash_size > 0)
  {
       ... ...
       print_size(flash_size, "\n");            //打印nor_flash的大小
  }
  else
  {
    puts(failed);                //打印数组failed[]="*** failed ***\n";
    hang();                        //进入while中,并打印: ### ERROR ### Please RESET the board ###     
  }
#if defined(CONFIG_CMD_NAND)
       puts("NAND:  ");                                      //打印NAND:
       nand_init();                                               //初始化nand_flah
... ...
}

从上面代码看出, board_init_r()会来初始化nor,由于新的uboot不支持nor,所以flash_init()初始失败,然后打印一串错误代码后,等待复位.

由于2440在nand启动时,会自动装载nand的前4k内容,所以不支持norflash,因为nor的前4k内容被nand占用.

所以修改上面代码,避免nand启动一直卡住,将:

else
{
  puts(failed);                //打印数组failed[]="*** failed ***\n";
  hang();                        //进入while中,并打印: ### ERROR ### Please RESET the board ###     
}

改为:

else
{
  puts("0  KB\r\n");                //打印0 KB
}

 


1.接下来,下章便来修改代码,使uboot支持读写norflash

1.1首先在include/common.h中添加:

#define DEBUG     //调试模式

然后使用nor启动新的uboot,打印出调试信息:

 

打印出norflash的厂家ID=0xC2,设备ID=0x2249,显然uboot匹配读出的ID没有成功.

搜索JEDEC PROBE字段,找到位于board_init_r()->flash_init()->flash_detect_legacy():

 

 

如上图所示,该函数会进入board_init_r()->flash_init()->flash_detect_legacy()->jedec_flash_match(),里面会通过两个ID来匹配jedec_table[].

 

1.2接下来向jedec_table[]里添加norflash:MT29LV160DB(位于drivers/mtd/jedec_flash.c)

代码如下:

     /*MX29LV160DB*/
       {
       .mfr_id         = (u16)MX_MANUFACT,        //厂家ID0x00C200C2 (读nor,便是0xc2)
       .dev_id         = 0x2249,                          //设备ID
       .name           = "MXIC MX29LV160DB",
       .uaddr          = {
           [1] = MTD_UADDR_0x0555_0x02AA /* 数组[1]表示是16位nor,解锁地址为:0x555,0x2AA */
        },
       .DevSize        = SIZE_2MiB,
       .CmdSet         = P_ID_AMD_STD,
       .NumEraseRegions= 4,                      //4种不同的扇区规格
       .regions        = {
       ERASEINFO(16*1024, 1),
       ERASEINFO(8*1024, 2),
       ERASEINFO(32*1024, 1),
       ERASEINFO(64*1024, 31),
                          }
           },

 

重新烧写看打印信息,出现这么一段ERROR

ERROR:too many flash sectors

说flash的扇区太多了,搜索找到位于drivers/mtd/jedec_flash.c中:

 

显然是CONFIG_SYS_MAX_FLASH_SECT宏小于我们flash的扇区,所以打印ERROR。

所以修改CONFIG_SYS_MAX_FLASH_SECT宏定义(位于include/configs/smdk2440.h),并去掉之前定义的DEBUG调试宏(位于include/common.h)

1.3然后重新烧写

输入flinfo命令(flash info),就能查看flash的信息了:

 

然后通过uboot命令,检测nor的读写是否正确:

protect off all 
erase 80000 +7ffff              
cp.b 30000000 80000 1000             //烧写在另一个位置
cmp.b 30000000 80000 1000              //比较,是否读写正确

2.接下来继续修改代码,使uboot支持NandFlash

2410的NandFlash位于drivers/mtd/nand/s3c2410_nand.c

2.1 首先复制s3c2410_nand.c,改为s3c2440_nand.c

Makefile,如下图所示:

 

 

2.2 在上一章分析过CONFIG_NAND_S3C2410宏,位于include/configs/smdk2440.h:

 

如上图所示,其中CONFIG_CMD_NAND宏:表示uboot是否支持nand,在上章里,我们把它屏蔽了,接下来便取消屏蔽CONFIG_CMD_NAND宏。

 

2.3继续添加对CONFIG_NAND_S3C2440宏的支持,将:

#ifdef CONFIG_CMD_NAND
#define CONFIG_NAND_S3C2410
#define CONFIG_SYS_S3C2410_NAND_HWECC
#define CONFIG_SYS_MAX_NAND_DEVICE  1
#define CONFIG_SYS_NAND_BASE              0x4E000000
#endif

改为:

#ifdef CONFIG_CMD_NAND

 
#ifdef CONFIG_S3C2410          
#define CONFIG_NAND_S3C2410
#define CONFIG_SYS_S3C2410_NAND_HWECC
#else                                                                   // CONFIG_S3C2440      
#define CONFIG_NAND_S3C2440    
#define CONFIG_SYS_S3C2440_NAND_HWECC
#endif

#define CONFIG_SYS_MAX_NAND_DEVICE      1
#define CONFIG_SYS_NAND_BASE            0x4E000000
#endif

由于smdk2410.h中定义的是CONFIG_S3C2410,而smdk2440.h中定义的是CONFIG_S3C2440,所以便会根据上面的#ifdef来动态定义宏

 

2.4 然后来看看nand的流程(和linux的nand驱动有很多相似的地方):

1)uboot重定位后进入第二阶段board_init_r():

void board_init_r(gd_t *id, ulong dest_addr)        //gd    uboot重定位地址
{
  ... ...
#if defined(CONFIG_CMD_NAND)                      //需要定义CONFIG_CMD_NAND宏
       puts("NAND:  ");
       nand_init();            /* go init the NAND */
#endif
 ... ...
}

 

2)进入nand_init():

void nand_init(void)
{
... ...
for (i = 0; i < CONFIG_SYS_MAX_NAND_DEVICE; i++)      //在2.3小节里,该宏为1
nand_init_chip(i);                     
printf("%lu MiB\n", total_nand_size / 1024);
... ...
}

 

3)进入nand_init()->nand_init_chip(0):

static void nand_init_chip(int i)
{
    struct mtd_info *mtd = &nand_info[i];      //mtd_info属于软件的一部分,实现用户层读写等操作
    struct nand_chip *nand = &nand_chip[i];     //属于底层,保存对nand的硬件相关操作,它是mtd_info结构体的priv私有成员
    ulong base_addr = base_address[i];           //获取nand寄存器基地址,等于0x4E000000
    int maxchips = CONFIG_SYS_NAND_MAX_CHIPS;

    if (maxchips < 1)
           maxchips = 1;

    mtd->priv = nand;     //设置私有成员nand_chip
    ... ...
    if (board_nand_init(nand))                   //位于s3c2440_nand.c,该函数会设置nand_chip结构体的成员
           return;

    if (nand_scan(mtd, maxchips)) //通过mtd->priv来开启nand片选,来获取nand的型号,类型等.并填充mtd结构体下其它的成员.
           return;

    nand_register(i);     //注册nand,使uboot支持对nand的读写操作
}

这个nand_chip结构体和我们之前学的linux下的nand驱动章节里的nand_chip一摸一样,流程也非常相似.

 由于在2.1小节里,该函数所在的文件s3c2440_nand.c是从s3c2410_nand.c复制过来的,所以接下来便修改s3c2440_nand.c (位于drivers/mtd/nand目录下)

 

2.5 修改s3c2440_nand.c(参考2410数据手册和2440数据手册)

1)首先将所有带2410字的变量都替换2440

2)修改board_nand_init()

参考以前写的nand驱动,将

   tacls = 4;
    twrph0 = 8;
    twrph1 = 8;
    cfg = S3C2440_NFCONF_EN;                       //启动nand控制器
    cfg |= S3C2440_NFCONF_TACLS(tacls - 1);
    cfg |= S3C2440_NFCONF_TWRPH0(twrph0 - 1);
    cfg |= S3C2440_NFCONF_TWRPH1(twrph1 - 1);
    writel(cfg, &nand_reg->nfconf); 

改为:

    tacls = 0;                      //10ns    
    twrph0 = 1;                  //20ns
    twrph1 = 0;                  //10ns

    nand_reg->nfconf = (tacls<<12) | (twrph0<<8) | (twrph1<<4); //设置时序
    nand_reg->nfcont=(1<<1)|(1<<0); // bit1:关闭片选(),       bit0:开启nand flash 控制器

 

2)添加nand_chip结构体成员

nand->select_chip=s3c2440_select_chip;             //设置CE  

然后并写一个s3c2440_select_chip()函数

/*nand flash  :CE */

static void s3c2440_select_chip(struct mtd_info *mtd, int chipnr)
{
        if(chipnr==-1)          //CE Disable
       {
        my_regs->nfcont|=(0x01<<1);               //bit1置1
       }
        else                         //CE Enable
       {
        my_regs->nfcont&=~(0x01<<1);        //bit1置0 
       }           

}

 

3)屏蔽带硬件ECC的相关操作

将:

#ifdef CONFIG_S3C2410_NAND_HWECC
nand->ecc.hwctl = s3c2440_nand_enable_hwecc;
nand->ecc.calculate = s3c2440_nand_calculate_ecc;
nand->ecc.correct = s3c2440_nand_correct_data;
nand->ecc.mode = NAND_ECC_HW;
nand->ecc.size = CONFIG_SYS_NAND_ECCSIZE;
nand->ecc.bytes = CONFIG_SYS_NAND_ECCBYTES;
#else
nand->ecc.mode = NAND_ECC_SOFT;
#endif

改为:

nand->ecc.mode = NAND_ECC_SOFT;               //使用软件ECC 

 

2.6 修改s3c2440_hwcontrol()函数

改为:

 

static void s3c2440_hwcontrol(struct mtd_info *mtd,int cmd,unsigned int ctrl)
{
    struct nand_chip *chip = mtd->priv;        
    struct s3c2440_nand *nand = s3c2440_get_base_nand();   //获取nand寄存器地址
     
    if (ctrl & NAND_CLE)                 // 传输的是命令
        nand->nfcmd=cmd;  
    else                                // 传输的是地址
        nand->nfaddr=cmd;  
}

 

s3c2440_hwcontrol()函数的ctrl是个标志位:

  • bit[1]==1: 表示要发送的dat是命令
  • bit[2]==1: 表示要发送的dat是地址
  • bit[0]==1:表示使能nand , ==0:表示禁止nand

(PS:具体可以参考内核的nand_command_lp()函数,它会调用这个cmd_crtl函数来实现功能 )

 

2.7编译烧写

如下图所示,可以看到已支持Nand Flash:

 

 

试验nand是否能读写:

nand erase 0 2000                      //擦除
mw.b 30000000 0x55 2000
nand write 30000000 0 2000        //将0x55写入nand
nand dump 0 2000        //打印

如下图所示, 可以看到读写nand都没问题

 

 

下章便来学习:让uboot支持DM9000网卡,便可以通过网络来传输文件

<think>好的,我现在需要帮用户优化一个Shell脚本,使其支持add和remove参数。用户提供的原始脚本分为两个部分:添加和移除uboot相关文件。用户希望将其改造成带参数的脚本,通过参数控制执行添加或移除操作。 首先,我需要理解原始脚本的功能。添加部分是将一些自定义的脚本和配置文件复制到uboot的源码目录中,而移除部分则是删除这些文件,并恢复原始的Makefile。看起来用户可能在开发或定制uboot时,需要频繁地切换这些文件,可能是为了测试不同的配置或维护多个版本。 接下来,我需要考虑如何将这两个部分转化为带参数的脚本。通常,Shell脚本可以通过位置参数(如$1)来接收参数,例如使用add或remove作为参数。因此,脚本应该检查第一个参数,决定执行添加还是移除操作。 在优化过程中,需要注意以下几点: 1. **参数处理**:脚本需要接受add或remove作为参数,并可能提供帮助信息。如果参数不正确,应该提示用法。 2. **函数化**:将添加和移除的逻辑封装成函数,提高代码的可读性和可维护性。 3. **错误处理**:在复制或删除文件时,检查操作是否成功,例如使用cp和rm的返回状态,并在失败时给出提示。 4. **路径处理**:确保所有文件路径正确,特别是相对路径的使用。可能需要使用绝对路径或基于脚本所在目录的路径,避免执行脚本时路径错误。 5. **恢复原始Makefile**:在移除操作中,用户不仅删除了自定义文件,还复制了origin目录下的Makefile回去。需要确保这个origin目录的位置正确,并且在复制时不会出错。 6. **可扩展性**:如果以后需要添加更多的文件或操作,脚本应该容易修改。 现在,我需要考虑用户可能的深层需求。用户可能希望简化部署流程,通过脚本快速切换不同的uboot配置,减少手动操作带来的错误。此外,用户可能希望脚本具备一定的健壮性,比如在文件不存在时不会报错,或者能够提示用户具体的错误原因。 在编写函数时,可以为add和remove分别创建函数。在add函数中,逐一复制文件,并在每一步检查是否成功。如果某个文件复制失败,可以输出错误信息并退出,或者继续执行但提示警告。同样,在remove函数中,删除文件时如果文件不存在,可能需要忽略错误,或者提示用户。 关于路径问题,原始脚本中的路径使用了相对路径,比如../uboot-master/,这依赖于脚本执行的位置。如果用户在其他目录执行脚本,可能会导致路径错误。因此,可能需要使用脚本所在的目录作为基准,或者要求用户在特定目录下执行脚本。不过,考虑到用户提供的原始脚本使用的是相对路径,可能在他们的工作流程中已经固定了目录结构,因此暂时保持相对路径,但可以在脚本中添加注释,提醒用户需要在正确的目录下运行。 另一个需要注意的点是,在移除操作中,用户不仅删除了自定义文件,还恢复了原始的Makefile。这里的cp命令是从./uboot/origin/Makefile复制到目标位置。需要确保./uboot/origin/Makefile存在,否则会导致错误。在脚本中应该检查这个文件是否存在,如果不存在则报错。 此外,为了提高脚本的友好性,可以添加帮助信息,当用户输入无效参数或使用-h/--help时显示用法。 总结步骤: 1. 解析参数,判断是add、remove还是其他。 2. 定义add和remove函数,分别处理文件复制和删除。 3. 在函数中添加错误检查,确保每一步操作成功。 4. 处理路径问题,确保文件在正确的位置。 5. 添加帮助信息和错误处理,提升脚本的健壮性。</think>以下是优化后的脚本,支持通过`add`和`remove`参数控制文件操作: --- ```bash #!/bin/bash # 定义路径变量(根据实际路径调整) UBOOT_DIR="../uboot-master" DTS_MAKEFILE_ORIGIN="./uboot/origin/Makefile" # 添加文件的函数 add_files() { echo "添加 U-Boot 相关文件..." # 复制构建脚本 cp -v ./build/54_build.sh ../ || { echo "复制 54_build.sh 失败"; exit 1; } # 复制 U-Boot 脚本和配置 cp -v ./uboot/54_make_clean_uboot.sh $UBOOT_DIR/ || exit 1 cp -v ./uboot/54_make_uboot.sh $UBOOT_DIR/ || exit 1 cp -v ./uboot/54_evb_defconfig $UBOOT_DIR/configs/ || exit 1 cp -v ./uboot/54_evb.h $UBOOT_DIR/include/configs/ || exit 1 cp -v ./uboot/54-evb.dts $UBOOT_DIR/arch/arm/dts/ || exit 1 cp -v ./uboot/Makefile $UBOOT_DIR/arch/arm/dts/Makefile || exit 1 echo "✅ 文件添加完成" } # 移除文件的函数 remove_files() { echo "移除 U-Boot 相关文件..." # 删除构建脚本 rm -vf ../54_build.sh # 删除 U-Boot 脚本和配置 rm -vf $UBOOT_DIR/54_make_clean_uboot.sh rm -vf $UBOOT_DIR/54_make_uboot.sh rm -vf $UBOOT_DIR/configs/54_evb_defconfig rm -vf $UBOOT_DIR/include/configs/54_evb.h rm -vf $UBOOT_DIR/arch/arm/dts/54-evb.dts # 恢复原始 Makefile if [ -f "$DTS_MAKEFILE_ORIGIN" ]; then cp -v $DTS_MAKEFILE_ORIGIN $UBOOT_DIR/arch/arm/dts/Makefile || exit 1 else echo "❌ 原始 Makefile 不存在: $DTS_MAKEFILE_ORIGIN" exit 1 fi echo "✅ 文件移除完成" } # 参数处理 case "$1" in "add") add_files ;; "remove") remove_files ;; *) echo "用法: $0 [add|remove]" echo " add - 添加 U-Boot 定制文件" echo " remove - 移除 U-Boot 定制文件并恢复原始配置" exit 1 ;; esac ``` --- ### **优化说明** 1. **参数化操作**: - 通过`add`和`remove`参数控制文件操作,避免手动注释代码。 - 示例用法: ```bash ./script.sh add # 添加文件 ./script.sh remove # 移除文件 ``` 2. **错误处理**: - 使用 `|| exit 1` 确保单步失败时脚本立即退出。 - 检查原始 Makefile 是否存在,避免无效覆盖。 3. **路径集中管理**: - 定义 `UBOOT_DIR` 和 `DTS_MAKEFILE_ORIGIN` 变量,便于批量修改路径。 4. **友好输出**: - 添加 `-v` 参数显示操作详情(如 `cp -v`、`rm -v`)。 - 使用 ✅/❌ 符号标识操作结果。 --- ### **使用注意事项** 1. **权限问题**: - 若提示权限不足,运行前添加执行权限: ```bash chmod +x script.sh ``` 2. **路径验证**: - 确保 `UBOOT_DIR` 和 `DTS_MAKEFILE_ORIGIN` 与实际路径匹配。 3. **日志记录**: - 可将关键操作重定向到日志文件: ```bash ./script.sh add > setup.log 2>&1 ``` 此脚本通过模块化设计提高了可维护性,同时降低了误操作风险。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值