as we known, mx6sx doesn’t have IPU, if we need to resize, rotation or blending…., we can use pxp module, this part, we talk about rotation for example. We also can use GPU for rotation, but in imx6sx, the number after 6sx in the part number stands for the chip including gpu or not, the number 4 and 3 mean mx6sx has gpu, like MCIMX6X3EVN10AB. and 1,2 and 3 mean mx6sx doesn’t have gpu, like MCIMX6X2EVN10AB for gpu, we know we can use xrander to rotate ,in this part, we focus on pxp rotation the stesp: enable pxp in the kernel:               $ bitbake -c menuconfig linux-imx, then choose Device Drivers ---> DMA Engine support ---> [*] MXC PxP support [*] MXC PxP Client Device 2) download the built image from tmp/deploy/images/imx6sxsabresd 3) boot up the board, then you can find the pxp_v4l2_test.out in the unit test 4) use the command as below to test the rotation: ./pxp_v4l2_test.out -sx 480 -sy 272 -res 352:240 -a 100  -r 90 fb-352x240.yuv BLANK   Sx and sy is resolution for display, -res is resolution for image or video. -r is for rotaion, you can set 0,90,180 and 270 for it. I attach the fb-352x240.yuv for testing

For imx8QM, The manufacture mode is supported on SD2 which is powered by LDO2 of PMIC2 on MEK board. LDO2 of PMIC2 on MEK board is OFF by default. (LDO2 of PMIC1 is on by default) So manufacture mode is NOT working on the imx8QM MEK board. the solution would be: 1. schematic change Exchange the power supply(VCC_LDO_SD) and USDHC_VSELECT signal of SD2 and SD1. between PMIC2 (U23) and PMIC 1(U10). so that, the VCC_LDO_SD2) and USDHC2_VSELECT will be located on where VCC_LDO_SD1) and USDHC1_VSELECT are origonally.  and VCC_LDO_SD1 and USDHC1_VSELECT will be located on where VCC_LDO_SD2) and USDHC2_VSELECT are origonally.  SD1 will no longer be supported as the boot resource, instead SD2 will be. anyway you still can connect a WIFI to SD1 , becasue the power supply can be turned on after software booting up. 2. Modify the default fuse of PMIC, whcih is to enable LDO2 of PMIC2 by default.     please contact your local FAE and Sales for this.  we may add notification in the reference schematic and HW development guild in the future.

The decommission of the git.freescale.com has caused some problems to BSPs dependent on packages stored in this repository. All contents on git.freescale.com have been moved to one of three locations: NXP · GitHub  (github.com/NXP) NXP Micro · GitHub  (github.com/NXPMicro) https://source.codeaurora.org/external/imx/   In the case of some older Android BSP this causes an error when fetching the imx-firmware packages originally stored in this repository. A workaround to this is to switch the original location to the new location. To do this we would need to manually create a build directory and initialize repo to locally load the manifest files and then make this change. Android BSP won’t require this workaround. Please note that this workaround only addresses this specific error that may show up when running the script included on the BSP release. We will be using the Oreo o8.0.0_1.0.0_ga BSP release as an example. Sources for this BSP can be found on the following link: https://www.nxp.com/design/development-boards/i-mx-evaluation-and-development-boards/android-os-for-i-mx-applications-processors:IMXANDROID?tab=Design_Tools_Tab Documentation for this BSP can be found on the following link: https://www.nxp.com/design/development-boards/i-mx-evaluation-and-development-boards/android-os-for-i-mx-applications-processors:IMXANDROID?tab=Documentation_Tab    1) Initialize the repo. If you have tried running the imx_android_setup.sh script the android build directory should already have been created. If this is the case, please skip to the next step. If not, please create it either by running imx_android_setup.sh or manually with the following commands (using the android setup script is preferred): $ mkdir android_build Once inside the build directory, initialize the repo and then sync it: $ repo init -u https://source.codeaurora.org/external/imx/imx-manifest.git -b imx-android-oreo -m imx-o8.0.0_1.0.0_ga.xml $ repo sync   2) Find and edit the Android Manifest. Once inside the build directory after synching, enter the repo manifests directory by executing the following command while inside the android build directory $ cd .repo/manifests  And look for the corresponding Android manifest. In this case imx-o8.0.0_1.0.0_ga.xml Open this file in any text editor (use sudo if running in a directory which requires it) In this case we’ll exemplify with nano $nano imx-o8.0.0_1.0.0_ga.xml And change the git://git.freescale.com/proprietary/  to git://github.com/NXP/ Also the path for imx-firmware so the complete line goes from: <project path="vendor/nxp/imx-firmware" name="imx-firmware" remote="imx-proprietary" revision="87ba304b9efbb2e8dbdd54af4c087584fb259535" />‍‍‍ To the following: <project path="imx-firmware" name="imx-firmware" remote="imx-proprietary" revision="87ba304b9efbb2e8dbdd54af4c087584fb259535" />‍‍‍ The manifest should look like the following. Save the file with these changes.   Now you can run the imx_android_setup.sh build script successfully. Since the repo was already synced it won’t fetch the manifests again and the change we made will persist, which will allow to find the imx-firmware package on its new location.

