This is the procedure and patch to set up Ubuntu 13.10 64bit Linux Host PC and building i.MX28 L2.6.35_1.1.0_130130. It has been tested to build GNOME profile and with FSL Standard MM codec. A) Basic Requirement: Set up the Linux Host PC using ubuntu-13.10-desktop-amd64.iso Make sure the previous LTIB installation and the /opt/freescale have been removed B) Installed the needed packages to the Linux Host PC $ sudo apt-get update $ sudo apt-get install gettext libgtk2.0-dev rpm bison m4 libfreetype6-dev $ sudo apt-get install libdbus-glib-1-dev liborbit2-dev intltool $ sudo apt-get install ccache ncurses-dev zlib1g zlib1g-dev gcc g++ libtool $ sudo apt-get install uuid-dev liblzo2-dev $ sudo apt-get install tcl dpkg $ sudo apt-get install asciidoc texlive-latex-base dblatex xutils-dev $ sudo apt-get install texlive texinfo $ sudo apt-get install lib32z1 lib32ncurses5 lib32bz2-1.0 $ sudo apt-get install libc6-dev-i386 $ sudo apt-get install u-boot-tools $ sudo apt-get install scrollkeeper $ sudo apt-get install gparted $ sudo apt-get install nfs-common nfs-kernel-server $ sudo apt-get install git-core git-doc git-email git-gui gitk $ sudo apt-get install meld atftpd $ sudo ln -s /usr/lib/x86_64-linux-gnu/librt.so   /usr/lib/librt.so C) Unpack and install the LTIB source package and assume done on the home directory: $ cd ~ $ tar -zxvf L2.6.35_1.1.0_130130_source.tar.gz $ ./L2.6.35_1.1.0_130130_source/install After that, you will find ~/ltib directory created D) Apply the patch to make L2.6.35_1.1.0_130130 could be installed and compiled on Ubuntu 13.10 64bit OS $ cd ~/ltib $ git apply 0001_make_L2.6.35_1.1.0_130130_compile_on_ubuntu_13.10_64bit_OS.patch What the patch is doing: a) The patch modifies the following files: dist/lfs-5.1/base_libs/base_libs.spec dist/lfs-5.1/elftosb/elftosb.spec dist/lfs-5.1/lkc/lkc.spec dist/lfs-5.1/mux_server/mux_server.spec dist/lfs-5.1/ncurses/ncurses.spec b) Add the following files to the pkgs directory: pkgs/elftosb-2.6.35.3-1385779630.patch pkgs/elftosb-2.6.35.3-1385779630.patch.md5 pkgs/lkc-1.4-lib.patch pkgs/lkc-1.4-lib.patch.md5 E) Then, it is ready to proceed the rest of the LTIB env setup process: $ cd ~/ltib $ ./ltib -m config $ ./ltib Reference: L2.6.35_1.1.0_130130_docs/doc/mx28/Setting_Up_LTIB_Host_on_Ubuntu_9_04.pdf https://community.freescale.com/docs/DOC-93394 https://community.freescale.com/message/332385#332385 https://community.freescale.com/thread/271675 https://community.freescale.com/message/360556#360556 scrollkeeper is for the gnome-desktop compilation elftosb compilation issue fixed by added -lm to LIBS in the elftosb-2.6.35.3-1.1.0/makefile.rules NOTE: When compiling gstreamer, this warning was pop up.  Just ignore it seems okay.

Dear,   We want to start application program from bootloader, we have below questions: We we use I.MX6UL bootrom start BootLoader， we need use mkimage.sh, compile and generator bin file, then we convert to executable file. If we need use Bootloader run application program,whether application image also need convert by mkimage.sh?  The file which convert by mkimage.sh is compressed file. we do not know its format, how about its start address, how to realize the the address jump, do you have example? Thanks.  

The document includes the following contents: (1)document how to port ov5646 to android jb4.2.2 (2) ov5645 driver for Linux 3.0.35 (3) ov5645 schematic based on i.MX6Q/DL (4)ov5645 for android camera HAL   [Note:]      P5V29A-0JG is a camera module based on OV5645, and PAO532-0JG is based on OV5640, both manufactured by NINGBO SUNNY OPOTECH CO.LTD (China), If customer wants to use them on i.MX6 platform, can send me email to ask for datasheets of P5V29A & PAO532 , or discuss corresponding questions on porting.   Email: weidong.sun@freescale.com

