Migration process:
1. Tools and raw materials for transplantation: buildroot tool i.MX6q device tree
Step 1: The buildroot tool generates the kernel and cross-compilation toolchain
①First of all, the buildroot tool I used is the buildroot-2017.02 version, the download address is https://buildroot.org/downloads/manual/manual.html#_buildroot_quick_start, and decompress it after downloading. There is a configuration file imx6qsabresd_defconfig for the board I use in the configs directory of its source code directory, and I copy the configuration file to the top-level directory of buildroot.
cp ./configs/freescale_imx6qsabresd_defconfig ./.config
②Compile and install necessary tools for buildroot
apt-get install build-essential kernel-package libncurses5-dev
apt-get install git
③ Modify some default configurations of the .config configuration file in buildroot
make menuconfig
a. Target options------> in the options
Target ABI uses the .config configuration file we copied by default to be EABIhf. If our development board already has a kernel and we only want to modify it based on it, then we need to check whether the cross-compilation toolchain is EABIhf or not. EABI, if you don't find the relevant information, you can leave it alone. Configure it first. After the subsequent buildroot compilation is completed, use the cross-compilation toolchain generated by the buildroot to compile a test program, download it to the development board and run it, the configuration is correct, otherwise it is Wrong, you need to reconfigure to EABI. (The main difference between the two seems to be that the libraries are different. If the static library is used to compile the program, there is no difference between the two. If the dynamic library is used to compile the program, the EABIhf compilation and generation cannot be used in the EABI environment. Execution will report an error no such file, our boss explained that the firmware version does not match). Here I configure it according to the default configuration EABIhf. Don't care if it's a board that has nothing or can be reprogrammed.
b、Toolchain
C library C library selection, select glibc
As a novice, you can configure this first, then save and then launch the configuration, and execute make in the top-level directory of buildroot
(Note: The general function of the buildroot tool is to automatically download and configure the UBOOT source code of the development board, compile the kernel source code into a relevant image that matches the configuration of the development board, make a root file system, etc. Since I am also using it for the first time, I am not too clear about it. The internal things, you can understand by yourself, I will see if I can post one or two better blog links that I have referenced in the comment area later, and share with you)
After the compilation is complete, everything we need is generated in the buildroot top-level directory /output directory.
Introduction to the output directory:
build Compile some raw materials of Uboot, kernel, cross-compilation tool, root file system, etc. (this is usually downloaded automatically through the network during the make process). Personally, I think the important ones are the Uboot source code (which has been compiled during make) and the kernel source code (which has been compiled during make). Later, when I transplanted and changed the kernel source code of flexcan, I changed it based on the kernel source code here.
host: There is a compiled cross-compilation toolchain in this directory. In the /output/host/usr/bin directory, we need the cross-compilation toolchain here when we later change the kernel code and recompile the device tree.
images: There are various compiled images stored here, which can be directly burned to the development board.
Others and writing directories will not be introduced one by one, but you can check them online.
Well, let's officially transplant flexcan:
FLEXCAN porting:
First of all, the development board imx6q I used is compared with the hardware schematic diagram officially given by NXP, and it has been greatly tailored, but the CAN module has not been changed. After burning the image to the development board, it is found that there is no related device file generated in the /sys/class/net directory (it should be noted here that the can bus is classified into the network version after a certain version of linux, as for which specific version I also forgot the version, but the 3.0.15 and later kernels are classified like this. If you don't understand this, it is easy to mistake it for a character device. Go to /dev to find the device file).
Secondly, the flexcan driver in the kernel is officially maintained by NXP (because the 4.1.15 version of the kernel downloaded by buildroot is downloaded from the NXP official website, which can be seen from the configuration file). So the driver itself is good and does not need to be modified, but there is no relevant hardware description file. This is because the hardware is not described in the device tree file of the kernel source code, and the module is disabled.
So the device tree needs to be modified.
After reading many blogs, I found that many descriptions are either not very clear, or the device description file can be generated according to its configuration, but the hardware cannot send data normally. Finally, in the NXP community, I found a device tree modification method that I think is more reliable and the hardware works normally after the configuration is cut.
1. Device tree file
According to my board model and what is described in the device tree, the device tree file I chose is imx6q-sabresd.dts (if it is another board, you may need to check it against your own board.)
The "header files" contained in this device tree are:
imx6q.dtsi and imx6qdl-sabresd.dtsi Then imx6q.dtsi includes imx6qdl.dtsi
Among them, there is a description of flexcan in imx6qdl.dtsi. According to its description, it is found that the described register address is the same as that described in the imx6q data sheet, so it is determined that the device tree can be used for the development board in my hand. ( Make sure the device tree is suitable for the development board method in your hand )
Then I modified these files as follows according to the description of the community:
①Add in iomuxc in imx6q.dtsi: (If our kernel version is the same: the file is in the /arch/arm/boot/dts directory of the kernel source code, and the place to add the content is in line 196 of the file)
can1{
pinctrl_flexcan1_1:can1grp{
fsl,pins = <
MX6QDL_PAD_GPIO_7__FLEXCAN1_TX 0x1b0b0
MX6QDL_PAD_GPIO_8__FLEXCAN1_RX 0x1b0b0
MX6QDL_PAD_GPIO_19__GPIO4_IO05 0x1b0b0
>;
};
};
②Add in the regulators of the imx6qdl-sabresd.dtsi file: (the directory where the file is located is the same as above, in line 134 of the file)
reg_can_xcvr:regulator@6{ //The numbers here change with the contents of the regulator, I wrote it from the previous rules
compatible = "regulator-fixed";
reg = <6>; // same as @6 above
regulator-name = "CAN XCVR";
regulator_min_microvolt = <33000000>;
regulator_max_microvolt = <33000000>;
pinctrl-names = "default";
gpio = <&gpio4 5 GPIO_ACTIVE_HIGH>;
enable-active-low;
};
③Add at the end of the imx6q-sabresd.dts file:
&can1{
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_flexcan1_1>;
xceiver-supply = <®_can_xcvr>;
status = "okay";
};
It should be noted that if the kernel version is different, then you need to look at the kernel file carefully. Some kernels may write the description of can1 here as flexcan1. This requires you to read and analyze the rules yourself, or learn the device tree. I understand it, I am new to this and I can't explain these things clearly, so I won't go into details.
④ After modifying the device tree, go to the top-level directory of the kernel source code to execute
make dtbs ARCH=arm
The device tree can be compiled (note that the cross-compilation toolchain must be specified as the buildroot in advance, my approach is to add the environment variable configuration at the end of the vi ~/.bashrc file, and then copy the compiled kernel in the buildroot. Then modify the device tree execution to avoid polluting the source code)
Finished firmware update method:
After my device tree was compiled, a new problem appeared, that is, there are many other important things in the root file system of my board, and the kernel was also made by colleagues, in order to avoid secondary labor. and breaking things, I need to replace the device tree in the board with the new device tree. After a lot of searching, it turns out that there is a way to update the firmware of the off-the-shelf product. Because our kernel image and device tree are placed in emmc, and there is a description file for the storage medium under /dev of the kernel, we can operate emmc through the device file and replace the original device tree. become ours. The specific operation method is as follows:
mount /dev/mmblk3p2 ./mmc
Entering mmc, I found that there are more kernel image files and device tree files in it. At this time, we only need to save the original device tree file, and then put our own mv in it. After restarting, it is found that there is already a description of the CAN module.
Hardware function test:
Now that the device files are all available, the hardware test can be performed, but it is found that the ip tool in the original kernel cannot set can. The reason is that the ip tool under /sbin is too old and needs to be replaced. This is relatively simple, compile the next iproute2 tool on the Internet, copy the generated ip tool to /sbin and replace the original one. It should be noted that many source codes downloaded from the Internet may not be compiled normally. This may be a problem with the source code itself. I tried to compile a few and found that
Compilation process:
①Modify CC = arm-linux-gcc in the Makefile (the cross-compilation toolchain generated by your own buildroot, if there is no global configuration of the cross-compilation toolchain, you need to add the absolute path).
②Because we only need the ip tool, SUBDIRS = lib ip (the default in the source code will also generate other tools).
③make
After the final compilation is successful, you can find a generated ip in the ip directory under the source code directory (this is an executable binary file ip tool). Copy the file to the /sbin directory of the development board to replace the original ip. Can.