Enter inside ~/ltibdir/rpm/BUILD and create a directory 'alpha': $ cd ltib/rpm/BUILD $ mkdir alpha Enter in 'alpha' dir and create setalpha.c file: $ cd alpha #include <stdio.h> #include <stdlib.h> #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> #include <sys/ioctl.h> #include <unistd.h> #include <asm/arch/mxcfb.h>  int main(int argc, char **argv) {              int fb_fd;              struct mxcfb_gbl_alpha gbl_alpha;               if(argc != 2){                       printf("Usage: %s alpha_val[0-255]\n",argv[0]);                       return -1;              }               fb_fd = open("/dev/fb0",O_RDWR,0);              gbl_alpha.enable = 1;              gbl_alpha.alpha = atoi(argv[1]);              ioctl(fb_fd, MXCFB_SET_GBL_ALPHA, &gbl_alpha);              close(fb_fd);              return 0; } Compile it using this command: ./ltib -m shell LTIB> cd rpm/BUILD/alpha LTIB> gcc -I../linux/include setalpha.c -o setalpha In your board execute it: root@freescale /home$ /unit_tests/mxc_v4l2_output.out -iw 320 -ih 240 -ow 480 -oh 640 -d 3 -r 4 -fr 5 qvga.yuv & While it is playing execute: root@freescale /home$ setalpha 128 root@freescale /home$ cat screen.raw > /dev/fb0 We used frame rate at 5 fps to have more time to execute next two commands.

Q: When trying to mount his SDIO WiFi module (an Azurewave module containing a Marvel 88W8790)  in 4 bit mode, and got error wifi module on iMX6 Smart SD dev board using the alpha kernel (3.5.7+3285970). mwifiex_sdio mmc0:0001:1: WLAN FW is active mwifiex_sdio mmc0:0001:1: mwifiex_cmd_timeout_func: Timeout cmd id (2004.239824) = 0xa9, act = 0x0 mwifiex_sdio mmc0:0001:1: num_data_h2c_failure = 0 mwifiex_sdio mmc0:0001:1: num_cmd_h2c_failure = 0 mwifiex_sdio mmc0:0001:1: num_cmd_timeout = 1 mwifiex_sdio mmc0:0001:1: num_tx_timeout = 0 mwifiex_sdio mmc0:0001:1: last_cmd_index = 1 mwifiex_sdio mmc0:0001:1: last_cmd_resp_index = 0 mwifiex_sdio mmc0:0001:1: last_event_index = 0 mwifiex_sdio mmc0:0001:1: data_sent=1 cmd_sent=1 mwifiex_sdio mmc0:0001:1: ps_mode=1 ps_state=0 +++++++++++++++++++++++ There are only two known issues with the SDHC driver as noted in the release notes and these don't seem to match.  The Linux Reference Manual states the operation of the SDIO was veriifed usign the AR6003.  My assumption is that this is the Silex module we have standardized on.  Was 4 bit mode verified using this module? Does anyone have any idea what could be happening here? A: L3.5.7 is an alpha release, and WiFi function is not stable. The test report shows that open WiFi issue exists. Wifi module sometime can't work on mx6q_smd. After insmod ath, ath6kl_core and ath6kl_sdio. Insert the wifi card, sometime(50%) will display -------------------------- ath6kl: unable to read RX_LOOKAHEAD_VALID                                      ath6kl: Unable to recv target info: -84                                        ath6kl: Failed to init ath6kl core                                             ath6kl_sdio: probe of mmc0:0001:1 failed with error -84    -------------------------- reinsert the wifi card may solve the problem. when execute "udhcpc -i wlan0", sometime (30%) will cause program exception. Sometime can't get the wlan0 ip(program hang). Environment(OS,Platform,Driver, etc): HW: MX6Q_SMD Num014 and Num017 MX6Q_ARD don't have this problem SW: Kernel 3.5.7-1.0.0 GNU/Linux Case ID: TGE-LV-WIFI-0043 Reproduce Steps: #modprobe ath #modprobe ath6kl_core #modprobe ath6kl_sdio insert the wifi card # iwconfig wlan0 mode managed # iwlist wlan0 scanning | grep MAD-wifi #iwconfig wlan0 key 00112233445566778899123456 #iwconfig wlan0 essid MAD-wifi #udhcpc -i wlan0 Attached MX6 ARD WiFi issue also. [Kernel3.5.7_MX6QARD]Wifi:wifi card can't work during suspend and resume. 100% -- Bug detailed description: With wifi card inserted in the board. doing system suspend and resume test. wifi card can't work well after the system suspend and resume. Always report : ath6kl: Unable to decrement the command credit count register: -84             ath6kl: Unable to write to the device: -84                                     ath6kl: bmi_write_memory for uart debug failed                                 ath6kl: Failed to boot hw in resume: -5          Environment(OS,Platform,Driver, etc): HW: MX6QARD -023 Only tried on this platform SW: root@imx6qsabreauto:~# uname -a                                                Linux imx6qsabreauto 3.5.7-1.0.0+3285970 #1 SMP PREEMPT Sat Jun 29 10:20:45 CDT 2013 armv7l GNU/Linux Case ID:  TGE-LV-WIFI-1060 and TGE-LV-WIFI-1062 Reproduce Steps: 1. boot the kernel with wif card inserted 2. doing wifi stress test 3. doing suspend and resume

