Mind Chasers Inc.
Mind Chasers Inc.

Build, Install, and Develop with NXP's Latest Yocto BSP for the MCIMX8M-EVK using the Linux 5.4 Kernel

We show how to build the latest NXP Yocto BSP for the NXP MCIMX8M-EVK evaluation kit for the i.MX 8MQuad processor


NXP has recently updated their BSP for the MCIMX8M-EVK evaluation kit for the i.MX 8MQuad processor to the Linux 5.4.24 kernel, and this article is an update to our previous article for the L4.14 BSP.

We have found that some of NXP's Yocto Linux related documentation is stale and confusing, so we have developed this article about how we perform basic development steps with the Yocto Project, Linux kernel, and user space in the context of our i.MX8 system.

The steps shown below can be followed to create a working EVK system from source using an Ubuntu 18.04 host as the Yocto build machine (and package server).

The Yocto Project itself has fantastic documentation, and there is a lot of it! If you're new to Yocto Project, then start with the Quick Build Guide. And don't overlook What I Wish I'd Known.

Listed below are some of the data points that we need to establish to move forward when building a Yocto image from source for our EVK:

  • i.MX 8MQuad is powered by a quad core 1.5 GHz ARM CORTEX-A53 with an auxiliary ARM M4
  • We are working with the NXP release "L5.4.24_2.1.0". This was developed using the Yocto Project Zeus (3.0) release.
  • Zeus 3.0 was released October 2019.
  • The very important meta-fsl-bsp-release Git repo is hosted at https://source.codeaurora.org/external/imx/meta-fsl-bsp-release. This is referred to as the "i.MX release layer" and "i.MX BSP release layer".
  • i.MX8 uses the wayland graphics back end
  • The Yocto Machine (for conf files): imx8mqevk
  • There is an EVKB and EVK. We are using the EVKB, and this has an upgrade to the WIFI over the EVK and a later revision of the i.MX8 SoC.
EVK Board

Initial Steps

As recommended by NXP, we're using the repo tool, which is a Python script developed by Google, to pull all the necessary Git repositories at the correct commits based on NXP's GA release manifest. Refer to NXP's Zeus README for some additional details.

Below we install NXP's Yocto Project release in our /build/nxp folder:

$ mkdir -p /build/nxp; cd /build/nxp
$ repo init -u https://source.codeaurora.org/external/imx/imx-manifest  -b imx-linux-zeus -m imx-5.4.24-2.1.0.xml

Get https://gerrit.googlesource.com/git-repo/clone.bundle
Get https://gerrit.googlesource.com/git-repo
repo has been initialized in /build/nxp

$ ls -a
.  ..  .repo

$ repo sync
Fetching projects:   8% (1/12) fsl-community-bsp-baseremote
Fetching projects:  16% (2/12) meta-python2remote
Fetching projects:  25% (3/12) meta-timesysremote
Fetching projects:  41% (5/12) meta-imxremote
Fetching projects:  66% (8/12) meta-qt5remote
Fetching projects: 100% (12/12), done.
Checking out projects: 100% (12/12), done.
repo sync has finished successfully.

$ ls
imx-setup-release.sh  README  README-IMXBSP  setup-environment  sources

Create our Yocto Project build environment under the folder build-wayland:

$ DISTRO=fsl-imx-wayland MACHINE=imx8mqevk source imx-setup-release.sh -b build-wayland
Your build environment has been configured with:


$ pwd 

$ tree
└── conf
    ├── bblayers.conf
    ├── bblayers.conf.org
    ├── local.conf
    ├── local.conf.org
    ├── local.conf.sample
    └── templateconf.cfg

It may be instructive to realize that the repos / layers under sources are not on a branch and may have been modified during the previous setup:

cd /build/nxp/sources/meta-freescale

$ git branch
* (no branch)

The bitbake command below will build an sdcard image in the deploy folder that we can use to boot our NXP EVK.

$ bitbake imx-image-multimedia

