Question: 1)      Is WDOG2 somehow accessible from customers code in normal mode? Is it only used within the trust zone to protect against DOS attacks from normal world?) 2)      Is there any mechanism preventing changing of the watchdog registers like being able to write them only during a period after Reset? If yes, which registers are protected? Answer: WDOG1 and WDOG2 are identical the only difference is how the signals are connected. There is nothing presenting someone from using both WDOGs for non-secure purposes. There is no time window for WDOG access but there are some write-once only bits in the register, which can be written only once after reset, after that all following writes will be ignored. They are clearly described in the RM. The bits are: WDZST, WDBG, WDW, WDE, WDT, WIE, WICT, and PDE.

ltib 编译的 解码插件包，官网比较难找到的。

When working on the IOMUX settings of an i.MX processor for our design it’s always good to make use of the IOMUX Tool provided by Freescale on the Download Page of most i.MX processors. We’ll focus on the latest release of the IOMUX tool for i.MX6. The IOMUX tool provides a Graphic User Interface to easily assign internal signals to external pins/balls and resolve any potential pin conflict and muxing options for the different modules available on the i.MX processors. IOMUX Tool Download (Will request to log in) Freescale’s Boards IOMUX settings. On the IOMUX tool package you’ll find the User’s Manual and also a folder containing the muxing options for Freescale’s Reference Boards, which may be of help when working with the Reference Designs as a starting point. You may load these settings files using the file/open option. MMDC pins Since the Multi-mode DDR controller MMDC pins are not muxed these cannot be changed on the IOMUX tool. This because the memory interfaces are much more sensitive to interference and thus have dedicated pins that do not share pad with other signals. The registers are also set on the default value so it’s good to keep this in mind when working with the code provided by the IOMUX tool. Considerations when using generated code The tool can generate code to be used as reference of the IOMUX configuration but still requires manual tweaking and the header files available on the i.MX Processor’s BSP in order to be implemented in an actual application code. It’s important to review the register settings on the Register tab in order to export the desired values; otherwise the code will have the default values for the registers according to the IOMUX tool. This is especially true for the Daisy Chain settings, always manually review these. Import function limitations There is an import function available so IOMUX configuration files saved in previous versions of the IOMUX tool can be loaded on the newest version. However, this feature should be used carefully. When importing a design it’s recommended to save the imported design on the new version of the IOMUX tool as imported.xml; then opening a new configuration and saving it as new.xml and comparing register value differences to manually correct the imported.xml values. In small projects it might be recommended to manually load the IOMUX information on the new IOMUX tool version to avoid register conflicts from version to version. For more information please refer to the documentation available within the IOMUX tool package. An advanced example is also included in that document.

Attached is a chunk of the Filesystem needed to construct the Linux Image https://community.freescale.com/docs/DOC-93887

[中文翻译版] 见附件   原文链接： eIQ Machine Learning Software for i.MX Linux 4.14.y 

Tested on Android 10 (android_Q10.0.0_1.0.0) After your the first BSP build the kernel sources are at: ${MY_ANDROID}/vendor/nxp-opensource/kernel_imx/ For the i.MX8M Mini, You can check the defconfig files being used on: ${MY_ANDROID}/device/fsl/imx8m/evk_8mm/UbootKernelBoardConfig.mk # imx8mm kernel defconfig TARGET_KERNEL_DEFCONFIG := android_defconfig TARGET_KERNEL_ADDITION_DEFCONF := android_addition_defconfig You could change one of them to add the desired configuration. - android_defconfig - is ${MY_ANDROID}/vendor/nxp-opensource/kernel_imx/arch/arm64/configs/android_defconfig - android_addition_defconfig - is on the same folder ${MY_ANDROID}/device/fsl/imx8m/evk_8mm/ "merge_config.sh" is called to generate the final defconfig file prior to building the kernel Check out: https://source.android.com/devices/architecture/kernel/config For example, I want to add DEVMEM support on my build: 1. Change the defconfig I add the line below to android_addition_defconfig CONFIG_DEVMEM=y (Or could have added it android_defconfig) 2. Build the kernel ./imx-make.sh kernel -c -j8 3. Verify your change After compiling, you can confirm your change by reading: ${MY_ANDROID}/out/target/product/evk_8mm/obj/KERNEL_OBJ/.config Then rebuild boot.img and reprogram the target.

