i.MX Processors Knowledge Base

cancel
Showing results for 
Search instead for 
Did you mean: 

i.MX Processors Knowledge Base

Discussions

Sort by:
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.
View full article
    The meta layer is designed for those guys who want to use i.MX8M series SOC and Yocto system to develop AGV and Robot.    The platform includes some key components: 1, ROS1 (kinetic, melodic) and ROS2(dashing, eloquent, foxy) 2, Real-time Linux solution : Xenomai 3.1 with ipipe 5.4.47 patch 3, Industrial protocol : libmodbus, linuxptp, ros-canopen, EtherCAT(TBD) 4, Security: Enhanced OpenSSL, Enhanced GmSSL, Enhanced eCryptfs, secure key store, secure boot(TBD), SE-Linux(TBD),  Dm-verity(TBD) The first release bases on i.MX Yocto release L5.4.47 2.2.0 and You need download Linux 5.4.47_2.2.0 according to​​ https://www.nxp.com/docs/en/user-guide/IMX_YOCTO_PROJECT_USERS_GUIDE.pdf  firstly. And then you can follow the below guide to build and test ROS and Xenomai. A, clone meta-robot-platform from gitee.com git clone https://gitee.com/zxd2021-imx/meta-robot-platform.git git checkout v0.1-L5.4.47-2.2.0 B, Adding the meta-robot-platform layer to your build 1,  copy meta-robot-platform into <i.MX Yocto folder>/source 2, You should create a symbol link: setup-imx-robot.sh -> sources/meta-robot-platform/imx/meta-robot/tools/setup-imx-robot.sh C, How to build Robot image (example for i.MX8MQ EVK board) $ DISTRO=imx-robot-wayland MACHINE=imx8mqevk source setup-imx-robot.sh -r kinetic -b imx8mqevk-robot-kinetic [or DISTRO=imx-robot-wayland MACHINE=imx8mqevk source setup-imx-robot.sh -r melodic -b imx8mqevk-robot-melodic ] [or DISTRO=imx-robot-wayland MACHINE=imx8mqevk source setup-imx-robot.sh -r dashing -b imx8mqevk-robot-dashing ] [or DISTRO=imx-robot-wayland MACHINE=imx8mqevk source setup-imx-robot.sh -r eloquent -b imx8mqevk-robot-eloquent ] [or DISTRO=imx-robot-wayland MACHINE=imx8mqevk source setup-imx-robot.sh -r foxy -b imx8mqevk-robot-foxy ] $ bitbake imx-robot-core [or bitbake imx-robot-system ] [or bitbake imx-robot-sdk ] And if you add XENOMAI_KERNEL_MODE = "cobalt" or XENOMAI_KERNEL_MODE = "mercury" in local.conf, you also can build real-time image with Xenomai by the below command: $ bitbake imx-robot-core-rt [or bitbake imx-robot-system-rt ] D, Robot image sanity testing //ROS1 Sanity Test #source /opt/ros/kinetic/setup.sh [or # source /opt/ros/melodic/setup.sh ] #echo $LD_LIBRARY_PATH #roscore & #rosnode list #rostopic list #only kinetic #rosmsg list #rosnode info /rosout //ROS2 Sanity Test #source ros_setup.sh #echo $LD_LIBRARY_PATH #ros2 topic list #ros2 msg list #only dashing #ros2 interface list #(sleep 5; ros2 topic pub /chatter std_msgs/String "data: Hello world") & #ros2 topic echo /chatter E, Xenomai sanity testing #/usr/xenomai/demo/cyclictest -p 50 -t 5 -m -n -i 1000 F, vSLAM demo You can find orb-slam2 demo under <i.MX Yocto folder>/sources/meta-robot-platform/imx/meta-robot/recipes-demo/orb-slam2. You should choose DISTRO=imx-robot-xwayland due to it depends on OpenCV with gtk+.   //////////////////////////////////////// update for Yocto L5.4.70 2.3.0  /////////////////////////////////////////////////////////// New release package meta-robot-platform-v0.2-L5.4.70-2.3.0 for Yocto release L5.4.70 2.3.0 and it supports i.MX8M series (8MQ,8MM,8MN and 8MP) and i.MX8QM/QXP.  git clone https://gitee.com/zxd2021-imx/meta-robot-platform.git git checkout v0.2-L5.4.70-2.3.0 Updating: 1, Support i.MX8QM and i.MX8QXP 2, Add ROS driver of RPLIDAR and Orbbec 3D cameras in ROS1 3, Upgrade OpenCV to 3.4.13. 4, Add imx-robot-agv image with orb-slam2 demo 5, Fix the issue which failed to create image when adding orb-slam2 6, Fix the issue which failed to create imx-robot sdk image when add package ISP and ML Note: Currently, orb-slam2 demo don't run on i.MX8MM platform due to its GPU don't support OpenGL ES3. imx-robot-sdk image is just for building ROS package on i.MX board, not  for cross-compile. You can try "bitbake imx-robot-system -c populate_sdk" to create cross-compile sdk without gmssl-bin. diff --git a/imx/meta-robot/recipes-core/images/imx-robot-system.bb b/imx/meta-robot/recipes-core/images/imx-robot-system.bb index 1991ab10..68f9ad31 100644 --- a/imx/meta-robot/recipes-core/images/imx-robot-system.bb +++ b/imx/meta-robot/recipes-core/images/imx-robot-system.bb @@ -35,7 +35,7 @@ CORE_IMAGE_EXTRA_INSTALL += " \ ${@bb.utils.contains('DISTRO_FEATURES', 'x11 wayland', 'weston-xwayland xterm', '', d)} \ ${ISP_PKGS} \ " -IMAGE_INSTALL += " clblast openblas libeigen opencv gmssl-bin" +IMAGE_INSTALL += " clblast openblas libeigen opencv" IMAGE_INSTALL += " \ ${ML_PKGS} \   //////////////////////////////////////// update for Yocto L5.4.70 2.3.2  /////////////////////////////////////////////////////////// New release package meta-robot-platform-v0.3-L5.4.70-2.3.2 for Yocto release L5.4.70 2.3.2 .  git clone https://gitee.com/zxd2021-imx/meta-robot-platform.git git checkout v0.3-L5.4.70-2.3.2 Updated: 1, Upgrade to L5.4.70-2.3.2 2, Enable xenomai rtdm driver 3, Add NXP Software Content Register and BSP patches of i.MX8M Plus AI Robot board. Note: How to build for AI Robot board 1, DISTRO=imx-robot-wayland MACHINE=imx8mp-ddr4-ipc source setup-imx-robot.sh -r melodic -b imx8mp-ddr4-ipc-robot-melodic 2, Add BBLAYERS += " ${BSPDIR}/sources/meta-robot-platform/imx/meta-imx8mp-ai-robot " in bblayers.conf 3, bitbake imx-robot-sdk or bitbake imx-robot-agv   //////////////////////////////////////// update for v1.0-L5.4.70-2.3.2  /////////////////////////////////////////////////////////// New release package meta-robot-platform-v1.0-L5.4.70-2.3.2 .  git clone https://gitee.com/zxd2021-imx/meta-robot-platform.git git checkout v1.0-L5.4.70-2.3.2 Updated: 1, Upgrade ROS1 Kinetic Kame to Release 2021-05-11 which is final sync. 2, Add IgH EtherCAT Master for Linux in i.MX Robot platform.
View full article
  Just sharing some experiences during the development and studying.   Although, it appears some hardwares, it focuses on software to speed up your developing on your  hardware.     杂记共享一下在开发和学习过程中的经验。    虽然涉及一些硬件,但其本身关注软件,希望这些能加速您在自己硬件上的开发。 04/07/2021 i.MX8QXP eMMC Secondary Boot https://community.nxp.com/t5/i-MX-Community-Articles/i-MX8QXP-eMMC-Secondary-Boot/ba-p/1257704#M45       03/25/2021 sc_misc_board_ioctl to access the M4 partition from A core side sc_misc_board_ioctl to access the M4 partition fr... - NXP Community     03/17/2021 How to Changei.MX8X MEK+Base Board  Linux Debug UART https://community.nxp.com/t5/i-MX-Community-Articles/How-to-Change-i-MX8X-MEK-Base-Board-Linux-Debug-UART/ba-p/1246779#M43     03/16/2021 How to Change i.MX8MM evk Linux Debug UART https://community.nxp.com/t5/i-MX-Community-Articles/How-to-Change-i-MX8MM-evk-Linux-Debug-UART/ba-p/1243938#M40       05/06/2020 Linux fw_printenv fw_setenv to access U-Boot's environment variables Linux fw_printenv fw_setenv to access U-Boot's environment variables  update and provide demo sdcard mirror for i.MX6ull evk.   03/30/2020 i.MX6 DDR calibration/stress for Mass Production https://community.nxp.com/docs/DOC-346065     03/25/2020 parseIVT - a script to help i.MX6 Code Signing https://community.nxp.com/docs/DOC-345998     02/24/2020 Linux fw_printenv fw_setenv to access U-Boot's environment variables Not authorized to view the specified document 345621    02/17/2020 Start your machine learning journey from tensorflow playground Start your machine learning journey from tensorflow playground      01/15/2020 How to add  iMX8QXP PAD(GPIO) Wakeup How to add iMX8QXP PAD(GPIO) Wakeup    01/09/2020 Understand iMX8QX Hardware Partitioning By Making M4 Hello world Running Correctly https://community.nxp.com/docs/DOC-345359   09/29/2019 Docker On i.MX6UL With Ubuntu16.04 https://community.nxp.com/docs/DOC-344462   09/25/2019 Docker On i.MX8MM With Ubuntu https://community.nxp.com/docs/DOC-344473 Docker On i.MX8QXP With Ubuntu https://community.nxp.com/docs/DOC-344474     08/28/2019 eMMC5.0 vs eMMC5.1 https://community.nxp.com/docs/DOC-344265     05/24/2019 How to upgrade  Linux Kernel and dtb on eMMC without UUU How to upgrade Linux Kernel and dtb on eMMC without UUU     04/12/2019 eMMC RPMB Enhance and GP https://community.nxp.com/docs/DOC-343116   04/04/2019 How to Dump a GPT SDCard Mirror(Android O SDCard Mirror) https://community.nxp.com/docs/DOC-343079   04/04/2019 i.MX Create Android SDCard Mirror https://community.nxp.com/docs/DOC-343078   04/02/2019: i.MX Linux Binary_Demo Files Tips  https://community.nxp.com/docs/DOC-343075   04/02/2019:       Update Set fast boot        eMMC_RPMB_Enhance_and_GP.pdf   02/28/2019: imx_builder --- standalone build without Yocto https://community.nxp.com/docs/DOC-342702   08/10/2018: i.MX6SX M4 MPU Settings For RPMSG update    Update slide CMA Arrangement Consideration i.MX6SX_M4_MPU_Settings_For_RPMSG_08102018.pdf   07/26/2018 Understand ML With Simplest Code https://community.nxp.com/docs/DOC-341099     04/23/2018:     i.MX8M Standalone Build     i.MX8M Standalone Build.pdf     04/13/2018:      i.MX6SX M4 MPU Settings For RPMSG  update            Add slide CMA Arrangement  Consideration     i.MX6SX_M4_MPU_Settings_For_RPMSG_04132018.pdf   09/05/2017:       Update eMMC RPMB, Enhance  and GP       eMMC_RPMB_Enhance_and_GP.pdf 09/01/2017:       eMMC RPMB, Enhance  and GP       eMMC_RPMB_Enhance_and_GP.pdf 08/30/2017:     Dual LVDS for High Resolution Display(For i.MX6DQ/DLS)     Dual LVDS for High Resolution Display.pdf 08/27/2017:  L3.14.28 Ottbox Porting Notes:         L3.14.28_Ottbox_Porting_Notes-20150805-2.pdf MFGTool Uboot Share With the Normal Run One:        MFGTool_Uboot_share_with_NormalRun_sourceCode.pdf Mass Production with programmer        Mass_Production_with_NAND_programmer.pdf        Mass_Production_with_emmc_programmer.pdf AndroidSDCARDMirrorCreator https://community.nxp.com/docs/DOC-329596 L3.10.53 PianoPI Porting Note        L3.10.53_PianoPI_PortingNote_151102.pdf Audio Codec WM8960 Porting L3.10.53 PianoPI        AudioCodec_WM8960_Porting_L3.10.53_PianoPI_151012.pdf TouchScreen PianoPI Porting Note         TouchScreen_PianoPI_PortingNote_151103.pdf Accessing GPIO From UserSpace        Accessing_GPIO_From_UserSpace.pdf        https://community.nxp.com/docs/DOC-343344 FreeRTOS for i.MX6SX        FreeRTOS for i.MX6SX.pdf i.MX6SX M4 fastup        i.MX6SX M4 fastup.pdf i.MX6 SDCARD Secondary Boot Demo        i.MX6_SDCARD_Secondary_Boot_Demo.pdf i.MX6SX M4 MPU Settings For RPMSG        i.MX6SX_M4_MPU_Settings_For_RPMSG_10082016.pdf Security        Security03172017.pdf    NOT related to i.MX, only a short memo