This is a HW design checklist for customer's reference. Please read and fill it in carefully before requesting a schematic review.

Most i.MX8QXP/QM customers already work on L4.14.98 GA for their Auto product, like C-V2X TBOX, Car infortainment system. Some customers also want to adopt OP-TEE in their security design, but OP-TEE on i.MX8QXP/QM platform don't support HW cryptography accelerating which base on CAAM module. So I worked on the issue last week and fixed it. The package meta-optee-add-on_4.14.98_2.0.0_ga.tgz is Yocto layer which includes all patches for fixing the issue. Software environments as the belows: Linux kernel: imx_4.14.98_2.0.0_ga HW platform:  i.MX8QM/QXP MEK. How to build: 1, decompress meta-optee-add-on_4.14.98_2.0.0_ga.tgz and copy meta-optee-add-on 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-optee and add BBLAYERS += " ${BSPDIR}/sources/meta-optee-add-on " into (Yocto 4.14.98_2.0.0_ga dir)/build-optee/conf/bblayers.conf  3, Run bitbake fsl-image-validation-imx. 4, You can run xtest or xtest -l 1 4007 on your MEK board to test optee crypto feature after completing build image. You can find it only take about one second comparing no CAAM accelerating when test "regression_4007.11 Generate RSA-2048 key".

The i.MX28 family of multimedia applications processors is the latest extension of Freescale's ARM9 product portfolio. The i.MX28 family integrates display, power management, and connectivity features unmatched in ARM9-based devices, reducing system cost and complexity for cost sensitive applications. It also integrates CAN, USB and Ethernet connectivity with full AEC-Q100 automotive qualification for automotive applications. i.MX Family Comparison Product Information on Freescale.com i.MX280 i.MX280 Multimedia Applications Processor i.MX281 i.MX281 Multimedia Applications Processor i.MX283 i.MX283 Multimedia Applications Processor i.MX285 i.MX285 Multimedia Applications Processor i.MX286 i.MX286 Multimedia Applications Processor i.MX287 i.MX287 Multimedia Applications Processor Evaluation/Development Boards and Systems MCIMX28EVKJ: i.MX28 Evaluation Kit How to add support for a new NAND How to add a New on imx28 with Win CE Running a mainline kernel on a MX28EVK board How to enable SPI NOR boot for iMX28 (Spansion s25fl256s) Embedded Software and Tools Android OS for i.MX Applications Processors i.MX28 Software and Development Tool Resources Additional Resources Adding Support For a New NAND with i.MX28–NAND Analysis Adding Support For a New NAND with i.MX28 on Win CE Board bring-up and DDR initialization tools i.MX as a USB Playback/Capture Device on One OTG Port i.MX28: GPIO interrupt on both rising and falling edges How to enable SPI NOR boot for iMX28 (Spansion s25fl256s) Running a Mainline Kernel on an i.MX28 EVK Board Running mk_mx28_sd on Ubuntu 12.04 Ubuntu 12.04 64-bit Precise Pangolin Host Setup for Building i.MX28 L2.6.35_MX28_SDK_10.12_SOURCE Use LCD_D11 pin for enet reset in iMX28

The i.MX 6 D/Q/DL/S/SL  Linux L3.10.17_1.0.2 Patch release is now available on www.freescale.com ·          Target HW boards o   i.MX6DL  SABRE SD board o   i.MX6Q  SABRE SD board o   i.MX6DQ SABRE AI board o   i.MX6DL SABRE AI board o   i.MX6SL EVK board This patch release is based on the i.MX 6 Linux L3.10.17_1.0.2 BSP release. ·         Release Description o    Kernel branch: imx_v2013.04_3.10.17_1.0.0_ga o    U-Boot branch: imx_3.10.17_1.0.0_ga o    Graphics: gpu-viv-bin-mx6q, 3.10.17_1.0.2 o    Graphics: gpu-viv-g2d, 3.10.17_1.0.2 o    Graphics: Xorg-driver, 3.10.17_1.0.2 ·         Patch Description Please consult the release notes.