The Yocto Project is open-source, so anyone can contribute. No matter what your contribution is (bug fixing or new metadata), contributions are sent through patches to a community list. Many eyes will look into your patch and at some point it is either rejected or accepted. Follow these steps to contribute: Make sure you have previously configured your personal info $ git config --global user.name "Your Name Here" $ git config --global user.email "[email protected]" Subscribed to the Freescale Yocto Project Mailing List Download `master` branches fsl-community-bsp $ repo init \   -u https://github.com/Freescale/fsl-community-bsp-platform \   -b master Update fsl-community-bsp $ repo sync Create local branches so your work is *not* done on master fsl-community-bsp $ repo start <branch name> --all Where `<branch name>` is any name you want to give to your local branch (e.g. `fix_uboot_recipe`, `new_gstreamer_recipe`, etc.) Make your changes in any Freescale related folder (e.g. sources/meta-fsl-arm). In case you modified a recipe (.bb) or include (.inc) file, do not forget to *bump* (increase the value by one) either the `PR` or `INC_PR` value Commit your changes using `git`. In this example we assume your change is on `meta-fsl-arm` folder sources/meta-fsl-arm $ git add <file 1> <file 2> sources/meta-fsl-arm $ git commit On the commit's log, the title must start with the filename change or introduced, then a brief description of the patch's goal, following with a long description. Make sure you follow the standards (type ` git log --pretty=oneline` to see previous commits) Create a patch sources/meta-fsl-arm $ git format-patch -s  --subject-prefix='<meta-fsl-arm][PATCH' -1 Where the last parameter (`-1`) indicate to patch last commit. In case you want to create patches for older commits, just indicate the correct index. If your patch is done in other folder, just make sure you change the `--subject-prefix` value. Send your patch or patches with git send-email --to [email protected] <patch> where `<patch>` is the file created by `git format-patch`. Keep track of patch's responses on the mailing list. In case you need to rework your patch, repeat the steps but this time the patch's subject changes to `--subject-prefix='<meta-fsl-*][PATCH v2'` Once your patch has been approved, you can delete your working branches fsl-community-bsp $ repo abandon <branch name>

This is an example to show how to connect two cameras (with same I2C address) on the i.MX6Q board. In this example, the I2C switch is PCA9543A. Two cameras are OV5640 & OV5645. OV5640 is connected to CSI0, and other one OV5645 is connected to MIPI. The Linux BSP is L3.0.35. In the your_board.c file, add the following for pca954x. static struct pca954x_platform_mode pca954x_modes[] = {      {            .adap_id = 4,            .deselect_on_exit = true,      },      {            .adap_id = 5,            .deselect_on_exit = true,      }, }; static struct pca954x_platform_data pca954x_data = {      .modes = pca954x_modes,      .num_modes = ARRAY_SIZE(pca954x_modes) }; In this example, the I2C switch is connected to i.MX6Q’s I2C0. The I2C address of the PCA9543A is 0x70. static struct i2c_board_info mxc_i2c0_board_info[] __initdata = {      {            I2C_BOARD_INFO("pca9543", 0x70),            .platform_data = (void *)&pca954x_data,      }, }; The channel 0 of PCA9543A is connected to the I2C of OV5645 MIPI. static struct i2c_board_info mux_i2c4_board_info[] __initdata = {      {            I2C_BOARD_INFO("ov5645_mipi", 0x3c),            .platform_data = (void *)&mipi_csi2_data,      }, }; The channel 1 of PCA9543A is connected to the I2C of OV5640 CSI0. static struct i2c_board_info mux_i2c5_board_info[] __initdata = {      {            I2C_BOARD_INFO("ov5640", 0x3c),            .platform_data = (void *)&csi0_camera_data,      }, }; In the board_init function, register the I2C4 and I2C5. i2c_register_board_info(4, mux_i2c4_board_info,                 ARRAY_SIZE(mux_i2c4_board_info)); i2c_register_board_info(5, mux_i2c5_board_info,                 ARRAY_SIZE(mux_i2c5_board_info)); Select the PCA954x driver In kernel configuration In Kernel Configuration, go to Device Drivers --> I2C support --> I2C bus multiplexing support --> Multiplexer I2C Chip support  --> Select <*> Philips PCA954x I2C Mux/switches