View full article
On imx8qm there are two DPUs(display process unit) and one ISI(image subsystem interface), ISI has 5 inputs and two of them are from DPU0 and DPU1.   This document demonstrates on how to loopback DPU1 outputs to ISI. Note that only mipi dsi0 of dpu0 and lvds1 of dpu1 can be loopbacked to isi.   Platform:                            imx8qm b0 mek OS:                                    yocto 4.14.78 ga hardware connection:        imx8qm lvds1 ====> it6263 cable =====> hdmi display.   1st: isi has 8 pipelines which can be assigned to any of the 5 inputs, this doc takes the 5th pipeline to sink the dpu1 input. So you will need to configure the isi_4( start from 0) source in the dts and write a simple v4l2 subdev for capture testing, the default isi_4 device will be /dev/video4.   2st: configure both framegen0 of dpu1 and lvds1's link to pixellink 3.   3st: write a v4l2 userspace program to capture from  /dev/video4 device, take this vulkan-capture as an example. Note that Vulkan-capture is rendered by vulkan api, you can also take opengl es for rendering.   See the atttachments for details.   ======================================== 2019/11/12 update patches. ======================================== 2019/12/19 add patch. Support connect real display to DC1-LVDS1   Note: for ISI loopback,  it needs output of 2x GPIO (4x for HDMI-TX or combo PHY) to pixel_link_receiver_address: For iMX8QM: o LVDS: pixel_link_receiver_address[1:0] = do_gpio_dr[7:6]  o MIPI-DSI: pixel_link_receiver_address[1:0] = do_gpio_dr[7:6] o HDMI-TX: odd_pixel_link_receiver_address[1:0] = do_gpio_dr[7:6],even_pixel_link_receiver_address[1:0] = do_gpio_dr[5:4]   For iMX8QXP: o Combo MIPI-DSI / LVDS: pixel_link0_receiver_address[1:0] = do_gpio_dr[7:6], pixel_link1_receiver_address[1:0] = do_gpio_dr[5:4] 
View full article
platform: imx8qxp c0 mek OS: yocto 4.19.35_1.1.0 hardware connection: imx8qxp lvds0 => dummy panel ,  lvds1 => it6263 => display   On imx8qxp there are one DPU(display process unit) and one ISI(image subsystem interface), ISI supports input from dpu.   dpu block diagram: note that only dsi0 and lvds0 can be used for loopback. and this patch only test the lvds0, since lvds support dummy panel.   Please see the readme in the attchment for how to enale this feature.   Note: for ISI loopback,  it needs output of 2x GPIO (4x for HDMI-TX or combo PHY) to pixel_link_receiver_address: For iMX8QM: o LVDS: pixel_link_receiver_address[1:0] = do_gpio_dr[7:6]  o MIPI-DSI: pixel_link_receiver_address[1:0] = do_gpio_dr[7:6] o HDMI-TX: odd_pixel_link_receiver_address[1:0] = do_gpio_dr[7:6],even_pixel_link_receiver_address[1:0] = do_gpio_dr[5:4]   For iMX8QXP: o Combo MIPI-DSI / LVDS: pixel_link0_receiver_address[1:0] = do_gpio_dr[7:6], pixel_link1_receiver_address[1:0] = do_gpio_dr[5:4]   
View full article
For iMX6DQ, there are two IPUs, so they can support up to 4 cameras at the same time. But the default BSP can only support up to two cameras at the same time. The attached patch can make the BSP support up to 4 cameras based on 3.10.53 GA 1.1.0 BSP.   The 4 cameras can be: - 1xCSI, 3xMIPI - 2xCSI, 2xMIPI - 4xMIPI   For 4xMIPI case, the four cameras should be combined on the single MIPI CSI2 interface, and each camera data should be transfered on a mipi virtual channel.   In this patch, we given the example driver for Maxim MAX9286, it was verified working on iMX6DQ SabreAuto board. The input to MAX9286 is four 720P30 cameras. The verified camera boards:     (1) Onsemi AR0140+AP0101+MAX9271 boards.     (2) OmniVision OV10635+MAX9271 boards.   The MIPI CSI2 CVBS camera surround view solution can be found at: iMX6DQ ISL79985/79987 MIPI CSI2 CVBS camera surround view solution for Linux BSP The MIPI CSI2 CVBS HD camera surround view solution can be found at: iMX6DQ TP2854 MIPI CSI2 720P CVBS camera surround view solution for Linux BSP   The kernel patches: 0001-IPU-update-IPU-capture-driver-to-support-up-to-four-.patch      Updated IPU common code to support up to four cameras.   0002-Add-Max9286-support-on-SabreAuto-board-which-can-sup.patch      MAX9286 driver, it includes MAX9271, AP0101 and AR0140 drivers.   0003-Remove-the-page-size-align-requirement-for-v4l2-capt.patch      With this patch, the mxc_v4l2_tvin test application can use overlay framebuffer as V4l2 capture buffer directly.   0004-Max9286-skip-AP0101-camera-re-initialization.patch      If the camera board's power had been kept after initialized, this patch will bypass the re-initialization to reduce the start up time.   0005-Max9286-set-I2C-speed-to-400Kbps.patch     Set I2C to 400Kbps to reduce the AP0101+AR0140 initialization time.   0006-Max9286-add-retry-for-MAX9271-I2C-access.patch     Added retry for MAX9271 I2C access.   0007-Max9286-Add-support-for-OV10635-camera.patch     Updated code for OV10635 camera.   0008-Max9286-support-auto-detect-camera-number.patch     Make the Max9286 driver can detect the camera number automatically.     How to builld the kernel with MAX9286 support:       make imx_v7_defconfig       make menuconfig (In this command, you should select the MAX9286 driver:             Device Drivers  --->                   <*> Multimedia support  --->                         [*]   V4L platform devices  --->                               <*>   MXC Video For Linux Video Capture                                       MXC Camera/V4L2 PRP Features support  --->                                           <*>Maxim max9286 GMSL Deserializer Input support                                               Select Camera Sensor (OmniVision OV10635 camera sensor)  // Or (Onsemi AP0101 and AR0140 camera sensor)                                           <*>mxc VADC support                                           <*>Select Overlay Rounting (Queue ipu device for overlay library)                                           <*>Pre-processor Encoder library                                           <*>IPU CSI Encoder library)       make zImage       make dtbs   The built out image file:       arch/arm/boot/dts/imx6q-sabreauto.dtb       arch/arm/boot/zImage   "mxc_v4l2_tvin_max9286.tar.gz" is the test application, test command to capture the four cameras and render on 1080P HDMI display: /mxc_v4l2_tvin.out -ol 0 -ot 0 -ow 960 -oh 540 -d 1 -x 0 -g2d & /mxc_v4l2_tvin.out -ol 960 -ot 0 -ow 960 -oh 540 -d 1 -x 1 -g2d & /mxc_v4l2_tvin.out -ol 0 -ot 540 -ow 960 -oh 540 -d 1 -x 2 -g2d & /mxc_v4l2_tvin.out -ol 960 -ot 540 -ow 960 -oh 540 -d 1 -x 3 -g2d &   Some hardware check point on AR0140+AP0101+MAX9271 camera board (Please get MAX9286 and OV10635 schematics from Maxim): 1. In this patch, MAX9286's I2C address is 0x4D, so ADD0 and ADD1 should be connected to high. AP0101's I2C address is 0xBA, so SADDR should be connected to high.   2. AP0101's DOUT0~DOUT7 should be connected to MAX9271's DIN7~DIN0, the order should be switched, MSB connected to LSB.   3. MAX9271's GPO pin should be connected to AP0101's FRAME_SYNC pin. The pull down resistance on FRAME_SYNC pin should not be 0 ohm.   Some known limitation: 1. AP0101's VSYNC invalid time, last video line's HSYNC to VSYNC porch's max value is 255 pixel clocks, it is not enough for MAX9286 to generate the Frame End MIPI packets for each camera. So in order to let iMX6DQ to capture 1280x720 video for each camera, we had let AP0101 output 1280*724 frame size, and iMX6 will only capture 720 lines, the remained video data and Frame End will be ignored. This solution will not impact the function, but there will be " Error matching Frame Start with Frame End for Virtual Channel x " error reported from iMX6 MIPI_CSI_ERR1 register. Maxim suggested to use MAX96705 to relace the MAX9271, it can delay the VSYNC invalid time, then the MIPI error will be fixed.     2015-11-17 update: Updated for OV10635 camera support. File: L3.10.53_GA1.1.0_MAX9286_Surroundview_Patch_2015-11-17.zip   2015-12-04 update: File: L3.10.53_GA1.1.0_MAX9286_Surroundview_Patch_2015-12-04.zip Added patch 0009-Max9286-updated-PCLK-edge-setting-for-OV10635.patch to correct the OV10635 PCLK edge setting     2016-03-07 update: File L3.14.38_GA_MAX9286_Surroundview_Patch_2016-03-07.zip Added kernel patch for L3.14.38 GA 1.1.0 BSP.   2016-07-26 update: Files: L3.10.53_GA1.1.0_MAX9286_Surroundview_Patch_2016-07-26.zip; L3.14.38_GA1.1.0_MAX9286_Surroundview_Patch_2016-07-26.zip; L3.14.52_GA1.1.0_MAX9286_Surroundview_Patch_2016-07-26.zip. Added gstreamer support. Added MAX96705 support. Added patch for L3.14.52_GA1.1.0.   2017-12-11 update: Added CVBS surround view link: iMX6DQ TP2854 MIPI CSI2 720P CVBS camera surround view solution for Linux BSP     2021-04-26 update: Some customer reported, when system loading is heavy, sometimes, some camera will flicker left and right. It is caused by SFMC FIFO data lost. The original patch used IDMAC 0 and IDMAC 1 for two cameras on one IPU, this is not the best setting.  IDMAC 1 is fixed to use 1/4 SMFC FIFO and it will cause IDMAC 0 to use 1/4 SMFC FIFO too. And another 1/2 of SMFC FIFO can't be used in this case. Some code update to improve it: For each IPU, please use IDMAC 0 and IDMAC 2 to capture the two cameras. This needs change the hard coding in "drivers\media\platform\mxc\capture\ipu_csi_enc.c", "CSI_MEM1" and "IPU_IRQ_CSI1_OUT_EOF" should be changed to "CSI_MEM2" and "IPU_IRQ_CSI2_OUT_EOF". In this case, all SMFC FIFO can be used. And in "ipu_common.c", function ipu_probe(), the followed code should be changed to make IDMAC2 use high priority too. /* Set sync refresh channels and CSI->mem channel as high priority */ - ipu_idmac_write(ipu, 0x18800003L, IDMAC_CHA_PRI(0)); + ipu_idmac_write(ipu, 0x1880000FL, IDMAC_CHA_PRI(0));
View full article
Linux kernel provide some apis to allow changing dtb node after system booted. But the node change must happen before the driver loading. We can use gereral dtb file and add some dts node after system boot.
View full article
GmSSL is an open source cryptographic toolbox that supports SM2 / SM3 / SM4 / SM9 and other national secret (national commercial password) algorithm, SM2 digital certificate and SM2 certificate based on SSL / TLS secure communication protocol to support the national security hardware password device , To provide in line with the national standard programming interface and command line tools, can be used to build PKI / CA, secure communication, data encryption and other standards in line with national security applications. For more information, please access GmSSL official website http://gmssl.org/english.html.   Software environments as the belows: Linux kernel: imx_4.14.98_2.0.0_ga cryptodev: 1.9 HW platform: i.MX6UL, i.MX7D/S, i.MX8M/MM, i.MX8QM/QXP. The patches include the following features: 1, Support SM2/SM9   encryption/decryption/sign/verify/ key exchange ,   RSA  encryption/decryption, DSA/ECDSA sign/verify, DH/ECDH key agreement, ECC & DLC & RSA key generation and big number  operation and   e lliptic  c urve   m ath by CAAM hardware   accelerating . 2, run "git apply 0001-Enhance-cryptodev-and-its-engine-in-GmSSL-by-CAAM-s-.patch" under folder sources/poky, and "git apply 0001-Add-public-key-cryptography-operations-in-CAAM-drive.patch"   under folder   sources/meta-fsl-bsp-release for patch these codes. 3, GmSSL Build command: $ tar zxvf GmSSL-master-iMX.tgz $  cd  GmSSL-master-iMX (For i.MX8M/MM, i.MX8QM/QXP) $  source /opt/arm-arch64/environment-setup-aarch64-poky-linux  $  ./Configure -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS -DHW_ENDIAN_SWAP  --prefix= ~/install64   --openssldir=/etc/gmssl --libdir=/usr/lib no-saf no-sdf no-skf no-sof no-zuc -no-ssl3 shared linux-aarch64 $  make  $  make install                              /*image and config file will be installed to folder   ~ /install64   */   (For  i.MX6UL, i.MX7D/S ) $   source /opt/arm-arch32/environment-setup-cortexa7hf-neon-poky-linux-gnueabi $   ./Configure -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS --prefix= ~ /install32   --openssldir=/etc/gmssl --libdir=/usr/lib no-saf no-sdf no-skf no-sof no-zuc -no-ssl3 shared linux-armv4 $  make  $  make install                             /*image and config file will be installed to folder   ~ /install32   */   4, How to use GmSSL: copy image gmssl to /usr/bin on i.MX board;  copy  gmssl libcrypto.so.1.1 and libssl.so.1.1 to /usr/lib  on i.MX board; copy folder etc/ gmssl to /etc/ on i.MX board. copy test examples (dhtest, dsatest, rsa_test, ecdhtest, ecdsatest, eciestest, sm3test, sms4test, sm2test, sm9test) under GmSSL-master-iMX/test  to U disk for running. You can run test examples by the following commands: #insmod /lib/modules/4.14.98-imx_4.14.98_2.0.0_ga+g5d6cbeafb80c/extra/cryptodev.ko #/run/media/sda1/dhtest #/run/media/sda1/dsatest #/run/media/sda1/rsa_test #/run/media/sda1/ecdhtest #/run/media/sda1/ecdsatest #/run/media/sda1/eciestest #/run/media/sda1/sm3test #/run/media/sda1/sms4test #/run/media/sda1/sm2test #/run/media/sda1/sm9test and speed test commands: #gmssl speed sm2 #gmssl genrsa -rand -f4 512 #gmssl speed dsa #gmssl genrsa -rand -f4 1024 #gmssl speed rsa #gmssl genrsa -rand -f4 2048 #gmssl speed ecdsa #gmssl genrsa -rand -f4 3072 #gmssl speed ecdh #gmssl genrsa -rand -f4 4096   ++++++++++++++++++++++++++++     updating at 2019-09-10    +++++++++++++++++++++++++++++++++++++++++++++ 0001-fix-the-bug-which-hash-and-cipher-key-don-t-use-DMA-.patch fix the issue which   dismatching on key buffer between crytodev and caam driver. Crytodev uses stack's buffer for key storage and caam driver use it to dma map which cause flush cache failure. The patch need to apply on cryptodev-module in Yocto build.   ++++++++++++++++++  updating at 2019-10-14 +++++++++++++++++++++++++++++++++++ This updating is for China C-V2X application. The package meta-cv2x_4.14.98_2.0.0_ga.tgz is Yocto layer which bases on GmSSL and Cryptodev. I add HW SM2 verification by dedicated CAAM job descriptor and enhanced SW  SM2 verification by precomputed multiples of generator and ARMv8 assembler language to accelerate point  operation.  Software environments as the belows: Linux kernel: imx_4.14.98_2.0.0_ga cryptodev: 1.9 HW platform: i.MX8M/MM/MN, i.MX8QM/QXP. How to build: 1, decompress  meta-cv2x_4.14.98_2.0.0_ga.tgz and copy meta-cv2x to folder (Yocto 4.14.98_2.0.0_ga dir)/sources/ 2, Run DISTRO=fsl-imx-wayland MACHINE=imx8qxpmek source fsl-setup-release.sh -b build-cv2x and add BBLAYERS += " ${BSPDIR}/sources/meta-cv2x " into ( Yocto 4.14.98_2.0.0_ga dir ) /build-cv2x/conf/bblayers.conf and  IMAGE_INSTALL_append += " gmssl-bin "  into local.conf 3, Run bitbake fsl-image-validation-imx. 4, You can find  cv2x-verify.c under (build dir)/tmp/work/aarch64-poky-linux/cryptodev-tests/1.9-r0/git/tests. It is example for using CAAM cryptdev interface to do C-V2X verification (includes SM2 p256, NIST p256 and brainpoolP256r1).   cv2x_benchmark.c   under ( build dir )/tmp/work/aarch64-poky-linux/gmssl/1.0-r0/gmssl-1.0/test is the benchmark test program of C-V2X verifying. It includes HW, SW and HW+SW(one CPU) verifying for  SM2 p256, NIST p256 and brainpoolP256r1. 5, Run the below command on your i.MX8QXP MEK board. modprobe cryptodev ./cv2x_benchmark Note: the udpated GmSSL also support projective coordinates and affine coordinates (CAAM only support affine  coordinates ). Affine  coordinates is used  by default. You can call EC_GROUP_set_coordinates() and EC_GROUP_restore_coordinates() to change coordinates and restore default. When you hope to use some EC APIs under expected coordinates, you need to call EC_GROUP_set_coordinates() before EC APIs and  EC_GROUP_restore_coordinates()  after them. Like the below example: orig_coordinate = EC_GROUP_set_coordinates(EC_PROJECTIVE_COORDINATES); group = EC_GROUP_new_by_curve_name(NID_sm2p256v1); EC_GROUP_restore_coordinates(orig_coordinate);   ++++++++++++++++++++++++++++     updating at 2020-11-09   +++++++++++++++++++++++++++++++++++++++++++++ This updating is for Yocto release of Linux 5.4.47_2.2.0​​. The package meta-gmcrypto_L5.4.47-2.2.0.tgz is Yocto layer which also support c-v2x feature in previous release .  Software environments as the belows: Linux kernel: imx_5.4.47_2.2.0 cryptodev: 1.10 HW platform: i.MX6UL, i.MX7D/S, i.MX8M/8M Mini/8M Nano/8M Plus, i.MX8/8X. How to build: 1, decompress meta-gmcrypto_L5.4.47-2.2.0.tgz and copy meta-gmcrypto to folder (Yocto 5.4.47_2.2.0 dir)/sources/ 2, Run DISTRO=fsl-imx-wayland MACHINE=imx8mmevk source imx-setup-release.sh -b build-imx8mmevk and add BBLAYERS += " ${BSPDIR}/sources/meta-gmcrypto " into ( Yocto 5.4.47_2.2.0 dir ) /build-imx8mmevk/conf/bblayers.conf and  IMAGE_INSTALL_append += " gmssl-bin "  into local.conf 3, Run bitbake fsl-image-validation-imx. 4, You can find  cv2x-verify.c under (build dir)/tmp/work/aarch64-poky-linux/cryptodev-tests/1.10caam-r0/git/tests. It is example for using CAAM cryptdev interface to do C-V2X verification (includes SM2 p256, NIST p256 and brainpoolP256r1).   cv2x_benchmark.c   under ( build dir )/tmp/work/aarch64-poky-linux/gmssl/1.0-r0/gmssl-1.0/test is the benchmark test program of C-V2X verifying. It includes HW, SW and HW+SW(one CPU) verifying for  SM2 p256, NIST p256 and brainpoolP256r1. 5, Run the below command on your i.MX8M Mini evk board. modprobe cryptodev ./cv2x_benchmark gmssl speed sm2 gmssl speed dsa gmssl speed rsa gmssl speed ecdsa gmssl speed ecdh gmssl genrsa -rand -f4 -engine cryptodev 4096 Note: 1, the udpated GmSSL also support projective coordinates and affine coordinates (CAAM only support affine  coordinates ). Affine  coordinates is used  by default. You can call EC_GROUP_set_coordinates() and EC_GROUP_restore_coordinates() to change coordinates and restore default. When you hope to use some EC APIs under expected coordinates, you need to call EC_GROUP_set_coordinates() before EC APIs and  EC_GROUP_restore_coordinates() after them. Like the below example: orig_coordinate = EC_GROUP_set_coordinates(EC_PROJECTIVE_COORDINATES); group = EC_GROUP_new_by_curve_name(NID_sm2p256v1); EC_GROUP_restore_coordinates(orig_coordinate); 2, Yocto Zeus integrates openssl 1.1.1g, so I change library name of gmssl from libcrypto to libgmcrypto and from libssl to libgmssl to avoid name confliction with openssl 1.1.1g (lib name are also libcrypto.so.1.1 and libssl.so.1.1). You should use -lgmcrypto and -lgmssl when you link gmssl library instead of -lcrypto and -lssl.   +++++++++++++++++++++++    updating at 2021-02-08  ++++++++++++++++++++++++++++ This updating is for Yocto release of Linux 5.4.70_2.3.0​​. The package meta-gmcrypto_L5.4.70-2.3.0.tgz is Yocto layer which also support c-v2x feature in previous release . 
View full article
    Xenomai is real-time framework, which can run seamlessly side-by-side Linux as a co-kernel system, or natively over mainline Linux kernels (with or without PREEMPT-RT patch). The dual kernel nicknamed Cobalt, is a significant rework of the Xenomai 2.x system. Cobalt implements the RTDM specification for interfacing with real-time device drivers. The native linux version, an enhanced implementation of the experimental Xenomai/SOLO work, is called Mercury. In this environment, only a standalone implementation of the RTDM specification in a kernel module is required, for interfacing the RTDM-compliant device drivers with the native kernel. You can get more detailed information from Home · Wiki · xenomai / xenomai · GitLab       I have ported xenomai 3.1 to i.MX Yocto 4.19.35-1.1.0, and currently support ARM64 and test on i.MX8MQ EVK board. I did over night test( 5 real-time threads + GPU SDK test case) and stress test by tool stress-ng on  i.MX8MQ EVK board. It looks lile pretty good. Current version (20200730) also support i.MX8MM EVK.     You need attached file xenomai-4.19.35-1.1.0-arm64-20200818.tgz (which inlcudes all patches and bb file) and add the following variable in conf/local.conf before build xenomai by command bitake xenomai.  XENOMAI_KERNEL_MODE = "cobalt"  PREFERRED_VERSION_linux-imx = "4.19-${XENOMAI_KERNEL_MODE}" IMAGE_INSTALL_append += " xenomai" or XENOMAI_KERNEL_MODE = "mercury" PREFERRED_VERSION_linux-imx = "4.19-${XENOMAI_KERNEL_MODE}" IMAGE_INSTALL_append += " xenomai" If XENOMAI_KERNEL_MODE = "cobalt", you can build dual kernel version. And If  XENOMAI_KERNEL_MODE = "mercury", it is single kernel with PREEMPT-RT patch. The following is test result by the command ( /usr/xenomai/demo/cyclictest -p 99 -t 5 -m -n -i 1000  -l 100000 😞 //Over normal Linux kernel without GPU SDK test case T: 0 ( 4220) P:99 I:1000 C: 100000 Min: 7 Act: 10 Avg: 9 Max: 23 T: 1 ( 4221) P:99 I:1500 C: 66672 Min: 7 Act: 10 Avg: 10 Max: 20 T: 2 ( 4222) P:99 I:2000 C: 50001 Min: 7 Act: 12 Avg: 10 Max: 81 T: 3 ( 4223) P:99 I:2500 C: 39998 Min: 7 Act: 11 Avg: 10 Max: 29 T: 4 ( 4224) P:99 I:3000 C: 33330 Min: 7 Act: 13 Avg: 10 Max: 26 //Over normal Linux kernel with GPU SDK test case T: 0 ( 4177) P:99 I:1000 C: 100000 Min: 7 Act: 10 Avg: 11 Max: 51 T: 1 ( 4178) P:99 I:1500 C: 66673 Min: 7 Act: 12 Avg: 10 Max: 35 T: 2 ( 4179) P:99 I:2000 C: 50002 Min: 7 Act: 12 Avg: 11 Max: 38 T: 3 ( 4180) P:99 I:2500 C: 39999 Min: 7 Act: 12 Avg: 11 Max: 42 T: 4 ( 4181) P:99 I:3000 C: 33330 Min: 7 Act: 12 Avg: 11 Max: 36   //Cobalt with stress-ng --cpu 4 --io 2 --vm 1 --vm-bytes 512M --timeout 600s --metrics-brief T: 0 ( 4259) P:50 I:1000 C:3508590 Min:      0 Act:    0 Avg:    0 Max:      42 T: 1 ( 4260) P:50 I:1500 C:2338831 Min:      0 Act:    1 Avg:    0 Max:      36 T: 2 ( 4261) P:50 I:2000 C:1754123 Min:      0 Act:    1 Avg:    1 Max:      42 T: 3 ( 4262) P:50 I:2500 C:1403298 Min:      0 Act:    1 Avg:    1 Max:      45 T: 4 ( 4263) P:50 I:3000 C:1169415 Min:      0 Act:    1 Avg:    1 Max:      22   //Cobalt without GPU SDK test case T: 0 ( 4230) P:50 I:1000 C: 100000 Min: 0 Act: 0 Avg: 0 Max: 4 T: 1 ( 4231) P:50 I:1500 C:   66676 Min: 0 Act: 1 Avg: 0 Max: 4 T: 2 ( 4232) P:50 I:2000 C:   50007 Min: 0 Act: 1 Avg: 0 Max: 8 T: 3 ( 4233) P:50 I:2500 C:   40005 Min: 0 Act: 1 Avg: 0 Max: 3 T: 4 ( 4234) P:50 I:3000 C:   33338 Min: 0 Act: 1 Avg: 0 Max: 5 //Cobalt with GPU SDK  test case T: 0 ( 4184) P:99 I:1000 C:37722968 Min: 0 Act: 1 Avg: 0 Max: 24 T: 1 ( 4185) P:99 I:1500 C:25148645 Min: 0 Act: 1 Avg: 0 Max: 33 T: 2 ( 4186) P:99 I:2000 C:18861483 Min: 0 Act: 1 Avg: 0 Max: 22 T: 3 ( 4187) P:99 I:2500 C:15089187 Min: 0 Act: 1 Avg: 0 Max: 23 T: 4 ( 4188) P:99 I:3000 C:12574322 Min: 0 Act: 1 Avg: 0 Max: 29 //Mercury without GPU SDK  test case T: 0 ( 4287) P:99 I:1000 C:1000000 Min: 6 Act: 7 Avg: 7 Max: 20 T: 1 ( 4288) P:99 I:1500 C:  666667 Min: 6 Act: 9 Avg: 7 Max: 17 T: 2 ( 4289) P:99 I:2000 C:  499994 Min: 6 Act: 8 Avg: 7 Max: 24 T: 3 ( 4290) P:99 I:2500 C:  399991 Min: 6 Act: 9 Avg: 7 Max: 19 T: 4 ( 4291) P:99 I:3000 C:  333322 Min: 6 Act: 8 Avg: 7 Max: 21 //Mercury with GPU SDK  test case T: 0 ( 4222) P:99 I:1000 C:1236790 Min: 6 Act: 7 Avg: 7 Max: 55 T: 1 ( 4223) P:99 I:1500 C:  824518 Min: 6 Act: 7 Avg: 7 Max: 44 T: 2 ( 4224) P:99 I:2000 C:  618382 Min: 6 Act: 8 Avg: 8 Max: 88 T: 3 ( 4225) P:99 I:2500 C:  494701 Min: 6 Act: 7 Avg: 8 Max: 49 T: 4 ( 4226) P:99 I:3000 C:  412247 Min: 6 Act: 7 Avg: 8 Max: 53 //////////////////////////////////////// update for Yocto L5.4.47 2.2.0  /////////////////////////////////////////////////////////// New release package xenomai-5.4.47-2.2.0-arm64.tgz for Yocto release L5.4.47 2.2.0 and it supports i.MX8M series (8MQ,8MM,8MN and 8MP). You need to add the following variable in conf/local.conf before build xenomai by command bitake xenomai.  XENOMAI_KERNEL_MODE = "cobalt"  PREFERRED_VERSION_linux-imx = "5-${XENOMAI_KERNEL_MODE}" IMAGE_INSTALL_append += " xenomai" or XENOMAI_KERNEL_MODE = "mercury" PREFERRED_VERSION_linux-imx = "5-${XENOMAI_KERNEL_MODE}" IMAGE_INSTALL_append += " xenomai" //////////////////////////////////////// update for Yocto L5.4.70 2.3.0  /////////////////////////////////////////////////////////// New release package xenomai-5.4.70-2.3.0-arm64.tgz for Yocto release L5.4.70 2.3.0 and it supports i.MX8M series (8MQ,8MM,8MN and 8MP) and i.MX8QM/QXP. Updating: 1, Support i.MX8QM and i.MX8QXP 2, Fix altency's the issue which uses legacy API to get time
View full article
BSP: L5.4.47-2.2.0-rc2 Board: imx8QM B0 HW:  LVDS2HDMI , MIPIDSI2HDMI. It is the porting of i.MX8QM dpu loopback to isi . to the 5.4.y, with the addition of the MIPI-DSI loopback and the HDMI loopback.  Overview of the DC capture configuration: For enabling the capture: only DC 0 Stream 0  and DC 1 Stream 1 can be captured The pixel link Master address should be set to 3 because the Receiver Address at ISI is 3 and can't be changed. To continue displaying the stream, the Receiver Address at LVDS and DSI or HDMI should be changed to 3. It is possible to change the RA by using GPIO of the modules.   Patches: Create V4L2 device enabling the capture of by the ISI of DC loop-backs. Enable ISI capture from DSI 0 / LVDS 1 in 1920x1080 (at the same time.) Enable ISI capture from HDMI in 2840x2160 (half with even pixel) in 1920x2160. While capturing with the ISI, the captured screen continue to be displayed. Remark: Ov5640 cameras are also enabled in the same dtb. So 4 stream in 1920x1080 can be captured at the same time. Installation and gstreamer command: See readme
View full article
How to connect i.MX51 and Ubuntu using USB cable: i.MX51 Side Plug in USB cable. getprop debug.adb.usb - Shows that debug.adb.usb are not set by default setprop persist.service.adb.enable 0 -> disable adb setprop debug.adb.usb 1 - adb will be through USB (for Ethernet, use setprop debug.adb.usb 0) setprop persist.service.adb.enable 1 -> enable adb Example: # getprop debug.adb.usb  # # # setprop persist.service.adb.enable 0 disabling adb # adb_release android_usb gadget: high speed config #1: android setprop debug.adb.usb 1 # # setprop persist.service.adb.enable 1 enabling adb # adb_open adb_release adb_open android_usb gadget: high speed config #1: android # Ubuntu Side On Ubuntu side, the most important tip is regarding permission. ADB server MUST be started with root right. Example of right mistake: $ sudo <AND_SDK_DIR>/android-sdk-linux_86/tools/adb devices List of devices attached ????????????    no permissions  $ sudo <AND_SDK_DIR>/android-sdk-linux_86/tools/adb shell error: insufficient permissions for device How to proceed to get permission: $ sudo <AND_SDK_DIR>/android-sdk-linux_86/tools/adb kill-server $ sudo <AND_SDK_DIR>/android-sdk-linux_86/tools/adb start-server * daemon not running. starting it now * * daemon started successfully * $ sudo <AND_SDK_DIR>/android-sdk-linux_86/tools/adb devices List of devices attached 0123456789ABCDEF    device  $ sudo <AND_SDK_DIR>/android-sdk-linux_86/tools/adb shell ADB over Ethernet/Wi-Fi To make ADB work in i.MX51 using TCP: In your host machine: - Install Android SDK - export ADBHOST=BOARD_IP (setenv ADBHOST=xxx.xxx.xxx.xxx) - adb kill-server In your board: - make sure that ro.secure property is *not* set when the adbd daemon is launched, so edit the file default.prop - make sure that /dev/android_adb or /dev/android do *not* exist - stop adbd - start adbd Now you will be able to list the device: hamilton@saygon:/opt/work/androidsdk/android-sdk-linux_86/tools$ ./adb kill-server hamilton@saygon:/opt/work/androidsdk/android-sdk-linux_86/tools$ ./adb devices * daemon not running. starting it now * * daemon started successfully * List of devices attached emulator-5554   device
View full article
  1) Remove all "network" parameter from .../ltib-dir/rootfs/rc.d/rc.conf 2) Add the path of rootfs in the /etc/exports file: /home/user/ltib"dir/rootfs/rootfs *(rw,sync,no_root_squash)   then execute :- #exportfs -ra 3) Execute NFS server /etc/init.d/nfs restart  
