i.MX处理器知识库

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

i.MX Processors Knowledge Base

讨论

排序依据:
Audio, from a file gst-launch filesrc location=test.wav ! wavparse ! mfw_mp3encoder ! filesink location=output.mp3 Audio Recording gst-launch alsasrc num-buffers=$NUMBER blocksize=$SIZE ! mfw_mp3encoder ! filesink location=output.mp3 # where #     duration = $NUMBER*$SIZE*8 / (samplerate *channel *bitwidth) # Example: 60 seconds recording # gst-launch alsasrc num-buffers=240 blocksize=44100 ! mfw_mp3encoder ! filesink location=output.mp3 # # To verify that is correct, do a normal audio playback gst-launch filesrc location=output.mp3 typefind=true ! beepdec ! audioconvert ! 'audio/x-raw-int,channels=2' ! alsasink Video, from a test source gst-launch videotestsrc ! queue ! vpuenc ! matroskamux ! filesink location=./test.avi Video, from a file gst-launch filesrc location=sample.yuv blocksize=$BLOCK_SIZE ! 'video/x-raw-yuv,format=(fourcc)I420, width=$WIDTH, height=$HEIGHT, framerate=(fraction)30/1' ! vpuenc codec=$CODEC ! matroskamux ! filesink location=output.mkv sync=false # where #     BLOCK_SIZE = WIDTH * HEIGHT * 1.5 #     CODEC = 0(MPEG4), 5(H263), 6(H264) or 12(MJPG). # # For example, encoding a CIF raw file gst-launch filesrc location=sample.yuv blocksize=152064 ! 'video/x-raw-yuv,format=(fourcc)I420, width=352, height=288, framerate=(fraction)30/1' ! vpuenc codec=0 ! matroskamux ! filesink location=sample.mkv sync=false Video, from Web camera # when the web cam is connected, the device node /dev/video0 should be present. In order to test the camera, without encoding gst-launch v4l2src ! mfw_v4lsink # in recording, run: # gst-launch v4l2src num-buffers=-1 ! queue max-size-buffers=2 ! vpuenc codec=0 ! matroskamux ! filesink location=output.mkv sync=false # # where sync=false indicates filesink to to use a clock sync # # In case a specific width/height is needed, just add the filter caps gst-launch v4l2src num-buffers=-1  ! 'video/x-raw-yuv,format=(fourcc)I420, width=352, height=288, framerate=(fraction)30/1' ! queue ! vpuenc codec=0 ! matroskamux ! filesink location=output.mkv sync=false # # In case you want to see in the screen what the camera is capturing, add a tee element # gst-launch v4l2src num-buffers=-1 ! tee name=t ! queue ! mfw_v4lsink t. ! queue ! vpuenc codec=0 ! matroskamux ! filesink location=output.mkv sync=false Video, from Parallel/MIPI camera # The camera driver needs to be loaded before executing the pipeline, refer to the BSP document to see which driver to load # MIPI (J5 port): modprobe ov5640_camera_mipi modprobe mxc_v4l2_capture   # Parallel (J9 port): modprobe ov5642_camera modprobe mxc_v4l2_capture   gst-launch mfw_v4lsrc ! queue ! vpuenc codec=0 ! matroskamux ! filesink location=output.mkv sync=false   # Do a 'gst-inspect mfw_v4lsrc' or 'gst-inspect vpuenc' to see other possible settings (resolution, fps, codec, etc.)
查看全文
Important: If you have any questions or would like to report any issues with the DDR tools or supporting documents please create a support ticket in the i.MX community. Please note that any private messages or direct emails are not monitored and will not receive a response. i.MX 6/7 Series Family DDR Tools Overview This page contains the latest releases for the i.MX 6/7 series DDR Tools. The tools described on this page cover the following i.MX 6/7 series SoCs: i.MX 6DQP (Dual/Quad Plus) i.MX 6DQ (Dual/Quad) i.MX 6DL/S (Dual Lite/Solo) i.MX 6SoloX i.MX 6SL i.MX 6SLL i.MX 6UL i.MX 6ULL/ULZ i.MX 7D/S i.MX 7ULP The purpose of the i.MX 6/7 series DDR Tools is to enable users to generate and test a custom DRAM initialization based on their device configuration (density, number of chip selects, etc.) and board layout (data bus bit swizzling, etc.). This process equips the user to then proceed with the bring-up of a boot loader and an OS. Once the OS is brought up, it is recommended to run an OS-based memory test (like Linux memtester) to further verify and test the DDR memory interface. The i.MX 6/7 series DDR Tools consist of: DDR Register Programming Aid (RPA) DDR Stress test _________________________________________________________ i.MX 6/7 Series DDR Stress Test The i.MX 6/7 Series DDR stress test tool is a Windows-based software tool that is used as a mechanism to verify that the DDR initialization is operational prior for use in u-boot and OS bring-up. The DDR Stress Test tool can be found here: i.MX 6/7 DDR Stress Test Tool Note that the DDR Stress test tool supports all of the above i.MX SoCs, however, some of the supported i.MX SoCs named in the tool support multiple i.MX SoCs as follows: MX6DQ – when selected, this supports both i.MX 6DQ and i.MX 6DQP (Plus) MX6DL – when selected, this supports both i.MX 6DL and i.MX 6S (i.MX 6DLS family) MX6ULL – when selected, this supports both i.MX 6ULL and i.MX6 ULZ MX7D – when selected, this supports both i.MX 7D and i.MX 7S _____________________________________________________________________________ i.MX 6/7 Series DDR Register Programming Aid (RPA) The i.MX 6/7 series DDR RPA (or simply RPA) is an Excel spreadsheet tool used to develop DDR initialization for a user’s specific DDR configuration (DDR device type, density, etc.). The RPA generates the DDR initialization script for use with the DDR Stress Test tool. For a history of the previous versions of an RPA, refer to the Revision History tab of the respective RPA. To obtain the latest RPAs, please refer to the following links: i.MX 6DQP i.MX6DQP Register Programming Aids i.MX 6DQ i.MX6DQ Register Programming Aids i.MX 6DL/S i.MX6DL Register Programming Aids i.MX 6SoloX i.MX6SX Register Programming Aids i.MX 6SL i.MX6SL Register Programming Aids  i.MX6SLL i.MX6SLL Register Programming Aids i.MX 6UL/ULL/ULZ i.MX6UL/ULL/ULZ DRAM Register Programming Aids i.MX7D i.MX7D DRAM Register Programming Aids i.MX 7ULP i.MX7ULP DRAM Register Programming Aids _____________________________________________________________________________ DRAM Register Programming Aids FAQ    
查看全文
adv7180 is the 8 bits parallel CSI interface TVin to iMX8QXP validation board. Its weaving mode de-interlace can be supported on both iMX8QXP B0 and C0 chips, but blending mode de-interlace can only work on iMX8QXP C0 chips.   ISL79987 is the 4 virtual channel TVin chip which can input 4 CVBS cameras to iMX8QXP with MIPI CSI2 inteface, it can only work with iMX8QXP C0 chips. The iMX8QXP B0 chips have MIPI CSI2 virtual channel errata.   To test the capture to file: $ /unit_tests/V4L2/mx8_v4l2_cap_drm.out -cam 1 -num 300 -fmt YUYV -of   To test the preview on screen: $ killall weston $ /unit_tests/V4L2/mx8_v4l2_cap_drm.out -cam 1 -fmt RGBP -num 30000   Note: 1. For weaving mode de-interlace, when the ISI is doing de-interlace, it can't do CSC at the same time, so preview will get color issue, because the real output video is always YUYV format. 2. For blending mode de-interlace, it must use ISI0, so for ISL79987, only one camera can use blending mode, the other three cameras are still using weaving mode. The preview color is OK for such use case. 3. The patch is for L4.19.35 BSP.     2019-11-14 update: Add the test application "mx8_v4l2_cap_drm.tar.gz" to support YUYV render to display. Test command to render 4 weaving mode cameras:    ./mx8_v4l2_cap_drm.out -cam 0xF -fmt YUYV -num 30000     2020-04-29 update: Add "0006-isl7998x-fix-the-mipi_bps-overwrite-issue-from-set_f.patch", it fixed the issue that MIPI bps information in isl7998x_data->format.reserved[0] had been overwritten by isl7998x_set_fmt().   2021-06-11 update: Added the patches based on L5.4.70_2.3.0 GA BSP.
查看全文
    Below mentioned are the step to enable secure boot in imx8m nano board. Mentioned each step log and address for imx8m nano board tested with LPDDR4.   secure boot feature uses digital signatures to prevent unauthorized software execution during the device boot sequence. In case a malware takes control of the boot sequence, sensitive data, services and network can be impacted. Download the CST(code signing tool) from the below mentioned link https://www.nxp.com/webapp/sps/download/preDownload.jsp?render=true 1. Generating a PKI tree The Code Signing Tools package contains an OpenSSL based key generation script under keys/ directory. The hab4_pki_tree.sh script is able to generate a PKI tree containing up to 4 Super Root Keys (SRK) as well as their subordinated IMG and CSF keys. $ ./hab4_pki_tree.sh ... Do you want to use an existing CA key (y/n)?: n Do you want to use Elliptic Curve Cryptography (y/n)?: n Enter key length in bits for PKI tree: 2048 Enter PKI tree duration (years): 5 How many Super Root Keys should be generated? 4 Do you want the SRK certificates to have the CA flag set? (y/n)?: y 2. Generating a SRK Table and SRK Hash The next step is to generated the SRK Table and its respective SRK Table Hash from the SRK public key certificates created in one of the steps above. The srktool can be used for generating the SRK Table and its respective SRK Table Hash. - Generating SRK Table and SRK Hash in Linux 64-bit machines: $ ../linux64/bin/srktool -h 4 -t SRK_1_2_3_4_table.bin -e \ SRK_1_2_3_4_fuse.bin -d sha256 -c \ SRK1_sha256_2048_65537_v3_ca_crt.pem,\ SRK2_sha256_2048_65537_v3_ca_crt.pem,\ SRK3_sha256_2048_65537_v3_ca_crt.pem,\ SRK4_sha256_2048_65537_v3_ca_crt.pem The SRK_1_2_3_4_table.bin and SRK_1_2_3_4_fuse.bin files can be used in further steps as explained in HAB guides available under doc/imx/habv4/guides/ directory. 3. step-by-step procedure on how to sign and securely boot a bootloader image on i.MX8M Nano devices 3.1 Enabling the secure boot support in U-Boot clone the u-boot from the git link https://source.codeaurora.org/external/imx/uboot-imx Enable the secure boot support in u-boot - Defconfig: CONFIG_SECURE_BOOT=y CONFIG_IMX_HAB=y from 2020.04 u-boot Build images $ make imx8mn_evk_defconfig $ make Output images $(UBOOT_SRC)/u-boot-nodtb.bin $(UBOOT_SRC)/spl/u-boot-spl.bin $(UBOOT_SRC)/arch/arm/dts/fsl-imx8mm-evk.dtb‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ 3.2 ARM Trusted Firmware Get the ATF from the below mentioned source link https://source.codeaurora.org/external/imx/imx-atf Build images $ make PLAT=imx8mn bl31 Output images $(ATF_SRC)/build/imx8mn/release/bl31.bin‍‍‍‍‍‍‍‍‍‍‍‍ 3.3 Get DDR FW images $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.0.bin $ chmod 777 firmware-imx-8.0.bin $ ./firmware-imx-8.0.bin Accept the LICENSE AGREEMENT $ cd firmware-imx-8.0.bin‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍/firmware/ddr/synopsys‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Output images $(DDRFW_SRC)/lpddr4_* 3.4 Get IMX-MKIMAGE source https://source.codeaurora.org/external/imx/imx-mkimage Below mentioned are the steps to generate bootloder using mkimage Gather necessary images SPL and U-boot images - u-boot-nodtb.bin - u-boot-spl.bin - fsl-imx8mm-evk.dtb‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ ATF image - bl31.bin DDR firmware images - lpddr4_pmu_train_1d_dmem.bin - lpddr4_pmu_train_1d_imem.bin - lpddr4_pmu_train_2d_dmem.bin - lpddr4_pmu_train_2d_imem.bin Copy these files to imx-mkimage/iMX8M directory 3.5 Build i.MX8MN boot image flash.bin $ make SOC=iMX8MN flash_evk ========= OFFSET dump ========= Loader IMAGE: header_image_off 0x0 dcd_off 0x0 image_off 0x40 csf_off 0x24a00 spl hab block: 0x911fc0 0x0 0x24a00 Second Loader IMAGE: sld_header_off 0x58000 sld_csf_off 0x59020 sld hab block: 0x401fcdc0 0x58000 0x1020 $ make SOC=iMX8MN print_fit_hab ./print_fit_hab.sh 0x60000 evk.dtb 0x40200000 0x5B000 0xC3AB0 0x402C3AB0 0x11EAB0 0x78F0 0x960000 0x1263A0 0xA1B0 0xBE000000 0x130550 0x10 3.6 Creating the CSF description file The build log provided by imx-mkimage can be used to define the "Authenticate Data" parameter in CSF. - SPL "Authenticate Data" addresses in flash.bin build log: spl hab block: 0x911fc0 0x0 0x24a00 - "Authenticate Data" command in csf_spl.txt file: Blocks = 0x911fc0 0x0 0x24a00 "flash.bin" - FIT image "Authenticate Data" addresses in flash.bin build log: sld hab block: 0x401fcdc0 0x57c00 0x1020 - FIT image "Authenticate Data" addresses in print_fit_hab build log: 0x40200000 0x5B000 0xC3AB0 0x402C3AB0 0x11EAB0 0x78F0 0x960000 0x1263A0 0xA1B0 0xBE000000 0x130550 0x10 - "Authenticate Data" command in csf_fit.txt file: Blocks = 0x401fcdc0 0x57c00 0x1020 "flash.bin", \ 0x40200000 0x5B000 0xC3AB0 "flash.bin", \ 0x402C3AB0 0x11EAB0 0x78F0 "flash.bin", \ 0x960000 0x1263A0 0xA1B0 "flash.bin", \ 0xBE000000 0x130550 0x10 "flash.bin"   3.7 Avoiding Kernel crash in closed devices - Add Unlock MID command in csf_spl.txt: [Unlock] Engine = CAAM Features = MID 3.8 Signing the flash.bin binary The CST tool is used for singing the flash.bin image and generating the CSF binary. Users should input the CSF description file created in the step above and receive a CSF binary, which contains the CSF commands, SRK table, signatures and certificates. - Create SPL CSF binary file: $ ./cst -i csf_spl.txt -o csf_spl.bin - Create FIT CSF binary file: $ ./cst -i csf_fit.txt -o csf_fit.bin 3.8 Assembling the CSF in flash.bin binary ------------------------------------------- The CSF binaries generated in the step above have to be inserted into the flash.bin image. The CSF offsets can be obtained from the flash.bin build log: - SPL CSF offset: csf_off 0x24a00 - FIT CSF offset: sld_csf_off 0x59020 The signed flash.bin image can be then assembled: - Create a flash.bin copy: $ cp flash.bin signed_flash.bin - Insert csf_spl.bin in signed_flash.bin at 0x24a00 offset: $ dd if=csf_spl.bin of=signed_flash.bin seek=$((0x24a00)) bs=1 conv=notrunc - Insert csf_fit.bin in signed_flash.bin at 0x59020 offset: $ dd if=csf_fit.bin of=signed_flash.bin seek=$((0x59020)) bs=1 conv=notrunc - Flash signed flash.bin image: $ sudo dd if=signed_flash.bin of=/dev/sd<x> bs=1K seek=33 && sync 3.9 Verifying HAB events ------------------------ The next step is to verify that the signatures included in flash.bin image is successfully processed without errors. HAB generates events when processing the commands if it encounters issues. Prior to closing the device users should ensure no HAB events were found, as the example below: - Verify HAB events: => hab_status Secure boot disabled HAB Configuration: 0xf0, HAB State: 0x66 3.10 Programming SRK Hash ------------------------- The U-Boot fuse tool can be used for programming eFuses on i.MX SoCs. - Dump SRK Hash fuses values in host machine: $ hexdump -e '/4 "0x"' -e '/4 "%X""\n"' SRK_1_2_3_4_fuse.bin 0x20593752 0x6ACE6962 0x26E0D06C 0xFC600661 0x1240E88F 0x1209F144 0x831C8117 0x1190FD4D - Program SRK_HASH[255:0] fuses on i.MX8MN devices: => fuse prog 6 0 0x20593752 => fuse prog 6 1 0x6ACE6962 => fuse prog 6 2 0x26E0D06C => fuse prog 6 3 0xFC600661 => fuse prog 7 0 0x1240E88F => fuse prog 7 1 0x1209F144 => fuse prog 7 2 0x831C8117 => fuse prog 7 3 0x1190FD4D 3.10 Completely secure the device ---------------------------------- Additional fuses can be programmed for completely secure the device, more details about these fuses and their possible impact can be found at AN4581[1]. - Program SRK_LOCK: => fuse prog 0 0 0x200 - Program DIR_BT_DIS: => fuse prog 1 3 0x8000000 - Program SJC_DISABLE: => fuse prog 1 3 0x200000 - JTAG_SMODE: => fuse prog 1 3 0xC00000
