i.MX Processors Knowledge Base

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MX Processors Knowledge Base

Discussions

Sort by:
Question: The description of the IOMUXC_GPR2 register is wrong. It contains exactly the same description as the LDB_CTRL register. The bits in the LDB_CTRL register work as advertised opposed to the GPR2 register. Answer: This is intentional. The LDB_CTRL description in the RM says "The register is implemented in the IOMUX Controller block (IOMUXC), as the register IOMUXC_GPR2.". And you will notice the two registers have the same address.
View full article
Notes: + Run the pipelines in the presented order + The above example streams H263 video. + the gl command is equal to 'gst-launch' (two instead of 'gst-launch'.size() chars ) + Pending work: H264 test cases and other scenarios. Scenario Shell variables and pipelines # Export always these variables on the i.MX export VSALPHA=1 export WIDTH=320 export HEIGHT=240 export SEP=20 # decoded and displayed Uni-directional: from PC to i.MX. PC is streaming 4 H.263 streams and i.MX displays all in the screen. # On i.MX (Target) gl udpsrc caps='application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H263' port=8890 ! rtph263depay ! vpudec ! mfw_isink sync=false axis-top=0 axis-left=0 disp-width=$WIDTH disp-height=$HEIGHT & gl udpsrc caps='application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H263' port=8891 ! rtph263depay ! vpudec ! mfw_isink sync=false axis-top=0 axis-left=`expr $WIDTH + $SEP` disp-width=$WIDTH disp-height=$HEIGHT & gl udpsrc caps='application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H263' port=8892 ! rtph263depay ! vpudec ! mfw_isink sync=false axis-top=`expr $HEIGHT + $SEP` axis-left=0   disp-width=$WIDTH disp-height=$HEIGHT & gl udpsrc caps='application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H263' port=8893 ! rtph263depay ! vpudec ! mfw_isink sync=false axis-top=`expr $HEIGHT + $SEP` axis-left=`expr $WIDTH + $SEP` disp-width=$WIDTH disp-height=$HEIGHT & # On PC (Source) export IP_iMX= # Place the IP address of the i.MX board gst-launch -v videotestsrc ! ffenc_h263 ! rtph263pay ! multiudpsink clients=IP_iMX:8890,IP_iMX:8891,IP_iMX:8892,$IP_iMX:8893 Uni-directional: from PC to i.MX. PC is streaming one H.264 stream and i.MX displays it on the screen # On i.MX (Target) # Make sure you set the caps correctly, specially the sprop-parameter-sets cap. The one show below is just an example and works with the source file sintel_trailer-1080p.mp4 export VSALPHA=1 GST_DEBUG=*:2 gst-launch -v udpsrc caps='application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, sprop-parameter-sets=(string)\"Z2QAMqw05gHgCJ+WEAAAAwAQAAADAwDxgxmg\\,aOl4TLIs\", payload=(int)96' port=8890 ! rtph264depay ! vpudec ! mfw_isink sync=false # On PC (Source) gst-launch -v filesrc location=sintel_trailer-1080p.mp4 typefind=true ! qtdemux ! rtph264pay ! multiudpsink clients=10.112.102.168:8890 Bi-directional: PC is streaming 4 H.263 streams to i.MX, iMX displays it and sends the four back to PC # On i.MX export IP_PC= # Place the IP address of the PC host machine gl -v udpsrc caps='application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H263' port=8890 ! rtph263depay ! vpudec ! tee name=t ! queue ! mfw_isink sync=false axis-top=0 axis-left=0 disp-width=$WIDTH disp-height=$HEIGHT t. ! queue ! vpuenc codec=5 ! rtph263pay ! udpsink host=$IP_PC port=9990 & gl -v udpsrc caps='application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H263' port=8891 ! rtph263depay ! vpudec ! tee name=t ! queue ! mfw_isink sync=false axis-top=0 axis-left=`expr $WIDTH + $SEP` disp-width=$WIDTH disp-height=$HEIGHT t. ! queue ! vpuenc codec=5 ! rtph263pay ! udpsink host=$IP_PC port=9991 & gl -v udpsrc caps='application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H263' port=8892 ! rtph263depay ! vpudec ! tee name=t ! queue ! mfw_isink sync=false axis-top=`expr $HEIGHT + $SEP` axis-left=0   disp-width=$WIDTH disp-height=$HEIGHT t. ! queue ! vpuenc codec=5 ! rtph263pay ! udpsink host=$IP_PC port=9992 & gl -v udpsrc caps='application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H263' port=8893 ! rtph263depay ! vpudec ! tee name=t ! queue ! mfw_isink sync=false axis-top=`expr $HEIGHT + $SEP` axis-left=`expr $WIDTH + $SEP` disp-width=$WIDTH disp-height=$HEIGHT t. ! queue ! vpuenc codec=5 ! rtph263pay ! udpsink host=$IP_PC port=9993 & # On PC ## Stream received from iMX export IP_iMX= # Place the IP address of the i.MX board gl -v udpsrc caps='application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H263' port=9990 ! rtph263depay ! ffdec_h263 ! xvimagesink & gl -v udpsrc caps='application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H263' port=9991 ! rtph263depay ! ffdec_h263 ! xvimagesink & gl -v udpsrc caps='application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H263' port=9992 ! rtph263depay ! ffdec_h263 ! xvimagesink & gl -v udpsrc caps='application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H263' port=9993 ! rtph263depay ! ffdec_h263 ! xvimagesink & ## Stream sent to iMX gl -v videotestsrc ! videoscale ! video/x-raw-yuv,width=\(int\)1408,height=\(int\)1152 !  ffenc_h263 ! rtph263pay ! udpsink host=$IP_iMX port=8890 & gl -v videotestsrc ! videoscale ! video/x-raw-yuv,width=\(int\)1408,height=\(int\)1152 ! ffenc_h263 ! rtph263pay ! udpsink host=$IP_iMX port=8891 & gl -v videotestsrc ! videoscale ! video/x-raw-yuv,width=\(int\)1408,height=\(int\)1152 ! ffenc_h263 ! rtph263pay ! udpsink host=$IP_iMX port=8892 & gl -v videotestsrc ! videoscale ! video/x-raw-yuv,width=\(int\)1408,height=\(int\)1152 ! ffenc_h263 ! rtph263pay ! udpsink host=$IP_iMX port=8893 &
View full article
[Brief description] (1)Contents The ducoment introduced how to expand Gigabit Ethernet based on i.MX6 PCI Express, and attached schematics in DSN & pdf format. (2)Binary file for EEROM I have the binary file used to debug intel82574 circuit in this schematic, If customer wants to use it to debug board based on i.MX6+Intel82574, she can submit a case for me to get the file by our Salesforece system. Best Regards, TIC Weidong Sun Email: [email protected]
View full article
Note that this is for Jive 5 and we are now on Jive 6.  Things have changed in Jive 6 with respect to setting email notifications.  Your Preferences page and the new connection streams control your your notification settings now.  This document will be updated soon. There are three channels in which you get notifications of community activity, and you can use these channels most effectively if you know how to control the flow to them.  The three channels are: 1.    Activity stream in the “What Matters: Activity” page 2.    Inbox in the “What Matters: Communications” page 3.    Email Activity stream: Notifications in your Activity stream are mostly your follows – the content, people and places that you have selected to follow.  For any activity on any content, or in any place, or by anyone you follow, you will get a notification here.  This Activity stream also makes an attempt to identify the followed content that “matters most” to you.  Note that there is also a tab here which allows you to see all activity in the entire community in a single stream. You can control the activity in the “Followed Activity” tab of your Activity stream in two ways: 1.    Select “Hide” (icon to the right of the title) for any content that you no longer want to show up in your Followed Activity stream. 2.    Be selective about what and who you follow. Stop following entire spaces/groups or members who may (need to) post things that you are not interested in. You can control who you follow in your “personal page” (click on your name) or by bringing up another member’s personal page.  Control what you follow by going to the place or content and selecting/deselecting the “Follow” icon. Inbox: Fewer activity notifications are collected in your Inbox than in your Activity stream.  The Inbox usually contains activity notifications for content such as announcements, direct messages, private discussions, content you created or contributed to, or content that someone @mentioned you or shared with you.  The Inbox can also contain notifications of activities for content, places or people which you have marked as “Track in Communications”. You can control notifications in your Inbox only for content/places/people you have marked as “Track in Communication”.  The option to select/deselect tracking in communications is found: ·         in the “Actions” selector box in each place ·         in the “Actions” list next to any specific content (discussions/document) ·         in a member’s personal page It may be better to get selected notifications in your Inbox rather than getting these notifications in your email (see below). Email: Email notifications can be set up in your Preferences for content in the following categories: 1.    Content in your Communications page (Inbox) 2.    Alerts or Notifications in your Actions (not Activity) page 3.    Direct social action (@mentions, shares and direct messages) 4.    Followed activity – Places, Content, People (Activity stream) Enabling email notifications for each of these types of content is done in your “Preferences”.  Each of the above four categories can be enabled/disabled separately.  Setting each of these preferences to "On" will enable email notification for any type of activity which applies to each of these categories. Note also that notifications are enabled in the "Receive email notifications" setting found in another member's personal page (Bio tab) and in the "Actions" box in a place or content page.  You can select to "Receive email notifications” for all activities by a member, or within a place, or for specific content.  Be sure to deselect this for members, places and content that you do not want email notifications for these activities. Notifications Summary table: Category Activity Stream (What Matters: Activity) Inbox (What Matters: Communications) Email – Select Places “Follow” in upper right corner of place “Track in Communications” in place’s Actions box "Receive email notifications" in place's Actions box People “Follow” in upper right corner of member's Bio tab of his personal page “Track in Communications” in member's Bio tab Actions list "Receive email notifications" in member’s Bio tab Actions list Content “Follow” in upper right corner of content “Track in Communications” in content’s Actions list "Receive email notifications" in content's Actions list Email - All "People, places and content I'm following (Followed Activity)" in Preferences All Content: “Everything in my Communications page” in Preferences @mentions, shares, and direct messages: “Direct social actions” in Preferences - Common questions: Q: What will have the biggest impact in controlling or reducing the notifications I get in the three channels? A: In order of impact: 1.    Stop following entire places (or at least turn off email notifications for followed activity) 2.    Stop following people who post content for which you don’t need notifications (or at least turn off email notifications for followed activity) 3.    Don’t set “Track in Communication” for places, content or people unless you really want this content in your Inbox (or at least turn off email notifications for Everything in my Communications Page (Inbox) It is recommended that you do not disable email notification for “Direct Social Action” in your preferences.  These are the most important notifications. Q: I have turned off “Follow” for a group I’m in, but I keep getting emails for activity in that group or community.  What do I need to do to disable these email notifications? A: Getting email notifications for activity can be enabled by several settings, and you only need one set to enable the notifications.  Some reasons why you might get email notifications: ·         Follows – you have email notification enabled for “Followed Activity” in your Preferences: o   You are following a place.  Note that you may not be following a group, but you may still be following a project (i.e., sub-group) within the group.  Therefore, you will get notifications for activity within the project. o   You are following members of a place.  If you are following a person then you will get notifications of all activity created by that person. o   You are following content.  If you have “Follow” set for any content, e.g., discussions or documents, you will get notifications for all activity on that content. ·         Content in your Inbox – you have email notifications enabled for “Everything in my Communications Page” in your Preferences: o   Activity for content that you created or contributed to is one set of activities captured in your Inbox. o   Activity where someone @mentioned you or shared with you. o   Activity in a place, on content, or by a member that you specifically marked as “Track in Communication”. Any of the above will cause you to get an email notification of activity.  Turn off the unneeded “Follows", “Track in communication”, or "Receive email notifications".  If you do not want emails for notifications hitting your inbox, consider disabling emails for “Everything in my Communications Page” in your Preferences. CC: MPU Support Freescale Community Managers Using Freescale Community
View full article
A new release of the manufacturing tool is was recently made available, "imx-3.10.53_1.1.0_ga-mfg-tools". It can be found in the software download sections for the iMX6 family. However, it can be used to program an iMX28 in a Win7 64-bit host by adding a few files. The steps to do so are listed below and can be checked against the script in ucl2.xml.   Download the attached "28.vbs" file and place it into where the manufacturing tool was installed, typically in  <install_dir>\mfgtools\   Replace <install_dir>\mfgtools\Profiles\Linux\OS Firmware\ucl2.xml with the attached ucl2.xml.    Copy the attached files "updater_ivt.sb" and "fdisk-u.input" into <install_dir>\mfgtools\Profiles\Linux\OS Firmware\firmware Copy your iMX28 image file into <install_dir>\mfgtools\Profiles\Linux\OS Firmware\files.  The file should be renamed to "linux.sb" to conform with the ucl2.xml script. Copy your "rootfs.tar.bz2" file into <install_dir>\mfgtools\Profiles\Linux\OS Firmware\files To launch the manufacturing tool, double click on "28.vbs". Issue: After MfgTool has finished and the progress bars have turned green, clock on the Stop button or the program will start another cycle.
View full article
Kernel provides mtdoops to dump kmsg to MTD device, but MMC card is not a MTD device. We can let user-space program to execute the write operation to dump kmsg into block storage. The sample code is below. kernel space -- #include <linux/kernel.h> #include <linux/module.h> #include <linux/console.h> #include <linux/vmalloc.h> #include <linux/seq_file.h> #include <linux/workqueue.h> #include <linux/sched.h> #include <linux/wait.h> #include <linux/delay.h> #include <linux/interrupt.h> #include <linux/kmsg_dump.h> #include <linux/proc_fs.h> static struct kmsg_dumper dump; static struct proc_dir_entry *my_proc; static int is_panic = 0; static int my_proc_show(struct seq_file *m, void *v) {     seq_printf(m, "%d", is_panic);     return 0; } static int my_proc_open(struct inode *inode, struct file *file) {     return single_open(file, my_proc_show, NULL); } static const struct file_operations my_proc_ops = {     .open        = my_proc_open,     .read        = seq_read,     .llseek        = seq_lseek,     .release    = single_release, }; static void oops_do_dump(struct kmsg_dumper *dumper,         enum kmsg_dump_reason reason, const char *s1, unsigned long l1,         const char *s2, unsigned long l2) {     int i;     printk("### [%s:%d] reason = %d\n", __func__, __LINE__, reason);     is_panic = 1;     for (i = 0;i < 10; i++)         msleep(1000);     printk("### [%s:%d] should be done\n", __func__, __LINE__); } static int __init my_oops_init(void) {     int err;     dump.dump = oops_do_dump;     err = kmsg_dump_register(&dump);     if (err) {         printk(KERN_ERR "oops: registering kmsg dumper failed, error %d\n", err);         return -EINVAL;     }     my_proc = proc_create("dump_tester", 0, NULL, &my_proc_ops);     return 0; } static void __exit my_oops_exit(void) {     printk("### [%s:%d]\n", __func__, __LINE__);     if (my_proc)         remove_proc_entry( "dump_tester", NULL);     kmsg_dump_unregister(&dump); } module_init(my_oops_init); module_exit(my_oops_exit); MODULE_LICENSE("GPL"); User space -- #include <stdio.h> #include <stdlib.h> #include <string.h> #include <sys/types.h> #include <sys/stat.h> #include <unistd.h> #include <fcntl.h> #include <poll.h> #define BUF_LEN 40960 void main(int argc, char **argv) {     char tmp = 'X';     char buf[BUF_LEN];     int fd_src, fd_trg;     int fd = open("/proc/dump_tester", O_RDONLY, 0);     while(1) {         lseek(fd, 0, SEEK_SET);         read(fd, &tmp, 1);         //printf("### [%s:%d] ==> '%c'\n", __FUNCTION__, __LINE__, tmp);         if (tmp == '1') {             fd_src = open("/proc/kmsg", O_RDONLY, 0);             fd_trg = open("/dev/block/mmcblk0p6",  O_RDWR, 0);             memset(buf, 0, BUF_LEN);             write(fd_trg, buf, BUF_LEN);             lseek(fd_trg, 0, SEEK_SET);             read(fd_src, buf, BUF_LEN);             write(fd_trg, buf, BUF_LEN);             close(fd_src);             close(fd_trg);             sleep(1);             printf("### dump panic log into %s\n", "/dev/block/mmcblk0p6");             break;         }         sleep(1);     }     close(fd); }
View full article
Add the above line to conf/local.conf file: PREFERRED_PROVIDER_virtual/kernel = "linux-fslc" Check this page to see what the mainline Linux kernel supports for a particular Freescale board.
View full article
On imx8qm there are two DPUs(display process unit) and one ISI(image subsystem interface), ISI has 5 inputs and two of them are from DPU0 and DPU1.   This document demonstrates on how to loopback DPU1 outputs to ISI. Note that only mipi dsi0 of dpu0 and lvds1 of dpu1 can be loopbacked to isi.   Platform:                            imx8qm b0 mek OS:                                    yocto 4.14.78 ga hardware connection:        imx8qm lvds1 ====> it6263 cable =====> hdmi display.   1st: isi has 8 pipelines which can be assigned to any of the 5 inputs, this doc takes the 5th pipeline to sink the dpu1 input. So you will need to configure the isi_4( start from 0) source in the dts and write a simple v4l2 subdev for capture testing, the default isi_4 device will be /dev/video4.   2st: configure both framegen0 of dpu1 and lvds1's link to pixellink 3.   3st: write a v4l2 userspace program to capture from /dev/video4 device, take this vulkan-capture as an example. Note that Vulkan-capture is rendered by vulkan api, you can also take opengl es for rendering.   See the atttachments for details.   ======================================== 2019/11/12 update patches. ======================================== 2019/12/19 add patch. Support connect real display to DC1-LVDS1   Note: for ISI loopback,  it needs output of 2x GPIO (4x for HDMI-TX or combo PHY) to pixel_link_receiver_address: For iMX8QM: o LVDS: pixel_link_receiver_address[1:0] = do_gpio_dr[7:6]  o MIPI-DSI: pixel_link_receiver_address[1:0] = do_gpio_dr[7:6] o HDMI-TX: odd_pixel_link_receiver_address[1:0] = do_gpio_dr[7:6],even_pixel_link_receiver_address[1:0] = do_gpio_dr[5:4]   For iMX8QXP: o Combo MIPI-DSI / LVDS: pixel_link0_receiver_address[1:0] = do_gpio_dr[7:6], pixel_link1_receiver_address[1:0] = do_gpio_dr[5:4] 
View full article
Here is a summary including kdump + crash porting in i.mx, the tool is very useful in crash issue. Overview What is Kdump + Crash Preconditions kernel kexec Step actions Crash tool Analysis of use cases   Besides that, I summary the dumper tools including kdump and pstore, the respective patches shown as below: Kdump: Customer can apply below patch in config and cmdline, which has been confirmed on linux os. As memory is very precious to android, so kdump is not worth adopting. Config:        First kernel:       CONFIG_KEXEC=y       CONFIG_SYSFS=y       CONFIG_DEBUG_INFO=Y        Capture kernel:       CONFIG_CRASH_DUMP=y       CONFIG_PROC_VMCORE=y Cmdline:        crashkernel=512M Pstore: Customer can apply below patch in config and dts showing as below, which has been confirmed on linux and android os. Config: CONFIG_PSTORE_PMSG=y Dts: +               ramoops@0x91f00000 { +                       compatible = "ramoops"; +                       reg = <0 0x91f00000 0 0x00100000>; +                       record-size     = <0x00020000>; +                       console-size    = <0x00020000>; +                       ftrace-size     = <0x00020000>; +                       pmsg-size       = <0x00020000>; +               }; +                 decoder_boot: decoder-boot@84000000 {                         reg = <0 0x84000000 0 0x2000000>;                         no-map;   Reproduce steps Reboot the system by enter below command:       $ reboot Check the related log by enter below command:       $ ls /sys/fs/pstore/          console-ramoops-0 pmsg-ramoops-0
View full article
In new iMX8QM and iMX8QXP BSP, it had implemented hardware partition to split the resource and memory regions. The default Android Auto BSP had given example for shared memory between M4 and A core, it is used for RPMSG. Here is an example to add a new shared memory for iMX8QXP MEK board with Android Auto P9.0.0_GA2.1.0 BSP, which can be accessed in both M4, Uboot and Linux Kernel. The new shared memory region is from 0xF6000000 to 0xFDFFFFFF, total 128MB, it covers the RPMSG region too. RPMSG shared memory is moved to 0xF6000000 ~ 0xF6BFFFFF, total 12MB. vendor_nxp_fsl-proprietary_uboot-firmware.patch SCFW patch for board file to change the old shared memory region (0x90000000~0x90BFFFFF) to new shared memory region (0xF6000000~0xFDFFFFFF). This patch is applied to android_build/vendor/nxp/fsl-proprietary/uboot-firmware/imx8q_car/board-imx8qxp.c, after patched, copy this file to SCFW porting kit and build out a new SCFW image, put it to "android_build/vendor/nxp/fsl-proprietary/uboot-firmware/imx8q_car/mx8qx-scfw-tcm.bin". vendor_nxp-opensource_uboot-imx.patch This is the Uboot patch to map the shared memory region, if Uboot doesn't need access these memory, this patch is not needed. vendor_nxp-opensource_kernel_imx.patch This is the kernel patch to map the shared memory region. Note: VPU reserved memory address shouldn't be changed, otherwise it will impact the VPU function. So the new reserved memory region had been moved to 0xF600000~0xFDFFFFFF. vendor_nxp_mcu-sdk-auto_SDK_MEK-MIMX8QX.patch M4 patch for RPMSG address changed from 0x90000000 to 0xF6000000. Note: 1. In this example, we put the two shared memory regions together, then it will not split the memory region used in Linux. Another reason for such modification is the limitation of memory region counts in SCFW. 2. Since the RPMSG shared memory had been moved from 0x90000000 to 0xF6000000, the M4 code who used shared memory should also be changed. 2019-07-29 Update: When "#define PHYS_SDRAM_2_SIZE  0x0" in Uboot, it will create a 0 size memory region, this will impact the Uboot shared memory patch. Added the "uboot_imx8_cpu.patch" to avoid such issue.
View full article
Important: If you have any questions or would like to report any issues with the DDR tools or supporting documents please create a support ticket in the i.MX community. Please note that any private messages or direct emails are not monitored and will not receive a response.   This is the detailed programming aid for the registers associated with DRAM initialization (DDR3 and LPDDR2) of the MX6UL/ULL/ULZ (consolidated RPA). The last work sheet tab in the tool formats the register settings for use with the ARM DS5/RealView debugger. It can be manually converted by the user to a DCD file format used by uboot or other bootloaders (note the removal of debugger specific commands in this tab). The programming aids were developed for internal NXP validation and development boards.   This tool serves as an aid to assist with programming the DDR interface of the MX6UL/ULL/ULZ and is based on the DDR initialization scripts developed by the R&D team and no guarantees are made by this tool.   The following are some general notes regarding this tool: Refer to the "How To Use" tab in the tool as a starting point to use this tool. Note that in the "DStream .ds file" tab there are DS5 debugger specific commands that should be commented out or removed when using the DRAM initialization for non-debugger specific applications (like when porting to bootloaders). This tool may be updated on an as-needed basis for bug fixes or future improvements.  There is no schedule for aforementioned maintenance.  
View full article
MX6UL_DDR3_调校_应用手册_V3_20160511.doc
View full article
This work is the result of my daughter's idea, she finished it with my guidance. Cradle-1 Palmsize mini-HPC World's first full function heterogeneous mini-HPC, this is what it looks like: 1 Architecture         Overall:  CPU+GPU heterogeneous, 4 nodes, connected by a 100M Ethernet switcher;         Nodes: FreeScale I.MX6 Quad core mini-pc, with 4 ARM Cortex-A9 cores and 1 Vivante GC2000 GPU 2  Software         OS:   Ubuntu 11.10 linaro         OpenCL driver: Vivante GC2000 OpenCL driver         Compiler:  C/C++: gcc 4.6.1, Fortan90/95:  gfortran 4.6.1,         MPI Parallel Computing: MPICH2 1.4-1         NFS network file system: nfs-kernel-server 1.2.4         SSH security:   openssh   1:5.8 3 Hardware         The hardware of all nodes are the same, only the software configurations are slightly different. One of them was assigned as the master node, the others are slave nodes. They were TV sticks originally, with android 4.0 installed. The node's hardware specification is:         CPU: 4 1.2G Cortex-A9 cores         GPU: 1 Vivante GC2000 GPU         RAM: 1G DDR         ROM: 8G SD         NIC:   usb2.0 100M Ethernet Adapter (this NIC is not the TV stick's component, we added it)         WIFI: 150M         Display Interface:  HDMI         Network Switcher: 5 port 100M Ethernet Switcher 4  Network         Each node has one USB2.0 NIC and one WIFI interface, the WIFI is used as the backup connection for NIC connection. Network configurations are:         IP Address assignment:  (baby1 - baby4 are the four computing nodes)         baby1: 100M NIC 192.168.10.1 WIFI 192.168.0.111         baby2: 100M NIC 192.168.10.2 WIFI 192.168.0.112         baby3: 100M NIC 192.168.10.3 WIFI 192.168.0.113         baby4: 100M NIC 192.168.10.4 WIFI 192.168.0.114 5  Performance         Cradle-1 has 16 1.2G ARM Cortex-A9 cores and 4 Vivante GC2000 GPU cores, the total computing power of these 20 computing devices is more than 100GFLOPS,   more powerful than an ordinary desktop. The whole machine is only a little bigger than a palm, and the total power consumption is less than 15 watts.          The overall architecture of Cradle-1 is almost the same as Chinese Tianhe-1A or the Titan in the oak ridge lab. they used the same set of software, LINUX+OPENCL+OPENMPI. Cradle-1 supports C/C++, Fortran90/95. And almost all kinds of parallel computing algorithms can run on it, the only difference is the scale.         We coded a MPI parallel computing program for large matrix multiplication with 4 processes, each process had 5 threads, four threads for the four CPU cores, and one thread for GPU computing. 6 Appearance Front Back Top Left Right One node, it has three interfaces, the right is HDMI interface, upper-left is the wireless adapter for keyboard and mouse, down-left is the power connection. One node is running Ubuntu 11.10. Coded a simple OpenCL program to display OpenCL driver information On a notebook, using remote desktop access function to obtan the node baby1's desktop. This is the sign in desktop of baby1 node. Baby 1 has X11VNC server installed. sign in baby1, open a terminal Ran a MPI testing program, ensuring that all babies (baby1 - baby4) were working     Any comments? please mail to [email protected]
View full article
The i.MX 8QXP MEK does not allow the OV5640/LVDS/LCD usage only by changing the device tree anymore. It occurs because the M4 owns the i2c resources, so the A core must use rpmsg to enable virtual drivers. Due to this, if the user changes the device tree, for instance, the *ov5640.dtb, the kernel won't boot, entering in the following loop: [    8.603353] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).      [    8.610025] [drm] No driver support for vblank timestamp query.              [    8.616077] imx-drm display-subsystem: bound imx-drm-dpu-bliteng.2 (ops dpu_) [    8.624978] imx-drm display-subsystem: bound imx-dpu-crtc.0 (ops dpu_crtc_op) [    8.632526] imx-drm display-subsystem: bound imx-dpu-crtc.1 (ops dpu_crtc_op) [    8.639833] imx-drm display-subsystem: failed to bind ldb@562210e0 (ops imx_7 [    8.648428] imx-drm display-subsystem: master bind failed: -517 With the approach provided in this post, it is possible to make this change manually, only by changing the flash.bin at U-boot for a non-m4 one. In order to make the changes to the flash.bin file, it’s needed to obtain the following files: - u-boot.bin from internal u-boot provided by NXP. - scfw_tcm.bin from SCFW porting kit - bl31.bin from ARM Trusted Firmware - SECO firmware container image Disclaimer The described procedures in this document target a GNU/Linux (Ubuntu 20.04 LTS) and it’s focused on iMX8QXP B0 + BSP L4.19.35_1.1.0. Required packages 1 - Install ARM64 ToolChain: 1.1 - Install ARM64 GCC and G++ cross-compilers: # apt install gcc-aarch64-linux-gnu g++-aarch64-linux-gnu 2 - Install ARM32 GCC6 ToolChain: 2.1 - Download the ARM32 6 Toolchain and install it: $ mkdir ~/gcc_toolchain $ cp ~/Downloads/gcc-arm-none-eabi-6-2017-q2-update-linux.tar.bz2 ~/gcc_toolchain/ $ cd ~/gcc_toolchain/ $ tar xvjf gcc-arm-none-eabi-6-2017-q2-update-linux.tar.bz2 # apt-get update # apt-get install srecord 3 - Download MKimage 3.1 - Create a new directory desired to the packages: $ mkdir flash_build $ cp flash_build 3.1 - Clone the MKimage: $ git clone https://source.codeaurora.org/external/imx/imx-mkimage -b imx_4.19.35_1.1.0 4 - U-boot build 4.1 - Clone the U-boot  $ git clone https://source.codeaurora.org/external/imx/uboot-imx -b imx_v2019.04_4.19.35_1.1.0 $ cd uboot-imx 4.2 - Export the ARM64 ToolChain:  $ export ARCH=arm64 $ export CROSS_COMPILE=/usr/bin/aarch64-linux-gnu- 4.3 - Build it:  $ unset LDFLAGS $ make -j4 imx8qxp_mek_defconfig $ make 4.4 - Copy the binary files to the MKimage/iMX8QX directory:  $ cp spl/u-boot-spl.bin ../imx-mkimage/iMX8QX/ $ cp u-boot-nodtb.bin ../imx-mkimage/iMX8QX/ $ cd ..   5 - ARM Trusted Firmware 5.1 - Clone the imx-atf:  $ git clone https://source.codeaurora.org/external/imx/imx-atf -b imx_4.19.35_1.1.0 $ cd imx-atf 5.2 - Build it:  $ unset LDFLAGS $ make PLAT=imx8qx bl31 5.3 - Copy the binary files to the MKimage/iMX8QX directory:  $ cp build/imx8qx/release/bl31.bin ../imx-mkimage/iMX8QX/ $ cd ..   6 - SCFW 6.1 - Export the ARM32 GCC6 Toolchain:  $ export TOOLS=~/gcc_toolchain/ 6.2 - Download the BSP L4.19.35_1.1.0_SCFW and copy it to the flash_build directory:  $ cp ~/Downloads/imx-scfw-porting-kit-1.2.7.1.tar.gz $ tar xvzf imx-scfw-porting-kit-1.2.7.1.tar.gz $ cd packages/ $ chmod a+x imx-scfw-porting-kit-1.2.7.1.tar.gz $ ./imx-scfw-porting-kit-1.2.7.1.bin 6.3 - Build it to i.MX 8QXP MEK B0:  $ cd imx-scfw-porting-kit-1.2.7.1/src/ $ tar xvzf scfw_export_mx8qx_b0.tar.gz $ cd scfw_export_mx8qx_b0/ $ make qx R=B0 B=mek 6.4 - Copy the binary file to the MKimage/iMX8QX directory:  $ cp build_mx8qx_b0/scfw_tcm.bin ../../../../imx-mkimage/iMX8QX/ $ cp ../../../../ 7 - SECO Firmware Container Image 7.1 - Download the SECO firmware binaries and copy it to the flash_build directory $ cp ~/Downloads/firmware-imx-7.9.bin . $ chmod a+x firmware-imx-7.9.bin 7.2 - Copy the binary files to the MKimage/iMX8QX directory:  $ cp firmware-imx-7.9/firmware/seco/mx8qx-ahab-container.img /imx-mkimage/iMX8QX/ 8 - Build flash.bin 8.1 - In a new terminal, open the imx-mkimage directory: $ cd flash_build/imx-mkimage 8.2 - Build it:  $ make SOC=iMX8QX flash 8.3 - Deploy it to the SDCard:  $ sudo dd if=iMX8QX/flash.bin of=/dev/sdX bs=1k seek=32 && sync Now, you are able to use any non-rpmsg.dtb without kernel errors. Author: Pedro Jardim: [email protected]
View full article
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.
View full article
This document provides steps to perform the system upgrade/OTA update for Android on i.MX platforms. Compile the Android images and generate an OTA Package: source build/envsetup.sh lunch sabresd_6dq-userdebug make -j4 make otapackage You can find your OTA package in the below path: ls out/target/product/sabresd_6dq/sabresd_6dq-ota-<xxx>.zip Copy the above OTA zip package to the device in sdcard using adb push adb push out/target/product/sabresd_6dq/sabresd_6dq-ota-<xxx>.zip /sdcard Move the package from sdcard to the location: /cache/update.zip Make the directory and perform the below steps on the device: mkdir -p /cache/recovery touch /cache/recovery/command echo "--update_package=/cache/update.zip" > /cache/recovery/command reboot recovery The recovery automatically applies the command and installs this update package. Note: In this document, the setup is for the i.MX6Q SABRESD Board. So, PathName and OTA package name subject to change based on target device compilation.
View full article
current imx6 bsp, not only ltib but also yocto couldn't support subtitle. now we have two solution to support subtitle on yocto, 1)one is extract the subtitle, then draw the subtitle on the video by UI, which is supported by the imxplayer. this solution is using QT by imxplayer, so if you build yocto, should choose QT as target. basicly, aiurdemux send the text to the QT by appsink, then QT draw the text on the UI layer. when build the yocot, pls using the command as below: " bitbake fsl-image-qt5" copy the font libary to the /usr/lib/fonts, then when you play the imxplayer, choose the font you need. 2)another one is blending the subtitle on the video buffer by gstreamer, then output with video enable gst pango lib in gstreamer1.0-plugins-base change playbin flag to disable native video flag basetextoverlay apply patch http://cgit.freedesktop.org/gstreamer/gst-plugins-base/commit/ext/pango/gstbasetextoverlay.c?id=267a8c24af4f02ba6f3075bd589d3c5d1dc826e9 use following command line gst-launch-1.0 playbin flags=0x17 uri=file://$VIDEO_FILE suburi=file://$SUBTITLE_FILE
View full article
   The purpose of this article is to describe how to join together the Processor Expert and ARM GCC toolchain under Eclipse environment.    Freescale provides the Processor Expert, which contains the Pin Settings Tool to support an easy way to configure pin signals, from multiplexing to the electrical properties of pins. With such Tool all the pins can be configured with a graphical user interface, and then generate C code, in order to use it as an example in applications. Please refer to the following Web for more details. http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=PROCESSOR-EXPERT-IMX   The Processor Expert Software for i.MX Processors (Version 1.0) does not include a compiler or linker. Customers should merge the generated code into a build system.   However, it is possible to use common Eclipse-based IDE for the Processor Expert (V 1.0) and GNU ARM “C” toolchains. In particular, the following sequence may be implemented for both Linux and Windows hosts. 1. Install Eclipse (Kepler release) IDE for C/C++ Developers. https://eclipse.org/downloads/packages/eclipse-ide-cc-developers/keplersr2 2. Add Eclipse Processor Expert plug-in, as recommended in the documentation. http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=PROCESSOR-EXPERT-IMX https://community.freescale.com/docs/DOC-101470 3.  Add GNU ARM Eclipse, which contains configurations for different toolchains, including Linux ones. http://gnuarmeclipse.livius.net/blog/plugins-install/ 4. Install appropriate toolchain. For bare-metal applications Sourcery CodeBench Lite for ARM is sutable one. Sourcery CodeBench Lite Edition including ARM GCC IDE - Mentor Graphics Please use Getting Started Guide document from the CodeBench Lite package, that explains how to install and build applications with the CodeBench Lite.    As an example, let’s consider minimal startup code for i.MX6Q (LED flickering project on i.MX6Q SDB / SDP). Assuming Eclipse IDE with the Processor Expert and GNU ARM tools is installed, we should create new “C” project under Eclipse : New -> C Project. Select “Empty Project” and “Cross ARM GCC”, enter “Project name”. Then : select “Advanced settings” -> C/C++ Build -> Settings Tab “Target Processor” : ARM Family : cortex – a9 Architecture : armv7-a Instruction set : ARM (-marm) Endianness : Little endian (-mlittle-endian) FloatABI : Library with FP (softfp) FPU Type : neon Unaligned access : Disabled (-mno-unaligned-access) “Cross ARM GNU Create Flash Image” : General : Raw binary. TAB “Toolchains” : Name : Sourcery CodeBench Lite for ARM EABI (arm-none-eabi-gcc) (If needed customers can select appropriate toolchain) Architecture : ARM (AArch32) Prefix : arm-none-eabi Check “Use global toolchain path” or select the required path directly.  Source codes may added via Eclipse : File -> Import -> File System -> From directory Example source is enclosed. After sources as included in the project, let’s configure linker options via project properties, C/C++ Build -> Settings -> Tool Settings -> Cross ARM C Linker -> General. Add script file “mx6dq.ld”, uncheck “Remove unused section”, check “Do not use standard start files”.   Note, the article of Miro Samek is very helpful in clarifying of startup code and linker script. Please refer to “Building Bare-Metal ARM Systems with GNU”. Article Published online at www.Embedded.com,  July/August 2007. So, now we can build the project : Project -> Build Project. Two executable file will be generated : test.elf (for JTAG debugger) and test.bin, which may be used to create bootable SD card, using cfimager-imx.exe utility : CMD> cfimager-imx -o 0 -f test.bin -d g: Please use readme files in the enclosed for more details.