Build Configuration:
BB_VERSION           = "1.44.0"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "ubuntu-18.04"
TARGET_SYS           = "aarch64-poky-linux"
MACHINE              = "imx8mqevk"
DISTRO               = "fsl-imx-wayland"
DISTRO_VERSION       = "5.4-zeus"
TUNE_FEATURES        = "aarch64 cortexa53 crc crypto"
TARGET_FPU           = ""
meta-poky            = "HEAD:cba967414370e195d109353e51510bd829aa86c3"
meta-python          = "HEAD:9e60d30669a2ad0598e9abf0cd15ee06b523986b"
meta-freescale       = "HEAD:c2a0d924f6200eea1fb1d1b61e7420ea5da2f8fb"
meta-freescale-3rdparty = "HEAD:dbcc686f52c3c84db8cb86aa8973a4e373651b98"
meta-freescale-distro = "HEAD:ca27d12e4964d1336e662bcc60184bbff526c857"
meta-ml              = "HEAD:a083ffbbc3f4d1c02b1542746784d7f641a75b60"
meta-browser         = "HEAD:5f365ef0f842ba4651efe88787cf9c63bc8b6cb3"
meta-rust            = "HEAD:a012a1027defe28495f06ed522a7a82bdd59a610"
meta-filesystems     = "HEAD:9e60d30669a2ad0598e9abf0cd15ee06b523986b"
meta-qt5             = "HEAD:b8bcf8cb576d072f435a0177375e54424f67d1c9"
meta-python2         = "HEAD:231c3d74cfcf734c3415e86ea8dd97f73ddced9d"