Booting from NAND    Some hardware configurations (switches) must be set for booting from NAND:    On the debug board:      Switch SW4 -> 10000001      Switch SW5 -> Off      Switch SW6 -> Off      Switch SW7 -> Off      Switch SW8 -> Off      Switch SW9 -> Off      Switch SW10 -> Off    On the personality board:      Switch SW21 -> 10011000      Switch SW22 -> 00100000 Booting from SD Card    Some hardware configurations (switches) must be set for booting from an SD card:       On the debug board:      Switch SW4 -> 10000001      Switch SW5 -> Off      Switch SW6 -> Off      Switch SW7 -> Off      Switch SW8 -> Off      Switch SW9 -> Off      Switch SW10 -> Off    On the personality board:      Switch SW21 -> 11000000      Switch SW22 -> 00000000   

Q: Does anyone have the Lauterbach script files for connecting to the mx53?  Also,  does anyone know of a converter to convert RealView scripts to Lauterbach? A: Please see below attach.cmm and load_simbols.cmm for i.MX53. attach.cmm ; ; Script to attach to a running system, halt the CPU, ; and display the ASM code ; screen.on ; Debugger Reset winpage.reset area.reset WINPOS 0. 26. 75. 8. 0. 0. W000 area print "resetting ICD..." System.Down Break.Delete MAP.RESet TASK.RESet sYmbol.RESet Data.PROLOG.RESet Data.EPILOG.RESet sYmbol.AutoLoad.CHECK OFF      ; disable dynamic autoloader sYmbol.AutoLoad.RESet          ; reset autoloader list MMU.RESet ; setup of ICD JTAG print "initializing JTAG..." SYStem.CPU CORTEXA8 SYStem.MultiCore IRPOST 0x0 SYStem.MultiCore IRPRE 0x0 SYStem.MultiCore DRPOST 0x0 SYStem.MultiCore DRPRE 0x0 SYStem.MultiCore DAPIRPOST 0x09 SYStem.MultiCore DAPIRPRE 0x0 SYStem.MultiCore DAPDRPOST 0x02 SYStem.MultiCore DAPDRPRE 0x0 SYStem.MultiCore MEMORYACCESSPORT 0 SYStem.MultiCore DEBUGACCESSPORT 1 SYStem.MultiCore COREBASE APB:0xC0008000 SYStem.Option DACR ON          ; give Debugger global write permissions TrOnchip.Set DABORT OFF        ; used by Linux OS for page miss! TrOnchip.Set PABORT OFF        ; used by Linux OS for page miss! TrOnchip.Set UNDEF OFF         ; let UNDEF be handled by Linux OS SYStem.Option MMU ON           ; enable space ids to virtual addresses SYStem.JtagClock 20.0MHz SETUP.IMASKASM ON              ; lock interrupts while single stepping ; Use on-chip breakpoints Break.SELect PROGRAM ONCHIP Break.SELect READ ONCHIP Break.SELect WRITE ONCHIP Break.SELect ALPHA ONCHIP Break.SELect BETA ONCHIP Break.SELect CHARLY ONCHIP Break.SELect DELTA ONCHIP Break.SELect ECHO ONCHIP SYStem.Option EnReset OFF SYS.m attach ; wait until reset is complete wait 2.s if run()     Break ; Open a Code Window -- we like to see something WINPOS 0. 0. 75. 20. Data.List enddo load.symbols.cmm ; ; Script to load the Linux kernel symbols into the debugger ; print "loading Linux kernel symbols..." &linuxpath="S:\git\kernel\linux-2.6-imx-0" &kbuildpath="build" sYmbol.SourcePATH.SET &linuxpath Data.LOAD.Elf &linuxpath\&kbuildpath\imx5\vmlinux /StripPART 3 /gnu /nocode ; Map the virtual kernel symbols to physical addresses ; to give the debugger access to it before CPU MMU is ; initialized print "setting system MMU..." MMU.FORMAT Linux swapper_pg_dir 0xc0000000--0xc1ffffff 0x70000000 MMU.Create 0xc0000000--0xc1ffffff 0x70000000 ; map kernel pages at RAM start MMU.COMMON 0xc0000000--0xffffffff            ; common area for kernel and processes ;MMU.TableWalk OFF   ; debugger uses a table walk to decode virtual addresses MMU.ON             ; switch on debugger(!) address translation ; Initialize Mutitasking Support print "initializing multitask support..." TASK.CONFIG ../linux       ; loads Linux awareness (linux.t32) MENU.ReProgram ../linux    ; loads Linux menu (linux.men) HELP.FILTER.Add rtoslinux  ; add linux awareness manual to help filter enddo This document was generated from the following discussion: Lauterbach CMM scripts for mx53

