uboot命令添加不上去.怎么回事

1. 首先，介绍以下有关Uboot的命令定义。

每个命令都是通过U_BOOT_CMD宏来定义的。这个宏定义了一个相关的结构体，文件是uboot/include/command.h,结构体为cmd_tbl_s。

具体的命令定义为：

#define U_BOOT_CMD(name,maxargs,rep,cmd,usage,help) \

cmd_tbl_t __u_boot_cmd_##name Struct_Section = {#name, maxargs, rep, cmd, usage, help}

U_BOOT_CMD(name,maxargs,repeatable,command,"usage","help")

name: is the name of the commad. THIS IS NOT a string.

maxargs: the maximumn numbers of arguments this function takes

command: Function pointer (*cmd)(struct cmd_tbl_s *, int, int, char *[])

usage: Short description. This is a string

help:long description. This is a string

每一个 U-Boot 命令有一个结构体来描述。结构体包含的成员变量:命令名称、最大参，数个数、重复数、命令执行函数、用法、帮助。

而相关命令的具体执行在uboot/common/cmd_xxxx.c文件中实现的。

接着，以我自己添加的MYTEST命令为例子，讲述添加命令的过程。

1）在对应的开发板配置文件中，添加相应命令的宏定义。如：在uboot/include/configs/mx25_3stack.h文件中，添加#define CONFIG_CMD_MYTEST。

当然，也可以在uboot/include/config_cmd_default.h文件中，添加该命令的宏定义。

2）在uboot/common/目录下，建立相应的命令执行文件，如cmd_mytest.c，注意命名的规范，必须是cmd_xxx.c才行。

里面的内容也是又格式要求的，如函数的格式，必须指定参数的；还有相应结尾部分的U_BOOT_CMD定义部分，使不能缺省的。如果命令不需要跟参数，则把maxargs设置为1即可了。

在U_BOOT_CMD中指明的命令执行函数，在该函数中，就是我们要设计的命令 *** 作内容。也就是说，这部分完成的我们定制的命令的功能的。还有，要在uboot/comman/Makefile文件中，加入生成相应的.o文件才可以的。

3）重新编译uboot文件，会在uboot/common/中，生成相应的.o文件。将生成的uboot下载到开发板后，通过终端可以看到我们加入的命令。在终端中输入问号或者help命令即可。执行该命令，只学要输入命令的名字，在回车就可以运行了。

通过在uboot中加入命令，可以完成我们的一些特定的 *** 作，实现调试和测试目的等。

首先icmp和arp是没有关系的！icmp承载于网络层他的协议号好像是1，其中有8种类型比如host不可达、超时等这是用来测试网络连通性的一种控制信息协议。ARP是以太网技术中最重要的一种协议地址解析协议，它承载于osi第二层类型号好像是806，因为以太网是多路访问的一种，所以为了解析其以太网物理MAC地址必须要用ARP协议，这种协议发送的request包中目标MAC地址为全1广播地址，reply包以自己的mac和IP地址为源，目标地址以目标主机MAC和IP地址为目标封装成帧后发送出去！虽然说它是链路层协议,但是他有网络层的概念IP地址，我抓包看到过ARP协议中有协议类型800这是IP协议的类型，因为他要用IP地址来解析MAC地址，所以每个网络层以上的设备都会有基于ARP的缓存，路由交换设备中的命令是showarp！windows中的命令是arp-a，有了这种缓存大大提高了互联网访问速度！好了说了这么多可能楼主认为我说的是废话！那么我就开始所问所答了！第一，ping命令是ICMP的一种形式，它属于ICMP，当然tracert也属于ICMP！ICMP与ARP没有任何关系，一个是网络层协议，一个是数据链路层协议！在功能方面上也没有什么交集的地方，唯一共同点就是都涉及IP地址。第二，我不会写什么UBOOT代码，但是既然承载在internet上那么他就应该遵循网络体系结构为了让网络统一化，IEEE和国际标准化组织iso统一定义了接入层及上层协议标准！当你ping时会发送ARP帧是因为你在以太网的环境中，为什么会发送ARP是因为在计算机刚刚启动的时候是没有对方主机的通信地址的！ping是为了测试与对方主机的连通性，所以需要知道对方主机的地址虽然你知道了目的的IP地址，但还需要其MAC地址，所以在ping之前就会发送ARP帧，主机中ARP默认缓存老化时间应该是10分钟。也就是说，自ARP解析10分钟后ARP缓存条目会自动清除。第三，arp帧发送和恢复确实不一样！一个用广播一个是单播好了！不管我写的是不是废话！辛辛苦苦写了这些不容易啊！接下来就看LZ你的了！^_^！

最近我们在做一个LCM两屏或三屏兼容的问题,所以首先要在uboot里面读出各屏的id,然后再将读得到的id传给recovery和kernel,实现机器的正常显示.

一.首先实现uboot读lcm的id.

1.bootable/bootloader/lk/target/msm7627a_sku3_Q6_D/rules.mk是uboot里面宏开关,打开所显示的屏宏

DEFINES += DISPLAY_MIPI_CMD_PANEL_ILI9487=1

DEFINES += DISPLAY_MIPI_CMD_PANEL_HX8357=1

