对比了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信息目前看不出什么区别。
扫一扫
1565
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