Why raising QoS priority for EPDC Eink has been developing higher resolution panel. With higher resolution, TCE underrun problem is observed more easily. Highest QoS priority can provide obvious improvement. What's TCE underrun TCE is Timing Controller Engine which is responsible for TFT scan frame refreshes. The pixel FIFO (PIX_FIFO) is used to load working buffer pixel data for TCE. When FIFO underrun, TCE_UNDERRUN_IRQ interrupt is triggered, and TCE underrun log pops up in kernel log. The pixel data is processed by TCE to generate TFT voltage control pixels for panel. If an underrun occurs, unknown data is used and that can damage the panel. About the patch The patch raises EPDC reading to highest priority (QoS='f'), so the EPDC reading becomes real time channel in MMDC configuration. The patch is based on L4.1.15 kernel. Stress test of unit test can pass with 1920x1440 configuration.

i.MX31 Lite Kit is a low cost development board developed by LogicPD OEM (an AMD company). Expanding on the Freescale offering of low-cost, high-performance application development kits, Freescale introduces the i.MX31 Lite Kit. Developed in collaboration with Logic Product Development, the Freescale i.MX31 Lite Kit provides a product-ready software and hardware platform for OEMs, ODMs, IDHs and independent developers. The i.MX31 Lite Kit enables rapid design of embedded products targeting the medical, industrial, wireless, consumer markets and general purpose markets. Leverage the power of our popular i.MX 31 multimedia processor in this cost-effective development solution. Features The Freescale i.MX31 SOM-LV is based on the i.MX31 multimedia applications processor running up to 532 MHz. LCD Display Connector Integrated LCD, touch, and backlight connector for Zoom Display Kits Audio Stereo input and output jacks Network Support One RJ45 Ethernet jack connector with magnetics (application/debug) PC Card Expansion CompactFlash® Type I card MMC/SD card ATA Support USB One USB 2.0 high-speed host interface One USB high-speed On-the-Go device interface Serial Ports 115.2kbps RS-232 debug serial port Software LogicLoader™ (bootloader/monitor) Windows® CE 5.0 BSP GNU cross development toolchain (compiler, linker, assembler, debugger) Cables Serial cable (null-modem) Ethernet crossover cable USB A to mini-B cable 5 volt power supply (with Europe, Japan, UK, & US adapters) Mechanical 146.1 mm wide x 158.8 mm long x 17.1 mm high RoHS Compliant More information [here.]

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-343802 

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-342420 