The i.MX 6 D/Q/DL/S/SL Linux 3.10.53_1.1.0 GA release is now available on www.freescale.com ·         Files available           Name Description L3.10.53_1.1.0_LINUX_DOCS i.MX 6 D/Q/DL/S/SL Linux   3.10.53_1.1.0 GA BSP documentation. L3.10.53_1.1.0_iMX6QDLS_Bundle i.MX 6 D/Q/DL/S  Linux   3.10.53_1.1.0 GA BSP Binary Demo Files L3.10.53_1.1.0_iMX6SL_Bundle i.MX 6 SL  Linux   3.10.53_1.1.0 GA BSP Binary Demo Files L3.10.53_1.1.0_AACP_CODECS AAC Plus Codec for the i.MX 6 D/Q/DL/S/SL Linux 3.10.53_1.1.0   GA BSP y IMX_6_MFG_L3.10.53_1.1.0_TOOL Manufacturing Tool and Documentation for Linux   3.10.53_1.1.0 GA BSP y ·         Target HW boards o   i.MX6DL  SABRE SD board o   i.MX6Q  SABRE SD board o   i.MX6DQ SABRE AI board o   i.MX6DL SABRE AI board o   i.MX6SL EVK board New Features ·                             Please refer to formal Release Note document for all details. Known issues For known issues and limitations please consult the release notes located in the BSP documentation package.