Add kcontrol API for Headphone Jack and Spk for WM8962, from this kcontrol, you can use amixer to change freely between Headphone and Spk. The names of the mixers 1: HP Function 2: SPK Function amixer controls: numid=62,iface=MIXER,name='HP Function' numid=63,iface=MIXER,name='SPK Function' 1: How to enable HeadPhone using this Kcontrol: amixer cget numid=62 numid=62,iface=MIXER,name='HP Function'    ; type=ENUMERATED,access=rw------,values=1,items=2    ; Item #0 'off'    ; Item #1 'on'    : values=0 amixer cset numid=62 1 //enable HP numid=62,iface=MIXER,name='HP Function'    ; type=ENUMERATED,access=rw------,values=1,items=2    ; Item #0 'off'    ; Item #1 'on'    : values=1 2: How to enable Speaker using this Kcontrol: amixer cget numid=63 numid=63,iface=MIXER,name='SPK Function'    ; type=ENUMERATED,access=rw------,values=1,items=2    ; Item #0 'off'    ; Item #1 'on'    : values=0 amixer cset numid=63 1 //SPK enable numid=63,iface=MIXER,name='SPK Function'    ; type=ENUMERATED,access=rw------,values=1,items=2    ; Item #0 'off'    ; Item #1 'on'    : values=1

       There are 8 UART ports on i.mx6ul and one uniform Linux driver for these UARTs. Form UART1~UART6, there is no special operation or attention to use them. But for UART7/UART8, there is a special rule to enable them.       According to i.mx6ul RM, we can see UART7/8 RTS pins are muxed with ENET TX_CLK pins. When SION bit of ENET_TX_CLK is set, we need switch to other MUX mode as input signal for UARTx_RTS. Otherwise, UARTx_RTS will be interrupted by loopback ENET clock signal. So we should set IOMUXC_UART7_RTS_B_SELECT_INPUT and IOMUXC_UART8_RTS_B_SELECT_INPUT registers to 0x2/03 to avoid ENET clock's conflict no matter whether we enable UART7/8 RTS/CTS function or not. Let's summarize the different scenarios to enable UART7/8 as follows: 1. ENET driver is disabled and UART7/8 is enabled. There is no special operation to do, just use UART7/8 like other UARTs 2. ENET and UART7/8 are both enabled. There are two use models, RTS/CTS enabled or disabled.     2a. If we enable RTS/CTS feature and configure RTS/CTS pins in the device tree, of course, we should avoid the conflict between UART CTS/RTS pins and ENET TX_CLK pins. There is no special operation to do becuase your RTS/CTS device tree would automatically set  IOMUXC_UART7_RTS_B_SELECT_INPUT/ IOMUXC_UART8_RTS_B_SELECT_INPUT register to correct value.     2b. If we don't enable RTS/CTS feature and no RTS/CTS pin configuration in devcie tree, we should manually add code to set  IOMUXC_UART7_RTS_B_SELECT_INPUT/  IOMUXC_UART8_RTS_B_SELECT_INPUT register because the default value is 0x0(ENETx_TX_CLK_ALT1) Here is an example to show how to use UART7 on EVK board in scenario 2b. 1. modify imx6ul-14x14-evk.dts to enable UART7     a. remove all  LCD settings to disable lcdif because we configure UART7 TX/RX pin pad to LCD data line     b. add UART7 related settings                &uart7 {                     pinctrl-names = "default";                     pinctrl-0 = <&pinctrl_uart7>;                    status = "okay";                 };               &iomuxc {                   pinctrl-names = "default";                   pinctrl-0 = <&pinctrl_hog_1>;                   ....                           pinctrl_uart7: uart7grp {                           fsl,pins = <                                       MX6UL_PAD_LCD_DATA16__UART7_DCE_TX 0x1b0b1                                       MX6UL_PAD_LCD_DATA17__UART7_DCE_RX 0x1b0b1                           >;                  }; 2. add code to set IOMUXC_UART7_RTS_B_SELECT_INPUT register in arch/arm/mach-imx/mach-imx6ul.c          static void __init imx6ul_init_machine(void)          {               struct device *parent;               void __iomem *iomux;               struct device_node *np;               ...........               imx6ul_pm_init();               np = of_find_compatible_node(NULL,NULL,"fsl,imx6ul-iomuxc");               iomux = of_iomap(np, 0);               writel_relaxed(0x2,iomux+0x650);            } 3. build zImage and imx6ul-14x14-evk.dtb 4. Test in linux console      root@imx6ulevk: ls /dev/ttymxc*                      //you can see ttymxc6 is in the list     root@imx6ulevk: echo hello > /dev/ttymxc6         root@imx6ulevk:

Background Configure Trace32 Attach to SCFW with Lauterbach Snooping Perf Examples Example 1 : Snoop a function call (or a variable) Example 2: MonitorFrame Per Second Example 3: Monitor Frame Per Second and rendering size Background None of my automotive have trace pins on their board. Trace is consequently not possible. Anyway you can do "Snooping" with your Lauterbach JTAG probe. Snooping just send data as fast as possible. In the following example I will Snoop the i.MX8X' SCFW, notice I do not have the sources (except board.c) but I have the elf file (thus I have debug info with functions names for instance). Notice Snooping is available on all MCU/MPU with JTAG.   In my case I used it for the first time in 2015 on Vybrid, our first heterogeneous dual core (Cortex-A5 & Cortex-M4) with no XRDC... My customer has sent the final product with a JTAG connector and flashed SW product to me. I had a laconic comment: "software is done all around the world in UK, India and the US, when we flash all the software the Vybrid Reset for some version, we don't have the sources for this specific software we have flashed in this product. Good Luck". In this case snooping on both core at the same time was the only solution for me... At the end I have discovered (thanks to the last PC addresses before the crash) the cortex-A5 was deconfiguring a pin of the QSPI flash interface on which the M4 was eXecuting In Place (XiP). Configure Trace32 When your Trace32 is open, CPU>>System Settings... menu and configure the JtagClock as fast as possible (here 40MHz) to have fast data streaming: go in Trace>>Configuration menu Select "SNOOPer" Select to stream the Pointer Counter thus select the mode "PC" Pass to State to "Arm" You can increase also the SIZE of the buffer Launch your code: Attach to SCFW with Lauterbach In Trace32, CPU>>System Settings, chose IMX8QXP-SCU: And then do an "Attach": Then yu should see your SCU core running: Snooping And break your code, your "used" field " should be filled: Open Trace>>List>>Default Click on "Chart" On the trace list you can see the sampling rate: around 48µs in our case. It means you may (almost) not see functions lasting less than 48µs (depends when it is sampled), or you'll see it sometimes. But for performance analysis it can be useful to see which function is too slow (rather then instrument the code), but as I mentioned in my case function has to last more than 48µs! Perf You can also get Performance analysis. But keep in mind if your function is faster than 48µs in my case, the result will not be accurate! Go in Perf>>Perf Configuration (it can also be done un real time with Perf>>Perf List Dynamic)... and select "Snoop": Then put the State in "Arm" and click on "List" to open the "List Window" Launch your code and stop it. In the "List" window you'll see all the function ranked according to their usage occurrence (my SCFW is almost always in sleep!) Examples Example 1 : Snoop a function call (or a variable) With Snooping you cannot trace a function calls. To do that I add a global variable in the function. You'll have a little overhead due to that. I will use an i.MXRT1170 with the SDK 2.6.1. I have built the Tiger example (vglite). April 4th 2020: i.MXRT1170 is not public, meaning not officially supported by Lauterbach. Please follow the instruction in my SharePoint folder (if the link disappears, it may signify i.MXRT1170 is supported) to add support of the i.MXRT1170. https://nxp1-my.sharepoint.com/:f:/g/personal/vincent_aubineau_nxp_com/Ej8ID8mXaNZPnVgTWgYgqHQBzR0XcE0K4sl1WusR3UMBnw?e=…  I want to know the framerate. To do that I have to monitor the redraw() calls. What I do, is I put the "n" variable as global. Trace>>Configuration ... Chose "memory" and "changes" (to log only when the variable is changing): Then then click on select... and "i" Search for "n" variable and select it: Launch your software and then do a break. Click on "List": You have the list of your function call (as you can see it is not always the same), in the "ti. call" you have the duration between 2 call (keep in mind the function must not be called at high frequency: If you click on "draw", you can display the variable values (click on  to scale it): Example 2: Monitor Frame Per Second I can also monitor the fps if I pass "time" variable global: And you can have a reprensentation of you fps (notive I have unchecked "Changes" to have an easy to intrepret curve Example 3: Monitor Frame Per Second and rendering size Results often depends of several variables. If you display 2 variables on 1 display window, if the 2 variable does not have the same range, it is not easy to observe. The best solution I have found in this case is to have 2 "Draw" Windows. Add the 2 variables in the "SElect" field ("time" and "ScaleCount", beware, it is case sensitive). Launch your code, and stop it after a while. Then right click on the "time" and "ScaleCount" variable in your code to display 2 "Draw" window: Thus you have 2 "Draw" windows, and you see FPS depends on rendering size... logical!  