Freescale introduces the i.MXS Development Kit, a high performance development kit ideal for Microsoft's Windows Vista™ SideShow™ platform and .NET Micro Framework applications. The advanced i.MXS Development Kit leverages Freescale's i.MXS applications processor, based on the ARM920T™ core, a highly integrated IC that has been in production for nearly two years. The integrated development platform, featuring support of Microsoft's .NET Micro Framework for use with SideShow applications, is designed to enable hardware developers to more quickly and easily design applications targeting Microsoft's highly anticipated Windows Vista operating system. Typical SideShow applications include laptop external displays, remote controls and USB dongles, which can run certain applications without powering up the laptop. The i.MXS Development Kit features a small form-factor reference board that has a 2.5 inch color LCD panel with QVGA resolution. The card includes Freescale’s i.MXS applications processor that provides superb performance and extremely low power consumption, enabling hours of use off a single battery charge. The development kit also includes a USB interface and an expansion connector for add-on modules such as Bluetooth™ technology or the ZigBee™ wireless protocol, creating a comprehensive development platform for a variety of applications. Features i.MXS applications processor, based on the powerful ARM920T™ core Clock source crystal: 32 kilohertz Powered by USB bus voltage or external power adaptor Multi-ICE debug support connector I2C and SSI bus connector for connection to external audio CODEC SMbus interface 32-megabyte (MB) SDRAM device One 8-megabyte (MB) Burst Flash memory device One RS232 transceiver (configured for DCE) supporting on-chip UART1 port 1 UART port at CMOS level for expansion On-Chip USB 1.1 interface On-board 2.5 inch LCD with back-light and QVGA resolution 11 separated GPIO for key-button input LED indicator for power

How to add Ethernet UI support in ICS     How to add Ethernet UI support in ICS 1.  Introduction 2.  New feature detail   1.  Introduction   If you want to add Ethernet UI support , you need manually apply the attached patches in this file which is based on Android ICS and i.MX6.        About what the patches do, here is some comments: framework/base-----0001-ENGR00220371-Ethernet-add-support-for-ethernet.patch        By default, Android has no support for Ethernet UI. So if you want to add Ethernet UI , add Ethernet state tracker & Ethernet service & Ethernet manager & Ethernet monitor like WiFi. Meanwhile we need add Ethernet display support in status bar. Here this patch can solve it. Build---0001-ENGR00220371-Ethernet-add-ethernet-support.patch        add package directory compile. packages\apps\Settings---0001-ENGR00220371-Ethernet-add-app-UI-in-setting.patch        add UI logic in setting app. packages\providers\DownloadProvider---0001-ENGR00220371-Ethernet-add-downloadinfo.patch        add ConnectivityManager.TYPE_ETHERNET type support in download provider’s DownloadInfo.   2.  New feature detail   After applying the above patches, you will get the following features: Icon for Ethernet connection status. If on, a green icon will appear in status bar; If off,no icon will appear.     Add “Ethernet configuration” UI.  Choose box is designed for turn on or off Ethernet.      Only Ethernet is turned on, Ethernet configuration can be configured static IP.   First boot, Ethernet device default may not be eth0. So change it from the device list. Use imx6-ics-ethernet-v3.zip. It has updated and fixed the following issues compared with the previous two versions:   1. fix static IP not work issue. 2. fix dns using default 8.8.8.8 issue. 3. eth0 is the default interface, no longer need to choose it from the list. 4. dhcp is default mode. and if you are using static IP. After reboot, it will restore to dhcp again. 5. no need to edit dns again.   List the bug list for update. If using ethernet as upstream type, you need to apply the attached fix-use-ethernet-as-upstream.patch.   For JB4.2.2 and JB4.3, we have written one apk for this. Anyone who is interested in this can get it.