查看全文
There are two format system image(ext4): raw and sparse. The raw image is  larger, you can mount it to ext4 directly(mount -t ext4 system.img system). The sparse image is supported lp5.0, it is a bit smaller. The below part will take IMX7D SDB board as example. You can change the setting according your platform hardware.   1 generate sparse image   In Lollipop 5.0 and 5.1, both raw image and sparse image will be generated by default. sparse system image is located in: out/target/product/sabresd_7d/system_sparse.img raw system image is located in:out/target/product/sabresd_7d/system.img Below are the steps used in android build system to generate system.img build out sparse image(-s means the building system image is sparse)           make_ext4fs -s -T -1 -S out/target/product/sabresd_7d/root/file_contexts -l 374476800 -a system           out/target/product/sabresd_7d/obj/PACKAGING/systemimage_intermediates/system.img out/target/product/sabresd_7d/system transform sparse image to raw image           simg2img out/target/product/sabresd_7d/system_sparse.img out/target/product/sabresd_7d/system.img   2 burn sparse image to sd/emmc      There are two ways to program the sparse image into android boot storage Transform the sparse image into raw image in host Linux PC. And use the commands dd commands to program the raw image into the boot storage. Program the sparse image with MFG Tool in i.MX Android release package.                Steps: copy system_sparse.img to files/android/sabresd/. copy simg2img binary (in simg2img.zip) to files/android/. You also need update mfgtools-without-rootfs.tar\mfgtools\Profiles\Linux\OS Firmware\ucl2.xml        diff --git a/Profiles/Linux/OS Firmware/ucl2.xml b/Profiles/Linux/OS Firmware/ucl2.xml      index 3b15ddd..3c3d2ae 100755      --- a/Profiles/Linux/OS Firmware/ucl2.xml      +++ b/Profiles/Linux/OS Firmware/ucl2.xml        @@ -621,8 +621,12 @@              <CMD state="Updater" type="push" body="$ mkfs.ext4 /dev/mmcblk%mmc%p6">Formatting cache partition</CMD>                <CMD state="Updater" type="push" body="$ mkfs.ext4 /dev/mmcblk%mmc%p7">Formatting device partition</CMD>      -       <CMD state="Updater" type="push" body="pipe dd of=/dev/mmcblk%mmc%p5 bs=512" file="files/android/sabresd/system.img">Sending and writting system.img</CMD>      -      +       <CMD state="Updater" type="push" body="send" file="files/android/simg2img" ifdev="MX7D">Sending simg2img</CMD>      +       <CMD state="Updater" type="push" body="$ cp $FILE /tmp/simg2img ">cp simg2img</CMD>      +       <CMD state="Updater" type="push" body="$ chmod  777 /tmp/simg2img ">chmod 777</CMD>      +       <CMD state="Updater" type="push" body="$  mount -o remount,size=512M rootfs /">change size of tmpfs</CMD>      +       <CMD state="Updater" type="push" body="send" file="files/android/sabresd/system_sparse.img" ifdev="MX7D">Sending system_sparse.img</CMD>      +       <CMD state="Updater" type="push" body="$ /tmp/simg2img $FILE /dev/mmcblk%mmc%p5">Sending and writting system_sparse.img</CMD>              <!-- Write userdata.img is optional, for some customer this is needed, but it's optional. -->              <!-- Also, userdata.img will have android unit test, you can use this to do some auto test. -->              <!--    <CMD state="Updater" type="push" onError="ignore" body="pipe dd of=/dev/mmcblk0p7" file="file/android/userdate.img"> Sending userdata.   3 Support sparse image in uboot(v2014.04)      Cheery-pick sparse image related patches. Use write_sparse_image to burn sparse system image.      For detail information, Please check the attached file(uboot(v2014.04)which support sparseimage.zip )        The step of apply these patches: cd myandroid/bootable/bootloader/uboot-imx/ copy uboot(v2014.04) which support sparseimage.zip to myandroid/bootable/bootloader/uboot-imx/         unzip uboot(v2014.04) which support sparseimage.zip git am 0001-add-header-for-Android-sparse-image-format.patch         git am 0002-add-code-to-handle-Android-sparse-image-format.patch         git am 0003-update-code-which-handles-Android-sparse-image-forma.patch         git am 0004-cleanup-code-which-handles-the-Android-sparse-image-.patch         git am 0005-implement-the-Android-sparse-image-format.patch         git am 0006-aboot-fix-block-addressing-for-don-t-care-chunk-type.patch         git am 0007-MA-6732-Add-sparse-image-flash-support-for-uboot-s-f.patch            The page will keep updating.   Reference:      How to enable userdata.img and cache.img in lollipop
查看全文
There are two optionsou 1. Remove all source code after building: You can indicate bitbake to remove all source code after a build adding this line INHERIT += "rm_work" our to your conf/local.conf file. Of course, when baking another image, ALL source code has to be fetched again and it can take a lot of time, specially on machines with low connections to the Internet. The smallest image you can build is core-image-minimal, containing the minimal set of packages to board a particular machine. The largest is fsl-image-gui (in fact, there is one bigger 'fsl-image-gui-sdk' used for developing purposes inside the target). Between these two, there are a lot of images you can choose. You can even create your own image using hob. In case you do not want to build anything, there are some pre-built images on this site, just download the sdcard file and flash it to an SD card. 2. Select only those  IMAGE_FSTYPES you need. There is a variable named IMAGE_FSTYPES  which indicates the output formats you want for the resulting root file system images, by default is has this value: IMAGE_FSTYPES ?= "tar.bz2 ext3 sdcard" and it is located on /sources/meta-fsl-arm/conf/machine/include/imx-base.inc machine's header file. If you want to change it, place this variable on the build/conf/local.conf file. In case you have NFS mounting, remove the 'sdcard' (and either 'ext3' or 'tar.bz2') string, resulting in IMAGE_FSTYPES = "tar.bz2"
查看全文
1. To setup the Yocto environment, from the BASE folder run fsl-community-bsp $ . setup-environment build 2. Build the toolchain build $ bitbake meta-toolchain # Other toolchains: # Qt Embedded toolchain build: bitbake meta-toolchain-qte # Qt X11 toolchain build: bitbake meta-toolchain-qt 3. Install it on your PC build $ sudo sh \   tmp/deploy/sdk/poky-eglibc-x86_64-arm-toolchain-<version>.sh 4. Setup the toolchain environment build $ source \   /opt/poky/<version>/environment-setup-armv7a-vfp-neon-poky-linux-gnueabi 5. Get the Linux Kernel's source code. $ git clone git://git.freescale.com/imx/linux-2.6-imx.git linux-imx $ cd linux-imx 6. Create a local branch linux-imx $ BRANCH=imx_3.0.35_4.0.0 # Change to any branch you want,   # Use 'git branch -a' to list all linux-imx $ git checkout -b ${BRANCH} origin/${BRANCH} 7. Export ARCH and CROSS_COMPILE linux-imx $ export ARCH=arm  linux-imx $ export CROSS_COMPILE=arm-poky-linux-gnueabi- linux-imx $ unset LDFLAGS 8. Choose configuration and compile linux-imx $ make imx6_defconfig  linux-imx $ make uImage  9. To Test your changes, copy the `uImage` into your SD Card linux-imx $ sudo cp arch/arm/boot/uImage /media/boot 10. If case you want your changes to be reflected on your Yocto Framework, create the patches following the document i.MX Yocto Project: How can I patch the kernel?
查看全文
Building Linux Kernel Building Linux Kernel Building Using LTIB Building Outside LTIB Downloading and installing GNU Toolchain and git Building Kernel from Freescale git repository Building Kernel Mainline About Linux Building Using LTIB Linux kernel can be easily built using Ltib. On Ltib menu, just select: [*] Configure the Kernel When you exit this menu, Ltib will show the Kernel Menuconfig as below: This is the Kernel Menuconfig, where it's possible to configure kernel options and drivers. After exit this menu, kernel will be built and stored at: <Ltib directory>/rootfs/boot Building Outside LTIB Downloading and installing GNU Toolchain and git When you install LTIB, a GNU toolchain is automatically installed on /opt/freescale/usr/local/ Kernel releases newer than 2.6.34 doesn't build on Toolchain 4.1.2, only on 4.4.1 or later Check on your host at /opt/freescale/usr/local/ the current installed Toolchain. Next step is to install GIT on host. For Ubuntu machines, use: sudo apt-get install git-core Building Kernel from Freescale git repository Freescale provides access to their own git kernel repository and can be viewed at: Freescale Public GIT To download the kernel source code, create a new folder and use the command: git clone git://git.freescale.com/imx/linux-2.6-imx.git OR git clone http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git After some minutes, a folder called linux-2.6-imx will be created containing the Linux kernel Create a local git branch from a remote branch you want to use. Let's use branch origin/imx_3.0.15 as example: cd linux-2.6-imx git checkout -b localbranch origin/imx_3.0.15 To check all available remote branches, use: git branch -r Export the cross compiler, architecture and the toolchain path: export ARCH=arm export CROSS_COMPILE=arm-none-linux-gnueabi- If using Toolchain 4.1.2: export PATH="$PATH:/opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/" OR If using Toolchain 4.4.4: export PATH="$PATH:/opt/freescale/usr/local/gcc-4.4.4-glibc-2.11.1-multilib-1.0/arm-fsl-linux-gnueabi/bin/" Copy the config file for the wanted platform on linux folder as example: cp arch/arm/configs/imx6_defconfig .config All platform config files are located at <linux directory>/arch/arm/configs/ Call menuconfig and change configuration (if needed) make menuconfig Now it's ready to be built: make uImage The zImage and uImage will be located at /arch/arm/boot/ folder. Building Kernel Mainline Mainline Kernel can be viewed on this link: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git To download the kernel source code, create a new folder and use the command: git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git OR git clone http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git OR git clone https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git After some minutes, a folder called linux will be created containing the Linux kernel Create a local git branch from a remote branch you want to use. Let's use branch origin/linux-3.8.y as example: cd linux git checkout -b localbranch origin/linux-3.8.y To check all available remote branches, use: git branch -r Export the cross compiler, architecture and the toolchain path: export ARCH=arm export CROSS_COMPILE=arm-none-linux-gnueabi- If using Toolchain 4.4.4: export PATH="$PATH:/opt/freescale/usr/local/gcc-4.4.4-glibc-2.11.1-multilib-1.0/arm-fsl-linux-gnueabi/bin/" Configure to the platform you want to build kernel. For i.MX family, use imx_v6_v7_defconfig: make imx_v6_v7_defconfig All platform config files are located at <linux directory>/arch/arm/configs/ Call menuconfig and change configuration (only if needed, this is an optional step!) make menuconfig Now it's ready to be built: make -j4 uImage LOADADDR=0x70008000 - Use -j4 option to speed up your build in case or PC has 4 cores. It's optional. - IMPORTANT: Use the correct address for each processor. You can check the correct address value at linux/arch/arm/mach-imx/Makefile.boot. After build the uImage, build the dtb file (device tree binary). For i.MX53 QSB use: make imx53-qsb.dtb The uImage will be located at: linux/arch/arm/boot/ folder and dtb binary will be located at: linux/arch/arm/boot/dts About Linux For general Linux information, see About Linux
查看全文
The document includes the following contents: (1)document how to port ov5646 to android jb4.2.2 (2) ov5645 driver for Linux 3.0.35 (3) ov5645 schematic based on i.MX6Q/DL (4)ov5645 for android camera HAL   [Note:]      P5V29A-0JG is a camera module based on OV5645, and PAO532-0JG is based on OV5640, both manufactured by NINGBO SUNNY OPOTECH CO.LTD (China), If customer wants to use them on i.MX6 platform, can send me email to ask for datasheets of P5V29A & PAO532 , or discuss corresponding questions on porting.   Email: [email protected]
查看全文
  This is a detailed programming aid for the registers associated with i.MX 8M Plus DDR initialization. LPDDR4 DDR4  For more details, refer to the main mScale DDR tools page: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX-8M-Family-DDR-Tool-Release/ta-p/1104467 Please note that this page is only intended to store the RPA spreadsheets. For questions, please create a new community thread.  