When we want to come back to the build system, we can do the following (or we can use NXP's script):

$ cd /build/nxp

$ source sources/poky/oe-init-build-env build-wayland/

### Shell environment set up for builds. ###

You can now run 'bitbake '

Common targets are:

You can also run generated qemu images with a command like 'runqemu qemux86'

Other commonly useful commands are:
 - 'devtool' and 'recipetool' handle common recipe tasks
 - 'bitbake-layers' handles common layer tasks
 - 'oe-pkgdata-util' handles common target package tasks

$ bitbake imx-image-multimedia

Burning our *.sdcard image on an SD Card

Let's first take a look at the image file system types we have configured:

$ bitbake imx-image-multimedia -e | grep ^IMAGE_FSTYPES
IMAGE_FSTYPES="wic.bmap  wic.bz2 tar.bz2"

Most documentation instructs the user to use dd to program an SD Card, but we use the open source tool Etcher on Windows 10. We find that this is the most robust solution since dd sometimes fails to work as we expect.

We also decompress the *sdcard.bz2 file before using Etcher to program our SD Card. We run the following in our Ubuntu shell on our build machine:

$ cd /build/nxp/build-wayland/tmp/deploy/images/imx8mqevk/

$ ls *.bz2
imx-image-multimedia-imx8mqevk-20200808045658.rootfs.sdcard.bz2  imx-image-multimedia-imx8mqevk.sdcard.bz2
imx-image-multimedia-imx8mqevk-20200808045658.rootfs.tar.bz2     imx-image-multimedia-imx8mqevk.tar.bz2
imx-image-multimedia-imx8mqevk-20200808045658.rootfs.wic.bz2     imx-image-multimedia-imx8mqevk.wic.bz2

$ bunzip2 -vfk imx-image-multimedia-imx8mqevk-<date>.rootfs.sdcard.bz2

$ file imx-image-multimedia-imx8mqevk-<date>.rootfs.sdcard
...: DOS/MBR boot sector; partition 1 : ID=0xc, active, start-CHS (0x80,0,1), end-CHS (0x3ff,3,32), startsector 16384, 170392 sectors; 
partition 2 : ID=0x83, start-CHS (0x3ff,3,32), end-CHS (0x3ff,3,32), startsector 196608, 6252502 sectors

Note that the resulting *.sdcard image is ~3GB, but we expect this to grow significantly once we add a toolchain and other packages. Also note that we get good results using a SanDisk 16GB Ultra microSDHC.

We transfer the resulting "*.sdcard" image to Windows 10 and burn the SD Card using Etcher. After programming is done, we insert it in the EVK SD Card slot, and the system does indeed boot Yocto Linux.

Note that we can also insert our burned SD Card back into our Ubuntu machine and make changes to the mounted partitions.

Notes on Directories and Source

imx-image-multimedia.bb can be found in sources/meta-imx/meta-sdk/recipes-fsl/images

As you may have noticed, there are several NXP layers under sources. Here's one way to determine where a recipe is located:

$ cd /build/nxp/sources/
$ find . -name 'linux-imx*bb'

We can see above that the linux-imx_5.4 recipe is located in the meta-imx/meta-bsp layer. This makes sense since NXP tells us that the purpose of this layer is to introduce new features into the Yocto Project build that might not have been availble for the Zeus release.

View the manifest:

$ cd /build/nxp/build-wayland/tmp/deploy/images/imx8mqevk

$ vi imx-image-multimedia-imx8mqevk.manifest

It can be confusing trying to determine where the source is hosted that is used to build our image. One way of determining this is shown below:

$ cd /build/nxp/build-wayland/tmp/work/

$ ls
aarch64-mx8m-poky-linux  aarch64-poky-linux  all-poky-linux  imx8mqevk-poky-linux  x86_64-linux

$ grep url imx8mqevk-poky-linux/linux-imx/5.4-r0/git/.git/config 
	url = https://source.codeaurora.org/external/imx/linux-imx.git
$ grep url imx8mqevk-poky-linux/u-boot-imx/1_2020.04-r0/git/.git/config 
	url = https://source.codeaurora.org/external/imx/uboot-imx.git

Remote login via SSH

We find that our EVK Linux image supports Ethernet connectivity without requiring customization.

After boot up of our EVK and determination of our EVK's IP address, we add the IP address for the EVK board to /etc/hosts and login remotely:

ssh root@evk
The authenticity of host 'evk (' can't be established.
RSA key fingerprint is SHA256:ZOx862o0VxZf4NOaqEHROt9pU+mb4cN3t0VyvkIxffg.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'evk,<ip address>' (RSA) to the list of known hosts.

# uname -a
Linux imx8mqevk 5.4.24-2.1.0+gbabac008e5cf #1 SMP PREEMPT Sat Aug 8 03:43:30 UTC 2020 aarch64 aarch64 aarch64 GNU/Linux

# cat /proc/cpuinfo 
processor	: 0
BogoMIPS	: 16.66
Features	: fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
CPU implementer	: 0x41
CPU architecture: 8
CPU variant	: 0x0
CPU part	: 0xd03
CPU revision	: 4

processor	: 1

processor	: 2

processor	: 3

DNF and package management

We add DNF package management support to our EVK target and build machine following Yocto documentation and our article "Use DNF Package Manager on a Yocto Linux Development System"

Add package management to our conf/local.conf file:

IMAGE_FEATURES += "package-management"

Note that modifying local.conf with the IMAGE change is considered bad form, and we'll eventually create our own custom layer, image recipe, and packagegroup to add our customizations.

Don't forget to run "bitbake package-index" on the build machine. Next, on our EVK, we run:

# dnf makecache
timer: config: 11 ms
DNF version: 2.7.5
Command: dnf makecache 
Installroot: /
Releasever: sumo
cachedir: /var/cache/dnf
Base command: makecache
Extra commands: ['makecache']
Repository 'oe-packages' is missing name in configuration, using id.
Making cache files for all metadata files.
oe-packages: has expired and will be refreshed.
repo: downloading from remote: oe-packages, _Handle: metalnk: None, mlist: None, urls [''].
oe-packages                                                                                               32 MB/s | 2.6 MB     00:00    
not found deltainfo for: oe-packages
not found updateinfo for: oe-packages
oe-packages: using metadata from Sat Oct 19 02:17:31 2019.
Last metadata expiration check: 0:00:03 ago on Sat Oct 19 02:18:50 2019.
timer: sack setup: 3188 ms
Metadata cache created.
Cleaning up.

Adding the GNU Toolchain to our target

We add "tools-sdk" to our IMAGE_FEATURES variable to install a full SDK on our target. After modifying IMAGE_FEATURES, we re-run our validation image and inspect our updated rootfs:

$ bitbake fsl-image-qt5-validation-imx

$ cd /opt/nxp/build-wayland/tmp/work/imx8mqevk-poky-linux/fsl-image-qt5-validation-imx/1.0-r0/rootfs

$ find . -name autoconf

$ find . -name gcc

Let's also take a look at the updated manifest after updating the package-index:

$ bitbake package-index

$ cd /opt/nxp/build-wayland/tmp/deploy/images/imx8mqevk/

$ grep autoconf imx-image-multimedia-imx8mqevk-.manifest 
autoconf aarch64 2.69

$ grep cmake imx-image-multimedia-imx8mqevk-.manifest 

As you can see above, cmake isn't included in the SDK, so let's add it by using dnf as described above:

build server:

$ bitbake cmake
$ bitbake package-index

imx shell:

# dnf install cmake
  cmake.aarch64 3.10.3-r0   

# cmake --version
cmake version 3.10.3

CMake suite maintained and supported by Kitware (kitware.com/cmake).

Obviously, creating customizations to an SD Card partition that will be later over written doesn't make much sense. We need to move our rootfs off of the SD Card, and we'll address this soon...

imx-boot and u-boot

The imx-boot includes includes SPL, U-Boot, Arm Trusted Firmware, DDR firmware, and HDMI firmware. We will add a section on this once we better understand it.

The following is copied verbatim from the "i.MX Linux User's Guide":

On i.MX 8, the U-Boot cannot boot the device by itself. The i.MX 8 pre-built images or Yocto Project default bootloader is imx-boot for the SD card, which is created by the imx-mkimage. The imx-boot binary includes the Uboot, ARM trusted firmware, DCD file (8QuadMax/8QuadXPlus), system controller firmware (8QuadMax/8QuadXPlus), SPL (8M Quad and 8M Mini), DDR firmware (8M Quad), and HDMI firmware (8M Quad), and SECO firmware for B0 (8QXP/8QuadMax).

On i.MX 8M Quad and 8M Mini, the second program loader (SPL) is enabled in U-Boot. SPL is implemented as the firstlevel bootloader running on TCML (due to OCRAM size limitation). It is used to initialize DDR and load U-Boot, U-Boot DTB, Arm trusted firmware, and TEE OS (optional) from the boot device into the memory. After SPL completes loading the images, it jumps to the Arm trusted firmware BL31 directly. The BL31 starts the optional BL32 (TEE OS) and BL33 (u-boot) for continue booting kernel.

In imx-boot, the SPL is packed with DDR Firmware together, so that ROM can load them into Arm Cortex-M4 TCML. The U-Boot, U-Boot DTB, Arm Trusted firmware, and TEE OS (optional) are packed into a FIT image, which is finally built into imx-boot.

Below we show the U-Boot welcome screen after a reboot via the NXP UART / USB:

U-Boot 2018.03-imx_v2018.03_4.14.98_2.0.0_ga+g87a19df5e4 (Oct 18 2019 - 03:28:59 +0000)

CPU:   Freescale i.MX8MQ rev2.1 1500 MHz (running at 1000 MHz)
CPU:   Commercial temperature grade (0C to 95C) at 44C
Reset cause: POR
Model: Freescale i.MX8MQ EVK
DRAM:  3 GiB
TCPC:  Vendor ID [0x1fc9], Product ID [0x5110], Addr [I2C0 0x50]
Display: HDMI (1280x720)
  - ATF 1cb68fa
  - U-Boot 2018.03-imx_v2018.03_4.14.98_2.0.0_ga+g87a19df5e4

Let's take a look at our U-Boot environment:

u-boot=> printenv
bootcmd=mmc dev ${mmcdev}; if mmc rescan; then if run loadbootscript; then run bootscript; else if run loadimage; then run mmcboot; else run netboot; fi; fi; else booti ${loadaddr} - ${fdt_addr}; fi
bootcmd_mfg=run mfgtool_args;if iminfo ${initrd_addr}; then if test ${tee} = yes; then bootm ${tee_addr} ${initrd_addr} ${fdt_addr}; else booti ${loadaddr} ${initrd_addr} ${fdt_addr}; fi; else echo "Run fastboot ..."; fastboot 0; fi;
bootscript=echo Running bootscript from mmc ...; source
console=ttymxc0,115200 earlycon=ec_imx6q,0x30860000,115200
jh_mmcboot=setenv fdt_file fsl-imx8mq-evk-root.dtb; setenv jh_clk clk_ignore_unused; if run loadimage; then run mmcboot; else run jh_netboot; fi;
jh_netboot=setenv fdt_file fsl-imx8mq-evk-root.dtb; setenv jh_clk clk_ignore_unused; run netboot;
loadbootscript=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};
loadfdt=fatload mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}
loadimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${image}
mfgtool_args=setenv bootargs console=${console},${baudrate} rdinit=/linuxrc clk_ignore_unused
mmcargs=setenv bootargs ${jh_clk} console=${console} root=${mmcroot}
mmcboot=echo Booting from mmc ...; run mmcargs; if test ${boot_fdt} = yes || test ${boot_fdt} = try; then if run loadfdt; then booti ${loadaddr} - ${fdt_addr}; else echo WARN: Cannot load the DT; fi; else echo wait for boot; fi;
mmcroot=/dev/mmcblk1p2 rootwait rw
netargs=setenv bootargs ${jh_clk} console=${console} root=/dev/nfs ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp
netboot=echo Booting from net ...; run netargs;  if test ${ip_dyn} = yes; then setenv get_cmd dhcp; else setenv get_cmd tftp; fi; ${get_cmd} ${loadaddr} ${image}; if test ${boot_fdt} = yes || test ${boot_fdt} = try; then if ${get_cmd} ${fdt_addr} ${fdt_file}; then booti ${loadaddr} - ${fdt_addr}; else echo WARN: Cannot load the DT; fi; else booti; fi;