Using Clock Out - i.MX31PDK i.MX31 has a clock out pin that can be used to output internal clock signals. On the i.MX31PDK the clock out pin is accessible on TP1. The clock out is controlled by register COSR (Clock Out Source Register) at address 0x53F8001C. There three fields on COSR: Field Description CLKOEN (bit 9) Clock output enable bit CLKOUTDIV (bits 8-6) Clock output divide factor CLKOSEL (bits 3-0) These bits select which clock is to be reflected on the clock output CKO. Here are the values each field may assume: CLKOEN Values CLKOUTDIV Values CLKOSEL Values 1 clock output IO pin is enabled 0 clock output IO pin disabled 000 => 1 001 => 2 010 => 4 011 => 8 100 => 16 0000 => mpl_dpdgck_clk 0001 => ipg_clk_ccm 0010 => upl_dpdgck_clk 0011 => pll_ref_clk 0100 => fpm_ckil512_clk 0101 => ipg_clk_ahb_arm 0110 => ipg_clk_arm 0111 => spl_dpdgck_clk 1000 => ckih 1001 => ipg_clk_ahb _emi_clk 1010 => ipg_clk_ipu_hsp 1011 => ipg_clk_nfc_20m 1100 => ipg_clk_perclk_uart1 1101 => ref_cir1 (ref_cir_gateload) 1110 => ref_cir2 (ref_cir_intrcload) 1111 => ref_cir3 (ref_cir_path) Based on the Clock Generation Scheme, we can play with COSR register using the Register Accessing application to test Clock out pin by checking some i.MX31 internal clocks. Testing First we can check the value of CKIH, it should be 26MHz as a 26MHz is connected to that pin. We can write 0x208 to COSR. [CLKOEN = 1| CLKOUTDIV = 1| CLKOSEL = ckih] root@freescale /home$ ./io2 0x53f8001c w 0x208 /dev/mem opened. Memory mapped on address 0x4001f000. Written: 0x208 Then we can check pll_ref_clock. We can write 0x203 to COSR. [CLKOEN = 1| CLKOUTDIV = 1| CLKOSEL = pll_ref_clk] root@freescale /home$ ./io2 0x53f8001c w 0x203 /dev/mem opened. Memory mapped on address 0x4001f000. Written: 0x203 As expected, pll_ref_clock is equals to CKIH because CCMR[PCRS]=10. Reading CCMR to confirm CCMR[PCRS]=10: root@freescale /home$ ./io2 0x53f80000 /dev/mem opened. Memory mapped on address 0x4001f000. Address value 0x53F80000 (0x4001f000): 0x174B0D7D The pll_ref_clock inputs to MCU PLL and Serial PLL. We can check MCU PLL and Serial PLL configurations on MPCTL (0x53F80010) and SPCTL (0x53F80010) registers respectively. Reading MPCTL and SPCTL: root@freescale /home$ ./io2 0x53f80010 /dev/mem opened. Memory mapped on address 0x4001f000. Address value 0x53F80010 (0x4001f010): 0x33280C root@freescale /home$ ./io2 0x53f80018 /dev/mem opened. Memory mapped on address 0x4001f000. Address value 0x53F80018 (0x4001f018): 0x2072356 Determine the PLL multiplication factor from MPCTL and SPCTL: - MPCTL: PD = 1 (0000) | MFD = 52 (0000110011) | MFI = 10 (1010) | MFN = 12 (0000001100) - MCPTL Multiplication Factor: 20,46153 - mpl-dpdgck-clk = 20,46153 * 26MHz = 532 MHz - SPCTL: PD = 1 (0000) | MFD = 520 (1000000111) | MFI = 8 (1000) | MFN = -170 (1101010110) - SCPTL Multiplication Factor: 15,3461538 - spl-dpdgck-clk = 15,3461538 * 26MHz = 399 MHz Finally we can output mpl-dpdgck-clk and spl_dpdgck_clk values to check the calculations above. We can write 0x300 to COSR for mpl-dpdgck-clk. [CLKOEN = 1| CLKOUTDIV = 16| CLKOSEL = mpl_dpdgck_clk] And 0x307 for spl-dpdgck-clk. [CLKOEN = 1| CLKOUTDIV = 16| CLKOSEL = spl_dpdgck_clk] root@freescale /home$ ./io2 0x53f8001c w 0x300 /dev/mem opened. Memory mapped on address 0x4001f000. Written: 0x300 root@freescale /home$ ./io2 0x53f8001c w 0x307 /dev/mem opened. Memory mapped on address 0x4001f000. Written: 0x307 By multiplying the results above by 16 to compensate for CLKOUTDIV we have the expected results.

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

imx8mm platform on 4.14.78/98 GA Android  LCD MIPI panel or HDMI display may appear some strange color stride .  This is  one patch for this issue.