如何在Android里面uboot传参数

如何在Android里面uboot传参数,第1张

最近我们在做一个LCM两屏或三屏兼容的问题,所以首先要在uboot里面读出各屏的id,然后再将读得到的id传给recovery和kernel,实现机器的正常显示
一首先实现uboot读lcm的id
1bootable/bootloader/lk/target/msm7627a_sku3_Q6_D/rulesmk是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_dsic
函数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
1uboot里面要做的bootable/bootloader/lk/app/aboot/abootc
其实原生态的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-msm7x27ac
在这个函数里面接受(依据自己用的平台阿,要灵活),同样是模仿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/abootc入手,现在就是要记住关键字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里面传来的值,其他的就不用做了到这里整个系统都可以完全显示完整正确的

开机出现UBOOT,是与您关机前的不当 *** 作有关系吧?比如:玩游戏、看视频、 *** 作大的东西、使用电脑时间长造成的卡引起的吧?或下载了不合适的东西、或删除了系统文件、或断电关机等,故障不会无缘无故的发生吧?
按电源键反复开关机试试,放一段时间试试,确实不可以就重装系统吧,如果自己重装不了,花30元到维修那里找维修的人帮助您。
只要自己的电脑不卡机、蓝屏、突然关机,开机就不会这样了。
有问题请您追问我。

网络机顶盒启动反应太慢的一般原因和解决方法:
1、机顶盒的硬件配置较低或者运行过程中硬件使用率过高(如CPU占用率、运存占用等),导致机顶盒系统运行又卡又慢,可以先重启机顶盒解决,如果重启无效,一般只能尝试进入系统设置界面,将机顶盒的系统还原为出厂设置来解决;如果是配置太低,则只能更换性能更好的机顶盒替代使用。
2、用户本身的带宽不足导致观看网络视频时又卡又慢,因为观看网络电视节目时,机顶盒需要上下行数据,需要占用较多的网络资源,如果用户带宽不足或者有其他设备在下载数据导致网速变慢,则会发生上述现象;建议暂停其他设备的下载任务或者联系网络服务商购买、增加网络带宽来解决;
3、网络服务提供商的服务器或者网络视频服务商的服务器拥挤或故障导致机顶盒连接播放资源又卡又慢,一般只能等待对方修复故障才能恢复正常;用户可以换个时间段再使用机顶盒;
4、另外,机顶盒硬件故障也可能导致又卡又慢,甚至出现死机等,如机顶盒出现频繁死机,建议及时联系售后进行检修。


欢迎分享,转载请注明来源:内存溢出

原文地址: https://outofmemory.cn/yw/13358364.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-07-21
下一篇 2023-07-21

发表评论

登录后才能评论

评论列表(0条)

保存