There are two ethernet ports in i.MX8MP： FEC0 and FEC1(eQOS). Normally we use iperf to test ethernets ports performance. However, when using tftp test, the result is different in two ports. This document describe how to fine tune parameters to increase speed under tftp test or other use case. It is suitable for most i.MX serials and most BSP version.

The i.MX6 Multi-Mode DDR Controller (MMDC) has profiling capabilities to monitor the operation of the controller. The profiling capability counts certain events related to a specified AXI-ID during a profiling period. The events that can be counted are: The number of read accesses during the profiling period (MMDCx_MADPSR2[RD_ACC_COUNT] register field) The number of write accesses during the profiling period (MMDCx_MADPSR3[WR_ACC_COUNT] register field) The number of bytes read during the profiling period (MMDCx_MADPSR4[RD_BYTES_COUNT] register field) The number of bytes written during the profiling period (MMDCx_MADPSR5[WR_BYTES_COUNT] register field) The number of MMDC clock cycles during which the MMDC state machine is busy (MMDCx_MADPSR1[BUSY_COUNT] register field) BUSY_COUNT is the number of MMDC clock cycles during the profiling period in which the MMDC state machine is not idle. So this is the time the MMDC spends doing any activity, not just read or write data transfers. The MMDC state machine is active whenever there are any read or write requests in the read and write FIFOs. The MMDC is active during many operations that are not reading or writing data such as arbitration of requests, control cycles, bank open/close, etc. So BUSY_COUNT represents the number of cycles when the controller is busy, not just the number of cycles when the external bus is busy. The number of bytes read and bytes written can be used to determine data throughput and the BUSY_COUNT can be used to determine what part of the time the controller is active/idle. Together these can be used to determine the controller efficiency for a particular application. For detailed information, see the "MMDC profiling" section of the MMDC chapter in the reference manual for the SoC being used.