We'll come back to this when we show NFS boot working.

Customizing the linux-imx kernel

To Be Added...

Customizing the linux-imx device tree

To Be Added...

Building from the Yocto Master Branch

To Be Added...

Kernel Debugging via JTAG

To Be Added...


One of our use cases for our NXP EVK is to work with custom cameras / imagers via the CSI-2 interface.

We perform some introspection of our live system below:

 # dmesg | grep CSI
[    2.464352] CSI: Registered sensor subdevice: mxc-mipi-csi2.0
[    2.494285] CSI: Registered sensor subdevice: mxc-mipi-csi2.1

Let's take a look at the default kernel configuration in our work's linux-imx folder:

excerpt of defconfig:


Next, we take a look at the kernel's menuconfig to get a feeling on how the MIPI CSI-2 driver support is structured within the source:

$ bitbake linux-imx -c menuconfig

The figure below is a screen shot from our menuconfig window showing us support for the OV5640 camera:

linux-imx menuconfig

Enabling MXC_CAMERA_OV5640_MIPI_V2 pulls in ov5640_mipi_v2.o to our build

Enabling MXC_CAMERA_OV5640_MIPI_V3 pulls in ov5640_mipi_v3.o to our build

Let's check the kernel log:

# dmesg | grep -i mipi
[    2.359569] ov5640_mipi 0-003c: No sensor reset pin available
[    2.365374] ov5640_mipi 0-003c: 0-003c supply DOVDD not found, using dummy regulator
[    2.373231] ov5640_mipi 0-003c: 0-003c supply DVDD not found, using dummy regulator
[    2.380954] ov5640_mipi 0-003c: 0-003c supply AVDD not found, using dummy regulator
[    2.400170] ov5640_mipi 0-003c: Read reg error: reg=300a
[    2.405497] ov5640_mipi 0-003c: Camera is not found
[    2.411174] ov5640_mipi 1-003c: No sensor reset pin available
[    2.417093] ov5640_mipi 1-003c: 1-003c supply DOVDD not found, using dummy regulator
[    2.424956] ov5640_mipi 1-003c: 1-003c supply DVDD not found, using dummy regulator
[    2.432658] ov5640_mipi 1-003c: 1-003c supply AVDD not found, using dummy regulator
[    3.681495] ov5640_mipi 1-003c: Camera is found
[    3.687312] mxc-mipi-csi2_yav 30a70000.mipi_csi1: mipi_csi2_probe
[    3.693526] CSI: Registered sensor subdevice: mxc-mipi-csi2.0
[    3.699380] mxc-mipi-csi2_yav 30a70000.mipi_csi: Remote device at /mipi_csi1@30a70000/port/endpoint1 XXX found
[    3.709397] mxc-mipi-csi2_yav 30a70000.mipi_csi: Registered sensor subdevice: ov5640_mipi 1-003c
[    3.718258] mxc-mipi-csi2_yav 30a70000.mipi_csi1: lanes: 2, name: mxc-mipi-csi2.0
[    3.726038] mxc-mipi-csi2_yav 30b60000.mipi_csi2: mipi_csi2_probe
[    3.732263] CSI: Registered sensor subdevice: mxc-mipi-csi2.1
[    3.738034] mxc-mipi-csi2_yav 30b60000.mipi_csi: Remote device at /mipi_csi2@30b60000/port/endpoint1 XXX found
[    3.748110] mxc-mipi-csi2_yav 30b60000.mipi_csi2: lanes: 2, name: mxc-mipi-csi2.1
[  129.298745] ov5640_mipi 1-003c: s_stream: 1