本文档主要包括两个部分： 1：如何将一首超过两声道的多声道音乐放到多个双声道声卡上播放，来模拟原音乐文件的多声道输出。 2：如何将多个双声道音乐文件同时放到一个8声道的声卡的不同channel上播放。 涉及的文件：etc/asound.conf 1：如何将一首超过两声道的多声道音乐放到多个双声道声卡上播放，来模拟原音乐文件的多声道输出。 1）：Sabresd板子 按设计来讲，sabresd板子最多只能播双声道的音乐，但是如果一个音乐文件是四声道，该如何用sabresd板子来播放呢？ 可以让前两个声道通过WM8962来播放，后两个声道通过HDMI来播放： 33 pcm.multi { 34         type multi 35 36         slaves.a.pcm "hw:0,0" 37         slaves.a.channels 2 38         slaves.b.pcm "hw:1,0" 39         slaves.b.channels 2 40 41         bindings.0.slave a 42         bindings.0.channel 0 43         bindings.1.slave a 44         bindings.1.channel 1 45         bindings.2.slave b 46         bindings.2.channel 0 47         bindings.3.slave b 48         bindings.3.channel 1 49 } 273 pcm.asymed{ 274 type asym 275 playback.pcm "multi" 276 capture.pcm "dsnoop_44100" 277 } 278 279 ctl.multi{ 280         type hw; 281         card 0; 282 } 289 pcm.!default{ 290 type plug 291 route_policy "average" 292 slave.pcm "asymed" 293 } 可以通过以下命令来测试： speaker-test -c 4 -t sine speaker-test -c 4 -t sine -D multi 2）：ARD板子 ARD板子，6声道的audio文件，用ESAI来播放前四个channel，后两个channel用HDMI来播放： 33 pcm.multi { 34         type multi 35 36         slaves.a.pcm "hw:0,0" 37         slaves.a.channels 4 38         slaves.b.pcm "hw:2,0" 39         slaves.b.channels 2 40 41         bindings.0.slave a 42         bindings.0.channel 0 43         bindings.1.slave a 44         bindings.1.channel 1 45         bindings.2.slave a 46         bindings.2.channel 2 47         bindings.3.slave a 48         bindings.3.channel 3 49         bindings.4.slave b 50         bindings.4.channel 0 51         bindings.5.slave b 52         bindings.5.channel 1 53 } 273 pcm.asymed{ 274 type asym 275 playback.pcm "multi" 276 capture.pcm "dsnoop_44100" 277 } 278 279 ctl.multi{ 280         type hw; 281         card 0; 282 } 289 pcm.!default{ 290 type plug 291 route_policy "average" 292 slave.pcm "asymed" 293 } 可以用下面命令来测试： 播源文件是6声道的音乐： aplay 48kHz16bit-six-channel.wav aplay -D multi 48kHz16bit-six-channel.wav speaker-test -c 6 -t sine speaker-test -c 6 -t sine -D multi 播源文件是双声道的音乐，ESAI的四个channel和HDMI的两个声道都是该音乐： aplay heart.wav 2：如何将多个双声道音乐文件同时放到一个8声道的声卡的不同channel上播放。 我们ARD的板子，ESAI是8声道的，大部分音乐都是双声道的，ESAI的6个channel会被浪费掉。如何将其余的6个声道也应用起来？ alsa lib有dshare这个plugin,可以将4个双声道的音乐文件当成一个8声道的音乐来处理。 28  pcm_slave.nforce { 29        pcm "hw:0,0” 30        channels 8 31        rate 48000        # fixed, because all dshare devices must use the same samplerate. 32        buffer_size 4096  # make these sizes smaller for lower latency 33        period_size 1024 34        periods 4 35        period_time 0 36    } 37 39  pcm.ch12 { 40        type dshare 41        ipc_key 47110815 42        slave nforce 43        bindings.0 0 44        bindings.1 1 45    } 46 47  pcm.ch34 { 48        type dshare 49        ipc_key 47110815 50        slave nforce 51        bindings.0 2 52        bindings.1 3 53    } 54 55   pcm.ch56 { 56        type dshare 57        ipc_key 47110815 58        slave nforce 59        bindings.0 4 60        bindings.1 5 61    } 62 63   pcm.ch78 { 64        type dshare 65        ipc_key 47110815 66        slave nforce 67        bindings.0 6 68        bindings.1 7 69    } 可以通过下面的命令来测试： (aplay -Dplug:ch12 XX.wav &) (aplay -Dplug:ch34 XXX.wav &) (aplay -Dplug:ch56 XXXX.wav &) (aplay -Dplug:ch78 XXXXX.wav &) 四首音乐会分配到ESAI的8个channel上。

The native Yocto not support chinese, so need to add chinese font . The first step should download Chinese font  files such as  MSYHMONO.ttf and DroidSansFallback.ttf.Then copy fonts files to /usr/share/fonts/truetype and run command  fc-cache .update font cache. use fc-list :lang=zh can see which Chinese fonts are installed:          /usr/share/fonts/truetype/MSYHMONO.ttf: Microsoft YaHei Mono:style=Regular          /usr/share/fonts/truetype/DroidSansFallbackFull.ttf: Droid Sans Fallback:style=Regular The secend step is to change default fonts. In weston-terminal.c we can see:           3119   weston_config_section_get_string(s, "font", &option_font, "mono");           3120   weston_config_section_get_int(s, "font-size", &option_font_size, 14);  weston-terminal default use mono font.Just to modify /etc/fonts/fonts.conf           <edit name="family" mode="assign" binding="same">                       <string>monospace</string> to   <string>Microsoft YaHei Mono</string> or <string>Droid Sans Fallback</string> could display Chinese character   But it have some problem such like as :   the left use Microsoft YaHei Mono font the Chinese character is overlapping ,the right use Droid Sans Fallback font is en-font could not display. If you have a better way to welcome a message！

Hello everyone, in this post we will control one (or more) WS2812 LEDs from a Linux UserSpace application, communicating with Cortex M33 through RPMSG.  Required materials: FRDM-IMX93 WS2812 LED/Strip Attached wsled.c (userspace application) Attached ws2812_m33_project (Source code of firmware for M33)   Environment: Linux Kernel 6.6 arm-gnu-toolchain-13.3.rel1-x86_64-arm-none-eabi SDK 24.12.00   This is the block diagram of the application:        CORTEX M33 SIDE.  From WS2812  LED datasheet, we can see the timing must be precise, that is the reason we will use the Cortex M33 (Real time applications):    As we can see, the timing just accept tolerance of 150ns, that is the reason is preferred to use the Cortex M33 instead of control with Linux that is in charge of other tasks.    The function that we will implement to send Zero and One is:  void WS2812B_send_bit(uint8_t bit) { if (bit) { // Send "1" RGPIO_PinWrite(WS2812B_LED_RGPIO, WS2812B_LED_RGPIO_PIN, 1); for (int i = 0; i < HIGH_ONE_CYCLES; i++) __asm__("NOP"); RGPIO_PinWrite(WS2812B_LED_RGPIO, WS2812B_LED_RGPIO_PIN, 0); for (int i = 0; i < LOW_ONE_CYCLES; i++) __asm__("NOP"); } else { // Send "0" RGPIO_PinWrite(WS2812B_LED_RGPIO, WS2812B_LED_RGPIO_PIN, 1); for (int i = 0; i < HIGH_ZERO_CYCLES; i++) __asm__("NOP"); RGPIO_PinWrite(WS2812B_LED_RGPIO, WS2812B_LED_RGPIO_PIN, 0); for (int i = 0; i < LOW_ZERO_CYCLES; i++) __asm__("NOP"); } }     Testing and measuring the toggle timing with the RGPIO driver of Cortex M33, we could find the best number of NOP instructions to adjust with the required timing according to datasheet, and the results with core running at 200MHz are:    Parameter  Number of NOP times  HIGH_ONE_CYCLES  22  (T1H: 700 ns)  LOW_ONE_CYCLES  12  (T1L: 600 ns)  LOW_ZERO_CYCLES  20  (T0L: 800 ns)  HIGH_ZERO_CYCLES  6    (T0H: 350 ns)      Zero:   One:   Taking in mind this information, we can start to develop our application. From Cortex M33, we created a little protocol, that will wait for instructions to do.    For example, the expected string to fill the RPMSG buffer is:    Index  Purpose  Example  app_buf[0]  Command ('c' or 't')  'c' = store color in buffer  't' = show colors on LEDs  app_buf[1]  Red component (0–255)  0xFF  app_buf[2]  Green component (0–255)  0x00  app_buf[3]  Blue component (0–255)  0x80  app_buf[4]  LED index (target LED position)  e.g. 0, 1, 2    Commands:    'c'  "Color store"  This command stores the RGB color value into a local buffer, targeting a specific LED (app_buf[4]).  It doesn't update the LED strip immediately, it just prepares the data.  Example of RPMSG received buffer from Cortex A (Linux):   app_buf = { 'c', 0xFF, 0x00, 0x00, 2 };  // Store red color for LED 2     't'  "Transfer"  This command sends the full color buffer to the WS2812 strip, updating the LED colors.  The RGB values in the buffer are ignored, it simply triggers an update based on previously stored data.  Example of RPMSG received buffer from Cortex A (Linux):  app_buf = { 't', 0, 0, 0, 0 };  // Transfer the buffered colors to the LED strip     You can modify the code to add your custom commands like change number of LEDs on the strip, or change the GPIO, etc. Currently, the number of WS2812 LEDs supported is defined in software by NUM_RGB_LEDS. As default is 8 LEDs.    I will attach the full code for Cortex M33 firmware, it was tested with arm-gnu-toolchain-13.3.rel1-x86_64-arm-none-eabi and SDK 2_15, SDK 2_16 and SDK 24.    In this example, the EXP_GPIO_IO24 of FRDM-IMX93 was used to control the LED Strip.   CORTEX A55 SIDE.  For Cortex A55 (Linux side), we developed an userspace application, that will create the structure for the buffer to send to the Cortex M33 and send through RPMSG using the imx_rpmsg_tty included on the NXP BSP. You can find the userspace application attached.    As we know, the imx_rpmsg_tty creates the tty channel called ttyRPMSG31 under /dev. So, this userspace application communicates directly with the device /dev/ttyRPMSG31 to send the buffer with the required structure for Cortex M33.    EXAMPLE OF USAGE.    STEP 1. Compile firmware for Cortex M33 and store in FRDM-IMX93 under /lib/firmware to use with remoteproc:   STEP 2.  Compile or cross-compile the userspace application (attached.)  To compile on the platform:  root@imx93evk:~# gcc wsled.c -o wsled root@imx93evk:~# ls wsled wsled.c Also, we can copy the wsled under /bin to practicity. root@imx93evk:~# wsled Error: -c <red> <green> <blue> is required. WS2812 Usage: wsled -c <red> <green> <blue> [-n <led_position>] Load the color of exact LED to the buffer wsled -t Shows the colors to the LEDs   STEP 3. To run the entire example: boot the board and load the firmware for cortex M33 with remoteproc: root@imx93evk:~# cd /sys/class/remoteproc/remoteproc0 root@imx93evk:/sys/class/remoteproc/remoteproc0# echo ws2812_m33.elf > firmware root@imx93evk:/sys/class/remoteproc/remoteproc0# echo start > state  Then, we will receive this from Cortex M33 terminal: RPMSG String Communication Channel FreeRTOS RTOS M33 clock is at: 200000000 Hz Nameservice sent, ready for incoming messages from Cortex-A55! WSLED   Load the imx_rpmsg_tty module in Linux to initialize RPMSG: root@imx93evk:~# modprobe imx_rpmsg_tty   Then, we will have the hello world message from Cortex A (Linux side), but with our buffer format in Cortex M33 console: CMD: h [1]:0x65 [2]:0x6c [3]:0x6c [4]: 111 LEN = 12   Finally, we are ready change colors of the LEDs: Load the buffer (LED 1 = RED, LED 2 = Green, LED 3 = Blue). root@imx93evk:~# wsled -c 0x55 0x00 0x00 -n 1 root@imx93evk:~# wsled -c 0x00 0x55 0x00 -n 2 root@imx93evk:~# wsled -c 0x00 0x00 0x55 -n 3   Show colors on LEDs. root@imx93evk:~# wsled -t    

The i.MX 6 D/Q L3.035_1.0.2 patch release is now available on the www.freescale.com ·         Files available # Name Description 1 L3.0.35_1.0.2_LDO_PATCH This patch release is based on the i.MX 6Dual/6Quad Linux   12.09.01 release. The purpose of this patch release is to manage the LDO and   PMIC ramp-up time correctly.

In this blog, we are going to discuss how we can configure iMX95EVK as PCIe Endpoint and test it using a RC which will be iMX8MM. Hardware Components iMX95EVK iMX8MM PCIe M.2 Key E Bridge Ethernet connectivity     Software Components Linux Factory 6.12.20 BSP linux-imx source code - https://github.com/nxp-imx/linux-imx/tree/lf-6.12.20-2.0.0 System setup Step -1 Flash the 6.12.20 BSP on the iMX95 EVK eMMC/SD card and boot with it. Step-2 Fetch linux-imx 6.12.20 source code from the github repo GitHub - nxp-imx/linux-imx at lf-6.12.20-2.0.0 Step-3 Make the following changes to arch/arm64/boot/dts/freescale/imx95-19x19-evk-pcie1-ep.dtso as per the following diff:-   diff --git a/arch/arm64/boot/dts/freescale/imx95-19x19-evk-pcie1-ep.dtso b/arch/arm64/boot/dts/freescale/imx95-19x19-evk-pcie1-ep.dtso index a8e3bbc53894..d082688fc1c2 100644 --- a/arch/arm64/boot/dts/freescale/imx95-19x19-evk-pcie1-ep.dtso +++ b/arch/arm64/boot/dts/freescale/imx95-19x19-evk-pcie1-ep.dtso @@ -11,12 +11,12 @@ &smmu {  };     -&pcie1 { +&pcie0 {         status = "disabled";  };   -&pcie1_ep { +&pcie0_ep {         pinctrl-names = "default"; -       pinctrl-0 = <&pinctrl_pcie1>; +       pinctrl-0 = <&pinctrl_pcie0>;         status = "okay";  };     As you can see, we are trying to enable 'End-point' mode on iMX95EVK's M.2 PCIe 0. The default dtb enables it for PCIe 1. Building the kernel will build this dtb from the dtso changes. Step-4 SCP the dtb to the board and rename it to "imx95-19x19-evk-pcie0-ep.dtb" to avoid confusion. Copy it to the location - /run/media/boot-mmcblk0p1/ Step-5 Boot the board with this DTB by changing the 'fdtfile' variable at Uboot. when the kernel boots up with this dtb, you will see the following pcie dmesg logs on the console through which you can verify if the changes have worked:-   root@imx95evk:~# dmesg | grep pcie-ep [    3.142123] imx6q-pcie 4c300000.pcie-ep: iATU: unroll T, 8 ob, 8 ib, align 4K, limit 1024G [    3.151767] imx6q-pcie 4c300000.pcie-ep: eDMA: unroll T, 4 wr, 4 rd root@imx95evk:~#   0x4c300000 is the address of pcie0 controller Step-6 Execute this script on iMX95EVK - 'conf_pcie0_ep' Step-7 Boot iMX8MM board with this dtb - imx8mm-evk.dtb Step-8 Executing 'lspci' on the iMX8MM, you will see the following output:- That's the iMX95EVK Endpoint that you see on the lspci output of iMX8MM RC.   The address space translation window is configured with the help of the info mentioned in  arch/arm64/boot/dts/freescale/imx8mm.dtsi If the readers want to make sense out of the translation window info mentioned in form of 'ranges' property of PCIe node, they can go through this article in which there is a detailed explanation of what is going behind the scenes - Demystifying the PCIe and CPU address space translation in Linux - NXP Community      

this article write down the steps when help customer bring dual camera under single mipi csi with NXP switch NX3DV642, just for a reference, connect OV5640 + os08a20 with mipi csi0 via ISP, as default, mipi csi0 just has one port with one camera, this document improve how to enable os08a20 with second port under mipi csi0, refer to the document and patch as attachment, for how to enable ov5640 with ISP, pls refer to my another document

This is about the case studay from two USB related issues: #1. Plugin detection issue caused by an errata in i.MX8/8X (host mode).       Very limited unit may encounter this problem. When issue happens, there will be totally no action on USB host port when a debug plugged in. #2: High Speed disconnection detection issue (host mode):       This may happen on some special USB design which have complex circuit and connector design on the USB path and long USB cable. The USB enumeration might be interrupted by an un-expected disconnection event. System log shows USB recognition started but failed at several different stages during handshake. For details, please refer to the doc attached (#1/#2). A reference patch for each has also been made by David.

This article describes how to integrate NXP WiFi & BT module into i.MX platform, some debug tips, how to test, etc. Although it takes i.MX8MM as example, it is also suitable for all i.MX8 serials platform.

Background Some customers connect their imx running Android to the cloud, so reboot-bootloader and the use of fastboot oem unlock is not acceptable. This way the system is disconnected and cannot be operated remotely using adb. This article therefore proposes to execute oem unlock before the bootloader is started when the system is first run, which can be unlocked directly.   Patch diff --git a/drivers/fastboot/fb_fsl/fb_fsl_boot.c b/drivers/fastboot/fb_fsl/fb_fsl_boot.c index 86b919775a..d60cd248ee 100644 --- a/drivers/fastboot/fb_fsl/fb_fsl_boot.c +++ b/drivers/fastboot/fb_fsl/fb_fsl_boot.c @@ -529,6 +529,42 @@ bool __weak is_power_key_pressed(void) { return false; } +static void wipe_all_userdata(void) +{ + char response[FASTBOOT_RESPONSE_LEN]; + + /* Erase all user data */ + printf("Start userdata wipe process....\n"); + /* Erase /data partition */ + fastboot_wipe_data_partition(); + +#if defined (CONFIG_ANDROID_SUPPORT) || defined (CONFIG_ANDROID_AUTO_SUPPORT) + /* Erase the misc partition. */ + process_erase_mmc(FASTBOOT_PARTITION_MISC, response); +#endif + +#ifndef CONFIG_ANDROID_AB_SUPPORT + /* Erase the cache partition for legacy imx6/7 */ + process_erase_mmc(FASTBOOT_PARTITION_CACHE, response); +#endif + +#if defined(AVB_RPMB) && !defined(CONFIG_IMX_TRUSTY_OS) + printf("Start stored_rollback_index wipe process....\n"); + rbkidx_erase(); + printf("Wipe stored_rollback_index completed.\n"); +#endif + process_erase_mmc(FASTBOOT_PARTITION_METADATA, response); + printf("Wipe userdata completed.\n"); +} +void do_unlock(void) +{ + int status; + wipe_all_userdata(); + status = fastboot_set_lock_stat(FASTBOOT_UNLOCK); + if (status < 0) + return FASTBOOT_LOCK_ERROR; + printf("Unlock device\n"); +} int do_boota(struct cmd_tbl *cmdtp, int flag, int argc, char * const argv[]) { ulong addr = 0; @@ -563,6 +599,9 @@ int do_boota(struct cmd_tbl *cmdtp, int flag, int argc, char * const argv[]) { fastboot_set_lock_stat(FASTBOOT_LOCK); lock_status = FASTBOOT_LOCK; } + if (lock_status == FASTBOOT_LOCK){ + do_unlock(); + } bool allow_fail = (lock_status == FASTBOOT_UNLOCK ? true : false); avb_metric = get_timer(0);      

This article will describe one suggestion for one issue that UART continuously generate RX interrupts and receive 0xFF even when Rx line is continuously high in some cases on imx6 series. Below I will explain with imx6DL. Some settings are just to make it easier to reproduce. BSP version: L5.4.70-2.3.0 Board HW: MCIMX6DL-SDB When issue happen Config imx6DL UART3 as the serial port to 1200 baud, 8-N-1 format. Keep the RX Line high. Make the RX line low and keep it for a short time (360 usec-370 usec).   At this condition, you will find that the UART will continuously generate RX interrupts and show receiving 0xFF even you make the RX line return to be high. Why issue happen The low time is not in the correct range and out of our spec. In the imx6DL AEC document, there is one chapter named UART Receiver like blow   If using 1200 band, that means one valid bit time is 833 usec. And there is a definition that “tolerate 1/(16 x Fbaud_rate) tolerance in each bit”. That’s means in the case of 1200 baud. A range of valid bit is 781 to 885 usec. But is reproducing, the Low level time is 360 usec. This time out of range will make UART state machine to be confused. How to fix Actually, the best way is following our spec. If there is such an unknown situation in the customer’s environment, then the following method could be regarded as a suggestion to fix the issue meet by the customer. The interrupt handler will check USR1[AWAKE]. 2    If AWAKE is asserted, clear it and proceed as usual (assume we have valid data), else, check if USR1[AGTIM] is asserted. 3    if AGTIM is asserted, clear it and proceed as usual, else perform software reset (assume we have invalid data). Checking AGTIM is for one race condition when the RX fifo has some characters (less than RXTL) but no more data is coming in. When following this procedure, the UART will perform a software reset when a block interrupt occurs. Notes: From customer report, error could be cleared if a valid start-bit is detected on the RX line. This needs to be verified by the customer themselves. Test code has been included in attachment.   Besst Regards