Video Tips for video in host side Testing Image Sensor and Display Testing on i.MX31 PDK Gstreamer in the iMX board The i.MX family has a big set of plugins that enable a lot of formats. It has some hardware acceleration, but each board has some peculiarities. I.MX27ADS Board I.MX51EVK Board I.MX53QSB Board How to create an application to play Audio+Video using gstreamer TV Out - Configuring I.MX27ADS TV Out AlphaBlending AlphaBlending is used to exibhit two images on display, one of these is transparent image. Normally you use a solid background image and a transparent (alpha) image on foreground. i.MX31PDK AlphaBlending DirectFB i.MX31PDK DirectFB How to get a screenshot from framebuffer display? i.MX31PDK Screenshot Theora Creating a Theora Encoder Example

The imx_bootlets package in LTIB contains the code that will be the first code loaded and executed by ROM when booting a build of the Linux BSP. It is responsible for initializing some of the low level peripherals such as the integrated power supply and the DRAM controller as well as a few other initialization tasks. The default configuration of the bootlet code for the latest i.MX233 and i.MX28x release (SDK 10.05 and SDK 10.12 respectively) support a hardware configuration that has both a LiIon battery configuration (as shown in the reference schematics for these platforms as shown on freescale.com). For other configurations though such as a VDD5V connection only or a DCDC_BATT/Battery connection only, some additional changes are recommended.