The ov5640_mipi device is instantiated from drivers/media/platform/mxc/capture/ov5640_mipi_v2.c.

The mxc-mipi-csi2_yav device is instantiated from drivers/media/platform/imx8/mxc-mipi-csi2_yav.c.

Note that the i.MX8 Reference Manual states MIPI_CSI1 Host Controller (Chapter 13.7) starts at 0x30A7_0000

Let's run gst-launch for the NXP MINISASTOCSI Camera that uses the OV5640 camera. Note that we'll end the pipeline with autovideosink.

# gst-launch-1.0 -v v4l2src ! ‘video/x-raw,width=1920,height=1080’ ! autovideosink

ssh into the iMX and run the following script that we'll call timer.sh:

cat /proc/interrupts | grep csi
sleep 10
cat /proc/interrupts | grep csi
# ./timer.sh
 23:      16230          0          0          0  GPC-PSCI  42 Edge      csi
 24:          0          0          0          0  GPC-PSCI  43 Edge      csi
 23:      16830          0          0          0  GPC-PSCI  42 Edge      csi
 24:          0          0          0          0  GPC-PSCI  43 Edge      csi

600 interrupts in 10 seconds probably corresponds to 60fps, but we need to dig into the existing CSI-2 driver(s).

Let's use the v4l2-ctl application to introspect the video driver:

