对比了RK3288的Ubuntu14.04和按官网编译的Android的log信息后发现很多不一样,鉴于官网上的编译方法是针对开发板的,所以烧录后内核起不来,也要查看一下硬件,先查一下各路电压。
电源名称 | 电压理论值(V) | 实际电压值(V) | 状态 | ||
---|---|---|---|---|---|
VCC_DC | 5 | 5 | 适配器和FPC出来的5v电压 | ||
VCC_SYSIN | 3.7~4.2 | 3.9 | 电池电压,通过TPS61232转出VCC_SYS | ||
VCC_SYS | 5 | 4.98 | 8846的输入,也是该系统的主电压 | ||
VCC_DDR | 1.5 | 1.5 | |||
VCC_20 | 2 | 1.99 | 好像是8846第4路主输出给自己ldo的输入端 | ||
VCC_IO | 3.3 | 3.3 | EMMC RK3288部分电压,和WiFi蓝牙及一些电路的供电 | ||
VDD_LOG | 1.1 | 1.19 | RK3288内的LOGIC部分电压 | ||
VDDIO_SD | 3.3 | 3.3 | 给RK3288的Internal BootRom供电 | ||
VDD10_LCD | 1 | 1.04 | 给RK3288内的EDP和LVDS部分供电 | 烧录前OFF | |
VCCA_CODEC | 3.3 | 2.79 | 给音频ALC5640供电 | 烧录前OFF | 不一致 |
VCC_TP | 3.3 | 3.3 | 给TP小板供电 | 烧录前OFF | |
VCC18_LCD | 1.8 | 1.84 | 给RK3288内的EDP和LVDS部分供电 | 烧录前OFF | |
VDD_10 | 1 | 1.09 | 都是去RK3288用了三四处 | ||
VCC_18 | 1.8 | 1.79 | 用到了RK3288和转VCCIO_CODEC | ||
VCCIO_PMU | 3.3 | 3.28 | 去RK3288和8846自己,以及耳机电路 | ||
VCC33_RTC | 3.3 | 3.3 | 由VCC_SYS转出用来给晶振电源按键等 | ||
VCC_SD | 3.3 | 3.3 | 由VCC_IO转来,给TF卡 | ||
VCC_WL | 1.8 | 1.79 | 由VCC_18转来给WiFi蓝牙用 | ||
VCC_LCD | 3.3 | 1.1 | 给RK3288内的EDP和LVDS供电,且转出FPC | 不一致 | |
VCC50_USB | 无电压 | 4.76 | 很显然 | ||
VDD_CPU | 1 | 1.35 | VCC_SYS通过SY827转出 | ||
VDD_GPU | 1 | 0.89 | VCC_SYS通过SY827转出 | ||
+V16P0_BKLT_IN | 5 | 4.97 | |||
VCCIO_FLASH | 1.8 | 1.8 | 给EMMC供电也去了RK3288的PIN由VCC_IO出来 | ||
VSYS_DISP | 3.3 | 0 | 背光使能 | ||
VCCIO_CODEC | 1.8 | 1.79 | |||
硬件上似乎还看不出问题,这里可能要去dts查了,先放下来,因为看到别人的博客,我在想既然Android是基于Linux内核起来的,那就把之前调试好的Ubuntu系统的东西烧进去,然后烧录Android的文件系统看一下log信息。
烧录的是Ubuntu的kernel.img发现log信息和Android的log信息,几乎一模一样。
烧录的是Ubuntu的kernelimg和resource.img文件报错信息,重启多次的log会有两个版本,其一个是kernel启动很短的过程,在DDR DEBUG的过程中停下来的,另一个是比较和之前关掉es8323的过程是一样的,从这里总结出的信息是不是firefly给出的编译方法出来的很多驱动源码还是在kernel中,并没有把很多厂商的驱动源码放到硬件抽象层。还有呢?
根据目前的信息掌握度,发现有一个Android的硬件抽象层,这一层放了很多再Linux中原本放在内核中的硬件驱动程序,所以理论上理解时,从开发板上移植到自己的板子时,会出现硬件抽象层的驱动不对劲,然后自己的硬件是不能用的,这可以理解,但关内核什么事呢?
接下来还是一层一层的往下关闭kernel源码中的硬件驱动,这个驱动不止在自己的板子上跑,也要在开发板上跑,这样来看看这个Android内核到底是个什么鬼。当然资料要继续看了。
把关闭了es8323的烧录文件烧到了开发板上,和想的一样当然也不会出现es8323,不过通过对比发现开发板和司板会有一些可能引起注意的信息:“[ 1.242285] mmcblk0: p1 p2 p3 p4 p5 p6 p7 p8 p9 p10 p11 p12 p13 p141358..dw_mci_set_ios: no card. [mmc1]”这条信息显示的内容是在司板上的,和开发板对比下来,好像mmc1没起来,贴一下开发板的信息:“[ 1.105850] mmcblk0: p1 p2 p3 p4 p5 p6 p7 p8 p9 p10 p11 p12 p13[ 1.107046] dwmmc_rockchip ff0c0000.rksdmmc: DW MMC controller at irq 64, 32 bit host data width, 256 deep fifo”开发板上的信息似乎是起来的。贴一张对比图片
这个信息,没仔细看出来什么。
接下来还是一步一步来,关闭log信息现实的最后一个“[ 1.366166] rockchip-spdif-card rockchip-spdif-card.25: rk-hdmi-spdif-hifi <-> ff880000.rockchip-spdif mapping ok”关闭spdif
根据之前关闭es8323的思路,这次直接在Kconfig文件中取消这个选项看看会报什么错,但是先还是在menuconfig下改一下看
编译的报错信息这样显示
根据报错显示,grep一下看看发现好多文件都有,准备一个一个来看,根据上次经验在./sound/soc/rockchip/hdmiin_audio.c这个文件可能性很大,先从这里做起
打开./sound/soc/rockchip/hdmiin_audio.c文件找到“snd_hdmiin_capture_mode”共有两处,注释掉。
编译下来还是包一样的错误,仔细再看看细节上搞错了
grep的是“snd_hdmiin_capture_mode”那么应该在和“snd_pcm_capture_open”相关的文件中改,所以刚刚在./sound/soc/rockchip/hdmiin_audio.c中不应该立即改,先把注释取消了。在./sound/core/pcm_native.c文件中注释掉
从信息看,确实把第二个错误注释掉了。继续grep -r "snd_stop_hdmi_in_audio_route" ./ 根据结果来显示
根据对应关系,应先打开./sound/soc/rockchip/hdmiin_audio.c这个文件注释掉snd_stop_hdmi_in_audio_route先看看结果
报错依旧
接下来再看相关的./drivers/media/video/rk_camsys/tc358749.c这个文件把其中的snd_stop_hdmi_in_audio_route注释掉
因为发现注释掉的信息,在我注释之前也会看到其他的注释信息,所以我住校的信息都会加上标识。
编译完竟然还有报错
这个显示一个报错了,自信看是snd_start_hdmi_inaudio_route,没仔细看到,有start和stop之分,现在把start也注释掉,保存编译。
还是报错
还是会报错,根据报错信息只要在hamiin_audio_store关键字相关的文件中处理就行,报错的话去tc358749文件中去看看,注释掉start相关
竟然编译通过了,看一下结果。这点上我很奇怪根据报错信息,不显示tc358749.c的文件里,应该在hdmiin_audio相关的文件里,如果不是之前有在处理这个 undefined reference to `snd_stop_hdmi_in_audio_route'使知道有这个tc358749.c文件可能就不知道怎么解决了,这说明有些报错不一定全部在报错显示的相关文件里,如果实在找不到错误所在,就全部搜索,注释试试。
把编译结果烧录到开发板和司板,开发板依然能启动,各自的log信息目前看不出什么区别。