前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >[ 物联网篇 ] 09 - Buildroot中构建NXP IMX8MM

[ 物联网篇 ] 09 - Buildroot中构建NXP IMX8MM

作者头像
程序手艺人
发布2019-06-14 20:40:25
2.5K0
发布2019-06-14 20:40:25
举报
文章被收录于专栏:程序手艺人程序手艺人

遇到的两个问题 :

  1. 下载buildroot-2019.05-rc2版本,构建freescale_imx8mmevk_defconfig(由于imx8mmevk 和imx8mqevk差别不大,因此在imx8mqevk的基础上得到imx8mmevk) , 构建出的固件烧录到开发板,发现无法启动
make freescale_imx8mmevk_defconfig 
make 
// buildroot-2019.05-rc2/output/images 目录得到固件
├── bl31.bin
├── boot.vfat
├── fsl-imx8mm-evk.dtb
├── Image
├── imx8-boot-sd.bin
├── imx-boot-imx8mmevk-sd.bin-flash_evk
├── lpddr4_pmu_train_fw.bin
├── rootfs.ext2
├── rootfs.ext4 -> rootfs.ext2
├── rootfs.tar
├── sdcard.img
├── signed_hdmi_imx8m.bin
├── u-boot.bin
├── u-boot.imx
├── u-boot.itb
├── u-boot-nodtb.bin
├── u-boot-spl.bin
└── u-boot-spl-ddr.bin

烧录固件之后,发现一行打印也没有,代表uboot 都无法启动,而buildroot uboot 打包固件的脚本对应 : buildroot-2019.05-rc2/board/freescale/common/imx/imx8-bootloader-prepare.sh ,应该是该脚本出现问题,该问题并没有深入研究,

而是把Yocto 构建出的最小系统得到的imx-boot-imx8mmevk-sd.bin-flash_evk直接放到buildroot 打包固件的配置文件中

buildroot-2019.05-rc2/board/freescale/common/imx/genimage.cfg.template_imx8
image sdcard.img {
  hdimage {
  }

  partition imx-boot {
    in-partition-table = "no"
     # image = "imx8-boot-sd.bin"
     # 这里是重点
    image = "imx-boot-imx8mmevk-sd.bin-flash_evk"
    offset = %IMXOFFSET%
  }

  partition boot {
    partition-type = 0xC
    bootable = "true"
    image = "boot.vfat"
    offset = 8M
  }

  partition rootfs {
    partition-type = 0x83
    image = "rootfs.ext2"
  }
}

替换了uboot之后,打包出的sdcard.img 烧录进去,确实可以启动,内核也启动起来了,但是无法进入文件系统

[    4.194949] VSD_3V3: disabling
[    4.199098] ALSA device list:
[    4.202081]   #0: wm8524-audio
[    4.205139]   #1: imx-spdif
[    4.207946]   #2: imx-audio-micfil
[    4.229743] EXT4-fs (mmcblk2p2): recovery complete
[    4.235308] EXT4-fs (mmcblk2p2): mounted filesystem with ordered data mode. Opts: (null)
[    4.243484] VFS: Mounted root (ext4 filesystem) on device 179:2.
[    4.251138] devtmpfs: mounted
[    4.254447] Freeing unused kernel memory: 1280K
[    4.274522] EXT4-fs (mmcblk2p2): re-mounted. Opts: data=ordered
Starting syslogd: OK
Starting klogd: OK
Initializing random number generator... [    4.310549] random: dd: uninitialized urandom read (512 bytes read)
done.
Starting network: OK

// 起初以为是这里问题,没有加载音频相关的固件,后来想明白了,固件加载不成功,卡住也不合理。
[    4.383016] imx-sdma 30bd0000.dma-controller: sdma firmware not ready!
[    4.389557] imx-uart 30860000.serial:    
[    4.446690] imx-sdma 30bd0000.dma-controller: sdma firmware not ready!
[    4.453230] imx-uart 30860000.serial: Prepare for the RX slave dma failed!
[    4.560810] imx-sdma 30bd0000.dma-controller: sdma firmware not ready!
[    4.567366] imx-uart 30860000.serial: We cannot prepare for the TX slave dma!
[    4.577798] imx-sdma 30bd0000.dma-controller: sdma firmware not ready!
[    4.584355] imx-uart 30860000.serial: We cannot prepare for the TX slave dma!
[    4.591517] imx-sdma 30bd0000.dma-controller: sdma firmware not ready!
[    4.598071] imx-uart 30860000.serial: We cannot prepare for the TX slave dma!
[   62.567126] imx-sdma 30bd0000.dma-controller: external firmware not found, using ROM firmware
[   62.567554] imx-sdma 302c0000.dma-controller: external firmware not found, using ROM firmware
[   62.584223] imx-sdma 302b0000.dma-controller: external firmware not found, using ROM firmware

遇到这问题,走了2天的冤枉路。继续找问题

  • NXP 最初提供的Yocto 编译出最小系统和Buildroot 最小文件系统做对比,对比差异发现区别很大,主要原因是 : Yocto 文件系统的启动方式是Systemd , 而 Buildroot 文件系统启动方式是 Sysvinit
  • buildroot 中文件系统启动方式切换到Systemd,和Yocto 对比发现差异还是很大
  • 最后查资料,通过把Yocto文件系统启动方式切换为Sysvinit,进行对比,发现差异较小,果然发现了问题
BR2_TARGET_GENERIC_GETTY_PORT="ttymxc0"
改为
BR2_TARGET_GENERIC_GETTY_PORT="ttymxc1"
对应的是串口登录
target/etc/ inittab 
ttymxc1::respawn:/sbin/getty -L  ttymxc1 0 vt100 # GENERIC_SERIAL

导致文件系统无法登录的原因应该是串口选择的不对,IMX8MM其实有两个串口,一个串口是Core-A53,另一个是Core-M4的.

  1. buildroot-2017.02 中添加freescale_imx8mmevk_defconfig相关配置,编译到内核报错 :
Incorrect selection of kernel headers: expected 4.14, got 4.9

buildroot/support/scripts/check-kernel-headers.sh 在执行check-kernel-headers.sh时会检测这这个内核版本代码。

内核是4.14的,而交叉编译器这里选择的是4.9,双方不匹配导致。

buildroot -> Toolchain -> Custom kernel headers series 这里选择到4.14.x ,而问题是buildroot-2017.02 版本最高只支持到 4.9.x , buildroot 需要升级

在这里插入图片描述
在这里插入图片描述

参考am335x buildroot 编译报错解决 Incorrect selection of kernel headers: expected 3.2.x, got 4.6.x找到解决办法

总结
  1. 系统无法进入文件系统这个问题走了不少弯路,最直接的办法,应该是熟悉内核到文件系统的过程,而不是去对比差异,这样耗时耗力
本文参与 腾讯云自媒体分享计划,分享自作者个人站点/博客。
原始发表:2019年05月22日,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 总结
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档