# dnf install v4l-utils 

# v4l2-ctl -d /dev/video0 --all -D --list-formats-ext
Driver Info (not using libv4l2):
	Driver name   : mx6s-csi
	Card type     : i.MX6S_CSI
	Bus info      : platform:30a90000.csi1_bridge
	Driver version: 4.14.98
	Capabilities  : 0x84200001
		Video Capture
		Extended Pix Format
		Device Capabilities
	Device Caps   : 0x04200001
		Video Capture
		Extended Pix Format
Priority: 0
Video input : 0 (Camera: ok)
Format Video Capture:
	Width/Height      : 2592/1944
	Pixel Format      : ''
	Field             : None
	Bytes per Line    : 0
	Size Image        : 10077696
	Colorspace        : Default
	Transfer Function : Default
	YCbCr/HSV Encoding: Default
	Quantization      : Default
	Flags             : 
Crop Capability Video Capture:
	Bounds      : Left 0, Top 0, Width 0, Height 0
	Default     : Left 0, Top 0, Width 0, Height 0
	Pixel Aspect: 1/1
Crop: Left 0, Top 0, Width 0, Height 0
Streaming Parameters Video Capture:
	Capabilities     : timeperframe
	Capture mode     : high quality
	Frames per second: 15.000 (15/1)
	Read buffers     : 0
	Index       : 0
	Type        : Video Capture
	Pixel Format: 'YUYV'
	Name        : YUYV 4:2:2
		Size: Discrete 640x480
			Interval: Discrete 0.033s (30.000 fps)
		Size: Discrete 320x240
			Interval: Discrete 0.033s (30.000 fps)
		Size: Discrete 720x480
			Interval: Discrete 0.033s (30.000 fps)
		Size: Discrete 1280x720
			Interval: Discrete 0.033s (30.000 fps)
		Size: Discrete 1920x1080
			Interval: Discrete 0.033s (30.000 fps)
		Size: Discrete 2592x1944
			Interval: Discrete 0.067s (15.000 fps)
		Size: Discrete 0x0

