i.MXプロセッサ ナレッジベース

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

i.MX Processors Knowledge Base

ディスカッション

ソート順:
Multiple-Display means video playback on multiple screens. In case playback needs to be in a unique screen, the mfw_isink element must be used and some pipelines examples can be found on this link: GStreamer iMX6 Multi-Overlay. Number of Displays Display type Kernel parameters Pipelines # Set these shells variables before running the pipelines alias gl=gst-launch SINK_1="\"mfw_v4lsink device=/dev/video17\"" SINK_2="\"mfw_v4lsink device=/dev/video18\"" SINK_3="\"mfw_v4lsink device=/dev/video20\"" media1=file:///root/media1 media2=file:///root/media2 media3=file:///root/media3 2 hdmi + lvds video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24 video=mxcfb1:dev=ldb,LDB-XGA,if=RGB666 gl playbin2 uri=$media1 video-sink=$SINK_1 playbin2 uri=$media2 video-sink=$SINK_2 2 lvds + lvds video=mxcfb0:dev=ldb,LDB-XGA,if=RGB666 video=mxcfb1:dev=ldb,LDB-XGA,if=RGB666 gl playbin2 uri=$media1 video-sink=$SINK_1 playbin2 uri=$media2 video-sink=$SINK_2 2 lcd + lvds video=mxcfb0:dev=lcd,800x480M@55,if=RGB565 video=mxcfb1:dev=ldb,LDB-XGA,if=RGB666 gl playbin2 uri=$media1 video-sink=$SINK_1 playbin2 uri=$media2 video-sink=$SINK_2 3 hdmi + lvds + lvds video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24 video=mxcfb1:dev=ldb,LDB-XGA,if=RGB6 video=mxcfb2:dev=ldb,LDB-XGA,if=RGB666 gl playbin2 uri=$media1 video-sink=$SINK_1 playbin2 uri=$media2 video-sink=$SINK_2 playbin2 uri=$media3 video-sink=$SINK_3
記事全体を表示
Application Note covering how to get the Silex SX-SDCAN working with the Sabre-SD i.MX6 Evaluation kit.
記事全体を表示
1. Description     These patches are used to support MPU 8080 LCD on L3.14.52_1.1.0_GA BSP.     They are based on ELCDIF hardware module, iMX6UL and iMX7D is the reference platform.   2. File List -- 0001-Add-ST7789S-MPU-LCD-support-for-iMX6UL-board.patch    Patch to support MPU display for iMX6UL, ST7789S 240*320 panel is the example.   -- 0002-Add-ST7735R-MPU-LCD-support-for-iMX7D-board.patch    Patch to support MPU display for iMX7D, ST7735R 128*128 panel is the example.   -- readme.txt    this file, please refer to it before use the patches   3. Requirement - iMX6UL EVK board or iMX7D SabreSD board. - L3.14.52_1.1.0_GA kernel.   4. How to use -- Copy the patch files to kernel folder.     $ cd ~/L3.14.52_GA1.1.0/build-imx7dsabresd-X11/tmp/work/imx7dsabresd-poky-linux-gnueabi/linux-imx/3.14.52-r0/git     $ git apply ./0001-Add-ST7789S-MPU-LCD-support-for-iMX6UL-board.patch     $ git apply ./0002-Add-ST7735R-MPU-LCD-support-for-iMX7D-board.patch   -- Build the new kernel image:     $ cd ~/L3.14.52_GA1.1.0/build-imx7dsabresd-X11/tmp/work/imx7dsabresd-poky-linux-gnueabi/linux-imx/3.14.52-r0/git     $ export CROSS_COMPILE=~/L3.14.52_GA1.1.0/build-imx7dsabresd-X11/tmp/sysroots/x86_64-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-     $ export ARCH=arm     $ make imx_v7_defconfig     $ make zImage     $ make dtbs   5. How to add a new MPU panel     1) in dts file, such as imx6ul-14x14-evk-i80lcd.dts, update the panel name "lcd_panel",        update the PINs in "pinctrl_lcdif_dat" and "pinctrl_lcdif_ctrl" for the new panel,        the reset and rs PINs can be from GPIO pin, lcd_reset_gpio and lcd_rs_gpio. &lcdif { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_lcdif_dat        &pinctrl_lcdif_ctrl>; display = <&display0>; status = "okay"; display0: display {   mpu-mode;   lcd_reset_gpio = <&gpio3 14 0>;   lcd_panel = "ST7789S-QVGA"; }; };       2) Reference to "mxsfb_st7789s_qvga.c", add a new panel driver code.       3) Add the new panel support in Makefile and Kconfig under "drivers/video/mxc/"       4) Add the new panel support in file "mxsfb.c" and "mxsfb.h"       5) Add the new panel support in default kernel config file "imx_v7_defconfig"   Note: mpu_lcd_fb_test.tar.gz is the test application, for 8080 display, it is not sync display, so software need call ioctl to refresh the LCD.     2016-08-02: Add the uboot reference patch for iMX7D. File: L3.14.52_Uboot_mpu_display.patch  
記事全体を表示
When working with an evaluation kit you will be provided with a System Controller Firmware (SCFW) binary included in your BSP. This scfw binary has been tailored for that specific board and you might need to modify some board dependencies to fit your specific hardware. This document aims to provide an overview on the SCFW porting process, for detailed information please refer to the System Controller Porting guide (sc_fw_port.pdf).   Setting up the system The SCFW is built on a Linux host. The steps to set-up your system are the following: Download the GNU ARM Embedded Toolchain: 6-2017-q2-update June 28, 2017 from the ARM website: Select a directory to untar the file unto, for instance: 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‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍   Set TOOLS environment variable to the directory containing the tool chain, "~/gcc_toolchain" on the example above, .bash_profile can also be modified to export this environment variable: export TOOLS=~/gcc_toolchain/ srec_cat is also necessary for the build, this is usually contained in the srecord package, on ubuntu you can do: sudo apt-get update sudo apt-get install srecord Now you can change to the porting kit directory (e.g. scfw_export_mx8qm) and build the scfw. System Controller Firmware Porting kit  The SCFW porting kit contains source files and object files that will allow you to modify the SCFW to work with your board. You can get the latest System Controller Firmware Porting kit from the i.MX Software and development webpage: Once you obtain the porting kit untar it: tar xvzf imx-scfw-porting-kit-1.1.tar.gz‍ You will see the following file structure: The porting kit is contained under packages, the README contains the instructions to extract the porting kit, basically: cd packages/ chmod a+x imx-scfw-porting-kit-1.1.bin ./imx-scfw-porting-kit-1.1.bin‍‍‍ You will be prompted to accept an End User License Agreement: Once you accept the agreement the porting kit will be extracted in a new folder, the folder structure is as follows: All documentation regarding SCFW is under doc/pdf or in html format if preferred, it is recommended to go over sc_fw_port.pdf. The porting kits for different SoC variants (QM A0, QM B0 and QXP B0) are under src packaged as tar.gz, all other files are SCFW libraries for different software packages, such as Linux, QNX, FreeRTOS, U-boot, ARM Trusted Firmware, etc...   If you will be working with several SoC variants (working with both QXP and QM) it is recommended to extract all porting kits into a single directory, that way you will be able to build for any variant from this directory, the command to do this is: cd imx-scfw-porting-kit-1.1/ cd src/ find scfw_export_mx8*.gz -exec tar --strip-components 1 --one-top-level=scfw_export_mx8 -xzvf {} \;‍‍‍ A scfw_export_mx8 folder will be created, from here you will be able to build SCFW for any supported variant. Or you can just extract the package for the variant you are interested on and use that. cd scfw_export_mx8/‍ All the build folders contain the results of building the SCFW and platform is where the source of the SCFW is stored.   All the code that is specific to a board configuration is under "platform/board/mx8<derivative>_<board_name>" where derivative is the i.MX8 silicon family such as QXP or QM, and board name is the name of the board the SCFW package is for. The first step in porting the SCFW to your board is to create a folder for your i.MX8 derivative and board, you can take one of the available board examples and rename the folder, that will provide you a project to get started with, for instance: cp -r platform/board/mx8qm_val/ platform/board/mx8qm_myBoard/‍‍‍‍‍‍‍‍‍‍ The board in this example will be called "myBoard" and it is for an i.MX8QM B0 device. To build a SCFW for this board simply call: make qm R=B0 B=myBoard‍‍‍‍‍‍‍‍‍‍‍‍ If the target is an i.MX8QXP simply take a board based on this device and change the call to "make qx". Additional information such as build options and in detailed boot information can be found in the SCFW porting guide (sc_fw_port.pdf), chapter 2 of this document is a great introduction to the porting process.   Overview and useful information Configuring the PMIC overview and board.c common modifications The main file that needs to be altered (if not the only) is the "board.c" file, it is located at "platform/board/mx8X_board/". The board.c file contains most of the board related information such as SCU UART ports, PMIC initialization routines, PMIC temperature alarms settings and you can also modify it to configure LDOs voltages and communicate with the PMIC in general. All functions in the board.c file are executed by the SCU itself and this gives you access to the I2C interface that is used to communicate with the PMIC. SoC resources that are powered by an external supply (PMIC LDO for instace) such as AP cores and GPUs are powered off/on by board_set_power_mode, the mapping of the resource to an specific PMIC supply happens in board_get_pmic_info, for instance in our i.MX8QM validation board using the A53 subsystem is powered by SW2 of the third PMIC (PMIC_2_ADDR addresses start at PMIC_0) on the PF100 PMIC card and by SW5 of the first PMIC (PMIC_0_ADDR) on the PF8100 PMIC card. case SC_SUBSYS_A53: pmic_init(); if (pmic_card == PF100) { pmic_id[0] = PMIC_2_ADDR; pmic_reg[0] = SW2; *num_regs = 1; } else {/* PF8100_dual Card */ pmic_id[0] = PMIC_0_ADDR; pmic_reg[0] = PF8100_SW5; *num_regs = 1; } break; ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ The voltages of SoC resources that are powered by an external supply (AP cores, GPUs, etc...) are managed by board_set_voltage in the board.c file. The mapping of resource to power supply occurs in board_get_pmic_info as in the example above. Eight "board resources" (SC_R_BOARD_R0, ... SC_R_BOARD_R7) are available, these resources allow you to define components in your board that the SCU can manage, for instance a sensor on your board powered by one of the PMIC LDOs can be mapped to a board resource and the board.c file can be modified to power on/off the sensor as well as modifying its voltage. Modifying the voltage on a board resource can be either be done by modifying the voltage at board_trans_resource_power (see below) or if the voltage needs to change at run time the function board_set_control can be modified to change the voltage whenever a miscellaneous call (more details in the Miscellaneous Service 101) is made on that resource. For instance to change the voltage on SC_R_BOARD_R7 you would have the following case to board_set_control: case SC_R_BOARD_R7: if (ctrl == SC_C_VOLTAGE) { /* Example only PMIC_X_ADDR and PMIC_SUPPLY need to match an actual device */ pmic_interface.pmic_set_voltage(PMIC_X_ADDR, PMIC_SUPPLY, val, step); } else return SC_ERR_PARM; break;‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ The case above will be executed by the SCU every time the application calls the function below: sc_misc_set_control( ipc, SC_R_BOARD_R7, SC_C_VOLTAGE, voltage_val);‍‍‍‍‍‍‍‍ Powering on/off a board resource happens at board_trans_resource_power in the board.c file. For instance in NXP's validation board the PTN5150 on the board is managed through a board resource 0, and the power on/off is managed as follows: case BRD_R_BOARD_R0 : /* PTN5150 (use SC_R_BOARD_R0) */ if (pmic_ver.device_id == PF100_DEV_ID) { if (to_mode > SC_PM_PW_MODE_OFF) { pmic_interface.pmic_set_voltage(PMIC_2_ADDR, VGEN6, 3300, SW_RUN_MODE); pmic_interface.pmic_set_mode(PMIC_2_ADDR, VGEN6, VGEN_MODE_ON); } else { pmic_interface.pmic_set_mode(PMIC_2_ADDR, VGEN6, VGEN_MODE_OFF); } } else {/* PF8100_dual Card */ if (to_mode > SC_PM_PW_MODE_OFF) { pmic_interface.pmic_set_voltage(PMIC_1_ADDR, PF8100_LDO1, 3300, REG_RUN_MODE); pmic_interface.pmic_set_mode(PMIC_1_ADDR, PF8100_LDO1, RUN_EN_STBY_EN); } else { pmic_interface.pmic_set_mode(PMIC_1_ADDR, PF8100_LDO1, RUN_OFF_STBY_OFF); } } break;‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Whenever the function below is called from the application side the SCU will execute the code above: sc_pm_set_resource_power_mode(ipc, SC_R_BOARD_R0, SC_PM_PW_MODE_ON/OFF);‍‍‍‍‍‍‍‍ board_config_sc is used to mark resources that the SCU needs, such as the I2C module and pads used to communicate with the PMIC, any resource needed by the board.c functions to work should be marked in this function as not movable, for instance to keep the SCU I2C module the following line is added: rm_set_resource_movable(pt_sc, SC_R_SC_I2C, SC_R_SC_I2C, false);‍‍‍‍‍‍‍‍‍ The following pads are part of the SCU and the application will not be able to access them: - SC_P_SCU_PMIC_MEMC_ON - SC_P_SCU_WDOG_OUT - SC_P_PMIC_EARLY_WARNING - SC_P_PMIC_INT_B - SC_P_SCU_BOOT_MODE0 through SC_P_SCU_BOOT_MODE5 board_system_config is where early resource management occurs, this function is only called when the alt_config flag is set in the image, and it can create partitions and allocate resources to it. More details are found in the resource management service 101. board_get_pcie_clk_src defines the clock that the PCIe uses, it can be either BOARD_PCIE_PLL_EXTERNAL or BOARD_PCIE_PLL_INTERNAL. board_print is very useful to debug your changes the syntax is as follows: board_print(3, "Debug printout %d\n", val);‍‍‍‍‍‍‍ Where the first parameter is the Debug Level and from there on it works as a standard printf. The output will only be visible on the SCU debug output whenever the SCU is built with the corresponding debug level, in the case above the SCFW needs to be built as follows in order to see the output: make qm B=myBoard‍‍‍‍ DL=3 or higher (debug level goes from 0 to 5)‍‍‍‍‍‍‍   Usage examples The following utility shows how to make System Controller Firmware requests and provides a way to make such requests through command line interface on both QNX and Linux System Controller Firmware Command Line Utility for Linux and QNX   System Controller Firmware 101  
記事全体を表示
Revisions Revisions Description Details V1.0 Initial version   V1.2 Make a little update 1. Modify the path of the toolchain 2. Remove the command: make menuconfig 3. Modify the path of folder "out" in some commands   Hardware Requirement PC Host: Ubuntu for compiling, Windows for downloading and debugging Target: i.MX6ULL 14x14 EVK with LCD or HDMI TF card USB cables for console and download Power adapter Overview Ubuntu uses the same packaging management system (deb and apt) and with each development cycle pulls in the latest packages from Debian and then adapts them to Ubuntu specifics and adds more features and patches where necessary. They also push changes back to Debian and often developers are Ubuntu and Debian developers. Both of them have a nice UI and can install softwares easier than Yocto. The purpose of this doc is to install the Debian 8 Jessie Rootfs on NXP i.MX6ULL EVK Board. The doc contains several steps as following:    1. Download and compile the u-boot, kernel and dtb.    2. Get and modify the linaro rootfs.    3. Download all things to the SD card via MfgTool.    4. Run the Debian 8 Jessie in the board. Download and compile the u-boot, kernel and dtb.    a. Download the toolchain cd ~/ wget -c https://releases.linaro.org/components/toolchain/binaries/6.3-2017.02/arm-linux-gnueabihf/gcc-linaro-6.3.1-2017.02-i686_arm-linux-gnueabihf.tar.xz mkdir toolchain tar xvf gcc-linaro-6.3.1-2017.02-i686_arm-linux-gnueabihf.tar.xz -C toolchain/ --strip-components 1 export ARCH=arm export CROSS_COMPILE=../toolchain/bin/arm-linux-gnueabihf- mkdir out    b. Download and make the u-boot cd ~/ wget -c http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/snapshot/uboot-imx-imx_v2016.03_4.1.15_2.0.0_ga.tar.bz2 mkdir uboot-imx tar jxvf uboot-imx-imx_v2016.03_4.1.15_2.0.0_ga.tar.bz2 -C uboot-imx/ --strip-components 1 cd uboot-imx make mx6ull_14x14_evk_defconfig make    c. Download and make the kernel and dtb cd ~/ wget -c http://git.freescale.com/git/cgit.cgi/imx/linux-imx.git/snapshot/linux-imx-imx_4.1.15_2.0.0_ga.tar.bz2 mkdir linux-imx tar jxvf linux-imx-imx_4.1.15_2.0.0_ga.tar.bz2 -C linux-imx/ --strip-components 1 cd linux-imx vi arch/arm/configs/imx_v7_defconfig Add a line “CONFIG_FHANDLE=y” in the file to prevent the error when boot into rootfs. ****************************************************************************** Note: If you want to use the HDMI port instead of LCD to output the screen, you should modify the file /arch/arm/boot/dts/imx6ull-14x14-evk.dts to add a child node in &i2c2 : sii902x: sii902x@39 {         compatible = "SiI,sii902x";         pinctrl-names = "default";         interrupt-parent = <&gpio2>;         interrupts = <13 IRQ_TYPE_EDGE_FALLING>;         mode_str ="1280x720M@60";         bits-per-pixel = <16>;         reg = <0x39>;         status = "okay"; }; ****************************************************************************** make imx_v7_defconfig make -j4 zImage dtbs    d. Copy the u-boot, kernel and dtb to a folder cd ~/ sudo cp uboot-imx/u-boot.imx  out/ sudo cp linux-imx/arch/arm/boot/zImage  out/ sudo cp linux-imx/arch/arm/boot/dts/imx6ull-14x14-evk.dtb  out/ Get and modify the linaro rootfs. cd ~/ wget -c https://releases.linaro.org/debian/images/alip-armhf/16.04/linaro-jessie-alip-20160428-22.tar.gz mkdir rootfs tar xvf linaro-jessie-alip-20160428-22.tar.gz -C rootfs/ --strip-components 1 cd rootfs tar jcvf linaro-jessie-alip-20160428-22.tar.bz2 ./* sudo mv linaro-jessie-alip-20160428-22.tar.bz2  ../out Now the uboot, kernel, dtb and rootfs are ready in folder ~/out/!   Download all things to the SD card via MfgTool. Download the MfgTool in: http://www.nxp.com/products/automotive-products/microcontrollers-and-processors/arm-mcus-and-mpus/i.mx-application-processors/i.mx-6-processors/sabre-board-for-smart-devices-based-on-the-i.mx-6quad-applications-processors:RD-IMX6Q-SABRE?tab=Design_Tools_Tab Select the “IMX6_L4.1.15_2.0.0_MFG-TOOL” and download. Extract “L4.1.15_2.0.0-ga_mfg-tools.tar.gz” to Windows, and then extract again the “mfgtools-with-rootfs.tar.gz” to <your path>/mfgtools/. You should rename the files in the folder ~/out/ and copy to the path <your path>/mfgtools/Profiles/Linux/OS Firmware/files/ to replace the original files: u-boot.imx -> u-boot-imx6ull14x14evk_sd.imx zImage -> zImage imx6ull-14x14-evk.dtb -> zImage-imx6ull-14x14-evk.dtb linaro-jessie-alip-20160428-22.tar.bz2 -> rootfs_nogpu.tar.bz2 Switch the SW602 in i.MX6ULL EVK board to D1: off, D2: on, insert the TF card in slot SD2 and power on the board. Connect the board with PC by two micro-USB to USB cables(one is for downloading and another is for watching log) Finally, open the script “mfgtool2-yocto-mx-evk-sdcard-sd2.vbs” in the <your path>/mfgtools/. When the “HID-compliant device” shows then click “Start”.   If the processing is done, all things have been download to the board and you can go to the next step. Run the Debian 8 Jessie in the board. The following table shows the DIP switch settings for booting from the TF slot. Switch D1 D2 D3 D4 SW601 OFF OFF ON OFF SW602 ON OFF - -   Then power on the board and the logs will show in the serial console. Debian 8 will automatic login to root. ****************************************************************************** Note: If you want to use the HDMI port instead of LCD to output the screen, you should press any key when the log: Hit any key to stop autoboot shows and change the bootargs like following example: setenv bootargs console=ttymxc0,115200 init=/init video=mxcfb0:dev=hdmi,1280x720M@60,if=RGB24,bpp=32 video=mxcfb1:off video=mxcfb2:off video=mxcfb3:off vmalloc=256M androidboot.console=ttymxc0 consoleblank=0 androidboot.hardware=freescale cma=384M saveenv ****************************************************************************** When inputting “startx &” in serial console, the alip GUI will appear in the screen.   You can also use command ”apt-get” to install softwares(E.g. Firefox as following). ****************************************************************************** Note: If you have issues with “sudo” on user UID, need to execute the following commands: root@linaro-alip:~# chown root:root /usr/bin/sudo root@linaro-alip:~# chmod 4755 /usr/bin/sudo root@linaro-alip:~# chown root:root /usr/lib/sudo/sudoers.so root@linaro-alip:~# chown root:root /etc/sudoers root@linaro-alip:~# chown root:root /etc/sudoers.d/ root@linaro-alip:~# chown root:root /etc/sudoers.d/README   Note: If you have issues with “su” from user to root, need to execute the following commands: root@linaro-alip:~# chown root:root /bin/su root@linaro-alip:~# chmod 4755 /bin/su   Note: If you want to disable the warning window “Failed to apply network settings” after executing command “startx &”, you should deactive the Bluetooth: root@linaro-alip:~# sudo systemctl stop bluetooth.service root@linaro-alip:~# sudo systemctl disable bluetooth.service ******************************************************************************
記事全体を表示
  Test environment   i.MX8MP EVK LVDS0 LVDS-HDMI  bridge(it6263) Uboot2022, Uboot2023 Background   Some customers need show logo using LVDS panel. Current BSP doesn't support LVDS driver in Uboot. This patch provides i.MX8MPlus LVDS driver support in Uboot. If you want to connect it to LVDS panel , you need port your lvds panel driver like  simple-panel.c   Update [2022.9.19] Verify on L5.15.32_2.0.0  0001-L5.15.32-Add-i.MX8MP-LVDS-driver-in-uboot 'probe device is failed, ret -2, probe video device failed, ret -19' is caused by below code. It has been merged in attachment. // /* Only handle devices that have a valid ofnode */ // if (dev_has_ofnode(dev) && !(dev->driver->flags & DM_FLAG_IGNORE_DEFAULT_CLKS)) { // /* // * Process 'assigned-{clocks/clock-parents/clock-rates}' // * properties // */ // ret = clk_set_defaults(dev, CLK_DEFAULTS_PRE); // if (ret) // goto fail; // }   [2023.3.14] Verify on L5.15.71 0001-L5.15.71-Add-i.MX8MP-LVDS-support-in-uboot   [2023.9.12] For some panel with low DE, you need uncomment CTRL_INV_DE line and set this bit to 1. #include <linux/string.h> @@ -110,9 +111,8 @@ static void lcdifv3_set_mode(struct lcdifv3_priv *priv, writel(CTRL_INV_HS, (ulong)(priv->reg_base + LCDIFV3_CTRL_SET)); /* SEC MIPI DSI specific */ - writel(CTRL_INV_PXCK, (ulong)(priv->reg_base + LCDIFV3_CTRL_CLR)); - writel(CTRL_INV_DE, (ulong)(priv->reg_base + LCDIFV3_CTRL_CLR)); - + //writel(CTRL_INV_PXCK, (ulong)(priv->reg_base + LCDIFV3_CTRL_CLR)); + //writel(CTRL_INV_DE, (ulong)(priv->reg_base + LCDIFV3_CTRL_CLR)); }   Zhiming_Liu_0-1694493549149.png     [2024.5.15] If you are uing simple-panel.c, need use below patch to set display timing from panel to lcdif controller. diff --git a/drivers/video/simple_panel.c b/drivers/video/simple_panel.c index f9281d5e83..692c96dcaa 100644 --- a/drivers/video/simple_panel.c +++ b/drivers/video/simple_panel.c @@ -18,12 +18,27 @@ struct simple_panel_priv { struct gpio_desc enable; }; +/* define your panel timing here and + * copy it in simple_panel_get_display_timing */ +static const struct display_timing boe_ev121wxm_n10_1850_timing = { + .pixelclock.typ = 71143000, + .hactive.typ = 1280, + .hfront_porch.typ = 32, + .hback_porch.typ = 80, + .hsync_len.typ = 48, + .vactive.typ = 800, + .vfront_porch.typ = 6, + .vback_porch.typ = 14, + .vsync_len.typ = 3, +}; + @@ -100,10 +121,18 @@ static int simple_panel_probe(struct udevice *dev) return 0; } +static int simple_panel_get_display_timing(struct udevice *dev, + struct display_timing *timings) +{ + memcpy(timings, &boe_ev121wxm_n10_1850_timing, sizeof(*timings)); + + return 0; +} static const struct panel_ops simple_panel_ops = { .enable_backlight = simple_panel_enable_backlight, .set_backlight = simple_panel_set_backlight, + .get_display_timing = simple_panel_get_display_timing, }; static const struct udevice_id simple_panel_ids[] = { @@ -115,6 +144,7 @@ static const struct udevice_id simple_panel_ids[] = { { .compatible = "lg,lb070wv8" }, { .compatible = "sharp,lq123p1jx31" }, { .compatible = "boe,nv101wxmn51" }, + { .compatible = "boe,ev121wxm-n10-1850" }, { } };   [2024.7.23] Update patch for L6.6.23(Uboot2023) [2025.10.24] If you are facing 'Enable clock-controller@30380000 failed' error, add clocks in ccm driver. diff --git a/drivers/clk/imx/clk-imx8mp.c b/drivers/clk/imx/clk-imx8mp.c index 05a7d050be6..38497056344 100644 --- a/drivers/clk/imx/clk-imx8mp.c +++ b/drivers/clk/imx/clk-imx8mp.c @@ -181,6 +181,11 @@ static const char * imx8mp_media_mipi_phy1_ref_sels[] = {"clock-osc-24m", "sys_p static const char * imx8mp_media_disp_pix_sels[] = {"clock-osc-24m", "video_pll1_out", "audio_pll2_out", "audio_pll1_out", "sys_pll1_800m", "sys_pll2_1000m", "sys_pll3_out", "clk_ext4", }; + +static const char * imx8mp_media_ldb_sels[] = {"clock-osc-24m", "sys_pll2_333m", "sys_pll2_100m", + "sys_pll1_800m", "sys_pll2_1000m", + "clk_ext2", "audio_pll2_out", + "video_pll1_out", }; #endif static const char *imx8mp_dram_core_sels[] = {"dram_pll_out", "dram_alt_root", }; @@ -321,6 +326,8 @@ static int imx8mp_clk_probe(struct udevice *dev) #ifndef CONFIG_SPL_BUILD clk_dm(IMX8MP_CLK_MEDIA_MIPI_PHY1_REF, imx8m_clk_composite("media_mipi_phy1_ref", imx8mp_media_mipi_phy1_ref_sels, base + 0xbd80)); clk_dm(IMX8MP_CLK_MEDIA_DISP1_PIX, imx8m_clk_composite("media_disp1_pix", imx8mp_media_disp_pix_sels, base + 0xbe00)); + clk_dm(IMX8MP_CLK_MEDIA_DISP2_PIX, imx8m_clk_composite("media_disp2_pix", imx8mp_media_disp_pix_sels, base + 0x9300)); + clk_dm(IMX8MP_CLK_MEDIA_LDB, imx8m_clk_composite("media_ldb", imx8mp_media_ldb_sels, base + 0xbe00)); #endif clk_dm(IMX8MP_CLK_DRAM_ALT_ROOT, imx_clk_fixed_factor("dram_alt_root", "dram_alt", 1, 4)); clk_dm(IMX8MP_CLK_DRAM_CORE, imx_clk_mux2_flags("dram_core_clk", base + 0x9800, 24, 1, imx8mp_dram_core_sels, ARRAY_SIZE(imx8mp_dram_core_sels), CLK_IS_CRITICAL)); @@ -363,7 +370,9 @@ static int imx8mp_clk_probe(struct udevice *dev) clk_dm(IMX8MP_CLK_MEDIA_APB_ROOT, imx_clk_gate2_shared2("media_apb_root_clk", "media_apb", base + 0x45d0, 0, &share_count_media)); clk_dm(IMX8MP_CLK_MEDIA_AXI_ROOT, imx_clk_gate2_shared2("media_axi_root_clk", "media_axi", base + 0x45d0, 0, &share_count_media)); clk_dm(IMX8MP_CLK_MEDIA_DISP1_PIX_ROOT, imx_clk_gate2_shared2("media_disp1_pix_root_clk", "media_disp1_pix", base + 0x45d0, 0, &share_count_media)); + clk_dm(IMX8MP_CLK_MEDIA_DISP2_PIX_ROOT, imx_clk_gate2_shared2("media_disp2_pix_root_clk", "media_disp2_pix", base + 0x45d0, 0, &share_count_media)); clk_dm(IMX8MP_CLK_MEDIA_MIPI_PHY1_REF_ROOT, imx_clk_gate2_shared2("media_mipi_phy1_ref_root", "media_mipi_phy1_ref", base + 0x45d0, 0, &share_count_media)); + clk_dm(IMX8MP_CLK_MEDIA_LDB_ROOT, imx_clk_gate2_shared2("media_ldb_root_clk", "media_ldb", base + 0x45d0, 0, &share_count_media)); #endif clk_dm(IMX8MP_CLK_USDHC3_ROOT, imx_clk_gate4("usdhc3_root_clk", "usdhc3", base + 0x45e0, 0));   Update LVDS panel demo.    