View full article
It is often not easy to use company network to flash application, due to network security (proxy, etc...). We will see in this tutorial, how to flash a Linux application in a SD card with ONLY a SD card reader and simple standard Linux commands. SD card Memory Map A Linux application is divided in 3 parts: the bootloader the Linux Kernel the Linux Rootfs We will flash sequentially these 3 parts Flashing U-boot With the SD card Reader, we will flash the yellow part. In the [...]/ltib/rootfs/boot/ folder $ sudo dd if=u-boot.bin of=/dev/sdb bs=512 skip=2 seek=2 && sudo sync Flashing Linux Kernel With the SD card reader, we will flash the green part. Keep in mind that 1MB=1048576B -> Kernel Offset. $ sudo dd if=uImage of=/dev/sdb bs=1048576 seek=1 && sudo sync Configure U-boot variables To launch the Kernel, you need to configure U-boot. Plug the serial cable on the EVK: 115kbps, 8 bits, 1 stop and no parity EVK switches must be configured as below: DS1 DS2 DS3 DS4 DS5 DS5 DS7 DS8 DS9 DS10 Boot from SD/MMC Card 0 0 0 0 0 0 1 1 0 0 Put the SD card in the EVK (bottom slot) and launch the app. In the hyperterminal type:   BBG U-Boot > printenv To print environnement variables Modify the bootcmd: BBG U-Boot > setenv bootcmd_mmc 'run bootargs_base bootargs_mmc;mmc read 0 ${loadaddr} 0x800 0x1800;bootm' "0x1800" is the size of the kernel. Must be bigger than uImage Kernel file (0x1800x512Byte=3MB) If you want to use the WVGA as display screen (kernel need to be configured with CLAA support), for LTIB1007 and after (before it was 'wvga' option): Script for LTIB1007's u-boot on i.MX51 EVK (copy/paste in the hyperterminal): setenv bootcmd_mmc 'run bootargs_base bootargs_mmc; mmc read 0 ${loadaddr} 800 1800 ; bootm' setenv bootargs_mmc 'setenv bootargs ${bootargs} root=/dev/mmcblk0p1 rootwait rw  init=/init' setenv bootargs_base' setenv bootargs console=ttymxc0,115200 di1_primary console=tty1' setenv bootcmd 'run bootcmd_mmc' saveenv Script for LTIB1007's u-boot on i.MX53 EVK (copy/paste in the hyperterminal): setenv bootcmd_mmc 'run bootargs_base bootargs_mmc; mmc read 0 ${loadaddr} 800 1800 ; bootm' setenv bootargs_mmc 'setenv bootargs ${bootargs} root=/dev/mmcblk0p1 rootwait rw  init=/init' setenv bootargs_base 'setenv bootargs console=ttymxc0,115200 di0_primary console=tty1' setenv bootcmd 'run bootcmd_mmc' saveenv You must have the following printenv: BBG U-Boot > printenv bootdelay=3 baudrate=115200 loadaddr=0x90800000 netdev=eth0 ethprime=FEC0 uboot_addr=0xa0000000 uboot=u-boot.bin kernel=uImage bootargs_nfs=setenv bootargs ${bootargs} root=/dev/nfs ip=dhcp nfsroot=${serveri p}:${nfsroot},v3,tcp bootcmd_net=run bootargs_base bootargs_nfs; tftpboot ${loadaddr} ${kernel}; boot m load_uboot=tftpboot ${loadaddr} ${uboot} ethact=FEC0 bootargs=console=ttymxc0,115200 di1_primary root=/dev/mmcblk0p1 rootwait rw init =/init bootcmd_mmc=run bootargs_base bootargs_mmc; mmc read 0 ${loadaddr} 800 1800 ; bo otm bootargs_mmc=setenv bootargs ${bootargs} root=/dev/mmcblk0p1 rootwait rw init=/i nit bootargs_base=setenv bootargs console=ttymxc0,115200 di1_primary bootcmd=run bootcmd_mmc stdin=serial stdout=serial stderr=serial</br> Environment size: 748/131068 bytes BBG U-Boot > Create ext3 partition With the SD card reader, create an ext3 partition. You can use gparted, a graphical partition manager tool. Launch gparted: $ sudo gparted Create a new ext3 partition, with 20MB of offset: Copying Linux To copy rootfs folder generated by LTIB, type in the shell: $ sudo cp -r /[…]/ltib/rootfs/* /media/FreescaleSD/ && sudo sync Test application Put the SD in the slot slot and launch the application. Password is root.
View full article
Ubuntu distro uses dash instead of bash as shell, then change it to bash: # cd /bin # sudo rm sh # sudo ln -s bash sh Install all necessary packages by typing: sudo apt-get install patch g++ rpm zlib1g-dev m4 bison libncurses5-dev libglib2.0-dev gettext \ build-essential tcl intltool libxml2-dev liborbit2-dev libx11-dev ccache flex uuid-dev liblzo2-dev If under Ubuntu 64bit, install ia32-libs package: sudo apt-get install ia32-libs If you will install Xorg in your ltib, you will need to install this package: sudo apt-get install x11proto-core-dev If you will install gtk+ in your ltib, you will need to install the following packages: sudo apt-get install libdbus-glib-1-dev libgtk2.0-dev libdbus-glib-1-dev Configure visudo file, as root using the command "/usr/sbin/visudo", and add the following line in the User privilege section: username ALL = NOPASSWD: /usr/bin/rpm, /opt/freescale/ltib/usr/bin/rpm Where username is your user name, the name you use to do logon in your system. Classic Error messages and solutions under Ubuntu Can't exec "mconf": No such file or directory at /home/tic/ltib/bin/Ltibutils.pm line 972. exec: mconf /home/tic/ltib/config/main.lkc: No such file or directory at /home/tic/ltib/bin/Ltibutils.pm line 972. traceback:   Ltibutils::system_nb:972   main::get_plat_dir:2947     main:548 Started: Tue Feb 16 18:01:38 2010 Ended:  Tue Feb 16 18:59:26 2010 Elapsed: 3468 seconds Build Failed Solution: edit the ltib script line 925:                   # install the new package           $cmd  = "$cf->{sudo} $cf->{rpm} ";           $cmd .= "--root $cf->{rpmroot} ";           $cmd .= "--dbpath $cf->{rpmdb} ";           $cmd .= "--prefix $cf->{rpmipfx} " if $cf->{rpmipfx};           $cmd .= "--ignorearch -ivh ";           $cmd .= "--force "  unless $cf->{conflicts} || $cf->{hostinst};           $cmd .= "--replacepkgs --replacefiles " if $cf->{hostinst};           $cmd .= "--nodeps " if $cf->{nodeps};           $cmd .= "--excludedocs "; +        $cmd .= "--force-debian " if $rpm =~ m/rpm-fs/ && `uname -a` =~ m/ubuntu/i;           $cmd .= "--define '_tmppath $cf->{tmppath}' ";           $cmd .= "$rpm"; error: cannot open Name index using db3 - No such file or directory (2) error: cannot open Name index using db3 - No such file or directory (2) sudo rpm --root / --dbpath /tmp/rpm-tic/rpmdb -e --allmatches --nodeps --define '_tmppath /home/tic/ltib/tmp' rpm-fs 2>/dev/null sudo rpm --root / --dbpath /tmp/rpm-tic/rpmdb --ignorearch -ivh --force --nodeps --excludedocs --define '_tmppath /home/tic/ltib/tmp'  /tmp/rpm-tic/RPMS/i686/rpm-fs-4.0.4-1.i686.rpm rpm: please use alien to install rpm packages on Debian, if you are really sure use --force-debian switch. See README.Debian for more details. sudo /opt/freescale/ltib/usr/bin/rpm --root / --dbpath /opt/freescale/ltib/var/lib/rpm -Uv --justdb --notriggers --noscripts --nodeps  /tmp/rpm-tic/RPMS/i686/rpm-fs-4.0.4-1.i686.rpm sudo: /opt/freescale/ltib/usr/bin/rpm: command not found mkdir: cannot create directory `/opt/freescale': Permission denied Cannot create the download directory:   /opt/freescale/pkgs Either change to a global directory you have write permissions to, or create it as root.  Please set the permissions to 777 traceback:   main::check_dirs:2469   main::host_checks:1426     main:542 Started: Wed Nov 25 01:56:53 2009 Ended:  Wed Nov 25 02:07:42 2009 Elapsed: 649 seconds Build Failed solution : sudo chmod 777 /opt make[1]: Entering directory `/opt/freescale/ltib/usr/src/rpm/BUILD/texinfo-4.8' Making all in tools make[2]: Entering directory `/opt/freescale/ltib/usr/src/rpm/BUILD/texinfo-4.8/tools' make[2]: *** No rule to make target `all'.  Stop. make[2]: Leaving directory `/opt/freescale/ltib/usr/src/rpm/BUILD/texinfo-4.8/tools' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/opt/freescale/ltib/usr/src/rpm/BUILD/texinfo-4.8' make: *** [all] Error 2 error: Bad exit status from /home/tic/ltib/tmp/rpm-tmp.U8vEdX (%build) RPM build errors:     Bad exit status from /home/tic/ltib/tmp/rpm-tmp.U8vEdX (%build) Build time for texinfo: 55 seconds Failed building texinfo Died at ./ltib line 1380. traceback:   main::build_host_rpms:1380   main::host_checks:1435     main:542 Started: Wed Nov 25 20:10:43 2009 Ended:  Wed Nov 25 20:31:42 2009 Elapsed: 1259 seconds These packages failed to build: texinfo Build Failed solution : install ccache package in host + cd /opt/freescale/ltib/usr/src/rpm/BUILD + cd lkc-1.4 + make -j1 conf mconf gcc -O0 -Wall -g -fPIC -c conf.c -o conf.o bison -l -b zconf -p zconf zconf.y flex -L -Pzconf zconf.l make: flex: Command not found make: *** [lex.zconf.c] Error 127 error: Bad exit status from /home/tic/ltib/tmp/rpm-tmp.010CjL (%build) RPM build errors:     Bad exit status from /home/tic/ltib/tmp/rpm-tmp.010CjL (%build) Build time for lkc: 2 seconds Failed building lkc Died at ./ltib line 1380. traceback:   main::build_host_rpms:1380   main::host_checks:1435     main:542 Started: Thu Nov 26 00:33:46 2009 Ended:  Thu Nov 26 01:19:39 2009 Elapsed: 2753 seconds These packages failed to build: lkc Build Failed solution : install flex package in host Making all in po make[2]: Entering directory `/home/tic/ltib/rpm/BUILD/alsa-utils-1.0.11rc2/alsaconf/po' mv: cannot stat `t-ja.gmo': No such file or directory make[2]: *** [ja.gmo] Error 1 make[2]: *** Waiting for unfinished jobs.... mv: cannot stat `t-ru.gmo': No such file or directory make[2]: *** [ru.gmo] Error 1 make[2]: Leaving directory `/home/tic/ltib/rpm/BUILD/alsa-utils-1.0.11rc2/alsaconf/po' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/tic/ltib/rpm/BUILD/alsa-utils-1.0.11rc2/alsaconf' make: *** [all-recursive] Error 1 error: Bad exit status from /home/tic/ltib/tmp/rpm-tmp.93730 (%build) RPM build errors:     Bad exit status from /home/tic/ltib/tmp/rpm-tmp.93730 (%build) Build time for alsa-utils: 84 seconds Failed building alsa-utils f_buildrpms() returned an error, exiting traceback:   main:560 Started: Sat Nov 28 07:39:40 2009 Ended:  Sat Nov 28 08:17:18 2009 Elapsed: 2258 seconds These packages failed to build: alsa-utils Build Failed Exiting on error or interrupt solution : install package gettext and ja-trans checking for glib-genmarshal... no configure: error: Could not find a glib-genmarshal in your PATH error: Bad exit status from /home/tic/ltib/tmp/rpm-tmp.13030 (%build) RPM build errors:     Bad exit status from /home/tic/ltib/tmp/rpm-tmp.13030 (%build) Build time for glib2: 107 seconds Failed building glib2 f_buildrpms() returned an error, exiting traceback:   main:560 Started: Sat Dec  5 03:19:36 2009 Ended:  Sat Dec  5 03:29:46 2009 Elapsed: 610 seconds These packages failed to build: glib2 Build Failed Exiting on error or interrupt solution : install the package libglib2.0-dev
View full article
When to enable CONFIG_DEBUG_LL, choose the debug port and then CONFIG_EARLY_PRINTK on i.MX6, system will hang. There is no error information there as below, Uncompressing Linux... done, booting the kernel. Booting Linux on physical CPU 0x0 Initializing cgroup subsys cpu Initializing cgroup subsys cpuacct Linux version 4.1.15-00001-gd582989-dirty (jay@jay-ubuntu) (gcc version 4.9 20 150123 (prerelease) (GCC) ) #10 SMP PREEMPT Mon Jul 17 15:08:55 CST 2017 CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c53c7d CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache Machine model: Freescale i.MX6 Quad SABRE Smart Device Board bootconsole [earlycon0] enabled cma: Reserved 448 MiB at 0x2a000000 Memory policy: Data cache writealloc -------------- hang ----------------- ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ The patch fix it on android n7.1.1_1.0.0, kernel: 4.1.15.
View full article
Booting Linux Directly from SD/MMC Card     You can create a self-bootable SD or MMC card with Linux.     This tutorial describes how to create a complete Linux system (bootloader + Linux kernel + root file system) that boots from SD/MMC card.     This is very useful for people willing to demonstrate several Linux images that can be self-contained in SD/MMC cards. Flashing RedBoot on MMC using ATK     To boot Linux from a SD card, the first thing to do is to program the bootloader to the card. For this, click on the link below:     I.MX35 PDK Board Flashing SDCard Flashing RedBoot on MMC using DD     You can also use dd on any linux system to load redboot:   $ sudo dd if=./Desktop/mx35_3stack_redboot_mmc.bin of=/dev/sdd bs=512 skip=2 seek=2 Configuring Kernel to Boot From SD/MMC     Creating a Linux bootable MMC/SD Card.     Execute LTIB:   $ ./ltib -c     Choose configure the kernel:   [*] Configure the kernel     Change image generation to NFS:     Target Image Generation     Options --->     (X) NFS only     Compile Linux kernel with built-in support to MMC/SD and ext3:     Follow that sequence:     Device Drivers --->     <*> MMC/SD card support --->     <*> UniFi SDIO glue for Freescale MMC/SDIO     <*> Freescale i.MX Secure Digital Host Controller Interface support       File systems --->     <*> Ext3 journalling file system support     After the compilation copy the file ~/ltib/rootfs/boot/zImage to tftpboot directory:   $ cp ~/ltib/rootfs/boot/zImage /tftpboot Creating RedBoot Kernel Partition     Create RedBoot partitions and copy Linux kernel to it:     Turn MMC active:   RedBoot> factive MMC     Initialize flash partitions:   RedBoot> fis init       RedBoot> fis list     ... Read from 0x07ee0000-0x07eff000 at 0x00060000: .     Name FLASH addr Mem addr Length Entry point     RedBoot 0x00000000 0x00000000 0x00040000 0x00000000     FIS directory 0x00060000 0x00060000 0x0001F000 0x00000000     RedBoot config 0x0007F000 0x0007F000 0x00001000 0x00000000     Load kernel to RAM:   RedBoot> load -r -b 0x100000 /tftpboot/zImage     Using default protocol (TFTP)     Raw file loaded 0x00100000-0x002c31b7, assumed entry at 0x00100000     Create a kernel partition with content of kernel image loaded to RAM:       RedBoot> fis create -f 0x200000 kernel         RedBoot> fis list     ... Read from 0x07ee0000-0x07eff000 at 0x00060000: .     Name FLASH addr Mem addr Length Entry point     RedBoot 0x00000000 0x00000000 0x00040000 0x00000000     FIS directory 0x00060000 0x00060000 0x0001F000 0x00000000     RedBoot config 0x0007F000 0x0007F000 0x00001000 0x00000000     kernel 0x00200000 0x00100000 0x001E0000 0x00100000     If you reset your board you need to see:   Booting from [SD card, CSD Version 1.0]     If instead you see this message:   Booting from [unknown version card ]     This means your card is not support, please replace it with other card. Creating the Root File System     After storing the kernel image in the SD card, remove the card from the target board and insert it in your computer (running Linux).     In this example, Linux detected the SD card as /dev/sdb.     Now we need to create two partitions. The first partition will not be used, this is just reserved to RedBoot and kernel. The second partition will be used to store Linux Root File System.   # fdisk /dev/sdb     Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel     Building a new DOS disklabel with disk identifier 0x526c22da.     Changes will remain in memory only, until you decide to write them.     After that, of course, the previous content won't be recoverable.         Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)         Command (m for help): p         Disk /dev/sdb: 1023 MB, 1023934464 bytes     32 heads, 62 sectors/track, 1008 cylinders     Units = cylinders of 1984 * 512 = 1015808 bytes     Disk identifier: 0x526c22da           Device Boot Start End Blocks Id System     Create the first partition with 8 MB; it already contains RedBoot and the kernel, as we stored previously:             Command (m for help): n     Command action       e extended       p primary partition (1-4)     p     Partition number (1-4): 1     First cylinder (1-1008, default 1):     Using default value 1     Last cylinder, +cylinders or +size{K,M,G} (1-1008, default 1008): +8M     Now, create the second partition using all remaining space on SD card:       Command (m for help): n     Command action       e extended       p primary partition (1-4)     p     Partition number (1-4): 2     First cylinder (10-1008, default 10):     Using default value 10     Last cylinder, +cylinders or +size{K,M,G} (10-1008, default 1008):     Using default value 1008         Command (m for help): p         Disk /dev/sdb: 1023 MB, 1023934464 bytes     32 heads, 62 sectors/track, 1008 cylinders     Units = cylinders of 1984 * 512 = 1015808 bytes     Disk identifier: 0x526c22da     Device Boot Start End Blocks Id System     /dev/sdb1 1 9 8897 83 Linux     /dev/sdb2 10 1008 991008 83 Linux         Command (m for help): w   Now format the second partition as EXT3: # mkfs.ext3 /dev/sdb2   Remove the SD card from your computer and insert again. Probably your Linux distribution will dectect it and will mount automatically.   On Ubuntu 8.10 it was mounted on /dev/media:   # mount   ...   /dev/sdb2 on /media/disk type ext3 (rw,nosuid,nodev,uhelper=hal) If your Linux didn't mount it, then you can mount it manually:   # mkdir -p /media/disk   # mount /dev/sdb2 -t ext3 /media/disk   Enter in your LTIB directory and copy the rootfs content to SD card:   # cd /home/alan/ltib-imx35/rootfs/   # cp -a * /media/disk/   Verify if it was copied correctly:   # ls -l /media/disk/   total 80   drwxr-xr-x 2 root root 4096 2009-03-12 09:55 bin   drwxr-xr-x 2 root root 4096 2009-03-12 09:53 boot   drwxr-xr-x 2 root root 4096 2009-03-12 09:55 dev   drwxr-xr-x 6 root root 4096 2009-03-12 14:41 etc   drwxr-xr-x 3 root root 4096 2009-03-12 09:53 home   drwxr-xr-x 4 root root 4096 2009-03-12 09:55 lib   lrwxrwxrwx 1 root root 11 2009-03-12 14:47 linuxrc -> bin/busybox   drwx------ 2 root root 16384 2009-03-12 14:37 lost+found   drwxr-xr-x 7 root root 4096 2009-03-12 09:53 mnt   drwxr-xr-x 2 root root 4096 2009-03-12 09:53 opt   drwxr-xr-x 2 root root 4096 2009-03-12 09:53 proc   drwxr-xr-x 2 root root 4096 2009-03-12 10:10 root   drwxr-xr-x 2 root root 4096 2009-03-12 09:55 sbin   drwxr-xr-x 2 root root 4096 2009-03-12 09:53 sys   drwxrwxrwt 3 root root 4096 2009-03-12 09:53 tmp   drwxr-xr-x 2 root root 4096 2009-03-12 09:55 unit_tests   drwxr-xr-x 9 root root 4096 2009-03-12 09:55 usr   drwxr-xr-x 11 root root 4096 2009-03-12 09:55 var   root@urubu:~/ltib-imx25/rootfs#     Now umount the SD card:   # umount /media/disk Configuring RedBoot to Load Kernel and Rootfs from SD/MMC Card     Remove the SD card from your computer and place again in the board.     Configure RedBoot to load the kernel from SD/MMC card and set up the kernel command parameter "root" to load the root file system from second SD/MMC card partition (/dev/mmcblk0p2)     RedBoot> fc     Run script at boot: true     Boot script:     Enter script, terminate with empty line     >> fis load kernel     >> exec -b 0x100000 -l 0x200000 -c "noinitrd console=ttymxc0,115200 root=/dev/mmcblk0p2 init=/linuxrc ip=none"     >>     Boot script timeout (1000ms resolution): 1     Use BOOTP for network configuration: false     Gateway IP address: 10.29.244.254     Local IP address: 10.29.244.135     Local IP address mask: 255.255.0.0     Default server IP address: 10.29.240.182     Board specifics: 0     Console baud rate: 115200     Set eth0 network hardware address [MAC]: false     Set FEC network hardware address [MAC]: false     GDB connection port: 9000     Force console for special debug messages: false     Network debug at boot time: false     Default network device: lan92xx_eth0     Update RedBoot non-volatile configuration - continue (y/n)? y     ... Read from 0x07ee0000-0x07eff000 at 0x00060000: .     ... Erase from 0x00060000-0x00080000: .     ... Program from 0x07ee0000-0x07f00000 at 0x00060000: .       Now just reset the board and it will boot directly from SD/MMC card.
View full article
Getting Started for i.MX53 Quick Start Board Here is a quick overview you can follow to get your very first contact with i.MX53 QSB. Introduction Out of box i.MX53 QSB video booting up Ubuntu Original Video: Out of box i.MX53 QSB video booting up Ubuntu with some demo (GPU and VPU) Original Video: How to load a pre-built image Here, you should have loaded your board with the out-of-box SD card. Next step is create your own SD card with some pre-built image. You can find pre-built image packages from Freescale for Linux look for Linux Binary Demo file Please, go to Timesys wikipage[1] and see how to load a pre-built image. You can use some Freescale image or some Timesys image. Both will work! For loading linux OS you need at least 3 images: bootloader image kernel image root file system image or tarball Bootloader For iMX53QSB the default bootloader provided by Freescale is u-boot.You can build your own image using LTIB following the same procedure from here. Kernel You can build a new uImage (kernel binary image to be loaded by u-boot) using LTIB, and you can follow the instructions from here Root File System Root file system is a set of directories and files that become the system environment. How to Built Your Own Image Take BSP package on Freescale i.MX53 QSB web site. Prepare your computer to LTIB installation, see that you need All Boards LTIB. Transfer all images to the SD Card (it will be placed under <ltib_dir>/rootfs/boot). Configure your u-boot environment variable. Boot your board. In case you want to boot via NFS, please follow the next procedure instead. Take BSP package on Freescale i.MX 53 QSB web site. Prepare your computer to LTIB installation, see that you need @all_boards_ltib Configure your computer to be able to provide NFS service: Configure your TFTP server. Configure your NFS server. Configure your u-boot environment variable. Boot your board. Be aware the kernel command line you set on u-boot variable can configure the display.
View full article
This document explains how to bring-up u-boot & Linux via JTAG This procedure has been tested on: i.MX6 Solo X Sabre SD i.MX6UL EVK Prerequistes: Get the latest BSP for your board. This procedure was tested with L4.1.15. Build the 'core-image-minimal' image to bring-up your board (Detailed steps here) Optional- Build a meta-toolchain for your device 1.- Set board to boot from Serial dowloader mode or set it to boot from the SD card and remove the sd card We basically want the board to stall in boot ROM to attach to the target. 2.- Connect JTAG probe and turn on the board The device should stall trying to establish a connection to download an image, this will allow us to attach to the target. 3.- Load Device Configuration Data In 'normal' boot sequence the boot ROM takes care of reading the DCD and configuring the device accordingly, but in this case we are skipping this sequence and we need to configure the device manually. The script used by Lauterbach to parse and configure the device is called dcd_interpreter.cmm and can be found here. Search for the package for your specific device. The DCD configuration for your board should be on your u-boot directory: yocto_build_dir/tmp/work/<your board>imx6ulevk/u-boot-imx/<u-boot_version>2016.03-r0/git under board/freescale/<name of your board>mx6ul_14x14_evk/imximage.cfg This file (imximage.cfg) contains all the data to bring up DRAM among other early configuration options. 4.- Load U-boot If an SREC file of U-boot is not present build it (meta-toolchain installed required) the SREC file contains all the information required by the probe to load it and makes this process easier. To build the SREC simply type: make <your board defconfig>mx6ul_14x14_evk_defconfig  (all supported boards are found under u-boot_dir/configs) make If you cannot build an SREC or do not want to, you can use the u-boot.imx (located under yocto_build_dir/tmp/deploy/images/<your board name>/) or u-boot.bin files but you will need to figure out the start address and load address for these files, this can be done by examining the IVT on u-boot.imx (here is a useful document explaining the structure of the IVT). Let U-boot run and you should see its output on the console I will try to boot from several sources but it will fail and show you the prompt. 5.- Create RAMDisk After building the core-image-minimal you will have all the required files under yocto_build_dir/tmp/deploy/images/<your board name>/ You will need: zImage.bin - zImage--<Linux Version>--<your board>.bin Device tree blob - zImage--<Linux Version>--<your board>.dtb Root file system - core-image-minimal-<your board>.rootfs.ext4 We need to create a RAMDisk out of the root file system we now have, these are the steps to do so: Compress current Root file system using gzip: gzip core-image-minimal-<your board>.rootfs.ext4 If you want to keep the original file use: gzip -c core-image-minimal-<your board>.rootfs.ext4 > core-image-minimal-<your board>.rootfs.ext4.gz Create RAMDisk using mkimage: mkimage -A arm -O linux -T ramdisk -C gzip -n core-image-minimal -d core-image-minimal-<your board>.rootfs.ext4.gz core-image-minimal-RAMDISK.rootfs.ext4.gz.u-boot Output: Image Name: core-image-minimal Created: Tue May 23 11:28:55 2017 Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 3017939 Bytes = 2947.21 kB = 2.88 MB Load Address: 00000000 Entry Point: 00000000 Here are some details on mkimage usage Usage: mkimage -l image -l ==> list image header information mkimage [-x] -A arch -O os -T type -C comp -a addr -e ep -n name -d data_file[:data_file...] image -A ==> set architecture to 'arch' -O ==> set operating system to 'os' -T ==> set image type to 'type' -C ==> set compression type 'comp' -a ==> set load address to 'addr' (hex) -e ==> set entry point to 'ep' (hex) -n ==> set image name to 'name' -d ==> use image data from 'datafile' -x ==> set XIP (execute in place) mkimage [-D dtc_options] [-f fit-image.its|-F] fit-image -D => set options for device tree compiler -f => input filename for FIT source Signing / verified boot not supported (CONFIG_FIT_SIGNATURE undefined) mkimage -V ==> print version information and exit 6.- Modify U-boot's environment variables Now we need to modify U-boot's bootargs as follows: setenv bootargs console=${console},${baudrate} root=/dev/ram rw We need to find out the addresses where u-boot will expect the zImage, the device tree and the initial RAMDisk, we can do it as follows: => printenv fdt_addr fdt_addr=0x83000000 => printenv initrd_addr initrd_addr=0x83800000 => printenv loadaddr loadaddr=0x80800000 Where: fdt_addr -> Device tree blob load address initrd_addr -> RAMDisk load address loadaddr -> zImage load address 7.- Load zImage, DTB and RAMDisk Now we know where to load our zImage, device tree blob and RAMDisk, on Lauterbach this can be achieved by running the following commands: Stop the target and execute: data.load.binary zImage.bin 0x80800000 data.load.binary Your_device.dtb 0x83000000 data.load.binary  core-image-minimal-RAMDISK.rootfs.ext4.gz.u-boot 0x83800000 Let the device run again and deattach from the device in lauterbach this is achieved by: go SYStem.mode.NoDebug start the boot process on u-boot as follows: bootz ${loadaddr} ${initrd_addr} ${fdt_addr} You should now see the Linux kernel boot process on your terminal: After the kernel boots you should see its prompt on your terminal: Since we are running out of RAM there is no way for us to save u-boot's environment variables, but you can modify the source and compile u-boot with the new bootargs, by doing so you can create a Load script that loads all the binaries hits go and the boot process will continue automatically. One way to achieve this is to modify the configuration file under U-boot_dir/include/configs/<your board>.h find the mfgtool_args and modify accordingly. The images attached to this thread have been modified as mentioned.
View full article
Introduction This is a brief guide showing how to integrate the driver for the WF111 module to the i.MX6 BSP Release. In this case the WF111 driver is available on a repository and it’s in accordance with the Yocto Project, which allows to easily customize a linux distribution for your board. Requirements WF111 Documentation – Silicon Labs have made a great job of documenting the steps to add the WF111 driver to a Linux distribution and have created Application Note 996 (link below), which we will use as reference. http://www.silabs.com/documents/login/application-notes/AN996.pdf WF111 Driver - We will also be using the Yocto layer included on the following repository: https://github.com/engicam-stable/meta-engicam i.MX6 3.14.52 BSP Release – In out scenario the WF111 layer that will be imported includes a driver that it’s compatible with Linux Kernel 2.6.24 up to 4.1., which it’s important to keep in mind.   Installing the 3.14.52 BSP Release First, setup the 3.14.52 BSP as described on the i.MX Yocto Project User’s Guide.   Adding the WF111 Driver Layer Clone the WF111 Driver Layer to your sources folder inside the BSP Release directory. Since the 3.14.52 BSP Release is based on Fido we will clone the Fido branch of the driver repository. $ cd <BSP_RELEASE_DIR>/sources $ git clone https://github.com/engicam-stable/meta-engicam -b fido ‍ ‍  Once the layer is cloned you would need to add the new later editing the bblayers.conf file located the following path: <BSP_RELEASE_DIR>/<BUILD_DIR>/conf/bblayers.conf By adding the following line to add the new layer.   BBLAYERS += " ${BSPDIR}/sources/meta-engicam " ‍   This should make the wf111-driver available through bitbake since bitbake will now look into this layer for all available recipes. You can then add the driver to your image by adding the following line to the <BUILD_DIR>/conf/local.conf   IMAGE_INSTALL_append += "wf111-driver" ‍ Or you may create a new image recipe that includes the wf111-driver package. However, there are certain kernel options that must be enabled for the driver to work.   Creating an append to configure the kernel options Before we can bake an image with the WF111 driver we would need to edit the kernel options as mentioned on Silabs AN996. The following kernel options must be enabled:   CONFIG_WIRELESS_EXT CONFIG_MODULES CONFIG_FW_LOADER We would need to add the CONFIG_WIRELESS_EXT as the other two options are enabled on the BSP by default.   This involves adding an addendum to the kernel recipe to change its configuration. You may either add this append to any layer. The best way to handle it would be using a new layer for all your customization. You can find how to create a new layer on the following document: https://community.nxp.com/docs/DOC-331917 We’ll use a new layer called meta-newlayer for this example. It’s important that this layer has a high priority so the changes from the bbappend are not overridden. The following alternative was suggested by Chris Hossack on the following thread: https://community.nxp.com/thread/376369 First, run the menuconfig tool on the bitbake environment: bitbake linux-imx -c menuconfig Enable the necessary options: Networking Support > Wireless > cfg80211 wireless extensions compatibility   Save the configuration and exit. Then run the following bitbake command, which will create a config fragment file that contains the changed made to the default kernel options. bitbake linux-imx -c diffconfig We’ll make an append file that adds the required options.  Content of the config fragment:   CONFIG_WIRELESS_EXT=y CONFIG_WEXT_CORE=y CONFIG_WEXT_PROC=y CONFIG_WEXT_SPY=y CONFIG_WEXT_PRIV=y CONFIG_CFG80211_WEXT=y CONFIG_LIB80211=y CONFIG_LIB80211_CRYPT_WEP=y CONFIG_LIB80211_CRYPT_CCMP=y CONFIG_LIB80211_CRYPT_TKIP=y # CONFIG_LIB80211_DEBUG is not set CONFIG_HOSTAP=y # CONFIG_HOSTAP_FIRMWARE is not set ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍    Since we are appending the kernel layer we need to add the addendum on the same path as that of the original kernel recipe but within our layer and create the append file there. Also add the WF111.cfg file to the linux-imx directory:   We would need to copy (and you may rename it as well) to the folder where are will be creating the append recipe for the kernel. Copy:  <BSP_RELEASE>/<BUILD_DIR>/tmp/work/<MACHINE>-poky-Linux-gnueabi/linux-imx/<KERNEL_VERSION>/fragment.cfg To: <BSP_RELEASE>/sources/meta-newlayer/recipes-kernel/linux/linux-imx/WF111.cfg You can do so suing the following command: cp <BSP_RELEASE>/<BUILD_DIR>/tmp/work/<MACHINE>-poky-Linux-gnueabi/linux-imx/<KERNEL_VERSION>/fragment.cfg <BSP_RELEASE>/sources/meta-newlayer/recipes-kernel/linux/linux-imx/WF111.cfg ‍ (Please note that the file was renamed for ease, but you may use any name for the config fragment)   We need to create the bbappend file on the following path (as it must be the same relative path as the original recipe it is appending) <BSP_RELEASE>/sources/meta-newlayer/recipes-kernel/linux/linux-imx_3.14.52.bbappend   The linux-imx_3.14.52.bbappend file would contain the following:   SRC_URI += "file://WF111.cfg"  do_configure_append() {          #this is run from         #./tmp/work/<MACHINE>-poky-linux-gnueabi/linux-imx/3.14.52-r0/git          cat ../*.cfg >> ${B}/.config  } ‍ ‍ ‍ ‍ ‍ ‍    After creating this recipe you should be able to bake any image from the BSP and see the driver there. I tested with the core-minimal-image and found that the files were indeed added to /lib/firmware. $ bitbake core-image-minimal ‍‍ ‍
View full article
The i.MX 8QXP MEK does not allow the OV5640/LVDS/LCD usage only by changing the device tree anymore. It occurs because the M4 owns the i2c resources, so the A core must use rpmsg to enable virtual drivers. Due to this, if the user changes the device tree, for instance, the *ov5640.dtb, the kernel won't boot, entering in the following loop: [    8.603353] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).      [    8.610025] [drm] No driver support for vblank timestamp query.              [    8.616077] imx-drm display-subsystem: bound imx-drm-dpu-bliteng.2 (ops dpu_) [    8.624978] imx-drm display-subsystem: bound imx-dpu-crtc.0 (ops dpu_crtc_op) [    8.632526] imx-drm display-subsystem: bound imx-dpu-crtc.1 (ops dpu_crtc_op) [    8.639833] imx-drm display-subsystem: failed to bind ldb@562210e0 (ops imx_7 [    8.648428] imx-drm display-subsystem: master bind failed: -517 With the approach provided in this post, it is possible to make this change manually, only by changing the flash.bin at U-boot for a non-m4 one. In order to make the changes to the flash.bin file, it’s needed to obtain the following files: - u-boot.bin from internal u-boot provided by NXP. - scfw_tcm.bin from SCFW porting kit - bl31.bin from ARM Trusted Firmware - SECO firmware container image Disclaimer The described procedures in this document target a GNU/Linux (Ubuntu 20.04 LTS) and it’s focused on iMX8QXP B0 + BSP L4.19.35_1.1.0. Required packages 1 - Install ARM64 ToolChain: 1.1 - Install ARM64 GCC and G++ cross-compilers: # apt install gcc-aarch64-linux-gnu g++-aarch64-linux-gnu 2 - Install ARM32 GCC6 ToolChain: 2.1 - Download the ARM32 6 Toolchain and install it: $ mkdir ~/gcc_toolchain $ cp ~/Downloads/gcc-arm-none-eabi-6-2017-q2-update-linux.tar.bz2 ~/gcc_toolchain/ $ cd ~/gcc_toolchain/ $ tar xvjf gcc-arm-none-eabi-6-2017-q2-update-linux.tar.bz2 # apt-get update # apt-get install srecord 3 - Download MKimage 3.1 - Create a new directory desired to the packages: $ mkdir flash_build $ cp flash_build 3.1 - Clone the MKimage: $ git clone https://source.codeaurora.org/external/imx/imx-mkimage -b imx_4.19.35_1.1.0 4 - U-boot build 4.1 - Clone the U-boot  $ git clone https://source.codeaurora.org/external/imx/uboot-imx -b imx_v2019.04_4.19.35_1.1.0 $ cd uboot-imx 4.2 - Export the ARM64 ToolChain:  $ export ARCH=arm64 $ export CROSS_COMPILE=/usr/bin/aarch64-linux-gnu- 4.3 - Build it:  $ unset LDFLAGS $ make -j4 imx8qxp_mek_defconfig $ make 4.4 - Copy the binary files to the MKimage/iMX8QX directory:  $ cp spl/u-boot-spl.bin ../imx-mkimage/iMX8QX/ $ cp u-boot-nodtb.bin ../imx-mkimage/iMX8QX/ $ cd ..   5 - ARM Trusted Firmware 5.1 - Clone the imx-atf:  $ git clone https://source.codeaurora.org/external/imx/imx-atf -b imx_4.19.35_1.1.0 $ cd imx-atf 5.2 - Build it:  $ unset LDFLAGS $ make PLAT=imx8qx bl31 5.3 - Copy the binary files to the MKimage/iMX8QX directory:  $ cp build/imx8qx/release/bl31.bin ../imx-mkimage/iMX8QX/ $ cd ..   6 - SCFW 6.1 - Export the ARM32 GCC6 Toolchain:  $ export TOOLS=~/gcc_toolchain/ 6.2 - Download the BSP L4.19.35_1.1.0_SCFW and copy it to the flash_build directory:  $ cp ~/Downloads/imx-scfw-porting-kit-1.2.7.1.tar.gz $ tar xvzf imx-scfw-porting-kit-1.2.7.1.tar.gz $ cd packages/ $ chmod a+x imx-scfw-porting-kit-1.2.7.1.tar.gz $ ./imx-scfw-porting-kit-1.2.7.1.bin 6.3 - Build it to i.MX 8QXP MEK B0:  $ cd imx-scfw-porting-kit-1.2.7.1/src/ $ tar xvzf scfw_export_mx8qx_b0.tar.gz $ cd scfw_export_mx8qx_b0/ $ make qx R=B0 B=mek 6.4 -  Copy the binary file to the MKimage/iMX8QX directory:  $ cp build_mx8qx_b0/scfw_tcm.bin ../../../../imx-mkimage/iMX8QX/ $ cp ../../../../ 7 - SECO Firmware Container Image 7.1 - Download the SECO firmware binaries and copy it to the flash_build directory $ cp ~/Downloads/firmware-imx-7.9.bin . $ chmod a+x firmware-imx-7.9.bin 7.2 - Copy the binary files to the MKimage/iMX8QX directory:  $ cp firmware-imx-7.9/firmware/seco/mx8qx-ahab-container.img /imx-mkimage/iMX8QX/ 8 - Build flash.bin 8.1 -  In a new terminal, open the imx-mkimage directory : $ cd flash_build/imx-mkimage 8.2 - Build it:  $ make SOC=iMX8QX flash 8.3 - Deploy it to the SDCard:  $ sudo dd if=iMX8QX/flash.bin of=/dev/sdX bs=1k seek=32 && sync Now, you are able to use any non-rpmsg.dtb without kernel errors. Author: Pedro Jardim: pedro.jardim@nxp.com
View full article