2.去初始化mipi的地方先读id. bootable/bootloader/lk/platform/msm_shared/mipi_dsi.c

在函数int mipi_dsi_panel_initialize(struct mipi_dsi_panel_config *pinfo)

{

......

#if defined(DISPLAY_MIPI_CMD_PANEL_ILI9487)||defined(DISPLAY_MIPI_CMD_PANEL_HX8357)

mipi_dsi_cmd_bta_sw_trigger()

dat = mipi_viroyal_manufacture_id()

if(dat == 0x90)

{

lcm_flag = 8357 //hx8357-c

}

else

{

lcm_flag = 9487 //ili9487

}

pinfo_tmp =get_panel_info()

memcpy(pinfo, pinfo_tmp, sizeof(struct mipi_dsi_panel_config))

#endif

......

}

3.读到id后再初始化屏

struct mipi_dsi_panel_config *get_panel_info(void)

{

.........

#elif (DISPLAY_MIPI_CMD_PANEL_ILI9487)||(DISPLAY_MIPI_CMD_PANEL_HX8357)

if (lcm_flag == 8357)

return &hx8357_cmd_panel_info

else

return &ili9487_cmd_panel_info

#endif

..........

}

这样在uboot里面就成功可以显示图片了,下面是如何将lcm_flag的值传给kernel了.

二.传lcm_flag给kernel

1.uboot里面要做的bootable/bootloader/lk/app/aboot/aboot.c

其实原生态的Android系统就有一个将uboot传给kernel的例子,那就是跟踪代码static const char *boot_splash = " splash=1"

我做的也是效仿系统做的,先定义一个字符串

static const char *lcm_flg_ili9486 = " lcmflag=9486"

static const char *lcm_flg_nt35310 = " lcmflag=5310"

然后在下面的函数copy到kernel

void boot_linux(void *kernel, unsigned *tags,

const char *cmdline, unsigned machtype,

void *ramdisk, unsigned ramdisk_size)

{

.....

if(!boot_into_recovery)

{

cmdline_len += strlen(boot_splash)

#if DISPLAY_TYPE_MIPI

if (lcm_flag == 8357)

cmdline_len += strlen(lcm_flg_hx8357c)

else

cmdline_len += strlen(lcm_flg_ili9487)

#endif

.....

if (!boot_into_recovery)

{

#if DISPLAY_TYPE_MIPI

if (lcm_flag == 8357)

src = lcm_flg_hx8357c

else

src = lcm_flg_ili9487

#endif

if (have_cmdline) --dst

while ((*dst++ = *src++))

.....

}

这样uboot里面的动作就做完了,即是将uboot里面的数据copy到一个数组里面,这个数组能从uboot传给kernel.

三.kernel接受uboot传来的字符串

msm7627a/kernel/arch/arm/mach-msm/board-msm7x27a.c

在这个函数里面接受(依据自己用的平台阿,要灵活),同样是模仿boot_splash,在代码里添加接受字符串,并转化为数字

/* LK lcm_flag, 0 - off, 1 - on */

int lcm_flag = 0

static int __init lk_lcmflag_setup(char *str)

{

lcm_flag = simple_strtol(str, NULL, 0)

printk("lcmflag = %d\n", lcm_flag)

return 1

}

__setup("lcmflag=", lk_lcmflag_setup)

这样就算是取到lcm_flag的值了,然后在具体的驱动中extern int lcm_flag即可,简单吧.其实技术就那样,很怕人认真,呵呵.开个玩笑.

四.把uboot里面的id还要给recovery

上面做完其实lcm可以在uboot和kernel正常显示了,但有一个位置显示会比较诡异,那就是进入"恢复出厂设置"的时候,会有一个诡异的画面,哥研究了2天,最终得出结论原来是recovery没有正常的接受到正确的屏的id,于是乎就将正确的id传给内核

还是从bootable/bootloader/lk/app/aboot/aboot.c入手,现在就是要记住关键字static const char *boot_splash_recovery = " splash=0"

我就仿效boot_splash_recovery将lcm_flag添加再下面的函数中:

void boot_linux(void *kernel, unsigned *tags,

const char *cmdline, unsigned machtype,

void *ramdisk, unsigned ramdisk_size)

{

....

#if DISPLAY_SPLASH_IN_KERNEL

if(!boot_into_recovery)

{

........

}

else

{

cmdline_len += strlen(boot_splash_recovery)

#if DISPLAY_TYPE_MIPI

if (lcm_flag == 8357)

cmdline_len += strlen(lcm_flg_hx8357c)

else

cmdline_len += strlen(lcm_flg_ili9487)

#endif

}

#endif

....

if(!boot_into_recovery)

{

.............

}

else

{

src = boot_splash_recovery

if (have_cmdline) --dst

have_cmdline = 1

while ((*dst++ = *src++))

#if DISPLAY_TYPE_MIPI

if (lcm_flag == 8357)

src = lcm_flg_hx8357c

else

src = lcm_flg_ili9487

#endif

if (have_cmdline) --dst

while ((*dst++ = *src++))

}

......

}

这样recovery就能完全接受uboot里面传来的值,其他的就不用做了.到这里整个系统都可以完全显示完整正确的图片.

---