記事全体を表示
Gingerbread (GB) Prepare the SD Card root/ : root file system (including init, init.rc, etc). Mounted at / system/:  Android system binary/libraries. Mounted at /system data/: Android data area. Mounted at /data recovery/: root file system when booting in "recovery" mode. Not directly used. Partition Description Type Size Header 8 BOOT raw area for bootloader and MEDIA DATA CACHE RECOVERY An example of partition a 4 GB SD card: Copy the system to SD card # sudo dd if=u-boot.bin of=/dev/sdx bs=1K skip=1 seek=1; sync # sudo dd if=u-boot-no-padding.bin of=/dev/sdx bs=1K seek=1; sync # sudo dd if=uImage of=/dev/sdx bs=1M seek=1; sync # sudo dd if=uramdisk.img of=/dev/sdx bs=1M seek=6; sync # sudo dd if=system.img of=/dev/sdx2; sync # sudo dd if=recovery.img of=/dev/sdx4; sync Ice Cream Sandwich (ICS)
記事全体を表示
-BACKGROUND       Since the release of i.MX8MQ and i.MX8M Mini, some customers have submitted questions about the design of USB2.0 for these two processors: due to the needs of the project, there is no need to use USB3.0 and USB TYPE-C. Therefore, these applications need to use a conventional USB2.0 interface design similar to i.MX6Q.       In order for customers with similar needs to complete the design smoothly, this document summarizes the answers to previous customer responses and draws two USB2.0 design schematics. At the same time, the i.MX expert hardware team member helped review these two drawings, and the i.MX Expert software team gave suggestions on software adjustments. -BEGIN       i.MX8MQ supports USB3.0 and is compatible with USB2.0, i.MX8M Mini only supports USB2.0, not USB3.0. In both development boards, the USB TYPE-C design scheme is used. We must remove the USB TYPE-C, PD chip and logic chip. At the same time, change the connector to MicroUSB and USB TYPE-A-F. No.1 Hardware Design 1. IOMUX list 2 、USB circuit design (1) USB Power & OC control I.MX8MM i.MX8MQ                                                 i.MX8MQ                                              i.MX8MQ [Comment] For i.MX8MQ -USB1 is configured as Dual Role Mode, USB1 OTG ID is used for detection -USB2 is configured as fixed Host mode, USB2 OTG ID is used for detection -i.MX8M Mini USB2.0                                        i.MX8M Mini                                     i.MX8M Mini [Comment] For i.MX8M Mini -USB1 is configured as Dual Role Mode, USB1 OTG ID is used for detection -USB2 is configured as fixed Host mode, USB2 OTG ID is used for detection (3) Additional description --About USB1_VBUS & USB2_VBUS of i.MX8M Mini          According to i.MX8M Mini datasheet, USB1_VBUS & USB2_VBUS allows 0~3.9V input. See below, please! Therefore, some customers have questioned the USB1_VBUS on the I.MX8M Mini-EVK. From the drawings, the external input voltage exceeds this range.          In fact, customers do not need to worry about this problem. There are internal voltage-dividing resistors on the USB1_VBUS and USB2_VBUS pins. As long as the customer refers to the design method on the I.MX8M Mini-EVK, the input voltage of these 2 pins can be guaranteed Inside. --About USBx OTG ID & USBx_ID (1) USBx_OTG_ID          USBx OTG ID is also called GPIO ID, which is the same as that of i.MX6Q. During the work process, the software changes the role between device and host according to the level of the ID pin from high to low or from low to high. (2)USBx_ID          USBx_ID is called USB PHY ID, which can also perform the same function as USBx OTG ID. (3)Using USBx_OTG_ID or USBx_ID          USBx_OTG_ID is recommended. But if customer wants to use USBx_ID, for i.MX8MQ, she can configure USB_CTL0_ADDR[utmiotg_iddig_sel] register. And for I.MX8M Mini, USBNC_n_CTRL2[DIG_ID_SEL] register. [Comment]          The configuration is got from reference manual of these 2 processors, due to no suitable board, this configuration is not validated on board. Customers can try it. (4) About Flashing Images to the Storage of Board          For an empty board or a board that requires an update image, we need to use the USB interface to program the image. At this time, we need the USB interface to work in device mode. For this, the ROM CODE inside the CPU will ensure that the USB works in device mode. No.2 Tuning Software 1.IOMUX According to the actual application, the signals to be used are multiplexed in the dts file. This step is relatively simple and will not be described here 2. Tuning USB configuration in u-boot / device tree For i.MX8M Mini & i.MX8MQ, i.MX Expert softer team gives the following suggestions, I quote their suggestions here:       Customer can try it by removing CONFIG_USB_TCPC in imx8mm_evk_defconfi and well as removing the typec_ptn5110_1/2 dependencies in the fsl-imx8mm-evk.dts. The uboot does check the state of the Type C ICs and crash or gets stuck if they are removed. --i.MX8M Mini U-BOOT:  CONFIG_USB_TCPC=n Device Tree: &usbotg1 {     status = "okay"; }; &usbotg2 {     status = "okay"; --------------------------------------------------------- --i.MX8MQ --u-boot CONFIG_USB_TCPC=n --Node of Device tree &usb_dwc3_0 {              status = "okay";              /*extcon = <&typec_ptn5100>;*/              dr_mode = "otg";              hnp-disable;              srp-disable;              adp-disable;              maximum-speed = "high-speed"; }; ---------------------------------------------- -END [Comment] If you encounter problems while using this document, please submit a ticket to me. Here are the steps to submit a ticket: 1. Open below SUPPORT site, click blue "Go to Tickets" in the middle. http://www.nxp.com/support/support:SUPPORTHOME 2.Then you will be requested to Login, if you have no an account, please first Register with your business email. 3.After login, please "Create New Cases" button in the middle, then you can submit your question. NXP TIC team Weidong Sun 2020/3/30
記事全体を表示
This is a series of documents that intend to help you grasp he concept of the System Controller Unit (SCU) / System Controller Firmware (SCFW).    Getting started Power management service  Resource management service Pad configuration service Timer service Miscellaneous service   Other Useful resources: https://community.nxp.com/docs/DOC-344684 (2019) i.MX 8 System Controller Unit and System Controller Firmware Overview (2018) Clusters & Infotainment: Introduction to the i.MX 8 System Controller Unit (2017 Slightly outdated, for correct boot sequence go to Chapter 5 System Boot of the Reference Manual) System Controller Firmware command line utility for QNX and Linux You can get the latest System Controller Firmware Porting kit from the i.MX Software and development webpage: The porting kit contains documentation and allows you to build the SCFW from source and do modifications to the board dependent parts: The API documents explain the System Controller Firmware API syntax and it has a section for introduction and general overview of the system. The port document contains information on what each board component function does and the overall process of porting the SCFW.
記事全体を表示
In case you missed our recent webinar, you can check out the slides and comment below with any questions.
記事全体を表示
Please find attached preliminary errata on the two i.MX security vulnerabilities: ERR010872 – Secure Boot Vulnerability when using the Serial Downloader (CVE-2017-7936) ERR010873 – Secure Boot Vulnerability when Authenticating a Certificate (CVE-2017-7932) These are preliminary versions of the errata. Final versions will be incorporated into the Chip Errata (CE) document for each impacted device at a later date. Customer Notification A Customer Information Notification(CIN 201704026I) with the affected part numbers has been sent out to impacted users. Updated Silicon Sample Availability An Advanced Product Change Notification (A-PCN 201705010A), that provides updated silicon availability information has also been sent out to impacted users. Mitigations An Engineering Bulletin (EB00854) on possible mitigation strategies is available to impacted users and can be requested through your NXP field support team or distributor.  Further Questions or Support Please contact your NXP support representative or enter a support request for further questions on this topic indicating the part number and the mass production start date.
記事全体を表示
Hi,          Here is the document about how to enable spread spectrum in imx6.   best regards Jack
記事全体を表示
Bad and Ugly gstreamer plugins has their own special licensing, so it cannot be released formally inside any tarball. (I do not understand it deeply, if you want more info, please go to GStreamer: Licensing advice) But you can add it on your own image, and you only need to change the local.conf Please, add the following code to your local.conf: LICENSE_FLAGS_WHITELIST = "commercial" COMMERCIAL_AUDIO_PLUGINS ?= " \ gst-plugins-ugly-mad \ gst-plugins-ugly-mpegaudioparse \ " COMMERCIAL_VIDEO_PLUGINS ?= " \ gst-plugins-ugly-mpeg2dec \ gst-plugins-ugly-mpegstream \ gst-plugins-bad-mpegvideoparse \ " CORE_IMAGE_EXTRA_INSTALL += " \ packagegroup-fsl-gstreamer \ gst-plugins-base-videotestsrc \ gst-plugins-bad-fbdevsink \ gst-ffmpeg alsa-utils \ gst-plugins-good-isomp4 \ " Please, note that this will not install *every* plugin from ugly or bad. It will only install the plugins from the list. Go to Yocto Training - HOME Go to Task #8 - Build kernel manually using created toolchain
記事全体を表示
This article describe i.MX8MP normal HAB security boot, and server/client mode. For server/client mode, it is based on customer requirement, because private is stored in server can't be accessed.
記事全体を表示
A tutorial on 'Freescale Yocto Project'. Source code is located here NOTE: When doing 'repo init -u .... -b <LATEST_STABLE_BRANCH_NAME>', make sure you are using the latest stable branch (dora is the latest when writing this note)
記事全体を表示
There is a very quick way to find out which line cause the crash in logcat, Generally, if some native service crashes, look in the crash log in logcat like this: I/DEBUG ( 2253): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** I/DEBUG ( 2253): Build fingerprint: 'freescale/sabresd_6dq/sabresd_6dq:4.0.4/R13.3-rc3/eng.b18293.20120710.124535:user/test-keys' I/DEBUG ( 2253): pid: 3043, tid: 3080 >>> /system/bin/mediaserver <<< I/DEBUG ( 2253): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr deadbaad I/DEBUG ( 2253): r0 deadbaad r1 00000001 r2 a0000000 r3 00000000 I/DEBUG ( 2253): r4 00000000 r5 00000027 r6 00bfd370 r7 40c1ef18 I/DEBUG ( 2253): r8 00004349 r9 00000000 10 000003f5 fp 00000000 I/DEBUG ( 2253): ip ffffffff sp 418876a0 lr 400ff1b5 pc 400fb91c cpsr 60000030 I/DEBUG   ( 2253):  ip ffffffff  sp 418876a0  lr 400ff1b5  pc 400fb91c  cpsr 60000030 We can see it’s possibly related to some code that we debugged, but don’t know exactly where or which line of code, Android has a tool to convert this log to a more precise log. As a quick example, if you got this crash in logcat: F/libc ( 3043): Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1) I/DEBUG ( 2253): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** I/DEBUG ( 2253): Build fingerprint: 'freescale/sabresd_6dq/sabresd_6dq:4.0.4/R13.3-rc3/eng.b18293.20120710.124535:user/test-keys' I/DEBUG ( 2253): pid: 3043, tid: 3080 >>> /system/bin/mediaserver <<< I/DEBUG ( 2253): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr deadbaad I/DEBUG ( 2253): r0 deadbaad r1 00000001 r2 a0000000 r3 00000000 I/DEBUG ( 2253): r4 00000000 r5 00000027 r6 00bfd370 r7 40c1ef18 I/DEBUG ( 2253): r8 00004349 r9 00000000 10 000003f5 fp 00000000 I/DEBUG ( 2253): ip ffffffff sp 418876a0 lr 400ff1b5 pc 400fb91c cpsr 60000030 I/DEBUG ( 2253): d0 3e4ccccd00000000 d1 7e37e43c3e4ccccd I/DEBUG ( 2253): d2 0000004042000000 d3 4200000000000000 I/DEBUG ( 2253): d4 3ff0000000000000 d5 3ff0000000000000 I/DEBUG ( 2253): d6 4220000041300000 d7 3e4ccccd3e4ccccd I/DEBUG ( 2253): d8 000000000000685d d9 00000000010bee7c I/DEBUG ( 2253): d10 0000000000000000 d11 0000000000000000 I/DEBUG ( 2253): d12 0000000000000000 d13 0000000000000000 I/DEBUG ( 2253): d14 0000000000000000 d15 0000000000000000 I/DEBUG ( 2253): d16 0000000000000000 d17 3ff0000000000000 I/DEBUG ( 2253): d18 7e37e43c8800759c d19 0000000000000000 I/DEBUG ( 2253): d20 bfe0000000000000 d21 405443dab91ed79f I/DEBUG ( 2253): d22 0000000000000000 d23 3f40624dd2f1a9fc I/DEBUG ( 2253): d24 7fff80007fff0000 d25 3f6328e1cb8c85e0 I/DEBUG ( 2253): d26 0000000000000000 d27 0000000000000000 I/DEBUG ( 2253): d28 0000000000000000 d29 0000000000000000 I/DEBUG ( 2253): d30 0000000000000000 d31 0000000000000000 I/DEBUG ( 2253): scr 28000010 I/DEBUG ( 2253): I/DEBUG ( 2253): #00 pc 0001791c /system/lib/libc.so I/DEBUG ( 2253): #01 pc 00003f3e /system/lib/libcutils.so (__android_log_assert) I/DEBUG ( 2253): #02 pc 0006c436 /system/lib/libstagefright.so (_ZN7android8OMXCodec16drainInputBufferEPNS0_10BufferInfoE) I/DEBUG ( 2253): #03 pc 0006cbc2 /system/lib/libstagefright.so (_ZN7android8OMXCodec17drainInputBuffersEv) I/DEBUG ( 2253): #04 pc 0006f570 /system/lib/libstagefright.so (_ZN7android8OMXCodec4readEPPNS_11MediaBufferEPKNS_11MediaSource11ReadOpti onsE) I/DEBUG ( 2253): #05 pc 00051aba /system/lib/libstagefright.so (_ZN7android11AudioPlayer5startEb) I/DEBUG ( 2253): #06 pc 0005411e /system/lib/libstagefright.so (_ZN7android13AwesomePlayer18startAudioPlayer_lEb) I/DEBUG ( 2253): #07 pc 0005554a /system/lib/libstagefright.so (_ZN7android13AwesomePlayer6play_lEv) I/DEBUG ( 2253): #08 pc 000558e0 /system/lib/libstagefright.so (_ZN7android13AwesomePlayer4playEv) I/DEBUG ( 2253): #09 pc 00027f4e /system/lib/libmediaplayerservice.so (_ZN7android17StagefrightPlayer5startEv) I/DEBUG ( 2253): #10 pc 00024dda /system/lib/libmediaplayerservice.so (_ZN7android18MediaPlayerService6decodeEixxPjPiS2_) I/DEBUG ( 2253): I/DEBUG ( 2253): code around pc: I/DEBUG ( 2253): 400fb8fc 4623b15c 2c006824 e026d1fb b12368db \.#F$h.,..&..h#. I/DEBUG ( 2253): 400fb90c 21014a17 6011447a 48124798 24002527 .J.!zD.`.G.H'%.$ I/DEBUG ( 2253): 400fb91c f7f47005 2106ee22 eebef7f5 f04fa901 .p.."..!......O. I/DEBUG ( 2253): 400fb92c 460a5380 93032006 94029401 ea7af7f5 .S.F. ........z. I/DEBUG ( 2253): 400fb93c 4622a905 f7f52002 f7f4ea84 2106ee0e .."F. .........! I/DEBUG ( 2253): I/DEBUG ( 2253): code around lr: I/DEBUG ( 2253): 400ff194 41f0e92d 4c0c4680 447c2600 68a56824 -..A.F.L.&|D$h.h I/DEBUG ( 2253): 400ff1a4 e0076867 300cf9b5 dd022b00 47c04628 gh.....0.+..(F.G I/DEBUG ( 2253): 400ff1b4 35544306 37fff117 6824d5f4 d1ee2c00 .CT5...7..$h.,.. I/DEBUG ( 2253): 400ff1c4 e8bd4630 bf0081f0 00028346 41f0e92d 0F......F...-..A I/DEBUG ( 2253): 400ff1d4 9004b086 f602fb01 460c461f 46154814 .........F.F.H.F I/DEBUG ( 2253): I/DEBUG ( 2253): memory map around addr deadbaad: I/DEBUG ( 2253): becef000-bed10000 [stack] I/DEBUG ( 2253): (no map for address) I/DEBUG ( 2253): ffff0000-ffff1000 [vectors] I/DEBUG ( 2253): You can see it’s related to which lib, but don’t know which line. So, let’s go to your source code, for example: mydroid; after do $. build/envsetup.sh$ lunch sabresd_6dp-eng $ development/scripts/stack Then you have a prompt: Reading native crash info from stdin The you just copy all the crash log in above to this prompt. And then Key in EOF (CTRL+D) in this prompt. You will get output like this: Reading symbols from /home/b33651/proj/ics/out/target/product/sabresd_6dq/symbols pid: 3043, tid: 3080 >>> /system/bin/mediaserver <<< signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr deadbaad   r0 deadbaad r1 00000001 r2 a0000000 r3 00000000   r4 00000000 r5 00000027 r6 00bfd370 r7 40c1ef18   r8 00004349 r9 00000000 10 000003f5 fp 00000000   ip ffffffff sp 418876a0 lr 400ff1b5 pc 400fb91c Stack Trace:   RELADDR FUNCTION FILE:LINE   0001791c __libc_android_abort+92 /home/b33651/proj/ics/bionic/libc/unistd/abort.c:82   00003f3e __android_log_assert+94 /home/b33651/proj/ics/system/core/liblog/logd_write.c:246   0006c436 android::OMXCodec::drainInputBuffer(android::OMXCodec::BufferInfo*)+138 /home/b33651/proj/ics/frameworks/base/media/libstagefright/OMXCodec.cpp:3181   0006cbc2 android::OMXCodec::drainInputBuffers()+102 /home/b33651/proj/ics/frameworks/base/media/libstagefright/OMXCodec.cpp:3125   0006f570 android::OMXCodec::read(android::MediaBuffer**, android::MediaSource::ReadOptions const*)+136 /home/b33651/proj/ics/frameworks/base/media/libstagefright/OMXCodec.cpp:4020   00051aba android::AudioPlayer::start(bool)+134 /home/b33651/proj/ics/frameworks/base/media/libstagefright/AudioPlayer.cpp:93   0005411e android::AwesomePlayer::startAudioPlayer_l(bool)+70 /home/b33651/proj/ics/frameworks/base/media/libstagefright/AwesomePlayer.cpp:953   0005554a android::AwesomePlayer::play_l()+202 /home/b33651/proj/ics/frameworks/base/media/libstagefright/AwesomePlayer.cpp:888   000558e0 android::AwesomePlayer::play()+20 /home/b33651/proj/ics/frameworks/base/media/libstagefright/AwesomePlayer.cpp:837   00027f4e android::StagefrightPlayer::start()+6 /home/b33651/proj/ics/frameworks/base/media/libmediaplayerservice/StagefrightPlayer.cpp:90   00024dda android::MediaPlayerService::decode(int, long long, long long, unsigned int*, int*, int*)+206 /home/b33651/proj/ics/frameworks/base/media/libmediaplayerservice/MediaPlayerService.cpp:1428 So, you get more reason logs. Note: The Android directory must have built once. The crash log better aligns with your Android build environment.
記事全体を表示
The purpose of this document is to provide supportive information for selection of suitable LPDDR4, DDR4 and DDR3L devices that are supported by i.MX 8M family of processors to aid project feasibility assessment capabilities of customers that are evaluating the SoCs for usage in their products.  It is strongly recommended to consult with NXP and the memory vendor the final choice of the memory part number to ensure that the device meets all the compatibility, availability, longevity and pricing requirements. Please note that some of the LPDDR4 devices may not support operation at low speeds and in addition, DQ ODT may not be active, which can impact signal integrity at these speeds. If low speed operation is planned in the use case, please consult with the memory vendor the configuration aspects and possible customization of the memory device so correct functionality is ensured. In all cases, it is strongly recommended to follow the DRAM layout guidelines outlined in the NXP Hardware Developer's Guides for the specific SoCs available on NXP.com Memory devices with binary densities (e.g., 1 GB, 2 GB, 4 GB) are preferred because they simplify memory management by aligning with system addressing schemes and reducing software complexity. For any questions related to specific DRAM part numbers please contact the respective DRAM vendor. For any questions regarding the i.MX SoC please contact your support representative or enter a support ticket.  LPDDR4 - maximum supported densities Please note that the SoCs only support memory devices that support either the LPDDR4 mode or support both LPDDR4 and LPDDR4X modes. Memory devices that support only the LPDDR4X mode are not supported. SoC Max data bus width Maximum density Assumed memory organization Notes i.MX 8M Quad 32-bit 32Gb/4GB dual rank, dual-channel  device with 16-row addresses (R0-R15) 1, 2, 4 i.MX 8M Mini  32-bit 64Gb/8GB dual rank, dual-channel  device with 17-row addresses (R0-R16) 1, 2 i.MX 8M Nano  16-bit 32Gb/4GB dual rank, single-channel  device with 17-row addresses (R0-R16) 1, 2, 3, 12 i.MX 8M Plus  32-bit 64Gb/8GB dual rank, dual-channel  device with 17-row addresses (R0-R16)  1, 2   LPDDR4 - list of validated memories Please note that the validation process is an ongoing effort - regular updates of the table are expected. Please contact NXP if a specific vendor or configuration is required. SoC Density Memory Vendor Validated Memory Part#  Notes i.MX 8M Quad  24Gb/3GB    Micron MT53B768M32D4NQ-062 WT:B  15 32Gb/4GB Micron MT53D1024M32D4DT-046 AAT:D  14 4Gb/512MB ISSI IS43LQ16256B-062BLI  5, 14 8Gb/1GB ISSI IS43LQ32256B-062BLI  5, 14 i.MX 8M Mini 16Gb/2GB Micron MT53D512M32D2DS-053 WT:D  15 16Gb/2GB    ESMT M56Z16G32512A-SMBIG 5, 14 32Gb/4GB Micron MT53E1G32D2FW-046 WT:A  5, 14 64Gb/8GB Micron MT53E2G32D4DT-046 AIT:A  5, 14 64Gb/8GB Micron MT53E2G32D4DE-046 AUT:C 5, 14 32Gb/4GB Intelligent Memory IMBG32L4KBB 5,14 32Gb/4GB Kingston B3221PM3BDGUI -U 5 16Gb/2GB Kingston D1621PM4CDGVIW-U related PNs also covered by the test: D1621PM4CDGUI-U D1621PM4CDGUIW-U D1621PM4CDGVI-U 5 i.MX 8M Nano  16Gb / 2GB  Kingston C1612PC2WDGTKR-U  15 16Gb / 2GB  Kingston  D1611PM3BDGUI-U 5,14 32Gb / 4GB Micron MT53E2G32D4DT-046 AIT:A  5, 13, 15 16Gb / 2GB Intelligent Memory  IMAG16L4KBB 5,14 4Gb / 512MB Nanya NT6AN256M16AV-J2 5,14 4Gb / 512MB  Winbond W66CP6RBQAHJ 5,14 8Gb / 1GB ISSI IS43LQ16512A-053BLI 5,14 8Gb / 1GB  Micron MT53D512M32D2DS-053 WT:D 13, 15   i.MX 8M Plus       48Gb/6GB  Micron MT53E1536M32D4DT-046 WT:A  15 64Gb/8GB  Micron MT53E2G32D4DE-046 AUT:C  5, 14 32Gb/4GB Samsung K4FBE3D4HB-KHCL  5, 14 32Gb/4GB Kingston B3221PM3BDGVIW-U 5, 14 64Gb/8GB Kingston Q6422PM3BDGVK-U  5, 14 8Gb/1GB Winbond W66DP2RQQAHJ  5, 14 32Gb/4GB ISSI IS46LQ32K01S2A-046BLA2 5, 14 16Gb/2GB ISSI IS46LQ32512A-046BLA3 5 32Gb/4GB ISSI IS43LQ32K01S2A-046BLI 5, 14 32Gb/4GB IM IMBG32LK4BBG-046I 5, 14 32Gb/4GB Nanya NT6AN1024F32AV-J2 5, 14 32Gb/4GB Nanya NT6AT1024T32AV-J1 5   LPDDR4 - list of incompatible devices Given the limitations mentioned in this document, the following memory devices were identified as incompatible with the particular SoCs as detailed in the following table:   Memory Vendor Memory Part# Density Incompatible SoCs Incompatibility reason Samsung K4FHE3S4HA-KU(H/F)CL 24Gb/3Gb i.MX 8M Quad  The memory device requires 17th row address bit to function. Samsung K4UHE3S4AA-KU(H/F)CL K4UJE3D4AA-KU(H/F)CL 24Gb/3Gb 48Gb/6GB i.MX 8M Quad i.MX 8M Mini i.MX 8M Nano i.MX 8M Plus The memory device only supports the LPDDR4X mode. Samsung K4FCE3Q4HB-KU(H/F)CL K4UCE3Q4AB-KU(H/F)CL 64Gb/8GB i.MX 8M Quad i.MX 8M Mini i.MX 8M Nano i.MX 8M Plus A byte mode memory device. The memory device only supports the LPDDR4X mode.    DDR4 - maximum supported densities SoC Max data bus width Maximum density Assumed memory organization Notes i.MX 8M Quad  32-bit 32Gb/4GB x16, 16Gb device with 1 bank group address, 17-row addresses and 10 column addresses 1, 6 i.MX 8M Mini  32-bit 64Gb/8GB x16, 16Gb device with 1 bank group address, 17-row addresses and 10 column addresses 1, 7 i.MX 8M Nano  16-bit 64Gb/8GB x8, 16Gb device with 2 bank group addresses, 17-row addresses and 10 column addresses 1, 8 i.MX 8M Plus  32-bit 64Gb/8GB x16, 16Gb device with 1 bank group address, 17-row addresses and 10 column addresses 1, 7   DDR4 - list of validated memories Please note that the validation process is an ongoing effort - regular updates of the table are expected. Please contact NXP if a specific vendor or configuration is required.   SoC Density Memory Vendor Validated Memory Part#  Notes i.MX 8M Quad 32Gb/4GB Micron 4x MT40A512M16JY-083EAAT  15 i.MX 8M Mini  16Gb/2GB Micron 2x MT40A512M16LY-075:E  15 i.MX 8M Nano 16Gb/2GB Micron 1x MT40A1G16RC-062E:B  15 8Gb/1GB Rayson 1x RS512M16Z2DD-62DT 14 8Gb/1GB UniIC SCB12Q8G160BF-06SI 14 i.MX 8M Plus 64Gb/8GB Micron 4x MT40A1G16RC-062E:B  15 16Gb/2GB Nanya NT5AD512M16C4-JRI  14   DDR3L - maximum supported densities SoC Max data bus width Maximum density Assumed memory organization Notes i.MX 8M Quad  32-bit 32Gb/4GB x16, 8Gb device with 16-row addresses and 10 column addresses 1, 9 i.MX 8M Mini  32-bit 64Gb/8GB x8, 8Gb device with 16-row addresses and 11 column addresses 1, 10 i.MX 8M Nano  16-bit 32Gb/4GB x8, 8Gb device with 16-row addresses and 11 column addresses 1, 11 i.MX 8M Plus  i.MX 8M Plus does not support DDR3L   DDR3L - list of validated memories Please note that the validation process is an ongoing effort - regular updates of the table are expected. Please contact NXP if a specific vendor or configuration is required. SoC Density Vendor Validated Memory Part#  Notes i.MX 8M Quad  16Gb/2GB Micron 4x MT41K256M16TW-107 AAT  14 i.MX 8M Mini  16Gb/2GB Micron 4x MT41K256M16TW-107 AAT  14              i.MX 8M Nano 8Gb/1GB Micron MT41K512M16VRN-107  15   Note 1: The numbers are based purely on the IP vendor documentation for the DDR Controller and the DDR PHY, on the settings of the implementation parameters chosen for their integration into the SoC, and on the JEDEC standards JESD209-4/JESD209-4A (LPDDR4), JESD279-4/JESD279-4A (DDR4), and JESD79-3E/JESD79-3F/JESD79-3-1A (DDR3/DDR3L). Therefore, they are not backed by validation, unless said otherwise and there is no guarantee that an SoC with the specific density and/or desired internal organization is offered by the memory vendors. Should the customers choose to use the maximum density and assume it in the intended use case, they do it at their own risk. Note 2: Byte-mode LPDDR4 devices (x16 channel internally split between two dies, x8 each) of any density are not supported therefore, the numbers are applicable only to devices with x16 internal organization (referred to as "standard" in the JEDEC specification). Note 3: The memory vendors often do not offer so many variants of single-channel memory devices. As an alternative, a dual-channel device with only one channel connected may be used. For example: A dual-rank, single-channel device with 16-row address bits has a density of 16Gb. If such a device is not available at the chosen supplier, a dual-rank, dual-channel device with 16-row address bits can be used instead. This device has a density of 32 Gb however since only one channel can be connected to the SoC, only half of the density is available (16 Gb). Usage of more than one discrete memory chips to overcome market constraints is not supported since only point-to-point connections are assumed for LPDDR4. Note 4: Devices with 17-row addresses (R0-R16) are not supported by the DDR Controller Note 5: The memory part number did not undergo full JEDEC verification however, it passed all functional testing items. Note 6: The density can be achieved by connecting 2 single-rank discrete devices with one 16Gb die each. Since the SoC supports x8 devices and also has connectivity for a second rank, usage of more discrete devices is possible. However, this advantage cannot be used to get higher density since this SoC has only 32Gb/4GB of address space dedicated for the DDR. Two x16 16Gb devices giving 32Gb/4GB in total is, therefore, the optimal choice that balances the maximum density aspects, the signal integrity aspects (only two discrete devices used), and bandwidth aspects (full data bus width used). Note 7: The density can be achieved by connecting 4 single rank discrete devices with one 16Gb die each, 2 devices connected to each chip select. Since the SoC supports x8 devices, the usage of more discrete devices is possible. However, this advantage cannot be used to get higher density since this SoC has only 64Gb/8GB of address space dedicated for the DDR. Four x16 16Gb devices giving 64Gb/8GB in total is the optimal choice that balances the maximum density aspects, the signal integrity aspects (only four discrete devices used), and the bandwidth aspects (full data bus width used). Note 8: The density can be achieved by connecting 4 single rank discrete devices with one 16Gb die each, 2 devices connected to each chip select.  Note 9: The density can be achieved by connecting 4 single rank discrete devices with one 8Gb die each, 2 devices connected to each chip select, or by connecting 2 dual rank discrete devices with two 8Gb dies each. Since the SoC supports x8 devices, the usage of more discrete devices is possible. However, this advantage cannot be used to get higher density since this SoC has only 32Gb/4GB of address space dedicated for the DDR. Four x16 8Gb devices giving 32Gb/4GB in total is, therefore, the optimal choice that balances the maximum density aspects, the signal integrity aspects (four discrete devices used), and bandwidth aspects (full data bus width used). Note 10: The density can be achieved by connecting 8 single rank discrete devices with one 8Gb die each, 4 devices connected to each chip select or by connecting 4 dual rank discrete devices with two 8Gb dies each. Note that the first option significantly exceeds the number of devices used on the validation board (4 discrete devices) therefore, it is not guaranteed that the i.MX would be able to drive the signals with margin to the required voltage levels due to increased loading on the traces. A significant effort would be required in terms of PCB layout and signal integrity analysis. Practically, it is not recommended to use more than 4 discrete DDR3L devices. This corresponds to the maximum density of 32Gb/4GB in the case of the single rank devices containing one 8Gb die or 64Gb/8GB in case of the dual-rank devices, each containing two 8Gb dies. Note 11: The density can be achieved by connecting 4 single rank discrete devices with one 8Gb die each, 2 devices connected to each chip select or by connecting 2 dual rank discrete devices with two 8Gb dies each. Note 12: For single-channel (x16) memory devices, the current maximum available density in the market is 16Gb/2GB (Q1 2022). Note 13: Only one channel of the device (and hence, half of its density) was utilized due to the reduced data bus width (x16) of the SoC. Note 14: Part is active. Reviewed Jan 2026 Note 15: Part will either EoL or is not recommended for new designs by the respective vendor.   Additional Links https://community.nxp.com/t5/iMX-and-Vybrid-Support/i-MX-8-8X-8XL-maximum-supported-LPDDR4-and-DDR3L-densities/ta-p/1152715           
記事全体を表示
Case Description There is requirement need to control(enable/disable) regulator from user space. Regulator userspace-consumer driver can help. But it doesn’t support device tree. A patch for handling device tree is needed. linux/drivers/regulator/userspace-consumer.c    
記事全体を表示
The reference code is based on L4.14.78 GA1.0.0 BSP and M4 SDK 2.5.1.  It is tested on iMX8QXP MEK board, and it should also work for iMX8QM board. In L4.14.78 GA1.0.0 BSP, MU_5 is used for RPMSG between M4 FreeRTOS and A35 Linux, SC_R_MU_5B is M4 side and SC_R_MU_5A is A35 side. In linux side, we used the "imx_rpmsg_tty.ko" for this test, this driver is built as module in default BSP. Case 1: M4 wake up A35. Apply "L4.14.78_rpmsg_wakeup.patch" to linux kernel, this patch will enable the RPMSG wake up feature. "rpmsg_lite_pingpong_rtos.tar.bz2" is the M4 side test code. After booted the board with Linux + M4 rpmsg software, run followed test commands: 1. In A35 UART side, run followed commands:     # echo enabled > /sys/bus/platform/devices/90000000.rpmsg/power/wakeup     # insmod ./imx_rpmsg_tty.ko     # /unit_tests/Remote_Processor_Messaging/mxc_mcc_tty_test.out /dev/ttyRPMSG30 115200 R 100 1000 &     # echo deadbeaf > /dev/ttyRPMSG30     # echo mem > /sys/power/state 2. M4 UART side:    After run "echo deadbeaf > /dev/ttyRPMSG30" from Linux side, it will show "Got ping..." and wait there, after run A35 suspend commane "echo mem > /sys/power/state", Linux suspends. Then from M4 UART side, press "c" key, it will send RPMSG to A35 and wake up A35 Linux. Case 2: A35 wake up M4. "power_mode_switch_rpmsg_wakeup.tar.bz2" is the M4 side test code, After booted the board with Linux + M4 rpmsg software, the M4 UART will wait for A35 RPMSG driver ready. Test commands: 1. In A35 UART side, run followed commands to make RPMSG driver ready:     # insmod ./imx_rpmsg_tty.ko     # /unit_tests/Remote_Processor_Messaging/mxc_mcc_tty_test.out /dev/ttyRPMSG30 115200 R 100 1000 &     # echo deadbeaf > /dev/ttyRPMSG30 2. Now M4 UART shows ping pong messages to make sure RPMSG is ready. Now M4 is in power switch menu, select VLLS power mode in M4 UART:      Press  H for enter: VLLS     - Very Low Leakage Stop mode     ... ...      Press R for RPMSG. After press "R" key in M4 UART, M4 will print "Send a RPMSG message to wake up" and goto suspend mode. 3. Wake up M4 from A35 side, send any data to RPMSG:     # echo deadbeaf > /dev/ttyRPMSG30 M4 resumed and goto power switch menu again. SDK folder to compile the two M4 sample code: SDK/boards/mekmimx8qx/multicore_examples/rpmsg_lite_pingpong_rtos SDK/boards/mekmimx8qx/demo_apps/power_mode_switch
記事全体を表示