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.

Network File System (NFS) Setting the Host 1 - Install NFS Service on host typing: $sudo apt-get install nfs-kernel-server 2 - Create symbolic link to ltib/rootfs $sudo ln -s <ltib instalation folder>/rootfs /tftpboot/rootfs 3 - Setup exports typing: $sudo gedit /etc/exports and add the following line: /tftpboot/rootfs/ *(rw,no_root_squash,no_subtree_check,async) 4 - Restart the NFS server: $sudo /etc/init.d/nfs-kernel-server restart Now the host is ready to use NFS. Setting Target Linux Image to use NFS 1 - Run LTIB configuration typing: $cd <ltib instalation folder> $./ltib -c 2 - On first page menu, go to "Target Image Generation -> Options" as in the picture below. 3 - Select the option NFS only and exit LTIB configuration to compile with the new configuration. 4 - LTIB should start new compiling and create a new Linux image on /<ltib instalation folder>/rootfs/boot/zImage 5 - Copy the created image on /<ltib instalation folder>/rootfs/boot/zImage to /tftpboot/zImage 6 - The system is ready to run with NFS. The root file system on target will be located on host on /<ltib instalation folder>/rootfs/

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

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 

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

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

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.

Question: An alignement trap in Linux had been seen in an unaligned access of the WEIM (to an external FPGA) Alignment trap: testFPGA (1027) PC=0x000086dc Instr=0xe1d330b0 Address=0x08000001 FSR 0x011 The issue can be reproduced with the platform SDK EIM parallel Nor Test on the Sabre AI - When I access WEIM_BASE_ADDR +1 I get an exception. EIM test start: Flash size: 0x 2000000 Flash erase... . Oops, data abort occurred! Registers at point of exception: cpsr = nZCvqeAift Supervisor (0x60000113) r0 = 0x00000000    r8 =  0x00000000 r1 = 0x00000000    r9 =  0x00000000 r2 = 0x00000001    r10 = 0x00000000 r3 = 0x08000001    r11 = 0x10409770 r4 = 0xdeadfeed    r12 = 0x00000001 r5 = 0x10002458    sp =  0x10409734 r6 = 0x00000000    lr =  0x1000ef9c r7 = 0x00000094    pc =  0x1000bfd0 dfsr = 0x00000001 dfar = 0x08000001 Access type: read Fault status: 0x1 Is adress alligned access mandatory for EIM or AXI HW? or is it possible to support unaligned access? Answer: EIM should support unaligned access. Also ARM architecture supports unaligned access to data and address buses but only if the MMU co-processor is setup for that. Try checking cp15 sctlr[1]. Linux discourage the access to unaligned memory and some times that makes a bus error resulting in a kernel panic. So the drivers and the setup architecture files should support unaligned memory access. ARM Information Center /linux/Documentation/unaligned-memory-access.txt The EIM device is a AXI slave which should support unaligned access. Reference Manual and there's a sub-chapter in the EIM call AXI(Master) Bus cycles support. In that chapter there's a table AXI to Memory Burst Splits Number in that table states the increment burst access to a aligned or unaligned address. I expect those are for the EIM and not refer only to the AXI bus. At any case is not state clear if unaligned access should work only in burst mode (which doesn't make any sense to me) or if the RM information is incorrect. Also in the same chapter in signals not supported never list the alignment signals so unaligned access is supported. Link with some generic ARM information about that. http://forums.arm.com/index.php?/topic/8862-axi-narrowunaligned-read-transfers/ AXI4 - Aligned & unaligned address - ARM Community

Purpose: Introduce how to debug M4 using trace 32 and the difference with regular debug mode for imx6sx. If you are using other jtag debug tools, maybe you need to do the similar configuration. Debug tools: Trace32 – you can refer to http://www.lauterbach.cn/ for more information about this tool.