View full article
Recipes to include Amazon's Alexa Voice Services in your applications. Step 1 : Get iMX Yocto AVS setup environment Review the steps under Chapter 3 of the i.MX_Yocto_Project_User'sGuide.pdf on the L4.X LINUX_DOCS to prepare your host machine. Including at least the following essential Yocto packages $ sudo apt-get install gawk wget git-core diffstat unzip texinfo \   gcc-multilib build-essential chrpath socat libsdl1.2-dev u-boot-tools Install the i.MX NXP AVS repo Create/Move to a directory where you want to install the AVS yocto build enviroment. Let's call this as <yocto_dir> $ cd <yocto_dir> $ repo init -u https://source.codeaurora.org/external/imxsupport/meta-avs-demos -b master -m imx-alexa-sdk-4.9.11.xml Download the AVS BSP build environment: $ repo sync Step 2: Setup yocto for Alexa_SDK image with AVS-SETUP-DEMO script: Run the avs-setup-demo script as follows to setup your environment for the imx7d-pico board: $ MACHINE=imx7d-pico DISTRO=fsl-imx-x11 source avs-setup-demo.sh -b <build_sdk> Where <build_sdk> is the name you will give to your build folder. After acepting the EULA the script will prompt if you want to enable: a Sound Card selection The following Sound Cards are supported on the build: SGTL (In-board Audio Codec for PicoPi) 2-Mic Synaptics/Conexant 2-Mic TechNexion Voice Hat (with DSPConcepts SW) The script will prompt to select the soundcard you will be using: Which Sound Card are you going to use? Sigmatel .............................. 1 Synaptics/Conexant .................... 2 VoiceHat (for DSPConcepts SW) ......... 3 Type the number of your selection and press Enter... Install Alexa SDK Next option is to select if you want to pre-install the AVS SDK software on the image. Do you want to build/include the AVS_SDK package on this image(Y/N)? If you select YES, then your image will contain the AVS SDK ready to use (after authentication). Note this AVS_SDK will not have WakeWord detection support, but it can be added on runtime. If your selection was NO, then you can always manually fetch and build the AVS_SDK on runtime. All the packages dependencies will be already there, so only fetching the AVS_SDK source code and building it is required. Install WiFi support Te WiFi support is optional and requires to get from NXP an additional meta-picopi-wifi layer. Contact NXP to get this layer to be able to support WiFi on your image The image will prompt: Do you want to include WiFi support on this image(Y/N)? Select YES if you already have the complementary meta-avs-demos-wifi layer Finish avs-image configuration At the end you will see a text according with the configuration you select for your image build. Next is an example for a Preinstalled AVS_SDK with Synaptics Sound Card support and WiFi/BT not enabled for PicoPi board. ============================================================ AVS configuration is now ready at conf/local.conf - Sound Card = Synaptics - Alexa SDK 1.7 pre-installed - Wifi supported You are ready to bitbake your AVS demo image now: bitbake avs-image If you want to use QT5DisplayCards, use then: bitbake avs-image-qt5 ============================================================ Step 3: Build the AVS image Go to your <build_sdk> directory and start the build of the avs-image There are 2 options Regular Build: $ cd  <yocto_dir>/<build_sdk>   $ bitbake avs-image With QT5 support included: $ cd  <yocto_dir>/<build_sdk>   $ bitbake avs-image-qt5 The image with QT5 is useful if you want to add some GUI for example to render DisplayCards. Step 4 : Deploying the built images to SD/MMC card to boot on target board. After a build has succesfully completed, the created image resides at <build_sdk>/tmp/deploy/images/imx7d-pico/ In this directory, you will find imx7d-pico-avs--.sdcard image or imx7d-pico-avs-qt5--.sdcard, depending on the build you chose on Step3. To Flash the .sdcard image into the eMMC device of your PicoPi board follow the next steps: Download the bootbomb flasher Follow the instruction on Section 4. Board Reflashing of the Quick Start Guide for AVS kit to setup your board on flashing mode. Copy the built SDCARD file $ sudo dd if=imx7d-pico-avs.sdcard of=/dev/sd<partition> bs=1M && sync $ sync Properly eject the pico-imx7d board: $ sudo eject /dev/sd<partition> NXP Documentation Refer to the Quick Start Quide for AVS SDK to fully setup your PicoPi board with Synaptics 2Mic and PicoPi i.mx7D For a more comprehensive understanding of Yocto, its features and setup; more image build and deployment options and customization, please take a look at the i.MX_Yocto_Project_User's_Guide.pdf document from the Linux documents bundle mentioned at the beginning of this document. For a more detailed description of the Linux BSP, u-boot use and configuration, please take a look at the i.MX_Linux_User's_Guide.pdf document from the Linux documents bundle mentioned at the beginning of this document.
View full article