从零移植uboot 2017 到nuc970(第二十三天)(第一阶段结束)
2017-03-31 19:15
656 查看
仔細跟着串口信息和瀏覽源代碼,發現昨天的判斷有些失誤。
但是解決這個問題,比較簡單採取註釋一個函數的方式
原函數
測試下問題解決
但有出現新的問題 卡在mmc 之後調用的一個函數裏
這裏我並沒有定義config_generic_mmc但是卻運行了這個函數,比較奇怪
和以前的config_spl_build一樣,好像默認的就會添加他們,我確定在kconfig的defconig中沒有定義,在/include/conifgs/xxxx.h中也沒有定義,不過現在比較簡單的註釋了就行。
然後添加打印信息,確定卡在哪裏
經過大量的建立debug點,然後發現問題在這裏
實際上這個代碼在於 size_t到loff_t的隱含強制轉換,但是看到的就是0x10000被轉換成B8000000,且mtd->size也是不正確的
這裏面提議個問題:1.強制轉換 int到longlong是否會影響數據準確性?
2. 32位mcu中long long的長度是幾位大小?
最後將
結果成功了
註釋掉debug信息看下
![](https://oscdn.geek-share.com/Uploads/Images/Content/202007/14/cd6a5f00e406bfb4ae764add3bc1e549)
![](https://oscdn.geek-share.com/Uploads/Images/Content/202007/14/9431453c1a0f66c5d84050ecce209baa)
到此第一階段的工作就結束了,實現了簡單的uboot2017移植到nuc972,歷時23天。還存在很多問題,還沒有增加很多功能,還沒有解析更多的代碼。還沒有解決一些遺留問題。
static void nand_init_chip(int i) { struct nand_chip *nand = &nand_chip[i]; struct mtd_info *mtd = nand_to_mtd(nand); ulong base_addr = base_address[i]; int maxchips = CONFIG_SYS_NAND_MAX_CHIPS; if (maxchips < 1) maxchips = 1; nand->IO_ADDR_R = nand->IO_ADDR_W = (void __iomem *)base_addr; if (board_nand_init(nand))//其中我調用過nand_get_flash_type return; if (nand_scan(mtd, maxchips))//又會調用一邊,問題就是第二遍的時候除了問題 return; nand_register(i, mtd); }
debug("run here\n"); /* Select the device */ chip->select_chip(mtd, 0); /* Reset the chip, required by some chips (e.g. Micron MT29FxGxxxxx) * after power-up. */ debug("run here2\n");//也就是說出問題的地方就是chip->select_chip(mtd, 0);
/* select chip */ //其代碼實現比較簡單,但是這裏還是有點疑問,爲什麼會出現這裏hang的現象? static void nuc970_nand_select_chip(struct mtd_info *mtd, int chip) { writel((readl(REG_SMCSR)&(~0x06000000))|0x04000000, REG_SMCSR); return; }這裏算是一個問題:該段代碼在第一次運行沒有問題,第二次就會出現問題,唯一的特點是兩次間隔時間非常小,是否是這樣造成的nand不能響應呢?
但是解決這個問題,比較簡單採取註釋一個函數的方式
原函數
int nand_scan(struct mtd_info *mtd, int maxchips) { int ret; ret = nand_scan_ident(mtd, maxchips, NULL); if (!ret) ret = nand_scan_tail(mtd); return ret; }修改如下
int nand_scan(struct mtd_info *mtd, int maxchips) { int ret; //ret = nand_scan_ident(mtd, maxchips, NULL); //if (!ret) ret = nand_scan_tail(mtd); return ret; }
測試下問題解決
running success get_flash_type() running check for a chip() running the end of this function() running mtd->writesize() running m_i32smrasize() 0 MiB initcall: E09650 (relocated to 3FAC650) MMC: initcall: E09620 (relocated to 3FAC620)
但有出現新的問題 卡在mmc 之後調用的一個函數裏
這裏我並沒有定義config_generic_mmc但是卻運行了這個函數,比較奇怪
和以前的config_spl_build一樣,好像默認的就會添加他們,我確定在kconfig的defconig中沒有定義,在/include/conifgs/xxxx.h中也沒有定義,不過現在比較簡單的註釋了就行。
#ifdef CONFIG_GENERIC_MMC initr_mmc, #endif接着繼續
running mtd->writesize() running m_i32smrasize() 0 MiB initcall: E09620 (relocated to 3FAC620)
然後添加打印信息,確定卡在哪裏
initcall: E0963C (relocated to 3FAC63C) run initr_env
debug("run initr_env\n"); /* initialize environment */ if (should_load_env()) env_relocate(); else set_default_env(NULL); #ifdef CONFIG_OF_CONTROL setenv_addr("fdtcontroladdr", gd->fdt_blob); #endif debug("run getenv_ulong\n");所以卡在 should_load_env或者env_relocate或者set_default_env,接下來就略去繁瑣的確定環節
經過大量的建立debug點,然後發現問題在這裏
running check for a chip()
running the end of this function()
running mtd->writesize()
running m_i32smrasize()
0 MiB
initcall: E0963C (relocated to 3FAC63C) run initr_env
run env_relocate
run env_relocate_spec
run readenv
nand_info[0]
amount_loaded,CONFIG_ENV_SIZE,offset,end:0,10000,80000,90000
ofs,mtd->size:B8000000,80000
return -einval
ofs,mtd->size:B8000000,80000
return -einval
實際上這個代碼在於 size_t到loff_t的隱含強制轉換,但是看到的就是0x10000被轉換成B8000000,且mtd->size也是不正確的
這裏面提議個問題:1.強制轉換 int到longlong是否會影響數據準確性?
2. 32位mcu中long long的長度是幾位大小?
最後將
static inline int nand_block_isbad(struct mtd_info *info, loff_t ofs) { return mtd_block_isbad(info, ofs);//修改成info->_block_isbad;也就是直接調用nand_block_isbad,而不經過mtd_block_isbad }實際上mtd_block_isbad封裝了nand_block_isbad。
結果成功了
initcall: E09780 (relocated to 3FAC780) initcall: E10AC0 (relocated to 3FB3AC0) initcall: E09638 (relocated to 3FAC638) initcall: E0CA3C (relocated to 3FAFA3C) In: serial Out: serial Err: serial Initial value for argc=3 Final value for argc=3 Initial value for argc=3 Final value for argc=3 Initial value for argc=3 Final value for argc=3 initcall: E00D70 (relocated to 3FA3D70) initcall: E09628 (relocated to 3FAC628) initcall: E09608 (relocated to 3FAC608) initcall: E095EC (relocated to 3FAC5EC) Net: Net Initialization Skipped No ethernet found. initcall: E095E0 (relocated to 3FAC5E0) ### main_loop entered: bootdelay=2 ### main_loop: bootcmd="<UNDEFINED>" =>
註釋掉debug信息看下
到此第一階段的工作就結束了,實現了簡單的uboot2017移植到nuc972,歷時23天。還存在很多問題,還沒有增加很多功能,還沒有解析更多的代碼。還沒有解決一些遺留問題。
相关文章推荐
- 独家 | Face++印奇:AI是场持久战,但第一阶段明年结束
- 从零移植uboot 2017 到nuc970(第十一天)
- 从零移植uboot 2017 到nuc970(第十六天)
- 从零移植uboot 2017 到nuc970(第一天)
- 从零移植uboot 2017 到nuc970(第二十天)
- 软件工程&软件专业实习第一阶段结束
- 从零移植uboot 2017 到nuc970(第二天)
- 从零移植uboot 2017 到nuc970(第三天)
- 从零移植uboot 2017 到nuc970(第六天)
- 从零移植uboot 2017 到nuc970(第八天)
- 从零移植uboot 2017 到nuc970(第十五天)
- 第一阶段工作结束
- 第一阶段的结束
- 校园跳蚤市场-第一阶段结束及总结
- 从零移植uboot 2017 到nuc970(第四天)
- 从零移植uboot 2017 到nuc970(第二十二天)
- 从零移植uboot 2017 到nuc970(第五天)
- 从零移植uboot 2017 到nuc970(第七天)
- 从零移植uboot 2017 到nuc970(第十天)
- 从零移植uboot 2017 到nuc970(第十四天)