This page describes how to determine the NAND timing parameters for use in the NAND driver. This is independent of any OS that may be used. Analyzing NAND Datasheets  We use a spreadsheet to capture and analyze NAND features. That spreadsheet is [attached to this wiki page|Adding support for a new NAND with i.MX28– Nand Analysis^nand_analysis_template.xls]. We analyze a NAND as described below. We must have the NAND datasheet to do the analysis. Copy the *analysis spreadsheet* to a new filename with the exact part number(s) of the NAND(s) being analyzed. Fill in sheet 1 ("Cover Page") of the analysis spreadsheet. Work on sheet 3 next: Fundamental Features. Other tables. If the NAND is one of a family listed together in a data sheet, then analyze the whole family with one spreadsheet. You can use the "Similar to" rows for the additional members of the family. Add more rows if needed. Most NANDs have an asyncrhronous interface, so there is not a simple clock frequency involved. Instead, there are various setup times, hold times, and output delays that imply limits on the I/O rate to/from the NAND. The spreadsheet compares the NAND's timing specifications to see if sums of the setup, hold, and output times are shorter than the minimim read-cycle or write-cycle times. The spreadsheet is specifically intended for use with the Nand controller in STMP378x/i.MX233/i.mx28 chips, so the spreadsheet performs the timing calculations with the goal of deriving the timing parameters *TSU*, *TDS*, and *TDH* for those CPUs. If the TDS and/or TDH quantities {color:#ff0000}turn red{color} after all the timings have been computed, then the computed TDS and/or TDH are too short for the specified cycle-time of the NAND. In that case:           You will have to increase one or both of them in the software. Write a note somewhere in the analysis spreadsheet about the values that you choose, but don't mess up the automatic computations. Record how the flash denotes factory-marked bad-blocks. (Some use the first page of a block, some use the last page,, etc.) Compare it to this [current superset of bad-block marking methods [http://wiki.freescale.net/display/PSGSW/Storage+Media%2C+Flash+Bad+Block+Marks] used to detect any flash factory bad block. Example Analysis Examples of NAND datasheets and analyses can be found on the [Hynix NAND Page | http://wiki.freescale.net/display/PSGSW/Hynix+NAND+Flash+Documents].

i.MX27 and i.MX31 Issues When Interfacing Micron's 78nm mDDRs Micron is discontinuing some "-75" mDDR parts (133MHz) popular on i.MX27 and i.MX31 designs, newer "-6" are being used to replace the EOL devices. However, loss of data issues may be experienced when i.MX mDDR controller is used to interface with newer Micron's mDDR. On some cases, the bootloader works, memory tests on RedBoot pass. However, Linux hangs when booting. Here are the DDR Controller configuration changes that may be used to avoid the issue: (This configuration is not proven to work on every design, but has been validated on at least 3 different boards.) ESDRAMC Configuration Registers Set ESDCFG0/1 to 0x0079D72F 0xD800_1004 = 0x79D72F Drive Strength Control Registers Use "Normal". i.MX27 Default. Enhanced MDDR Delay Line Configuration Debug Register Set the ESDCDLYx to 0x002C0000 0xD800_1020 = 0x2C0000 0xD800_1024 = 0x2C0000 0xD800_1028 = 0x2C0000 0xD800_102C = 0x2C0000

These are my notes for compiling Qt 5.3.0 release using the fsl-community-bsp and the meta-qt5 layer graciously provided by the much lauded Otavio and Martin Jansa.  My test board is the wandboard solo.  My original procedure was based on this document: Compiling Qt5.3.0-beta1 on Yocto which was in turn based on this tutorial: Building Qt5 using yocto on Wandboard - Wandboard Wiki Steps to build: repo init -u https://github.com/Freescale/fsl-community-bsp-platform -b daisy; repo sync cd sources; git clone https://github.com/cetola/meta-qt5.git **as of this commit: https://github.com/meta-qt5/meta-qt5/commit/e9ad98bbed6065989ef4648e724f27275b35b838 the meta-qt5 official repo is now using qt 5.3.  I won't be updating my layer, and I suggesting using theirs. add to bblayers.conf:   ${BSPDIR}/sources/meta-openembedded/meta-ruby \   ${BSPDIR}/sources/meta-qt5 \ add to local.conf: DISTRO_FEATURES_remove = "x11 wayland" PACKAGECONFIG_append_pn-qtmultimedia = " gstreamer010 " bitbake wandboard-image-qt5 I will do my best to keep this working with the latest in daisy. Current functionality includes playing hardware accellerated video in QML.  However, examples such as multimediawidgets/player,  multimediawidgets/videowidget do not play video. Also qtwebkit/browser, qtwebkit/youtubeview qtwebkit/fanicybrowser do not support HTML5 video. Comments welcome. Cheers, Stephano

ERR005723           PCIe: PCIe does not support L2 Power Down   Description: When PCIe works as Root Complex, it can exit L2 mode only through reset. Since PCIe doesn't have a dedicated reset control bit, it cannot exit L2 mode.   Projected Impact: PCIe does not support L2 Power Down   Workarounds: The PCIe can be put in PDDQ mode to save on PCIe PHY power and wakeup only by the OOB (Out of Band) wakeup signal (since wakeup by a beacon from link partner is not supported) driven from the link partner (End Point). This signal could be used as a GPIO interrupt to exit this mode. The limitation of this workaround is that the link partner cannot be put into L2.   Proposed Solution:                 No fix scheduled   Linux BSP Status:                 No software workaround available   SW workaround used to fix ERR005723 in Linux BSP Why the original workarounds can’t be implemented in Linux BSP * PCIe controller doesn’t have the reset mechanism that can be used when re-insmod the PCIe driver without power down/up PCIe module. * During the PCie driver rmmod/insmod operations, the PCIe CLKs would be turned off/on. IC can’t guarantee that the PCIe PHY can work well and re-establish the PCIe link properly. One SIMPLE SW workaround for this errata imx: pcie: toggle bit18 of grp1 fix pcie can't exit L2 issue.   Set bit18 of gpr1 before enter into supend, and clean it after resume, can fix the following errata. Errata ERR005723_PCIe PCIe does not support L2 Power Down. About the details, please refer to the attached patch. "0001-imx-pcie-toggle-bit18-of-grp1-fix-pcie-can-t-exit-L2.patch"   The conception of the other SW workaround (System warm-reset) The procedures of the original suspend/resume. Suspend User suspend command echo mem > /sys/power/state All driver call suspend function SRPG,  ARM save all state to memory Enter Stop mode and Power down ARM Resume: GPC receive IRQ Wake up system Power on ARM domain. ROM code running Jump to SRPG point Recovery ARM status from memory Call all devices resume function. Because PCIe only reset by system reset, we need change above follow. Resume: GPC receive IRQ Wake up system Power on ARM domain. ROM code running Jump to SRPG point Warm Reset system, memory context will be kept. But all peripheral status lost. ROM code running Jump to SRPG point again. Recovery ARM status from memory Call all devices resume function. Resume function call init to initialize it.  And recover to the status saved before. Impact: Can’t support usb remote wake up, which required 4ms responsive Longer latency, warm reset need some ms.  The recovery of the device status needs some more ms. Risk: Current BSP have not tested above follow Device driver have not supported this follow yet. Need additional work to enable \debug\test it. Modules enabled in this workaround now: * UART* ENET* PCIe Tests procedure. HW: one i.MX6Q SD boards, and one INTEL pciex1 1000M CT network card. SW(The images used by me are attached): * Apply the attached patches(kernel and uboot) to the kernel/uboot source codes, re-build, get the images. Kernel is based on imx_3.0.35_4.0 release, uboot , is based on imx_v2009.08 # build out SD/MMC and USB driver to make DRAM hibernate work # build pcie in. *procedure of the suspend/resume tests;     # unload ep's driver --> suspend/resume --> reload ep's driver. NOTE: Please make sure that the command line contains “no_console_suspend”The command used to enable the console input wake up after login the consol:echo enabled > /sys/devices/platform/imx-uart.0/tty/ttymxc0/power/wakeup Log when the INTEL CT 1G network card is used: -------------------------------log--------------------------------------------PM: Syncing filesystems ... done.                                             start suspendFreezing user space processes ... (elapsed 0.01 seconds) done.Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.add wake up source irq 101add wake up source irq 99add wake up source irq 103add wake up source irq 51add wake up source irq 58PM: suspend of devices complete after 15.482 msecsPM: late suspend of devices complete after 0.823 msecsDisabling non-boot CPUs ...CPU1: shutdownCPU2: shutdownCPU3: shutdownIMX PCIe imx_pcie_pltfm_suspend entering.IMX PCIe imx_pcie_pltfm_suspend exit.          suspendedU-Boot 2009.08-00679-g6ec6783 (May 20 2013 - 14:50:20)     resumeCPU: Freescale i.MX6 family TO1.2 at 792 MHzsrc 0x92eac8resume 0x92eac8jump to resumeIMX PCIe imx_pcie_pltfm_resume entering.IMX PCIe imx_pcie_pltfm_resume pcie start re-link.IMX PCIe port imx_pcie_pltfm_resume: re-link up.Enabling non-boot CPUs ...CPU1: Booted secondary processorCalibrating delay loop (skipped) already calibrated this CPU i.MXC CPU frequency driver CPU1 is upCPU2: Booted secondary processorCalibrating delay loop (skipped) already calibrated this CPU i.MXC CPU frequency driver CPU2 is upCPU3: Booted secondary processorCalibrating delay loop (skipped) already calibrated this CPU i.MXC CPU frequency driver CPU3 is up PM: early resume of devices complete after 0.974 msecs remove wake up source irq 58 imx-ipuv3 imx-ipuv3.0: IPU DMFC DP HIGH RESOLUTION: 1(0,1), 5B(2~5), 5F(6,7) imx-ipuv3 imx-ipuv3.1: IPU DMFC DP HIGH RESOLUTION: 1(0,1), 5B(2~5), 5F(6,7) remove wake up source irq 51 remove wake up source irq 103 remove wake up source irq 101 remove wake up source irq 99 PM: resume of devices complete after 54.174 msecs Restarting tasks ... done. PHY: 1:01 - Link is Up - 100/Full                            resume is ok, reload ep’s driver num is 61 e1000e: Intel(R) PRO/1000 Network Driver - 1.3.10-k2 e1000e: Copyright(c) 1999 - 2011 Intel Corporation. e1000e 0000:01:00.0: Disabling ASPM L0s e1000e 0000:01:00.0: (unregistered net_device): Failed to initialize MSI-X interrupts.  Falling back to MSI interrupts. e1000e 0000:01:00.0: (unregistered net_device): Failed to initialize MSI interrupts.  Falling back to legacy interrupts. e1000e 0000:01:00.0: eth1: (PCI Express:2.5GT/s:Width x1) 00:1b:21:3a:18:8b e1000e 0000:01:00.0: eth1: Intel(R) PRO/1000 Network Connection e1000e 0000:01:00.0: eth1: MAC: 3, PHY: 8, PBA No: E42641-005 e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx PING 192.168.0.1 (192.168.0.1): 56 data bytes 64 bytes from 192.168.0.1: seq=0 ttl=64 time=3.126 ms 64 bytes from 192.168.0.1: seq=1 ttl=64 time=0.244 ms 64 bytes from 192.168.0.1: seq=2 ttl=64 time=0.232 ms 64 bytes from 192.168.0.1: seq=3 ttl=64 time=0.206 ms 64 bytes from 192.168.0.1: seq=4 ttl=64 time=0.222 ms 64 bytes from 192.168.0.1: seq=5 ttl=64 time=0.207 ms 64 bytes from 192.168.0.1: seq=6 ttl=64 time=0.250 ms 64 bytes from 192.168.0.1: seq=7 ttl=64 time=0.209 ms 64 bytes from 192.168.0.1: seq=8 ttl=64 time=0.154 ms 64 bytes from 192.168.0.1: seq=9 ttl=64 time=0.211 ms   --- 192.168.0.1 ping statistics --- 10 packets transmitted, 10 packets received, 0% packet loss round-trip min/avg/max = 0.154/0.506/3.126 ms PM: Syncing filesystems ... done.                                   ep’s functions are ok, re-do the suspend/resume tests Freezing user space processes ... (elapsed 0.01 seconds) done. -------------------------------end-------------------------------------------- Original Attachment has been moved to: uboot_patch_image.zip Original Attachment has been moved to: 0001-imx-pcie-toggle-bit18-of-grp1-fix-pcie-can-t-exit-L2.patch.zip Original Attachment has been moved to: kernel_patch_image.zip

This documents describes how to add the NFC support to i.MX8M mini evk running Android Pie. Hardware setup: The i.MX8M mini evk (see i.MX 8M Mini Evaluation Kit | NXP) featuring Raspberry Pi compliant connector, the OM5578/RPI PN7150 demo kit can be used to perform this porting (see NFC Development Kits for Arduino and more|NXP). However a small modification must be done because some of the signals required by PN7150 are not mapped to i.MX8M mini expansion connector pins. OM5578 IRQ signal must be mapped to Raspberry Pi connector pin #19 and OM5578 VEN signal must be mapped to Raspberry Pi connector pin #21. See below a picture of the modification: Then, the two boards can fit together as shown in the picture below: Quick start using demo image: The demo image including support for PN7150, is based on Android P9.0.0 Pie (P9.0.0_1.0.0, 4.14 kernel) i.MX software release (see i.MX Software | NXP). Related documentation can be downloaded from here: https://www.nxp.com/docs/en/supporting-information/android_p9.0.0_1.0.0-ga_docs.zip. Just flash the demo image (downloaded from here:https://www.nxp.com/lgfiles/updates/NFC/ANDROID_P9-0-0_PN7150_IMAGE_8MMEVK.zip) following guidelines from i.MX_Android_Quick_Start document (part of Android P9.0.0_1.0.0 Documentation package mentioned above). The NFC support is then included in the device settings, as shown in below screenshot of the device: Approaching the NFC tag, provided as reference in the OM5578 demo kit, to the NFC Antenna will trigger a sound notification: Unfortunately the Android demo image doesn't embed a web browser, so it won't be automatically open when the NFC tag content (an URL to the demo kit web page) is read. Otherwise (if a web browser is installed) you could see such page opening on the device: Adding PN7150 support to imx-android-pie release: If you wish to add PN7150 support to your imx-android-pie environment, just apply the patches (imx-p9.0.0_1.0.0-ga_pn7150_patches.tar.gz file attached) from the ${MY_ANDROID} source code root folder (refer to i.MX_Android_User_Guide document part of Android P9.0.0_1.0.0 Documentation package mentioned above).  $ patch -p1 -d device/fsl/ <device_fsl.patch  $ patch -p1 -d packages/apps/Nfc <packages_apps_Nfc.patch  $ patch -p1 -d hardware/nxp/nfc <hardware_nxp_nfc.patch  $ patch -p1 -d vendor/nxp <vendor_nxp.patch  $ patch -p1 -d vendor/nxp-opensource/kernel_imx/ <vendor_nxp-opensource_kernel_imx.patch When building, the PN7150 support will then be included to the android image, as shown in the demo image described above. Reference: This porting have been done (demo image and patches creation) following guidelines provided in AN11690_NXP-NCI_Android_Porting_Guidelines document.

Hypoxemia is a common clinical condition associated to several diseases that affect the respiratory system, including not only the lungs diseases, but also cardiac, neurological, neuromuscular and chest wall diseases. Its occurrence bring serious risks being essential its detection for appropriate treatment, and even to prevent the death of the patient. Hypoxemia is defined as the low saturation of oxygen carried by the blood. The most efficient way to determine the oxygen saturation is the gasometry, an invasive method (through the collection of blood) which is able to determine the gases present in the blood as well as its relative amount, as well as other data related to the blood. The Oximetry is a less effective method, but not least important, because of its practicality for not being an invasive method. Depending on the quality of the equipment, it can ensure very small variations with respect to the gasometry. In some cases, the constant monitoring of oxygen saturation is required. The portable oximeters are useful in such cases due to their ease of use. For monitoring oxygen saturation in the blood and also the heart rate, the machine suitable for this purpose is the Pulse Oximeter. Such equipment can be easily purchased at a low cost, but requires an assisted operation for each measurement, by the user or another person. This project proposed the development of a device capable of measuring blood oxygen saturation and heart rate. The data collected will be transmitted to a Smartphone, featuring an Android Application that displays the received data to the user and sends an automatic message to a health care center with the user's location in case of emergency. The project will also have sensors (accelerometers) to detect when the user has lost concience and fallen to the ground. This device will help to people with a history of health problems such as hypertension, hypoxia, risk of heart attack, among other diseases, giving them more autonomy, since in case of any health problems, somebody will be informed. The mobile monitoring of vital signals will detect when these signals vary significantly out of a safe range, and upon such occurrance a message is sent to pre-registered telephone numbers informing the user's location, and that he needs help help. The device will monitor the blood oxygen level and heart rate by measuring the change in the transparency of the blood through the presence of oxygen saturated hemoglobin is made. The measurement is taken by the emission of light at two wavelengths (red and infrared), where a sensor detects the intensity of light that is absorbed by hemoglobin, which depends on the degree of oxygen saturation. From the comparison between the received signals for each wavelength, it is possible to determine the degree of oxygen saturation in the blood. The meter is controlled by a microcontroller to be selected for this project. There will be a Bluetooth module connected to the microcontroller in order to establish the communication between the device and a paired Smartphone. An Android App will be developed to control the communicatin, display the user information sent by the device as well as send automatic voice messages to pre-registered telephones. The App will also reproduce additional messages played through the headphones to help the user in using the devices features, and also in case of emergency.

Most engineers should incorporate the following fundamental methodology when designing and bringing up a new board design: 1. Review the schematics and layout to ensure proper connectivity of all devices 2. Once the board returns from the manufacturer, measure and document all of the voltage rails of each IC on the board (especially the SoC and DRAM) 3. Ensure JTAG debugger connectivity (due to the complexity of systems today, every new board design should have some “hooks” to allow JTAG connectivity, even if these are simply test points) 4. Bring up and ensure proper DRAM functionality; it is imperative the first three steps are precisely accomplished – often times, DRAM instability or non functionality is due to improper connection (including not being connected to the voltage net) or poor layout. Once these four steps are completed, the board can then proceed to a more broad based checkout of other peripherals using some type of compiled test code executed from DRAM. More often than not, the end user’s board will differ from Freescale reference design boards either in how the DRAMs are connected or simply by using a different DRAM vendor.  As such, tools were created to aid in the development of DRAM initialization scripts.  The resulting script, though targeted for the RealView development system (aka include files), can be easily ported to another debugger’s command syntax or to assembly code for use in boot loaders.  These tools are Excel spread sheet based and include a “How To Use” tab, making the tool usage relatively self-explanatory.  Each tool is unique to a specific i.MX processor and to the DRAM technology used with each processor.  This attached files are tools available for the following i.MX SoCs:

Hello Android users Sagar has posted on the Element14 community three clear tutorials (accessible following the link below) to create an Android application on the RiOTboard. RIoTboard: Part 1: Build an Android app on RIoT... | element14 RIoTboard: Part 2: Build an Android App on RIoT... | element14 RIoTboard: Part 3: Build an Android App on the ... | element14 I recommend you to start following those steps to ensure a proper setup of the Android tools. Happy Programming Greg

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

- In LTIB generate a rootfs.jffs2 with a erase block size of 16KB: ./ltib -c ---Target Image Generation   Options ---> ---Choose your root file system image type     Target image: (jffs2) --->   (16) jffs2 erase block size in KB - Copy the generated rootfs.jffs2 to /tftpboot : cp rootfs.jffs2 /tftpboot - Program 200732 Redboot binary. The 200732 Redboot is available in the 20071008 BSP iso. After mounting the iso go to the bootloaders directory, extract the redboot_200732.tar.gz file and use the pre-built mx31ads_redboot.bin inside the bin directory. - Boot from NAND and setup the network parameters fis init load -r -b 0x100000 /tftpboot/zImage fis create -l 0x200000 kernel load -r -b 0x100000 /tftpboot/rootfs.jffs2 fis create -l 0x1d000000 root - Pass the following kernel command line: fis load kernel exec -b 0x100000 -l 0x200000 -c "noinitrd console=ttymxc0,115200 root=/dev/mtdblock6 rootfstype=jffs2 init=linuxrc ip=none mtdparts=mx" You need to replace mtdblock6 with your rootfs partition, see below: mx31# cat /proc/mtd dev:    size  erasesize  name mtd0: 00040000 00020000 "RedBoot" mtd1: 001a0000 00020000 "kernel" mtd2: 0001f000 00008000 "FIS directory" mtd3: 00001000 00008000 "RedBoot config" mtd4: 00040000 00004000 "RedBoot" mtd5: 00200000 00004000 "kernel" mtd6: 01d00000 00004000 "root" mtd7: 00003000 00004000 "FIS directory" mtd8: 00001000 00004000 "RedBoot config" mx31#

Yes. The Yocto Project site hosts some of the MX machines here. NOTES: If the machine's folder is present but it is empty, a building error may have occurred. Check the build's status for the machine on the archives or send an email to the list. Due to limited resources, not all (Freescale) machines are (nightly) built, in case you need one of these, you need to bake it yourself. You can start building following these instructions.