One of the features that many users have asked about but still is a work in progress for android, is the extended desktop capabilities. Currently android allows you to mirror your desktop in two displays, but you are still unable to extend your desktop like you would with any other OS like Linux or Windows. This tutorial is intended to show you how to use a special object that allows you to control what should appear on a secondary or external display, replacing the screen mirroring. So how do we do this? A presentation is a container to display a user interface, in the form of a view hierarchy on an external display. This is pretty much like a Dialog since it displays its UI separated from its activity, but the difference is that the presentation shows in an external display while the dialog displays it in the primary screen. Now, because of this, the resources that are to be used by the UI on an external display are different then the resources used in the primary screen, the context of the presentation is NOT the activity. How do we choose where to send this presentation? The easiest way to do this is to use the MediaRouter API. What the mediarouter does is it keeps track of which audio and video routes are available on the system. The MediaRouter sends notifications whenever routes are selected or unselected. An application can simple watch for these notifications and show or dismiss a presentation on the preferred presentation display automatically. The preferred presentation display is the display that the mediarouter recommends that the application should use if it wants to show content on the secondary display. IF there is not a preferred presentation display, the application should show its content locally without using a presentation. Using the Mediarouter The MediaRouter is a system service obtained by calling getSystemService() and asking for the MEDIA_ROUTER_SERVICE. We should use the mediarouter to create and show a presentation on the preferred presentation display: MediaRouter mediaRouter = (MediaRouter) context.getSystemService(Context.MEDIA_ROUTER_SERVICE); MediaRouter.RouteInfo route = mediaRouter.getSelectedRoute(); if (route != null) { Display presentationDisplay = route.getPresentationDisplay(); if (presentationDisplay != null) { Presentation presentation = new MyPresentation(context, presentationDisplay); presentation.show(); } } In order to use this framework in your app, you need to get an instance of the MediaRouter framework object and attach a MediaRouter.Callback object to listen for event in available media routes. The android apps that implement the media router API need to include a Cast button to allow users to select a media route to play media on a secondary output device. The recommended way to implement the Cast button  is to extend your activity from ActionBarActivity() and use the onCreateOptionMenu() method to add an options menu. The Cast button must use the MediaRouteActionProvider class as its action: <?xml version="1.0" encoding="utf-8"?> <menu xmlns:android="http://schemas.android.com/apk/res/android" xmlns:app="http://schemas.android.com/apk/res-auto" > <item android:id="@+id/media_route_menu_item" android:title="@string/media_route_menu_title" app:actionProviderClass="android.support.v7.app.MediaRouteActionProvider" app:showAsAction="always" /> </menu> The media router framework communicates with an app through a callback object that you attach to the mediarouter framework object.  Its necessary to extend the callback object in order to receive messages when a media route is connected. Once your callback is defined for the media router,  you need to attach it to the media router object.  The following sample demonstrates how to use the lifecycle methos to appropriately add and remove your app’s media router callback object. You need to add and remove it because it needs to be free for whenever you close the app or have it in the background so other apps use it if necessary. public class MediaRouterPlaybackActivity extends ActionBarActivity { private MediaRouter mMediaRouter; private MediaRouteSelector mSelector; private Callback mMediaRouterCallback; // your app works with so the framework can discover them. @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); // Get the media router service. mMediaRouter = MediaRouter.getInstance(this); ... } // Add the callback on start to tell the media router what kinds of routes // your app works with so the framework can discover them. @Override public void onStart() { mMediaRouter.addCallback(mSelector, mMediaRouterCallback, MediaRouter.CALLBACK_FLAG_REQUEST_DISCOVERY); super.onStart(); } // Remove the selector on stop to tell the media router that it no longer // needs to discover routes for your app. @Override public void onStop() { mMediaRouter.removeCallback(mMediaRouterCallback); super.onStop(); } ... } Remote playback This approach sends control commands to a secondary device to initiate playback and to control the playback that is in progress (play, stop, fast-forward, rewind, etc). When your app supports this type of media route, you must need to create a RemotePlaybackClient boject using a remote playback MediaRoute.RouteInfo object received through your app’s MediaRouter.Callback object. The following sample code demonstrates a controller method that creates a new remote playback cliente and sends it a video for playback. private void updateRemotePlayer(RouteInfo route) { // Changed route: tear down previous client if (mRoute != null && mRemotePlaybackClient != null) { mRemotePlaybackClient.release(); mRemotePlaybackClient = null; } // Save new route mRoute = route; // Attach new playback client mRemotePlaybackClient = new RemotePlaybackClient(this, mRoute); // Send file for playback mRemotePlaybackClient.play(Uri.parse( "http://archive.org/download/Sintel/sintel-2048-stereo_512kb.mp4"), "video/mp4", null, 0, null, new ItemActionCallback() { @Override public void onResult(Bundle data, String sessionId, MediaSessionStatus sessionStatus, String itemId, MediaItemStatus itemStatus) { logStatus("play: succeeded for item " + itemId); } @Override public void onError(String error, int code, Bundle data) { logStatus("play: failed - error:"+ code +" - "+ error); } }); } } For more information on how to use the media router, you can visit developer.android.com

When using SSI Slave Mode for ASRC_P2P function (https://community.freescale.com/docs/DOC-95342), the waveform of the converted 24bit data is abnormal(have some values between 0 and 1). When using SSI Master Mode, these abnormal data disappear. This patch shows how to enable SSI Master Mode based on ASRC_P2P patches. Because SSI Master Mode uses fixed data width for LRCLK(32bits for each L or R), and the SSI Dual FIFO Mode is not supported for ASRC_P2P, the converted 16bit data is not well supported in this patch. Suggestions: If you want to convert the audio data to 16bit, you can use SSI Slave Mode; if you want to convert the audio data to 24bit, you can use SSI Master Mode.

NOTE: Always de-power the target board and the aggregator when plugging or unplugging smart sensors from the aggregator. The aggregator portion of the i.MX Power Profiling System sits between the "smart" current sensor boards and the host computer. It provides power and signal connections to each connected sensor board. The communication is done over I2C, where three I2C bus extenders (PCA9518) effectively provide a dedicated bus to each I2C device, to better allow for cabling.  More information will follow... A photo, layout images and schematic attached below.   MBED source for the FRDM-KL25Z is available here: 30848-KL25Z-AGGREGATOR    Smart Sensor Connections At each smart sensor header JP0-JP13, these are the connections provided: 5V: powers the 3.3V regulator on each sensor board 12V: all the gates of all the switching FETs are pulled pulled up to 12V GND: ground connection SCL/TX0: I2C clock line  SDA/RX0: I2C data line  SWD_CLK:  global line for triggering smart sensors to make measurements RESET_B:  global line for resetting all smart sensor boards SWD_IO_n: individual select line for each smart sensor I2C Bus Connection Three I2C bus extenders (PCA9518) provide buffered connections between the FRDM board and all the connected smart sensors. The bus extenders were added to allow for longer cables between the aggregator and the smart sensor boards. Each bus extender has five ports and along with connections that allow extending the bus to more bus extenders. Gate Supply The aggregator contains a boost regulator that boost the 5V input from the FRDM board to 12V. The boosted voltage is fed to each of the smart sensor headers. It's used by the smart sensor board to pull up the gates of the switching FETs above any of the rails under test by at least 4.5V in order to benefit from a lower Rds(on). Caution must be exercised with some older FRDM boards since the 5V from the USB connection passes through diodes with a maximum current of 200mA.  The boost regulator and the load presented by the smart sensor boards may exceed the diode's limit and damage it. (Yes, it's happened... two older FRDM-KL25Z boards were used during development. One of them failed with the diode shorted (~0.05 Ohms), so everything kept working. The other failed with a  short of ~45 Ohms, so it kind of worked but not really...) Application Code for Aggregator  To date, application code has only been developed for the FRDM-KL25Z board. The latest application code resides at: https://os.mbed.com/users/r14793/code/30848-KL25Z-AGGREGATOR/, with the latest binary attached below. SWD Programming of Smart Sensors  Connectors J5 and JP15 are provided as an adapter for programming the smart sensor boards via SWD. JP15 provides power to the smart sensor board, since they have no direct 3.3V input for the KL05Z. An SWD programmer (or suitably modified FRDM-KL05Z board) connects to J5. Both connections use 10-pin 0.05"-spaced ribbon cables. Additionally, when a smart sensor is connected to JP15, J6 provides access to the UART pins of the smart sensor (the I2C pins on the smart sensor also mux out the UART of the KL05Z). No hardware changes are necessary at all; changing the code running on the smart sensor is all that's required. In fact, during the initial prototyping of the smart sensors, the serial UART connection was used instead of I2C. Modify Aggregator To Use SWD Dongle To Program Smart Sensor:  Add a wire as shown on the bottom side of the aggregator board as shown below. This ties 3.3V on the aggregator to the debug header, enabling the voltage level translators on the dongle to communicate with the KL05Z on the smart sensor board.  

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.

Wi-Fi Android IMX53 QSB enable WIFI android How to Support New WiFi Card in Android How to enable PCIe WiFi into i.MX6 Android Release? WiFi.zip

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

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.

Hello everyone, this document will share an step by step guide of the configuration needed in a Linux PC to compile the SDK examples we provide, as well as how to download them in an easy way. Requirements: I.MX 8M Mini EVK SDK package (for i.MX8MM) UUU tool First step would be to get the SDK package, this include documentation and code, which is available at the MCUXpresso builder webpage: https://mcuxpresso.nxp.com/en/welcome Click on the select a development board and select the package for your development kit or the i.MX MPU   This guide is focused on Linux build so will select GCC package and Linux host PC as the environment. Click on build and wait for the SDK package to be ready for download. Note1: Click on select all if the whole middleware package is desired Note2: it is possible to select each middleware that are desired. On new window select download SDK Select on new pop-up window download both SDK and documentation Read and accept EULA so the download start Decompress the package using the following command: $ tar -xvzf ~/SDK_2_13_0_EVK-MIMX8MM.tar.gz -C ~/SDK_2_13_0_EVK-MIMX8MM Next will be to download the GCC from the ARM webpage, gcc-arm-none-eabi-10.3-2021.10-x86_64-linux.tar.bz2 https://developer.arm.com/downloads/-/gnu-rm Note that the GCC version used is based on the minimum version required, since this was tested and supported, this could be found within the SDK documentation (~/SDK_2_13_0_EVK-MIMX8MM/docs/MCUXpresso SDK Release Notes for EVK-MIMX8MM) Once downloaded we can decompress and configure the environment: $ tar -xf gcc-arm-none-eabi-10.3-2021.10-x86_64-linux.tar.bz2 $ export ARMGCC_DIR=~/gcc-arm-none-eabi-10.3-2021.10 $ export PATH=$PATH:~/gcc-arm-none-eabi-10.3-2021.10 $ sudo apt-get install cmake  Check the version >= 3.0.x $ cmake --version Once this is done we enter the path of the example of our choice and compile using the script, as necessary using debug, release or all. $ cd ~/SDK_2_13_0_EVK-MIMX8MM/boards/evkmimx8mm/demo_apps/hello_world/armgcc $./build_release.sh The binary (elf and bin) will be found inside the folder according to whether we use debug or release script. For this example we used release script: $ cd release Once builded we can move/download the binaries from the Linux host PC to the board by using the UUU tool with the command fat_write #### we put the board in fastboot mode by entering the command in the uboot terminal fastboot 0 #### From the Linux terminal introduce the UUU command to  download to the FAT partition of the eMMC of the baord: ## For rproc it is needed the .elf binary ## $ uuu -v -b fat_write hello_world.elf mmc 0:1 hello_world.elf ## For bootaux it is needed the .bin binary ## $  uuu -v -b fat_write hello_world.bin mmc 0:1 hello_world.bin Once with the binaries in the FAT partition of the SD/eMMC of our board we can make the necessary modifications (device tree/bootargs) to test the Cortex-M examples. For any question regarding this document, please create a community thread and tag me if needed. Saludos/Regards, Aldo.

Q: Is there any guidelines document on 3G/4G modem integration with the iMX platforms running Android Lollipop versions ? A: Generally speaking, porting documents on 3G/4G should be provided by manufacture, For different 3G/4G module, porting steps are also distinct.The following steps are for ZTE 3G on android jb 4.2.2,  as a reference: ----Common steps: (1) linux USB driver In linux kernel, we should select GSM module in USB driver path. (2)Communication port for 3G After linux booting normally, you can find some communation port at path /dev/, like ttyUSB0,ttyUSB1,ttyUSB2... These tty ports are for AT commands & data transmitting, but which one is for data , or which one is for AT command, we should have to ask manufacture or get information for them. (3)dial script 3G manufacture will give the script to you, if not, ask for it. (4)Dynamic library(libreference-ril.so) 3G manufacture will give you the library to replace original one in android. (5)Add service for 3G in init.rc file according their documents ---As an example, let us see steps for ZTE 3G(CDMA) ** Replace original file with libreference-ril.so file that ZTE released. **Copy init.gprs-pppd file to system/etc/ppp directory **Modify init..rc like following: service ril-daemon /system/bin/rild -l /system/lib/libreference-ril.so -- -d /dev/ttyUSB2 -u /dev/ttyUSB0 class main socket rild stream 660 root radio socket rild-debug stream 660 radio system socket rild-ppp stream 660 radio system user root group radio cache inet misc audio sdcard_rw log service pppd_gprs /etc/ppp/init.gprs-pppd class main user root group radio cache inet misc disabled oneshot

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上。

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

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

Useful information about push buttons.   Physical level.            When there is a change of voltage level on P0-P7 pins, PCA9555PW will generate interrupt on INT pin. The driver (running on SoC) can read the status of P0-P7 pins via I2C (SCL/SDA pins) and generate separate interrupts for each of P0-P7 pins. This is why this driver acts as interrupt controller. Consider next configuration:        One push button changes level on P4 pin, tempting PCA9555PW to generate interrupt. Interrupt from PCA9555PW is connected to GPIO5 IP-core (inside of SoC), and it uses line #9 of that GPIO5 module to notify CPU about interrupt. So we can say that PCA9555PW is cascaded to GPIO5 controller. GPIO5 also acts as interrupt controller, and it's cascaded to GIC interrupt controller.   Device tree properties.   The meaning of properties is as follows: interrupt-controller  property defines that device generates interrupts; it will be needed further to use this node as interrupt-parent in each push button node. #interrupt-cells defines format of interrupts property; in our case it's 2 : 1 cell for line number and 1 cell for interrupt type interrupt-parent and interrupts properties are describing interrupt line connection   Interrupt handling.   CPU now is in interrupt context in GIC interrupt handler. From gic_handle_irq() it calls handle_domain_irq() , which in turn calls generic_handle_irq() . See Documentation/gpio/driver.txt for details. Now we are in SoC's GPIO controller IRQ handler. SoC's GPIO driver also calls generic_handle_irq() to run handler, which is set for each particular pin. See for example how it's done in omap_gpio_irq_handler() . Now we are in PCA9555PW IRQ handler. PCA9555PW IRQ handler calls handle_nested_irq() . Finally, gpio_keys_gpio_isr() is called.      The following steps allow you to enable rgb led's and push buttons on 8MIC-RPI-MX8 board with i.MX 8M Mini Applications Processor Evaluation Kit (EVKB). You have to use a led driver and change the device tree. On the Host. Cloning the Linux kernel repository.   Clone the i.MX Linux Kernel repo to the home directory. cd ~ git clone https://source.codeaurora.org/external/imx/linux-imx This guide will use the following commit which corresponds to Kernel 5.10.35-2.0. cd linux-imx/ git checkout -b RGB ef3f2cfc6010 Patching the device tree.   Download the "0001-Enable-RGB-LED-s-and-push-buttons-on-8MIC-RPI-MX8-bo.patch" file attached to this post and copy it into linux-imx directory, then apply the patch. cp 0001-Enable-RGB-LED-s-and-push-buttons-on-8MIC-RPI-MX8-bo.patch ~/linux-imx/ cd ~/linux-imx/ patch < 0001-Enable-RGB-LED-s-and-push-buttons-on-8MIC-RPI-MX8-bo.patch When prompted, select the file to patch: File to patch: arch/arm64/boot/dts/freescale/imx8mm-evk-8mic-revE.dts patching file arch/arm64/boot/dts/freescale/imx8mm-evk-8mic-revE.dts Then setup your toolchain, for example: source /opt/fsl-imx-wayland/5.10-hardknott/environment-setup-cortexa53-crypto-poky-linux Generate config file. make imx_v8_defconfig Compile the device tree. make freescale/imx8mm-evk-8mic-revE.dtb Copy the .dtb file to the EVK, for example with scp: scp imx8mm-evk-8mic-revE.dtb root@<EVK_IP>:/home/root Alternatively, you may copy the .dtb file directly to the FAT32 partition where the Kernel and Device Tree files are located. Compiling the Led driver.   Obtain the leds-pca995x.h file in the next site: https://github.com/TechNexion/linux-tn-imx/blob/tn-imx_5.4.70_2.3.0-stable/include/linux/platform_data/leds-pca995x.h  Copy it into the next path: cp leds-pca995x.h ~/linux-imx/include/linux Create a new directory. mkdir ~/linux-imx/PCA9955 Create a makefile. cd ~/linux-imx/PCA9955 vim Makefile   KERNEL_ROOT?=~/linux-imx obj-m += leds-pca995x.o all: make -C $(KERNEL_ROOT) M=$(PWD) modules clean: make -C $(KERNEL_ROOT) M=$(PWD) clean   Press the key "Esc" and then: :wq Obtain the leds-pca995x.c file in the next site: https://github.com/TechNexion/linux-tn-imx/blob/tn-imx_5.4.70_2.3.0-stable/drivers/leds/leds-pca995x.c Copy it into the next path: cp leds-pca995x.c ~/linux-imx/PCA9955 Obtain 0001-PCA9955BTW.patch file and copy it into the next path: cp 0001-PCA9955BTW.patch ~/linux-imx/PCA9955 Apply the patch. patch < 0001-PCA9955BTW.patch Then setup your toolchain, for example: source /opt/fsl-imx-wayland/5.10-hardknott/environment-setup-cortexa53-crypto-poky-linux Generate .ko file. cd ~/linux-imx/PCA9955 make all Copy the .ko file to the EVK, for example with scp: scp leds-pca995x.ko [email protected]:/home/root NOTE: The linux version of .ko file must be the same as EVK. On the EVK. Switching the device tree.   To copy the updated device tree to the corresponding partition, first create a directory. mkdir Partition_1 Mount the partition one. mount /dev/mmcblk1p1 Partition_1/ Copy or move the device tree into partition one. cp imx8mm-evk-8mic-revE.dtb Partition_1/ Reboot the board. reboot Stop on u-boot and modify the .dtb file to use the device tree for 8mic board. u-boot=> editenv fdtfile edit: imx8mm-evk-8mic-revE.dtb u-boot=> saveenv Saving Environment to MMC... Writing to MMC(1)... OK u-boot=> boot Installing a led driver.   Execute the following command to load the led driver into the kernel. insmod leds-pca995x.ko And you will see something like: [ 249.359103] leds_pca995x: loading out-of-tree module taints kernel. [ 249.366864] ALL [ 249.368740] ALL 0 [ 249.370667] ALL 1 [ 249.372609] ALL 2 [ 249.374536] ALL 2 [ 249.376475] ALL 2 [ 249.378401] ALL 2 [ 249.380338] ALL 2 [ 249.382264] ALL 2 [ 249.384202] ALL 2 [ 249.386127] ALL 2 [ 249.388063] ALL 2 [ 249.389989] ALL 2 [ 249.391913] ALL 2 [ 249.393847] ALL 2 [ 249.395774] ALL 2 [ 249.397709] ALL 2 [ 249.399635] ALL 2 [ 249.401568] ALL 2 [ 249.403496] ALL 3 Turning on a Led.   If you changed the device tree, you can turn on a led with the following command: echo 250 > /sys/class/leds/pca995x\:blue0/brightness To turn off a led: echo 0 > /sys/class/leds/pca995x\:blue0/brightness The red, blue and green leds can be turned on at different intensities provided. Testing the push buttons.   If you changed the device tree, you can test the push buttons with the following command: evtest Select the correct number: No device specified, trying to scan all of /dev/input/event* Available devices: /dev/input/event0: 30370000.snvs:snvs-powerkey /dev/input/event1: sw_keys /dev/input/event2: gpio_ir_recv Select the device event number [0-2]: 1 And you will see: Input driver version is 1.0.1 Input device ID: bus 0x19 vendor 0x1 product 0x1 version 0x100 Input device name: "sw_keys" Supported events: Event type 0 (EV_SYN) Event type 1 (EV_KEY) Event code 67 (KEY_F9) Event code 113 (KEY_MUTE) Event code 114 (KEY_VOLUMEDOWN) Event code 115 (KEY_VOLUMEUP) Properties: Testing ... (interrupt to exit) Event: time 1642457988.1642457988, type 1 (EV_KEY), code 114 (KEY_VOLUMEDOWN), value 1 Event: time 1642457988.1642457988, -------------- SYN_REPORT ------------ Event: time 1642457988.1642457988, type 1 (EV_KEY), code 114 (KEY_VOLUMEDOWN), value 0 Event: time 1642457988.1642457988, -------------- SYN_REPORT ------------

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！

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.

Hey everyone !! This piece covers how to configure the iMX93EVK board to wake up Cortex A55[ running Linux] from Cortex M33 core[running a bare metal application].    We will be using UART console on Cortex M33 to signal Cortex A55 via RPMSG to wake-up from deep sleep.   This can be done as follows:-   1. Boot iMX93EVK with RPMSG enabled DTB and load M33 binary via UBOOT   After booting to Uboot terminal, set the fdtfile variable to <rpmsg dtb> that will help us enable rpmsg in the kernel.   u-boot=> setenv fdtfile imx93-11x11-evk-rpmsg.dtb u-boot=> setenv bootargs ${jh_clk} ${mcore_clk} console=${console} root=${mmcroot}   then, load the M33 binary from the eMMC partition    u-boot=> fatload mmc 0:1 0x80000000 imx93-11x11-evk_m33_TCM_power_mode_switch.bin 18996 bytes read in 14 ms (1.3 MiB/s)   u-boot=> cp.b 0x80000000 0x201e0000 0x4a34 u-boot=> saveenv Note:-  Do not run the M33 core via bootaux at this point, instead just boot to Linux   u-boot=> boot         2. Starting the Cortex M33 core from Cortex A55[running Linux]   Once linux is up, load the elf of Cortex M33 power mode switch application.   echo ~/power_mode_switch.elf > /sys/devices/platform/imx93-cm33/remoteproc/remoteproc0/firmware   start the M33 core   echo start > /sys/devices/platform/imx93-cm33/remoteproc/remoteproc0/state   On console of Cortex M33 you will see the output as below:-   The log below shows the output of the power mode switch demo in the terminal window: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Start SRTM communication Task 1 is working now #################### Power Mode Switch Task #################### Build Time: Nov 10 2023--15:15:16 Core Clock: 200000000Hz Select the desired operation Press A to enter: Normal RUN mode Press B to enter: WAIT mode Press C to enter: STOP mode Press D to enter: SUSPEND mode Press W to wakeup A55 core Press M for switch M33 Root Clock frequency between OD/ND. Waiting for power mode select.. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~   M33 at this point is ready to wake up the A55 core.     3. Put A55 core to deep sleep and trigger a wakeup from M33 console   To put A55 to deep sleep   echo mem > /sys/power/state you will see something like below on linux console:-     At this point, A55 core is in deep sleep power saving mode. So the A55 console will not respond to any of the key presses. Go on, give it a try 🙂   Now to wake up this core, go to M33 serial console and type 'W'  This will wake up A55 core and you will see the logs denoting that the core has woken up:-   That's it! that's how you exercise UART wake-up functionality on imx93evk. Please feel free to drop any follow-up questions or additional thoughts on this.