查看全文
This is a How-To documentation for OpenCL on i.MX6 using LTIB, there are all necessary steps and sample code to create,  build and run a HelloWorld application.
查看全文
** If you cannot access the www.youtube.com you may watch the Wi-Fi Display Sink Demo in here: ** ********      http://v.youku.com/v_show/id_XNzczMzQ2MTc2.html             ******** We already have the strong i.MX 6 to support the Android kitkat now. So we also develop the WiFi Display Sink in it. With Wi-FI Display technology we can cast the screen and audio to another one via Wi-Fi P2p. It's also named the Miracast. Freescale extends Android by offering a Wi-Fi Display Sink feature. The Wi-Fi hardware module used for this feature are the Realtek RTL8821AS , RTL8723AS and AR6233 SDIO Cards. But the design of this feature allows porting to any Wi-Fi hardware module. Using the Freescale Wi-Fi Display Sink API and the demonstration application, users can easily develop their own Sink Application. This feature has been verified using several of the most popular Android phones and tablets. Our Wi-Fi Display has the following highlight feature: Low latency Support UIBC (When Source device uses Freescale Android maddev_kk4.4.3-2.0.0) Rapid recovery from network congestion Compatibility to different vendor Wi-Fi chips and Wi-Fi Display devices From the demo video we can cast the stopwatch and measure the latency by it. Here are the high quality video shots and we can calculate the real latency which less than 200ms!      For the WiFi Display Spec the orange ones in below figure were achieved in our WiFi Display. Reference pages:       Miracast - Wikipedia       Wi-Fi CERTIFIED Miracast | Wi-Fi Alliance             For more information and details about Wi-Fi Display Sink in i.MX6, please send inquiry to [email protected] .
查看全文
Question: How is mx6 PMIC_ON_REQ under SW control? mx6 PMIC_ON_REQ is hooked up to the PFUZE100's PWRON and Linux and our 3.0.35bsp is used. Mx6 SW control is to drive the PMIC_ON_REQ pin low.  It appears from the documentation that this pin can be controlled by either another imx6 pin OR through SW control. The issue is that the reference manual is not clear on how to do this. While doing an SR search (SR 1-877711457), it does appear the PMIC_ON_REQ is controlled by SW. Answer: In latest RM version, Figure 60-3. Chip on/off state flow diagram and Table 60-3. Power mode transitions in IMX6DQRM.pdf show two ways to make PMIC_ON_REQ go low. I'm sure in latest BSP SW method had been included. It turns out the SNVS module on the mx6s/dl is different from the mx6q/d which is again different from the mx6slx. The bottom line is that the requirements for the SNVS functionality came primarily from the Android market so many of the Linux use cases are not supported. SW control of the PMIC_ON_REQ pin is an example of this. This means that you are correct, there only 2 ways to get PMIC_ON_REQ to power up for the mx6q/d 1 -  a low on the ON/OFF pin greater than the debounce time (750ms) 2 - a wake-up/tamper event. For the mx6s/dl, there are 3 ways to get PMIC_ON_REQ to power up 1 - power-on-reset on the VSNVS  (i.e first applying VSNVS) 2 -  a low on the ON/OFF pin greater than the debounce time (750ms) 3 - a wake-up/tamper event. Note, in my case, where there is an external input that actually wakes up the system, turns on the PMIC and brings up the mx6 there is only 1 way to get PMIC_ON_REQ to go back high 1 - a low on the ON/OFF pin greater than the debounce time (750ms) As it turns out, when the VSNVS_HP section is powered (i.e VDDHIGH is applied), it gates off the wake-up timer.
查看全文
The following steps allow to make use of device tree overlay files, a definition of device tree overlay provided by kernel.org is the next:  "A Devicetree’s overlay purpose is to modify the kernel’s live tree, and have the modification affecting the state of the kernel in a way that is reflecting the changes. Since the kernel mainly deals with devices, any new device node that result in an active device should have it created while if the device node is either disabled or removed all together, the affected device should be deregistered." Knowing that, in this post will be used as an example the baseboard "i.MX 93 EVK" and will be added with device tree overlay an LVDS panel, adding an automatic detection from u-boot, and will be used a host with linux version Ubuntu 20.04.2. Note: It only works for linux kernel version 6.6.3-nanbield onward. Linux device-tree overlay from linux-imx   This section explains all about device tree overlay compilation and building, to create a .dtso file, the equivalent of .dts for overlays, adding some difference between them, using as base the linux-imx repository. It can be downloaded from the following repository:   git clone https://github.com/nxp-imx/linux-imx.git -b <branch version>   Branch version used by this post "lf-6.6.3-1.0.0". Device tree source overlay (.dtso)    It can be similar to a device tree source (.dts) but it had little difference between them, there are some difference in the next list: There's another type of files to be included, if is used pinmux it's necessary adding it with "#include "imx93-pinfunc.h"" and libraries from dt-bindings, it depends on the type of device tree to implement "#include <dt-bindings/<library>>" At initialization it needs to add: "/dts-v1/;"  "/plugin/;" Addition of "fragment" nodes, it allow override parts of a device tree,  it can be a specific node or create a new node. following structure it's the structure of a fragment:   { /* ignored properties by the overlay */ fragment@0 { /* first child node */ target=<phandle>; /* phandle target of the overlay */ or target-path="/path"; /* target path of the overlay */ __overlay__ { property-a; /* add property-a to the target */ node-a { /* add to an existing, or create a node-a */ ... }; }; } fragment@1 { /* second child node */ ... }; /* more fragments follow */ }   kernel.org Overlays can't delete a property or a node when it's applied, so can't be used "/delete-node/" nor "/delete-prop/", but it can be added to the node "status = "disabled";" to disable it.  Using as an example the file imx93-11x11-evk-boe-wxga-lvds-panel.dts located in the previous repository file direction <linux-imx path>/arch/arm64/boot/dts/freescale/ using it as a base tree:   // SPDX-License-Identifier: (GPL-2.0+ OR MIT) /* * Copyright 2022 NXP */ #include "imx93-11x11-evk.dts" / { lvds_backlight: lvds_backlight { compatible = "pwm-backlight"; pwms = <&adp5585pwm 0 100000 0>; enable-gpios = <&adp5585gpio 8 GPIO_ACTIVE_HIGH>; power-supply = <&reg_vdd_12v>; status = "okay"; brightness-levels = < 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100>; default-brightness-level = <80>; }; ... }; ... &adv7535 { status = "disabled"; }; ...   imx93-11x11-evk-boe-wxga-lvds-panel.dts Using the previous points and making use of fragments, if we want adapt the node lvds_backlight as fragment, it will be  added in the section of overlay, and adding it to a target-path "/":   #include <dt-bindings/interrupt-controller/irq.h> #include "imx93-pinfunc.h" #include <dt-bindings/gpio/gpio.h> /dts-v1/; /plugin/; / { fragment@0 { target-path = "/"; __overlay__ { lvds_backlight: lvds_backlight { compatible = "pwm-backlight"; pwms = <&adp5585pwm 0 100000 0>; enable-gpios = <&adp5585gpio 8 GPIO_ACTIVE_HIGH>; power-supply = <&reg_vdd_12v>; status = "okay"; brightness-levels = < 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100>; default-brightness-level = <80>; }; }; }; ... };   imx93-11x11-evk-test-lvds-panel.dtso In the case of adding a property to an existing node, it will look in the following way using as example the node adv7535.   ... / { ... fragment@2 { target = <&adv7535>; __overlay__ { status = "disabled"; }; }; ... };   imx93-11x11-evk-boe-wxga-lvds-panel.dts At the end of this post, will be attach the complete file used for LVDS panel named as imx93-11x11-evk-test-lvds-panel.dtso Build device tree blob for overlay (dtbo)   To compile the previous .dtso it's necessary to include it to linux-imx repository, linux device tree overlay was included in BSP from version 6.6.3-nanbield onward in Makefile, so it's only necessary adding it as files to be compiled as .dtso, at the end of the post will be a patch file named as linux-imx-makefile.patch to add LVDS-panel to Makefile from branch lf-6.6.3-1.0.0 Add previously file imx93-11x11-evk-test-lvds-panel.dtso to path <linux-imx path>/arch/arm64/boot/dts/freescale/ Add imx93-11x11-evk-test-lvds-panel.dtso as file to be compiled in Makefile, it is located in the next path <linux-imx path>/arch/arm64/boot/dts/freescale/Makefile, it can be added with the next sentence format: <overlay without extension>-dtbs := <file to be overlayed>.dtb <overlay>.dtbo Example of how to add LVDS panel to makefile  imx93-11x11-evk-test-lvds-panel-dtbs := imx93-11x11-evk.dtb imx93-11x11-evk-test-lvds-panel.dtbo Makefile From main path, make the configuration to be compiled with the following bash command: $ cd <linux-imx path>/ $ make -j$(nproc --all) ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- imx_v8_defconfig​ Compile overlay to use $ make -j $(nproc --all) ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- freescale/<overlay>.dtbo​ as example for LVDS panel $ make -j $(nproc --all) ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- freescale/imx93-11x11-evk-test-lvds-panel.dtbo It will compile the device tree blob overlay to use. Copy .dtbo generated in memory used by i.MX 93, it can be sending it from scp. scp ./​<overlay>.dtbo​ root@<ip>:/run/media/<memory section used> u-boot   This section explain the procedure to load a device tree overlay, it will be from u-boot explaining commands used and using the LVDS panel as an example. Before applying overlay   Before applying, it's necessary had a device tree loaded so looking around in the process of booting in a i.MX 93 from u-boot, this process is defined by the enviroment variable "bsp_bootcmd" that calls the variable mmcboot, and looking what does these variables, it can be look in the following sentence:    bsp_bootcmd=echo Running BSP bootcmd ...; mmc dev ${mmcdev}; if mmc rescan; then if run loadbootscript; then run bootscript; else if test ${sec_boot} = yes; then if run loadcntr; then run mmcboot; else run netboot; fi; else if run loadimage; then run mmcboot; else run netboot; fi; fi; fi; fi; mmcboot=echo Booting from mmc ...; run mmcargs; if test ${sec_boot} = yes; then if run auth_os; then run boot_os; else echo ERR: failed to authenticate; fi; else if test ${boot_fit} = yes || test ${boot_fit} = try; then bootm ${loadaddr}; else if run loadfdt; then run boot_os; else echo WARN: Cannot load the DT; fi; fi;fi;   but reducing it in a normal situation, ignoring if else case and echoes, it can be simplify to:   mmc dev ${mmcdev}; run loadimage; run mmcargs; run loadfdt; run boot_os;   the device tree is load is in the section "run loadfdt" with fatload in his definition:   loadfdt=fatload mmc ${mmcdev}:${mmcpart} ${fdt_addr_r} ${fdtfile}   So, it's necessary to applying device tree overlay after "run loadfdt". How to apply an overlay   To load correctly an overlay it's necessary to following some steps: Load flattened device tree (fdt). (executed by loadfdt) Configure fdt address.  In some cases it's necessary to expand fdt memory size Load overlay Apply overlay The full sentence to apply it, it's the following u-boot command:   u-boot=> setexpr fdtovaddr ${fdt_addr} + 0xF0000; setexpr fdt_buffer 16384; fdt addr ${fdt_addr} && fdt resize ${fdt_buffer}; fatload mmc ${mmcdev}:${mmcpart} ${fdtovaddr} <overlay>.dtbo && fdt apply ${fdtovaddr};   First of all, setexpr it's just to create a new variable, in this case these variable is an integer. Spliting the previously command we can found the steps to applying it. "fdt addr ${fdt_addr};" used to configure fdt address, and point to the space of memory previously charged. "fdt resize ${fdt_buffer};" expand fdt memory size, is used as a value 16384 just to get the enough space to charge dtbo, this number was related with 2 14 "fatload mmc ${mmcdev}:${mmcpart} ${fdtovaddr} <overlay>.dtbo" Load device tree overlay using fdovaddr, that is fdt_addr adding an offset of memory space.  "fdt apply ${fdtovaddr};" apply device tree overlay Remembering about load overlay needs to be executed after loadfdt, it's possible to save the previous command to a variable and executing it after loadfdt with setexpr, in this case using as example lvds test.   u-boot=> setenv loadoverlay "setexpr fdtovaddr ${fdt_addr} + 0xF0000; setexpr fdt_buffer 16384; fdt addr $\{fdt_addr\} && fdt resize $\{fdt_buffer\}; fatload mmc $\{mmcdev\}:$\{mmcpart\} $\{fdtovaddr\} imx93-11x11-evk-test-lvds-panel.dtbo && fdt apply $\{fdtovaddr\};"   and modifying mmcboot with loadoverlay after loadfdt   u-boot=> setenv mmcboot "run mmcargs; run loadfdt; run loadoverlay; run boot_os;"   to save the environment variables created, it can be saved from u-boot wit the following command.   u-boot=> saveenv   At the end, boot imx93   u-boot=> boot   The LVDS panel should be working using the original dtb (imx93-11x11-evk.dtb) applied the overlay. Automatize u-boot LVDS Panel   This section explain how can be automatize the u-boot load overlay using an LVDS panel, it can vary depending the device to used for, the method used is detecting it in u-boot initialization and if found any device it will generate an environment variable. All the steps was using as a base uboot-imx repository, it can be downloaded from the following repository, at the end of this post will be a patch with the changes.   git clone https://github.com/nxp-imx/uboot-imx.git -b <branch version>   Branch version used "lf-6.6.3-1.0.0". Base   Knowing more about LVDS Panel used by imx93 it's really hard know more information about registers, so in this example will be limited to detect that is connected the address to a corresponding bus from touch controller.  To know i2c address and bus used by LVDS panel it was used searching it from the original device tree in the next section:   &lpi2c1 { exc80h60: touch@2a { compatible = "eeti,exc80h60"; reg = <0x2a>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_ctp_int>; /* * Need to do hardware rework here: * remove R131, short R181 */ interrupt-parent = <&gpio2>; interrupts = <21 IRQ_TYPE_LEVEL_LOW>; reset-gpios = <&pcal6524 17 GPIO_ACTIVE_HIGH>; status = "okay"; }; };   imx93-11x11-evk-boe-wxga-lvds-panel.dts Previous node is related with touch controller from LVDS using lpi2c1, the first channel of i2c corresponding to i2c bus 0, and the register used express the address used to be detected by device tree, in this case was the address 0x2A. u-boot generating a trigger   About how it can be detected touch controller from u-boot, this procedure use a function named as "board_late_init", it can be found by his definition from u-boot readme:   Board initialization settings: ------------------------------ During Initialization u-boot calls a number of board specific functions to allow the preparation of board specific prerequisites, e.g. pin setup before drivers are initialized. To enable these callbacks the following configuration macros have to be defined. Currently this is architecture specific, so please check arch/your_architecture/lib/board.c typically in board_init_f() and board_init_r(). - CONFIG_BOARD_EARLY_INIT_F: Call board_early_init_f() - CONFIG_BOARD_EARLY_INIT_R: Call board_early_init_r() - CONFIG_BOARD_LATE_INIT: Call board_late_init()   u-boot README In the case of i.MX 93 this function can be found in the next path <u-boot path>/board/freescale/imx93_evk/imx93_evk.c. Using the library included, "uclass.h", it will create a function that, if detect in the bus 0 (LVDS i2c bus) the address 0x2A (i2c LVDS address), it will create an environment variable with the overlay used, it can be set with the function env_set(<String with the name of the variable>, <String with the content of the variable>), the following function can detect and create the environment variable mentioned, creating it with the name "device-tree-overlay" with the content "lvds-panel".   #define LVDS_TOUCH_I2C_BUS 0 #define LVDS_TOUCH_I2C_ADDR 0x2A static void detect_display_connected(void) { struct udevice *bus = NULL; struct udevice *i2c_dev = NULL; int ret; ret = uclass_get_device_by_seq(UCLASS_I2C, LVDS_TOUCH_I2C_BUS, &bus); if (ret) { printf("%s: Can't find bus\n", __func__); } else { ret = dm_i2c_probe(bus, LVDS_TOUCH_I2C_ADDR, 0, &i2c_dev); if (ret) { printf("%s: Can't find device id=0x%x\n", __func__, LVDS_TOUCH_I2C_ADDR); } else { env_set("device-tree-overlay", "lvds-panel"); } } }   imx93_evk.c At the end, add this function to the previously mention, named as board_late_init, in the section CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG, like the following snipped from code:   int board_late_init(void) { #ifdef CONFIG_ENV_IS_IN_MMC board_late_mmc_env_init(); #endif env_set("sec_boot", "no"); #ifdef CONFIG_AHAB_BOOT env_set("sec_boot", "yes"); #endif #ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG env_set("board_name", "11X11_EVK"); env_set("board_rev", "iMX93"); detect_display_connected(); #endif return 0; }   imx93_evk.c Now, when it's starting u-boot after flashing, it will generate the environment variable as trigger if something it's connected with that i2c address, else it doesn't do anything. u-boot applying device tree overlay through event   As was explained in the section "How to apply device tree overlay", applying the device tree overlay automatically after configure the trigger it's easy, just adding an if/else case for this example, it can be more ways to applying it, even it's possible adding more of one device tree overlay, but in this example will load one.  Using u-boot command "test -e <environment variable>" it will detect if exist this environment variable, adding it to an if/else sentence it can create the event and applying the overlay if was detected or not, for this solution will be added this if/else as input if exists loadoverlay variable with the following structure:   u-boot=> if test -e ${device-tree-overlay}; then <case exists device-tree-overlay variable> else <case doesn't exists device-tree-overlay variable>; fi;   adding it to loadoverlay, it will be written like the following command:   u-boot=> setenv loadoverlay "if test -e ${device-tree-overlay}; then setexpr fdtovaddr ${fdt_addr} + 0xF0000; setexpr fdt_buffer 16384; fdt addr ${fdt_addr} && fdt resize $\{fdt_buffer\}; fatload mmc ${mmcdev}:${mmcpart} $\{fdtovaddr\} imx93-11x11-evk-test-lvds-panel.dtbo; fdt apply $\{fdtovaddr\} ; else echo no overlay; fi;"   A no recommended method it's that it can be saved the environment, and changing mmcboot variable with the following command:   u-boot=> setenv mmcboot "run mmcargs; run loadfdt; run loadoverlay; run boot_os;"; saveenv;   The problem about just saving it, it still necessary compile u-boot to load auto-detection of LVDS panel and flashing, another way to add the event trigger, it's adding it to u-boot as initial environment variable, it can be added in the header file of imx93, it is located in the next path <u-boot path>/include/configs/imx93_evk.h, line number 60, it can be added with the same string but it's recommended follow the same structure, like the following definition:   /* Initial environment variables */ #define CFG_EXTRA_ENV_SETTINGS \ ... "loadoverlay=echo loading overlays from mmc ...; " \ "if test -e ${device-tree-overlay}; then " \ "setexpr fdtovaddr ${fdt_addr} + 0xF0000; " \ "setexpr fdt_buffer 16384; " \ "fdt addr ${fdt_addr} && fdt resize ${fdt_buffer}; " \ "fatload mmc ${mmcdev}:${mmcpart} ${fdtovaddr} imx93-11x11-evk-test-lvds-panel.dtbo && fdt apply ${fdtovaddr}; " \ "else " \ "echo no overlay; " \ "fi;\0" \ ...   imx93_evk.h it also it's necessary to change mmcboot environment variable adding loadoverlay after executing loadfdt.    /* Initial environment variables */ #define CFG_EXTRA_ENV_SETTINGS \ .. "mmcboot=echo Booting from mmc ...; " \ "run mmcargs; " \ "if test ${sec_boot} = yes; then " \ "if run auth_os; then " \ "run run boot_os; " \ "else " \ "echo ERR: failed to authenticate; " \ "fi; " \ "else " \ "if test ${boot_fit} = yes || test ${boot_fit} = try; then " \ "bootm ${loadaddr}; " \ "else " \ "if run loadfdt; then " \ "run loadoverlay; " \ "run boot_os; " \ "else " \ "echo WARN: Cannot load the DT; " \ "fi; " \ "fi;" \ "fi;\0" \ ...   imx93_evk.h To build u-boot, copy the following commands in main path from u-boot   $ cd <u-boot path> $ make -j $(nproc --all) clean PLAT=imx93 CROSS_COMPILE=aarch64-linux-gnu- $ make -j $(nproc --all) ARCH=arm CROSS_COMPILE=aarch64-linux-gnu- imx93_11x11_evk_defconfig $ make -j $(nproc --all) PLAT=imx93 CROSS_COMPILE=aarch64-linux-gnu-   generating the files u-boot.bin and u-boot-spl.bin located in <uboot-imx path>/ and <uboot-imx path>/spl Build imx-boot image using imx-mkimage   To build the binary necessary to flash to iMX 93 EVK it's necessary build a file named as flash.bin, it can building using the next repository using the branch used for this example:    $ git clone https://github.com/nxp-imx/imx-mkimage.git -b lf-6.6.3_1.0.0   to build imx-boot image it's necessary adding some files to the path <imx-mkimage path>/iMX93, including 2 generated by u-boot, u-boot.bin and u-boot-spl.bin, move these files to iMX93 directory.   $ cp <uboot-imx path>/u-boot.bin <uboot-imx path>/spl/u-boot-spl.bin <imx-mkimage path>/iMX93/   follow the steps from imx linux users guide section 4.5.13 and imx linux release notes section 1.2 to build flash.bin, as an example of compile, there's the steps to compile for imx93. Get mx93a1-ahab-container.img $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-sentinel-0.11.bin $ chmod +x firmware-sentinel-0.11.bin $ ./firmware-sentinel-0.11.bin $ cp firmware-sentinel-0.11/mx93a1-ahab-container.img <imx-mkimage path>/iMX93/​ Get lpddr4_imem_1d_v202201.bin, lpddr4_dmem_2d_v202201.bin, lpddr4_imem_1d_v202201.bin and lpddr4_imem_2d_v202201.bin $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.23.bin $ chmod +x firmware-imx-8.23.bin $ ./firmware-imx-8.23.bin $ cp firmware-imx-8.23/firmware/ddr/synopsys/lpddr4_dmem_1d_v202201.bin firmware-imx-8.23/firmware/ddr/synopsys/lpddr4_dmem_2d_v202201.bin firmware-imx-8.23/firmware/ddr/synopsys/lpddr4_imem_1d_v202201.bin firmware-imx-8.23/firmware/ddr/synopsys/lpddr4_imem_2d_v202201.bin <imx-mkimage path>/iMX93/​ Get bl31.bin $ git clone https://github.com/nxp-imx/imx-atf.git -b lf-6.6.3-1.0.0 $ cd imx-atf $ make -j $(nproc --all) PLAT=imx93 CROSS_COMPILE=aarch64-linux-gnu- $ cp <imx-atf path>/build/imx93/release/bl31.bin <imx-mkimage path>/iMX93​ Compile flash.bin from imx-mkimage $ cd <imx-mkimage path>/ $ make SOC=iMX9 REV=A1 flash_singleboot​ it will generate the binary flash.bin located in the path <imx-mkimage path>/iMX93/flash.bin. Flashing u-boot   Flashing just u-boot image using flash.bin, will be used uuu.exe, it can be downloaded from the his repositroy, try using the most recent version taged as "Latest"    https://github.com/nxp-imx/mfgtools/releases   make sure is using i.MX 93 EVK in boot mode download and connect it to your host from download USB port, using uuu.exe run the next code:   .\uuu.exe -b emmc .\flash.bin   or it can be flashed the full image with flash.bin binary.   .\uuu.exe -b emmc_all .\flash.bin ..\uuu\imx-image-full-imx93evk.wic   after that, starting be will using the created u-boot environment. Result   Inside u-boot, when it's connected the LVDS panel, it will create the variable named "device-tree-overlay" and will be charged automatically LVDS panel overlay, enabling it, if not it will working normally using DSI as output. Note: Ensure to have imx93-11x11-evk-test-lvds-panel.dtbo in memory. Reference   Device tree overlay: https://docs.kernel.org/devicetree/overlay-notes.html  
查看全文
Hi All, The new i.MX 6 Q/D/DL/S/SL L3.0.35_4.1.0 GA release is now available on the http://www.freescale.com/site. ·         Files available                                   # Name Description 1 L3.0.35_4.1.0_LINUX_DOCS i.MX   6Quad, i.MX 6Dual, i.MX 6DualLite, i.MX 6Solo and i.MX 6Sololite Linux BSP   Documentation. Includes Release Notes, Reference Manual, User guide. API   Documentation 2 L3.0.35_4.1.0_LINUX_MMDOCS i.MX   6Quad, i.MX 6Dual, i.MX 6DualLite, i.MX 6Solo and i.MX 6Sololite  Linux Multimedia Codecs Documentation.   Includes CODECs Release Notes and User's Guide 3 L3.0.35_4.1.0_SOURCE_BSP i.MX   6Quad, i.MX 6Dual, i.MX 6DualLite, i.MX 6Solo and i.MX 6Sololite Linux BSP   Source Code Files 4 L3.0.35_4.1.0_MM_CODECS i.MX   6Quad, i.MX 6Dual, i.MX 6DualLite, i.MX 6Solo and i.MX 6Sololite  Linux Multimedia Codecs Sources 5 L3.0.35_4.1.0_AACP_CODECS i.MX   6Quad, i.MX 6Dual, i.MX 6DualLite, i.MX 6Solo and i.MX 6Sololite  Linux AAC Plus Codec 6 L3.0.35_4.1.0_DEMO_IMAGE_BSP i.MX   6Quad, i.MX 6Dual, i.MX 6DualLite, i.MX 6Solo and i.MX 6Sololite  Linux Binary Demo Files 7 L3.0.35_4.1.0_UBUNTU_RFS_BSP i.MX   6Quad, i.MX 6Dual, i.MX 6DualLite, i.MX 6Solo and i.MX 6Sololite  Linux File System for the Ubuntu Images 8 i.MX_6D/Q_Vivante_VDK_146_Tools Set   of applications for the Linux L3.0.35_4.1.0 BSP, designed to be used by   graphics application developers to rapidly develop and port graphics   applications. Includes applications, GPU Driver with vprofiler enabled and   documentation. 9 IMX_6DL_6S_MFG_TOOL Tool   and documentation for downloading OS images to the i.MX 6DualLite and i.MX   6Solo. 10 IMX_6DQ_MFG_TOOL Tool   and documentation for downloading OS images to the i.MX 6Quad and i.MX 6Dual. 11 IMX_6SL_MFG_TOOL Tool   and documentation for downloading OS images to the i.MX 6Sololite. ·         Target HW boards o   i.MX 6Quad SABRE-SDP o   i.MX 6Quad SABRE-SDB o   i.MX 6Quad SABRE-AI o   i.MX 6DualLite SABRE-SDP o   i.MX 6DualLite SABRE-AI o   i.MX 6SL EVK ·         New features o   BSP New Features on i.MX 6D/Q, i.MX 6DL/S and MX 6SL: §  HDCP §  CEC §  GPU4.6.9p12 §  Audio playback IRAM/SDMA §  V4L capture resize on MX6SL §  MX6DQ disable the double line fill feature of PL310 ·         Known issues o   For known issues and limitations please consult the release notes.
查看全文
This document provides the steps to patch and build a fastboot Linux System. This document assumes the BSP 3.0.35_1.1.0 and a  i.MX6Q platform. For more information about what the patches do, please check this link. Install LTIB and move to the ltib folder Download the ltib patch from this document and patch it (patch -p1 < 0001-set-imx6_ssd_lite_defconfig-as-default-kernel-config.patch) Go to the LTIB configuration menu (./ltib -m config), select mx6q platform and min profile Select mx6q_sabresd as u-boot board Fetch and Patch: u-boot: Prepare u-boot source code (./ltib -m prep -p u-boot) Move to u-boot folder (cd rpm/BUILD/u-boot-2009.08) Download u-boot attached patches Patch code (for p in *.patch; do patch -p1 < $p;done) kernel: Prepare kernel source code (./ltib -m prep -p kernel) Move to kernel folder (cd rpm/BUILD/linux) Download attached kernel patches Patch code (for p in *.patch; do patch -p1 < $p;done) Build  (./ltib) Add  an application to run first after boot in rootfs/etc/inittab (see example inittab file, it captures data from the MIPI Camera) Create necessary devices nodes under rootfs/dev. For example terminal: sudo mknod ttymxc0 c 207 16 video capture nodes: sudo mknod video0 c 81 5; sudo mknod video1 c 81 6 video display nodes: sudo mknod video16 c 81 0; sudo mknod video17 c 81 1 frame-buffers: for i in 0 1 2 3 4; do sudo mknod fb$i c 29 $i; done Package rootfs (cd rootfs; sudo tar --numeric-owner -cvfj ../rootfs.tar.bz2 *; cd ..) On a windows machine, download latest Manufacturing tool and uncompress it. Move rootfs.tar.bz2, rootfs/boot/uImage and rootfs/boot/u-boot.bin into the corresponding Manufacturing folder (Profiles\MX6Q Linux Update\OS Firmware\files) Choose a sabresd-eMMC profile and flash the board Boot the board using the eMMC
查看全文
This is the procedure and patch to set up Ubuntu 14.04 64bit Linux Host PC and building i.MX6x L3.0.35_4.1.0. It has been tested to build GNOME profile and with FSL Standard MM Codec for i.MX6Q SDP with LVDS display. Add suggestion about compiling "gstreamer-plugins-good" when selecting "Min profile" rootfs.  Please refer to the Note session. A) Basic Requirement: Set up the Linux Host PC using ubuntu-14.04-desktop-amd64.iso Make sure the previous LTIB installation and the /opt/freescale have been removed B) Installed the needed packages to the Linux Host PC      Needed packages: $ sudo apt-get install gettext libgtk2.0-dev rpm bison m4 libfreetype6-dev $ sudo apt-get install libdbus-glib-1-dev liborbit2-dev intltool $ sudo apt-get install ccache ncurses-dev zlib1g zlib1g-dev gcc g++ libtool $ sudo apt-get install uuid-dev liblzo2-dev $ sudo apt-get install tcl dpkg $ sudo apt-get install asciidoc texlive-latex-base dblatex xutils-dev $ sudo apt-get install texlive texinfo $ sudo apt-get install lib32z1 lib32ncurses5 lib32bz2-1.0 $ sudo apt-get install libc6-dev-i386 $ sudo apt-get install u-boot-tools $ sudo apt-get install scrollkeeper $ sudo ln -s /usr/lib/x86_64-linux-gnu/librt.so   /usr/lib/librt.so      Useful tools: $ sudo apt-get install gparted $ sudo apt-get install nfs-common nfs-kernel-server $ sudo apt-get install git-core git-doc git-email git-gui gitk $ sudo apt-get install meld atftpd      Note: this operation "$ sudo ln -s /usr/lib/x86_64-linux-gnu/librt.so /usr/lib/librt.so" is used to fix rpm-fs build issue; which is taking reference from: LTIB - Strange problem building IMX6 Linux BSP from fresh on Ubuntu 13.10 C) Unpack and install the LTIB source package and assume done on the home directory: $ cd ~ $ tar -zxvf L3.0.35_4.1.0_130816_source. tar.gz $ ./L3.0.35_4.1.0_130816_source/install D) Apply the patch to make L3.0.35_4.1.0 could be installed and compiled on Ubuntu 14.04 64bit OS $ cd ~/ltib $ git apply 0001_make_L3.0.35_4.1.0_compile_on_Ubuntu_14.04_64bit_OS What the patch is doing: a) The patch modifies the following files: bin/Ltibutils.pm dist/lfs-5.1/base_libs/base_libs.spec dist/lfs-5.1/m4/m4.spec dist/lfs-5.1/ncurses/ncurses.spec dist/lfs-5.1/openssl/openssl.spec dist/lfs-5.1/xorg-server/xorg-server.spec b) Add the following files to the pkgs directory: pkgs/m4-1.4.16-1383761043.patch pkgs/m4-1.4.16-1383761043.patch.md5 pkgs/openssl-1.0.1c-1398677566.patch pkgs/openssl-1.0.1c-1398677566.patch.md5 pkgs/xorg-server-1.6.1-1398785267.patch pkgs/xorg-server-1.6.1-1398785267.patch.md5 E) Then, it is ready to proceed the rest of the LTIB env setup process: $ cd ~/ltib $ ./ltib -m config $ ./ltib F) about the patch: LTIB script warning when running with Perl v5.18.2 associated change: bin/Ltibutils.pm description: It prints out the following warning when doing package unpack, the patch is used to remove the warning. defined(@array) is deprecated at bin/Ltibutils.pm line 259         (Maybe you should just omit the defined()?) busybox compilation issue: associated change: dist/lfs-5.1/base_libs/base_libs.spec reference: Re: LTIB on Ubuntu 13.04 m4 compilation issue: associated change: dist/lfs-5.1/m4/m4.spec pkgs/m4-1.4.16-1383761043.patch pkgs/m4-1.4.16-1383761043.patch.md5 reference: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-devel/m4/files/m4-1.4.16-no-gets.patch alsa-utils compilation issue: associated change: dist/lfs-5.1/ncurses/ncurses.spec reference: Re: Android and LTIB build error in ubuntu 12.04 x86_64 openssl compilation issue due to Perl v5.18.2: associated change: dist/lfs-5.1/openssl/openssl.spec pkgs/openssl-1.0.1c-1398677566.patch pkgs/openssl-1.0.1c-1398677566.patch.md5 description: the build fails in pod2man while trying to generate man pages from the pod files reference: https://forums.freebsd.org/viewtopic.php?&t=41478 https://gist.github.com/martensms/10107481 xorg-server configuration fail: associated change: dist/lfs-5.1/xorg-server/xorg-server.spec pkgs/xorg-server-1.6.1-1398785267.patch pkgs/xorg-server-1.6.1-1398785267.patch.md5 description: When doing configuration, it stops at saying tslib not found.  It could be fixed by adding -dl when doing tslib test in configuration stage. NOTE: A) During the LTIB setup and compilation, these warnings were pop up.  Just ignore them and it seems okay. B) the dist/lfs-5.1/gst-plugins-good.spec is used to configurate/compile/install the "gstreamer-plugins-good" package.  It set up the environment variables pointing to libcairo but disable it when doing configuration. Thus, libcairo is actually not being used.           In Gnome profile, cario has been selected by default.  Thus, it does not experience the problem when compiling "gstreamer-plugins-good". However, in Min profile, if you select gstreamer-plugins-good to compile and install to your rootfs but without selecting cario as well, you will experience the error described in this thread: Re: gst-fsl-plugins build failed Thus, you could follow the solution provide in the Re: gst-fsl-plugins build failed or simply select cairo in your package list.          
查看全文
This document describes all the i.MX 8 MIPI-CSI use cases, showing the available cameras and daughter cards supported by the boards, the compatible Device Trees (DTS) files, and how to enable these different camera options on the i.MX 8 boards. Plus, this document describes some Advanced camera use cases too, such as multiples cameras output using imxcompositor_g2d plugin, GStreamer zero-copy pipelines and V4L2 API extra-controls examples.
查看全文
1. Follow all steps from Freescale's github repo except the last bitbake command 2. The images that Freescale supports are located on the meta-fsl-demos/recipes-fsl/images folder. 3. Bake the standard Freescale image build$ bitbake fsl-image-gui 4. The produced Linux image is packaged in several formats; the .sdcard single file has all the system (u-boot + uImage + rootfs) so it can be directly flashed into an SD card build$ sudo dd if=tmp/deploy/images/fsl-image-gui-imx6qsabresd.sdcard of=/dev/sdX bs=4M NOTES: In case of building issues, please follow this link In case of booting issues, make sure: 1. board DIP switches are set correctly 2. you have chosen the correct machine before baking If issues persist, report it to the community
查看全文
This tutorial will explain how to compile a Linux distro and the pingpong MQX application to test the communication between ARM Cortex-A9 and ARM Cortex-M4 cores on the SABRE Board for Smart Devices Based on the i.MX 6SoloX. INITIAL SETUP All of the steps were executed on an Ubuntu 14.04 64 bits machine, but should work on other distributions with minimal or no changes. The first step is to install the required tools and applications in the host: $ sudo apt-get install gawk wget git-core diffstat unzip texinfo \   gcc-multilib build-essential chrpath socat libsdl1.2-dev xterm picocom You also need to install the repo tool that will be used to download the Freescale's BSP: $ mkdir ~/bin $ curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > ~/bin/repo $ chmod a+x ~/bin/repo $ export PATH=${PATH}:~/bin Create an environment variable to store the directory name that will be used to download and compile all required software and applications (do no forget to redefine this variable if you close the current terminal or open a new one). $ export IMX6SOLOX=~/imx6solox $ mkdir -p $IMX6SOLOX LINUX DISTRIBUTION Download the Freescale's BSP source code: $ cd $IMX6SOLOX $ mkdir -p fsl-release-bsp && cd fsl-release-bsp $ repo init -u git://git.freescale.com/imx/fsl-arm-yocto-bsp.git -b imx-3.10.53-1.1.0_ga $ repo sync And compile a minimal image for the SABRE Board: $ MACHINE=imx6sxsabresd source fsl-setup-release.sh -b build $ bitbake core-image-minimal After the compilation, a sdcard image should be available. Write it to the sdcard (do not forget to change the device name /dev/sdX in the command below). $ cd tmp/deploy/images/imx6sxsabresd/ $ sudo dd if=core-image-minimal-imx6sxsabresd.sdcard of=/dev/sdX bs=1M && sync To test the image you need to connect the board to your host machine using the USB cable. Two TTY ports will be created. Open your favorite terminal application (minicom, putty, screen, picocom) in the first one and check the Linux boot process. You should be able to login with the root user. FIRMWARE MQX Download the last MQX source code from Freescale's website at http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MQX#. I have used the 4.1.0 version in the tests. Do not forget to download the Linux version (*.gz). Create a directory and decompress the source code: $ cd $IMX6SOLOX $ mkdir -p mqx && cd mqx $ tar xfv ~/Downloads/Freescale\ MQX\ RTOS\ 4.1.0\ for\ i.MX\ 6SoloX\ Linux\ Base.gz $ ls build config doc mcc mqx tools Download and install the required toolchain to compile the MQX application: $ cd $IMX6SOLOX $ mkdir -p toolchain && cd toolchain $ wget https://launchpad.net/gcc-arm-embedded/4.8/4.8-2014-q1-update/+download/gcc-arm-none-eabi-4_8-2014q1-20140314-linux.tar.bz2 $ tar xfv gcc-arm-none-eabi-4_8-2014q1-20140314-linux.tar.bz2 && rm gcc-arm-none-eabi-4_8-2014q1-20140314-linux.tar.bz2 Now compile the MQX and related libraries: $ cd $IMX6SOLOX/mqx/build/imx6sx_sdb_m4/make $ export TOOLCHAIN_ROOTDIR=$IMX6SOLOX/toolchain/gcc-arm-none-eabi-4_8-2014q1 $ ./build_gcc_arm.sh And compile the pingpong application: $ cd $IMX6SOLOX/mqx/mcc/examples/pingpong/build/make/pingpong_example_imx6sx_sdb_m4 $ ./build_gcc_arm.sh Convert the ELF application to a binary format: $ arm-none-eabi-objcopy -O binary gcc_arm/extflash_release/pingpong_example_imx6sx_sdb_m4.elf m4_qspi.bin The U-Boot bootloader will be responsible to read the MQX firmware from the SDCARD, write in the NOR flash and start the application on the Cortex-M4. Save the m4_qspi.bin file in the first sdcard partition and access the U-Boot's prompt. Run the following command to write the firmware image to the NOR flash: > run update_m4_from_sd And setup U-Boot environment variables so the application will start automatically at boot: > setenv fdt_file imx6sx-sdb-m4.dtb > setenv mmcargs "${mmcargs} uart_from_osc" > setenv bootcmd "run m4boot;${bootcmd}" > saveenv Open another terminal application on the second TTY to have access to the MQX console e reboot the board. You should see the message below: ***** MCC PINGPONG EXAMPLE ***** Please wait : 1) A9 peer is ready Then press "S" to start the demo ******************************** Press "S" to start the demo : Wait for the Linux boot process to finish and press "S" to start the demo application. In the Linux terminal, start the communication with the pingpong application: # echo 1 > /sys/devices/soc0/soc.1/2200000.aips-bus/mcctest.17/pingpong_en & You should see the log of messages sent and received on both terminals. Please let me know if you have any question. Best regards, Sergio Prado [email protected] http://e-labworks.com
查看全文