# v4l2-ctl --stream-mmap --stream-count=1 --stream-to=file.yuv 

Note that the i.MX8 Reference Manual states CSI1 Bridge (Chapter 13.7) starts at 0x30A9_0000

Debugging the I2C Messages to the Camera

Next we rebuild our kernel with the following debug KConf defines active:


After a reboot we can see the kernel's debug messages if we configure our console properly:

# cat /proc/sys/kernel/printk
4	4	1	7

# echo '8' > /proc/sys/kernel/printk
# cat /proc/sys/kernel/printk
8	4	1	7

Now when we exercise the camera, we see I2C debug messages for writes and reads to the camera. An example is shown below:

i2c i2c-1: master_xfer[0] W, addr=0x3c, len=2  
i2c i2c-1: <i2c_imx_write> write byte: B0=0x38 
i2c i2c-1: <i2c_imx_write> write byte: B1=0xD  
i2c i2c-1: master_xfer[0] R, addr=0x3c, len=1 
i2c i2c-1: <i2c_imx_read> read byte: B0=0x1C  

Referring to the OV5640 datasheet, we can see that the i.MX8 read a 0x1c from the TIMING HTS register.

USB 3.0 node via Type-C interface

To Be Added...

References and Resources

Acronyms and Terms

  • SRC: i.MX8 System Reset Controller


Although the i.MX8 RM states there are four I2C "channels" available on the device, only three are exposed:

# i2cdetect -l
i2c-1	i2c       	30a30000.i2c                    	I2C adapter
i2c-2	i2c       	30a40000.i2c                    	I2C adapter
i2c-0	i2c       	30a20000.i2c                    	I2C adapter

# ls /dev/i2c*
/dev/i2c-0  /dev/i2c-1	/dev/i2c-2

We want to work with the i.MX8 driver: i2c/busses/i2c-imx.c

MODULE_AUTHOR("Darius Augulis");
MODULE_DESCRIPTION("I2C adapter driver for IMX I2C bus");

We find that function calls within i2c-mx.c mainly come through the functions in i2c-core-base.c.

Didn't find an answer to your question? Post your issue below or in our new FORUM, and we'll try our best to help you find a solution.

And please note that we update our site daily with new content related to our open source approach to network security and system design. If you would like to be notified about these changes, then please follow us on Twitter and join our mailing list.

Related articles on this site:

subscribe to mailing list:

Please help us improve this article by adding your comment or question:

your email address will be kept private
authenticate with a 3rd party for enhanced features, such as image upload
previous month
next month