i.MXプロセッサ ナレッジベース

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

i.MX Processors Knowledge Base

ディスカッション

ソート順:
By default Linux BSP will work with LVDS screen on i.MX 6SoloX SABRE board. To enable MCIMX28LCD on the board, following need to be modified in u-boot: setenv panel 'MCIMX28LCD' setenv fdt_file 'imx6sx-sdb-lcdif1.dtb' #add video=mxc_lcdif:SEIKO-WVGA,bpp=16 to kernel command line you’re using #For example, when booting from MMC it will be: #  setenv mmcargs 'setenv bootargs console=${console},${baudrate} root=${mmcroot} video=mxc_lcdif:SEIKO-WVGA,bpp=16' saveenv
記事全体を表示
In this post we see how to setup a Debian server, to allow booting the i.MX6 sabre sd platform (mostly) from the network. Booting from the network instead of e.g. the SD card is very handy for day to day development and testing, as it eliminates almost all physical interactions with the board and saves much time. Also, fortunately for us, both u-boot and Linux for i.MX6 support network booting out of the box. Boot sequence principles Before we setup the server, here are some more details on the boot sequence we will obtain in the end: i.MX6 boots, loads u-boot from SD card. u-boot starts, loads its environment (boot commands) from SD card. u-boot obtains its network address by DHCP, loads a Linux kernel uImage and a dtb by TFTP. Linux boots; obtains its network address by DHCP (again), mounts its root filesystem on NFS. Setting up DHCP and TFTP One can easily setup a Debian server to act as DHCP and TFTP server with Dnsmasq; just install the dnsmasq package. The default configuration is mostly empty; so we need to enhance it a bit. For the following we will assume that your Debian server has IP address 192.168.111.1 on the network where it sees the i.MX6 sabre sd platform. You can add some options to a dnsmasq config file such as e.g. /etc/dnsmasq.d/my-custom-config-file:   dhcp-range=192.168.111.50,192.168.111.150,12h   enable-tftp   tftp-root=/var/ftpd This informs dnsmasq to act as a DHCP server for addresses range 192.168.111.50-150 and act as TFTP server, which serves files under /var/ftpd. That means you will need to copy a Linux uImage and an imx6q-sabresd.dtb under /var/ftpd/. See this post for more details about compiling Linux to obtain those two files. Setting up NFS If we want the root filesystem to be mounted on the network we will need to export some folders with NFS from the Debian server. We need to install the nfs-kernel-server package and setup /etc/exports with a line such as:   /tftpboot       192.168.111.*(rw,no_root_squash,subtree_check) This allows clients on the 192.168.111.0 network to access filesystems under the /tftpboot folder. So you will need to create a /tftpboot folder on the server, and install some "filesystem" under there. For this example we assume you will have a busybox installed under a /tftpboot/busybox/ folder. That means we want to have under there all folders such as bin, dev, etc... See this post for details on how to compile busybox to populate this folder. Do not forget to restart the NFS server after configuration, with:   # /etc/init.d/nfs-kernel-server restart We are now setup on the server side. Setting up u-boot At the time of this writing we need to help u-boot a bit when booting the i.MX6 sabre sd platform from the network. Stop at u-boot prompt and configure a few things:   env default -a   setenv netargs $netargs rw   setenv serverip 192.168.111.1   setenv nfsroot /tftpboot/busybox   setenv bootcmd run netboot   saveenv Reset your board; it should now boot from the network:   U-Boot 2013.07-rc1-00210-gc623eb0 (Jun 27 2013 - 21:10:47)   (..)   Hit any key to stop autoboot:  0   Booting from net ...   BOOTP broadcast 1   DHCP client bound to address 192.168.111.121   Using FEC device   TFTP from server 192.168.111.1; our IP address is 192.168.111.121   Filename 'uImage'.   Load address: 0x12000000   Loading: #################################################################            #################################################################            #################################################################            #################################################################            ##########################            4 MiB/s   done   Bytes transferred = 4185600 (3fde00 hex)   BOOTP broadcast 1   DHCP client bound to address 192.168.111.121   Using FEC device   TFTP from server 192.168.111.1; our IP address is 192.168.111.121   Filename 'imx6q-sabresd.dtb'.   Load address: 0x11000000   Loading: ##            2.7 MiB/s   done   Bytes transferred = 22818 (5922 hex)   ## Booting kernel from Legacy Image at 12000000 ...      Image Name:   Linux-3.10.0-rc7   (..)   Starting kernel ...   Booting Linux on physical CPU 0x0   Linux version 3.10.0-rc7 (jenkins@debian) (gcc version 4.7.2 (Debian 4.7.2-5) ) #1 SMP Tue Jun 25 08:28:31 CEST 2013   (..)   Kernel command line: console=ttymxc0,115200 root=/dev/nfs ip=dhcp nfsroot=192.168.111.1:/tftpboot/busybox,v3,tcp rw   (..)   fec 2188000.ethernet eth0: Freescale FEC PHY driver [Generic PHY] (mii_bus:phy_addr=2188000.ethernet:01, irq=-1)   IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready   libphy: 2188000.ethernet:01 - Link is Up - 1000/Full   IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready   Sending DHCP requests ., OK   IP-Config: Got DHCP answer from 192.168.111.1, my address is 192.168.111.121   IP-Config: Complete:        device=eth0, hwaddr=00:04:9f:02:b7:fd, ipaddr=192.168.111.121, mask=255.255.255.0, gw=192.168.111.1        host=192.168.111.121, domain=, nis-domain=(none)        bootserver=192.168.111.1, rootserver=192.168.111.1, rootpath=        nameserver0=192.168.111.1   ALSA device list:     No soundcards found.   VFS: Mounted root (nfs filesystem) on device 0:11.   devtmpfs: mounted   Freeing unused kernel memory: 292K (806d5000 - 8071e000)   Please press Enter to activate this console. Enjoy! Bonus: updating u-boot by the network One last piece remains on the SD card: u-boot. If you do not want to move your SD card out of its slot any more, here is a method for you to update even u-boot from the network. You will need to copy u-boot.imx under /var/ftpd. See this post for details on how to compile u-boot and obtain u-boot.imx. Then, at u-boot prompt, do:   dhcp $loadaddr u-boot.imx   mmc dev 1   mmc write $loadaddr 2 600 This will download a new u-boot.imx from the network and flash it to your SD card; reboot your board and you are done. Note that we give 600 as the number of SD card blocks to write; this is a rough estimate of ~300KB, which should work in most of the cases as writing a bit "too much" blocks does not harm. If you are very picky, you can compute the exact number of blocks by dividing your u-boot.imx size by 512 and rounding it up. See also... Did you know that dnsmasq primary role is to be used to "relay" the DNS queries? A feature that come very handy when you want to let your i.MX6 platform "see" the internet.
記事全体を表示
Introduction The SABRE Board for Smart Devices Based on the i.MX 6 Series is an evalutaion board featuring the i.MX6 Quad Core Cortex-A9 processor. Freescale ported the Linux Operating System (as of this writing version 3.0.35) and the Board Support Package (BSP) containing the Linux Kernel, build system called LTIB, GCC compiler tools, boot loader, u-boot, and root file system is available for download, install, and build. LTIB is a perl script and is the acroynm for Linux Target Image Builder. This document describes setting up a CentOS 6.3 64-bit host in a virtual machine for using the BSP and running the images on i.MX6Q-SDB evaluation board. References Description Reference CentOS 6.3 LiveCD installed in a virtual machine from virtual box. http://centos.org CentOS-6.3-x86_64-LiveCD.iso 9953ff1cc2ef31da89a0e1f993ee6335 Virtual Box - A Virtual Machine used for creating the CentOS host. Virtual Box installed on Windows 7 64-bit Pro, then create the VM. Allocated 20 GB Hard disk and 1 MB RAM. The steps for installations are found at the virtual box web site. http://www.virtualbox.org The BSP provides, a build system called ltib, GNU tools, U-Boot, Linux Kernel, and root file system: Download archive from http://freescale.com/sabresdb L3.0.35_12.09.01.0_GA_source.tar.gz 5ab4198278e92e03be74ca602227afad Document Conventions Bold lines are Linux commands and edits run on CentOS. The '$' indicates running the command as a regular user The '#' indicates running the command as root user. CentOS Host Setup For this example a virtual machine is used, however a dedicated PC running only CentOS linux could be used. 1. Add user login to sudo'ers file           Login as user root and run the visudo command          # visudo           Add the following line and save the file:           user     ALL=(ALL)     ALL 2. Update the system packages:           $ sudo yum udpate 3. Install package for "ltib" operations:           $ sudo yum install make gcc gcc-c++ kernel-devel bison libuuid-devel ncurses-devel zlib-devel lzo-devel intltool libtool tcl rpm-build perl-ExtUtils-MakeMaker ld-linux.so.2 zlib-1.2.3-27.el6.i686 4. Update sudo'ers file for supporting ltib rpm           $ sudo visudo           Add the following line and save the file:           user     ALL=NOPASSWD: /bin/rpm,/opt/freescale/ltib/usr/bin/rpm Install BSP The sources are in a tar gziped archive file which is downloaded from http://freescale.com/sabresdb, selecting the Software & Tools tab then expanding Run-time Software in the middle of the page. A free login is required for download which can be registered for by selecting the Login at the top right of the freescale.com page. Once downloaded, verify the md5 checksum (see references above for the value). $ mkdir ~/imx6 $ tar -zxf L3.0.35_12.09.01.01_GA_source.tar.gz -C ~/imx6 $ cd ~/imx6/*source $ ./install Read and accept the licensing information. Choose a directory to install too, for this example entered .. which is the parent directory. Build the i.MX6Q SDB $ cd ~/imx6/ltib $ ./ltib After some time (depends on how fast your host computer is) the menuing system is shown which allows you to select build configurations. The second screen selects the development platform which is imx6q for the SDB. For this example the Min profile is chosen which is the default. Use the arrow keys to move and the enter key to select. The space bar selects/deselects an entry. Use the right arrow key to move to <Exit> and press the enter key. The save dialog box is presented, save. The next menu is the iMX6x Base Boards which leaving all as default except for the U-boot board selection which is mx6q_sabresd for the SDB. Save and exit. Images When ltib completes, the images are found in <ltib>/rootfs/boot. Bootloader = u-boot.bin Linux Kernel = uImage File system = </ltib>/rootfs
記事全体を表示
Downloading and building the V4L2 examples V4L2 examples - v0.1 are available at https://github.com/rogeriorps/v4l2-examples To download, just clone the project: $ git clone https://github.com/rogeriorps/v4l2-examples.git Available demos Example1: Display an image coming from camera using V4L2_BUF_TYPE_VIDEO_OVERLAY Example2: Display an image coming from camera using V4L2_BUF_TYPE_VIDEO_OUTPUT Known issues
記事全体を表示
How To Convert RealView CP15 Config To OpenOCD? # arm11 mcr <jtag_target> <coprocessor> <opcode 1> <CRn> <CRm> <opcode 2> <32bit value to write> Setting CP15 Control RealView: setreg @CP15_CONTROL=0x00050078 OpenOCD: arm11 mcr 1 15 0 1 0 0 0x00050078 Setting CP15 Peripheral Memory Remap RealView: setreg @CP15_PERIP_MEM_REMAP=0x40000015 OpenOCD: arm11 mcr 1 15 0 15 2 4 0x40000015
記事全体を表示
Attached is a chunk of the Filesystem needed to construct the Linux Image https://community.freescale.com/docs/DOC-93887
記事全体を表示
Some of SDIO cards need SD clock active for 4-bit mode, in order to generate interrupt. But i.MX6 SD controller enables SD clock gated by default, the attached patch is an example to disable SD clock gated. It's able to check if clock gated is enable or not by the register, "uSDHCx_PRES_STATE:SDOFF", of SD controller.
記事全体を表示
通常的音乐播放是这样一个流程: alsa将一段上层的应用空间和底层的物理空间通过mmap映射起来,然后DMA从被映射的物理空间往I2S的fifo传送数据。 现在有个客户想将FEC网络那边收到的数据中的audio数据分离出来,暂存到一段物理内存中,然后通过DMA传输到我们芯片的I2S fifo,从而节省掉数据在上层、底层之间来回调用的时间。 这就需要我们I2S这边支持通过DMA直接从一段物理内存拿数据。 为了较为方便的实现这一功能,通过对ALSA架构的分析,我保留了我们整个ASoC代码的架构,只是不让DMA从原来的mmap的地址拿数据,而是从我自己分配的DMA内存中拿数据。 258         uint8_t *wbuf; 259         uint8_t *index1; 261         wbuf = dma_alloc_coherent(NULL, 0x10000, &wpaddr, GFP_DMA); 265         for (i=0; i<0x10000; i++) { 269                         *(wbuf + i) = wav_data[i]; 273         } 333                 iprtd->desc = chan->device->device_prep_dma_cyclic( 334                         chan, wpaddr, 335 //                      chan, dma_addr, 336                         iprtd->period_bytes * iprtd->periods, 337                         iprtd->period_bytes, 338                         substream->stream == SNDRV_PCM_STREAM_PLAYBACK     ? 339                         DMA_TO_DEVICE : DMA_FROM_DEVICE); 代码实现上,实际上是比较简单的,可以套用以前做过的dma_m2m的部分代码。 现在我们要拿一些wav里面的audio数据。 linux可以用16进制的方法读wav里面的数据: hexdump -n 65700 -C audio44k16S.wav > wav_data_44100_s16_stereo.h将audio44k16S.wav 里面的audio数据用16进制的形式保存到wav_data_44100_s16_stereo.h这个文件里。 然后我们要编辑这个头文件里的audio数据,原数据是这种格式的: 00000000  52 49 46 46 12 63 0c 00  57 41 56 45 66 6d 74 20  |RIFF.c..WAVEfmt | 00000010  12 00 00 00 01 00 02 00  44 ac 00 00 10 b1 02 00  |........D.......| 00000020  04 00 10 00 00 00 66 61  63 74 04 00 00 00 b5 18  |......fact......| 00000030  03 00 64 61 74 61 d4 62  0c 00 58 01 f0 00 98 01  |..data.b..X.....| 00000040  56 01 3d 01 1e 01 d0 00  ae 00 81 00 35 00 40 00  |V.=.........5.@.| 00000050  dd ff f7 ff 90 ff 9f ff  1d ff 54 ff bb fe 18 ff  |..........T.....| 00000060  61 fe 1e ff e7 fd 5e ff  e4 fd 23 00 39 fe ee 00  |a.....^...#.9...| 我们要把它转换成符合我们要求的这种形式: ,0x63 ,0xf0 ,0x0f ,0xf0 ,0x7f ,0xf1 ,0x21 ,0xf1  ,0x89 ,0xf3 ,0xef ,0xf2 ,0x9d ,0xf5 ,0x8c ,0xf4 ,0x5f ,0xf7 ,0xd3 ,0xf5 ,0x8c ,0xf8 ,0x08 ,0xf7  ,0x4c ,0xf9 ,0x01 ,0xf8 ,0x74 ,0xf9 ,0x2e ,0xf8 ,0x1c ,0xf9 ,0x15 ,0xf8 ,0x09 ,0xf9 ,0x82 ,0xf7  ,0x45 ,0xf9 ,0xd1 ,0xf6 ,0x0b ,0xf9 ,0x1e ,0xf6 ,0xce ,0xf8 ,0xbe ,0xf5 ,0xd7 ,0xf8 ,0x9a ,0xf5  ,0xa8 ,0xf9 ,0xc7 ,0xf5 ,0xe0 ,0xfa ,0x3e ,0xf6 ,0x25 ,0xfc ,0x44 ,0xf7 ,0x44 ,0xfd ,0xa2 ,0xf8  ,0x9a ,0xfe ,0xea ,0xf9 ,0x25 ,0x00 ,0x94 ,0xfb ,0x16 ,0x02 ,0xec ,0xfc ,0xcb ,0x03 ,0xfe ,0xfd  ,0xef ,0x04 ,0xa5 ,0xfe ,0x45 ,0x05 ,0x0b ,0xff ,0x3b ,0x05 ,0x24 ,0xff ,0x34 ,0x05 ,0x94 ,0xff  ,0x06 ,0x05 ,0x13 ,0x00 ,0x6c ,0x04 ,0x82 ,0x00 这里有一个比较好的方法, 可以通过VIM 垂直编辑的方法较为轻松的实现。 vim垂直编辑: ctrl+v 然后上下左右移动选中,D删除选中的。 ctrl+v 选中, shift+i 可以在选中的地方加入想插入的字符。 将编辑过的数据放到uint8_t wav_data[],赋值给wbuf,wbuf对应的物理地址wpaddr中的数据,就是上面wav中的audio数据。 wbuf = dma_alloc_coherent(NULL, 0x10000, &wpaddr, GFP_DMA);中的0x10000=1024*64是我们分配的dma内纯的大小,我们sdma是根据以下大小传输数据的: iprtd->period_bytes = 21844, iprtd->periods = 3 //21844*3=65532= 0xfffc 这样实际上DMA是不停的刷我们分配的内存里的数据,因为我们没有更新DMA内存里的数据,所以听到的是不断重复播放的声音片段。 刚开始时,我听这个片段,发现片段之间有较为明显的pop音,这是由于我截取的是一首音乐开始的部分,包含了wav包头数据,这不是音乐数据,将这个去除就可以了。
記事全体を表示
Hi, the document "how to create ubuntu hardfloat rootfs for imx6d/q" was shared by Junping Mao. https://community.freescale.com/docs/DOC-95387 Here, i build the OpenCV based on the ubuntu hardfloat rootfs for i.MX6Q sabre board. Details about building instruction pls refer to the attachment. Thanks! 
記事全体を表示
Hello,   recently I'm running CTS test on MX6Q SabreSD to fix some of the issues my customer found, and found that "factory reset" is an important step during the test-environment setup but not mentioned in i.MX CTS test report.   "Factory reset" is need on official CTS page: Setting up CTS | Android Open Source Project     Without factory reset, the CTS test result in "android.core.tests.libcore.package.libcore" package looks like: There are total 8 failed items.     If we run "factory reset" before conduct the CTS test in in "android.core.tests.libcore.package.libcore" package, only 2 failed items found as below:   PS: and those 2 failed items can be waived, according to the test-house of CTS tests. PS1: the test reports of are also attached.       Please do run "factory reset" before CTS test, verified working on 4.2.2 and should also work on the version above according to the pages I found on Google when trying to fix this issue. Unfortunately "factory reset" is not documented in the environment setup process in i.MX CTS test report, you will need this if you are following the steps in i.MX CTS test report.   Best regards, Jim.
記事全体を表示
Minicom       It's a simple terminal program, easy to configure and use. Can be downloaded and installed from your Linux package distribution (Synaptic, apt-get, yum) or through this link.       Minicom is a terminal emulation that can access a remote serial console enabling the configuration of Bootloader or the flash file system of the board.   Configuring       Run Minicom calling it from Terminal:     $ minicom       Reach the cofiguration by typing CTRL-A Z Press key Z after releasing CTRL and A. Configure Minicom to work with i.MX, follow the procedure below.   Set the Serial Port       At the screen configuration, type O, choosing Configure Minicom In menu, choose Serial Port Setup Below, the configuration option:       +-----------------------------------------------------------------------+ | A - Serial Device  : /dev/ttyS0                            | | B - Lockfile Location  : /var/lock                          | | C - Callin Program  :                                          | | D - Callout Program  :                                        | | E - Bps/Par/Bits  : 115200 8N1                          | | F - Hardware Flow Control : No                          | | G - Software Flow Control : No                            | |                                                                        | | Change which setting?                                      | +-----------------------------------------------------------------------+       Type the letter of option to enable the modification. Remember to choose the right Serial Device. Screen       Another useful program to use with serial ports is screen. It is a screen manager with VT100/ANSI terminal emulation usually available in Linux distributions. To open serial device /dev/ttyS0, for example, using 115200 baudrate, simply use:     $ screen /dev/ttyS0 115200       To kill the screen manager, use Ctrl + a, k. For a list of useful parameters and commands, try:     $ man screen
記事全体を表示
[中文翻译版] 见附件   原文链接: https://community.nxp.com/docs/DOC-343178 
記事全体を表示
Use the EPDC Unit Test to exercise your EPD panel 1.  Introduction The i.MX 6Solo/6DualLite and i.MX 6SoloLite processors contain an Electrophoretic Display Controller (EPDC) designed to drive E-INK(TM) EPD panels supporting a wide variety of TFT backplanes. Detailed information about the EPDC is available in the i.MX 6Solo/6DualLite and i.MX 6SoloLite Reference Manuals. Information about programming the EPDC and integrating support for a particular panel into the Linux BSP is provided in the Linux BSP Reference Manual. Now that you have your panel hardware and software integrated, how can you tell if it is all working? Or perhaps you're using a standard panel that doesn't seem to be working - how can you test it at the lowest level? The answer is the EDPC Unit Test. 2. Running the EPDC Unit Test Most i.MX processor hardware modules have an associated unit test in the unit_tests directory of the root file system image. The basics of running the EPDC unit test are simple. After logging in as root on the debug console, change to the unit tests directory and execute the test as follows: $ cd /unit_tests $ ./mxc_epdc_fb_test.out Without any arguments, the unit test runs thirteen individual tests and takes about 8 minutes to complete. You will get a lot of output on the panel and it may not be obvious that the images are displaying correctly. Running the unit test with no arguments is a nice automated way to make sure your panel is at least displaying something, and is not causing a crash or hang. But to really verify correctness each test should be run individually and the output carefully reviewed. This can be accomplished by passing a test number option as follows: $ ./mxc_epdc_fb_test.out -n 1 To show a list of all the available options, as well as a list of the individual test numbers, use the "-h" argument. The helpful output is shown below. $ ./mxc_epdc_fb_test.out -h EPDC framebuffer driver test program. Usage: mxc_epdc_fb_test [-h] [-a] [-p delay] [-u s/q/m] [-n ]         -h        Print this message         -a        Enabled animation waveforms for fast updates (tests 8-9)         -p        Provide a power down delay (in ms) for the EPDC driver                   0 - Immediate (default)                   -1 - Never                    ms - After ms milliseconds         -u        Select an update scheme                   s - Snapshot update scheme                   q - Queue update scheme                   m - Queue and merge update scheme (default)         -n        Execute the tests specified in expression                   Expression is a set of comma-separated numeric ranges                   If not specified, tests 1-13 are run Example: ./mxc_epdc_fb_test.out -n 1-3,5,7 EPDC tests: 1 - Basic Updates 2 - Rotation Updates 3 - Grayscale Framebuffer Updates 4 - Auto-waveform Selection Updates 5 - Panning Updates 6 - Overlay Updates 7 - Auto-Updates 8 - Animation Mode Updates 9 - Fast Updates 10 - Partial to Full Update Transitions 11 - Test Pixel Shifting Effect 12 - Colormap Updates 13 - Collision Test Mode 14 - Stress Test In addition to "-n" to run individual tests, the "-a" and "-u" options are provided to set animation mode and waveform used, respectively. These options make sense only for some of the individual tests, as noted in the next section. The "-u s" (snapshot) mode purposely does not allow pending updates, so some of the tests will cause the driver to issue the following warning in snapshot mode: imx_epdc_fb: No free intermediate buffers available. The "-p" (power down delay) option allows you to specify how soon the device driver automatically powers down the controller after all pending updates have completed. The default is 0 (zero), meaning power down immediately. Use "-1" to disable power down (i.e. never power down). Sidebar: You can use another unit test, "dump-clocks.sh", to view the state of the EPDC clocks (i.e. the power state of the module). In the example below, a "1" in the third column indicates that the clock is running; a "0" indicates the clock is gated: $ ./dump-clocks.sh | grep epdc epdc_pix_clk             pll5_video_main_clk       1   26666667 epdc_axi_clk             pll2_pfd2_400M             1  198000000 3.  Individual Test Details Important! The notes below assume you are running the version of the unit test binary in the tar file attached to this How-to. Please extract the file mxc_epdc_fb_tests.out from the tar file into your rootfs unit_tests directory before running the test. Most tests begin with a screen blank operation (all white pixels). Each test works with all three update schemes (snapshot, queue, queue and merge) unless otherwise noted. 3.1 Test 1: Basic Updates Draws the following patterns: Crosshatch Squares Text Ginger image Colorbar 3.2 Test 2: Rotation Updates Draws text, squares, crosshatch, and square outlines in all rotation modes: No rotation Clockwise (90 degrees) Upside down (180 degrees) Counterclockwise (270 degrees) The square outlines are drawn first in RGB format and then in Y8 format. 3.3 Test 3: Grayscale Framebuffer Updates Draws a top half black screen and then a colorbar, rotated clockwise. First draws in normal Y8 format and then in inverted Y8 format. 3.4 Test 4: Auto-waveform Selection Updates Draws several small squares using auto-waveform selection. Note: unlike the i.MX508 EPDC driver, the i.MX 6 driver does not report the final waveform selection to user-level applications. This test also verifies that squares at non-8-bit aligned pixels can be drawn. 3.5 Test 5: Panning Updates Draws a colorbar to an off-screen region. Draws the Ginger image to the frame buffer. Sets the focus (pan) to the colorbar, then updates portions of the screen. You should see the colorbar poke through. Slowly pans from Ginger to the entire colorbar. Use pan to flip between black and white buttons. Flashes buttons using pixel inversion. Flashes buttons using panning. 3.6 Test 6: Overlay Updates Switches between the frame buffer (FB) and the alternate (overlay) frame buffer as follows: Draws Ginger to the FB. Draws the colorbar to the alternate frame buffer. Shows the FB (Ginger). Shows the alternate FB (colorbar). Shows FB again (Ginger). Shows half FB, half alternate FB. Shows cutout region of alternate FB. Shows cutout in upper corner. Shows black screen. Shows clockwise-rotated text overlay in center. 3.7 Test 7: Auto-Updates Important! The auto-update mechanism must be enabled in the kernel configuration for this test to work. Enable it using the LTIB Kernel configuration menu item "Device Drivers->Graphics support->E-Ink Auto-update Mode Support." Also, please check the Linux BSP Release Notes for any issues with this feature. 3.8 Test 8: Animation Mode Updates Shows how normal (gray level) and monochrome (black and white) updates compare in appearance and performance. Quickly flashes back and forth between black and white screens. Draws normal squares. Draws black and white squares. Draws Ginger in gray scale and monochrome. Draws colorbar in gray scale and monochrome. Draws normal Y8 colorbar and monochrome colorbar. Draws inverted normal Y8 colorbar and inverted monochrome colorbar. You can run this test in animation mode using the "-a" command line option. Animation mode only updates monochrome pixels, so you will notice a drawing speed improvement. Also, you will see the implementation of one of the "rules" of using this mode: The screen must be blanked (all white or all black) when switching in and out of animation mode. 3.9 Test 9: Fast Updates Animates a square across the screen and down one side. This test can also be run in animation mode using "-a". See the animation mode notes in the Test 8 description above. 3.10 Test 10: Partial to Full Update Transitions Draws small gray squares using separate updates in partial update mode (only pixels that change are updated). Then re-draws the entire screen in one update using full update mode. In full update mode, you will notice the entire screen transition from black to the final grey value. 3.11 Test 11: Test Pixel Shifting Effect Draws a short, two pixel line and then sends two updates one pixel apart in distance and 5 seconds apart in time. Nothing much to see here; just verifies that a one pixel update shift works. 3.12 Test 12: Colormap Updates Creates a colormap and uses it to draw full screen blanks and to draw a color bar. In this test, you should follow along with the text printed in the debug console and verify each state: Screen should be black. Screen should be white now. Screen should still be white. Should be inverted color bar (white to black, left to right). Colorbar again, with no CMAP (black to white, left to right). Posterized colorbar. In the above output, "CMAP" means colormap and "Posterized colorbar" is a colorbar drawn from only black and white components. 3.13 Test 13: Collision Test Mode Draws two overlapping rectangles. Tests for collision on the first rectangle, which should result in the message: Collision test result = 0 Then draws the same overlapping rectangles, this time testing for collision on the second rectangle. The result should be: Collision test result = 1 Note: This test cannot be run using the snapshot scheme. If you try to use "-u s" it will print a message and return. 3.14 Test 14: Stress Test Draws thousands of random rectangles on the screen in different rotations. Runs for about 8 minutes. This test must be explicitly specified on the command line; it does not run by default. For example: $ ./mxc_epdc_fb_test.out -n 14 Note: This test cannot be run using the snapshot scheme. If you try to use "-u s" it will print a message and return. 4. Customizing A great way to know what's really going on in each test is to look at the source code. You may want to customize the source as well - say to add a new test that exercises some cool feature of your panel. Fortunately, the source is included in the BSP distribution so you can extract, customize, and rebuild it as needed. The magic of LTIB is beyond the scope of this article, but here are some hints: # Extract the unit test source from the imx-test package: $ ./ltib -m prep -p imx-test # Source is now in rpm/BUILD/imx-test-12.08.00/test/mxc_fb_test/mxc_epdc_fb_test.c (your package version number my be different). # Build from source: $ ./ltib -m scbuild -p imx-test # Deploy all unit test binaries to ltib rootfs directory: $ ./ltib -m scdeploy -p imx-test # Alternatively you can copy just the epdc unit test binary as follows: $ sudo cp rpm/BUILD/imx-test-12.08.00/platform/IMX6S/mxc_epdc_fb_test.out rootfs/unit_tests/ As noted in the Individual Test Details section, you should replace the file mxc_epdc_fb_test.c referenced above with the one found in the tar file attached to this How-to. 5. Something is wrong! Of course there are many things that can go wrong that are beyond the scope of this article, but assuming your hardware is working and the panel options are correctly configured in the BSP (again, beyond our scope), here are some things to check: Is the kernel configured correctly for EPDC support? Check that the following item is enabled in the LTIB Kernel configuration menu: "Device Drivers->Graphics support->E-Ink Panel Framebuffer." Are the U-boot kernel command line arguments set correctly for EPDC? For example, "video=mxcepdcfb:E060SCM consoleblank=0". The "consoleblank=0" command is useful to prevent entering low power suspend mode while you are testing. Does the "Tux" image display correctly on your panel after system boot? If so, the EPDC driver was a least able to perform the initial framebuffer update to your panel. Note: for Tux to display at boot, you need to disable LCDIF support at "Device Drivers->Graphics support->Support MXC ELCDIF framebuffer." Are there any EPDC-related error messages in the kernel log after boot? You can check with "dmesg | grep epdc".
記事全体を表示
(   converted from discussion created by Alfred Latypov   IMX6 PCI with external cloks  )    Hello, I had a problem, to launch a board with an imx6 solo processor with a pci-express, and with external clock. I'll tell you my decision. On my motherboard there is a pci-switch PI7C9X2G606 from Pericom with 4 endpoints of Intel type 82574 ethernet controller. I used the Linux kernel version 4.9.16 In the device-tree file, I used the following options to enable external clocks for CLK1 input gate (100MHz). Sorry, I had to change the root imx6 device tree file. See attached (imx6*.dtsi) files. From ..kernel/arch/arm/boot/dts/.. Add anatop external clock source for clocks section, and change clk source for pcie-phy. ... anaclk1 {             compatible = "fixed-clock";             reg = <0>;             #clock-cells = <0>;             clock-frequency = <100000000>;  /* 100MHz */         }; ... Change pcie section ...         pcie: pcie@0x01000000 {             compatible = "fsl,imx6q-pcie", "snps,dw-pcie";             reg = <0x01ffc000 0x04000>,                   <0x01f00000 0x80000>;             reg-names = "dbi", "config";             #address-cells = <3>;             #size-cells = <2>;             device_type = "pci";             ranges = <0x81000000 0 0          0x01e00000 0 0x00100000 /* downstream I/O */                   0x82000000 0 0x01000000 0x01000000 0 0x00e00000>; /* non-prefetchable memory */             /* ranges = <0x81000000 0 0          0x01f80000 0 0x00010000                   0x82000000 0 0x01000000 0x01000000 0 0x00f00000>; */             num-lanes = <1>;             interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>;             interrupt-names = "msi";             #interrupt-cells = <1>;             interrupt-map-mask = <0 0 0 0x7>;             interrupt-map = <0 0 0 1 &gpc GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>,                             <0 0 0 2 &gpc GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,                             <0 0 0 3 &gpc GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>,                             <0 0 0 4 &gpc GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>;             clocks = <&clks IMX6QDL_CLK_PCIE_AXI>,                  <&clks IMX6QDL_CLK_LVDS1_IN>,                  <&clks IMX6QDL_CLK_SATA_REF_100M>;             clock-names = "pcie", "pcie_bus", "pcie_phy";             status = "disabled";         }; ... and add new source clocks dependencies: .... &clks {         assigned-clocks = <&clks IMX6QDL_PLL6_BYPASS_SRC>,                           <&clks IMX6QDL_PLL6_BYPASS>;                                   assigned-clock-parents = <&clks IMX6QDL_CLK_LVDS1_IN>,                                  <&clks IMX6QDL_PLL6_BYPASS_SRC>;         assigned-clock-rates = <100000000>, <100000000>; }; .... for your board dtsi. I could not start the pcie-bus with the function Gen2. Next, I needed to change the bus driver (pci-imx6.c), for fine tuning the bus clock frequency. I add MPLL frequency services functions (Thanks for Charle Powe i.MX6Q: Using an external reference for PCIe 😞 ... static void imx_pcie_override_phy_mpll(struct pcie_port *pp, u32 mpll_multiplier, u32 ref_clkdiv2) {     u32 ref_usb2_en;     u32 reg1;               pr_info("Overriding PCIe PHY MPLL config: multiplier = %d, clkdiv2 = %d\n",         mpll_multiplier, ref_clkdiv2);                   // set MPLL to disabled     ////pcie_phy_write(pp->dbi_base, PCIE_PHY_MPLL_OVRD_IN_LO, 0x0001);          // set MPLL multiplier         pcie_phy_write(pp->dbi_base, PCIE_PHY_MPLL_OVRD_IN_LO,             (0x0001<<9 | (mpll_multiplier<<2)) & 0x03fc);          /*      * set the ref_clkdiv2.  when this override is enabled it      * overrides both ref_clkdiv2 and ref_usb2_en.  make sure      * the overriden ref_usb2_en reflects the original value.      */          pcie_phy_read(pp->dbi_base, PCIE_PHY_ATEOVRD, &reg1);          ref_usb2_en = (reg1 >> 1) & 0x1;        /* set the current value of ref_usb2_en as the override */          /* set the ref_clkdiv2 override  */          /* enable the ref_clkdiv2 override */          pcie_phy_write(pp->dbi_base, PCIE_PHY_ATEOVRD,             (ref_usb2_en << 1) | ref_clkdiv2 | (0x1 << 2));             /* enable MPLL */         ///pcie_phy_write(pp->dbi_base, PCIE_PHY_MPLL_OVRD_IN_LO, 0x0003);          } ... call this function in pcie_hos_init ... static void imx6_pcie_host_init(struct pcie_port *pp) {     imx6_pcie_assert_core_reset(pp);            imx6_pcie_init_phy(pp);            imx6_pcie_deassert_core_reset(pp);        imx_pcie_override_phy_mpll(pp, 50, 1); /* tune this */          dw_pcie_setup_rc(pp);     imx6_pcie_establish_link(pp);      if (IS_ENABLED(CONFIG_PCI_MSI))         dw_pcie_msi_init(pp); } ... See documentation for p.p. IMX6DLRM 50.5.1.2. Tune <pci_hotplug_mem_size> global variable for optimal pci window sizes enumeration. See for my imx6_add_pcie_port call. If you use a FEC module, it will stop working. You must use an external clock as specified in the documentation (http://cache.freescale.com/files/32bit/doc/user_guide/IMX6DQ6SDLHDG.pdf ). Changes are shown in the attached dtsi file. For clocks segment ... rmii_clk: clock@0 {             compatible = "fixed-clock";             reg = <0>;             #clock-cells = <0>;             clock-frequency = <50000000>;  /* 50MHz */         }; ... and for fec: ... fec: ethernet@02188000 {                 compatible = "fsl,imx6q-fec";                 reg = <0x02188000 0x4000>;                 interrupts-extended =                     <&intc 0 118 IRQ_TYPE_LEVEL_HIGH>,                     <&intc 0 119 IRQ_TYPE_LEVEL_HIGH>;                 clocks = <&clks IMX6QDL_CLK_ENET>,                      <&clks IMX6QDL_CLK_ENET>,                      <&rmii_clk>;                 clock-names = "ipg", "ahb", "ptp";                 status = "disabled";             }; ... If they are not required, disable this editing this file. Thanks for all. Sorry for my bad English. Alfred <[email protected]> This document was generated from the following discussion: IMX6 PCI with external cloks
記事全体を表示
Building on the success of low-cost, high-performance application development kits, Freescale introduces the i.MX27 Lite Kit. Once again, Developed in Logic Product Development and Freescale have worked together to deliver a product-ready software and hardware platform for OEMs, ODMs, IDHs and independent developers and a price point that's quite appealing. The i.MX27 Lite Kit enables rapid design of embedded products targeting the medical, industrial, wireless, consumer markets and general purpose markets. Leverage the power of the i.MX27 multimedia processor in this cost-effective development solution. Features The Freescale i.MX27 SOM-LV is based on the i.MX27 multimedia applications processor running up to 400 MHz. Click here for the full list of i.MX27 SoC features: Includes i.MX27 SOM-LV module Standard peripheral connectors supporting: Ethernet, LCD, audio in/out, serial, CompactFlash®, MMC/SD, USB host, USB OTG, ATA LogicLoader™ (bootloader/monitor) in executable format GNU Cross-Development Toolchain (compiler, linker, assembler, debugger) included Kit contents: i.MX27 SOM-LV Application baseboard Expansion header breakout board Null-modem serial cable Ethernet crossover cable USB A to mini-B cable 5 volt power supply with power adapters (Europe, Japan, UK, and US) Logic Starter CD QuickStart Guide Zoom™ LV baseboard (146.1 x 158.8 x 17.1 mm) RoHS compliant
記事全体を表示
Fix cdc_ether connection over usb0 stalls and cannot recover after transmitting few MByte data The patch is modified from ENGR00278073.
記事全体を表示
Garz & Fricke GmbH - new software releases - Embedded Linux System Yocto
記事全体を表示
The new i.MX 6 Platform SDK 1.1 release is now available on the http://www.freescale.com/ site. NOTICE: The Platform SDK is no longer available and is unsupported. Please contact your Sales team for assistance. ·      Files available i.MX 6Series Platform SDK Bare-metal SDK for the i.MX 6 series, including reusable drivers and tests for many peripherals, and much example code. Also includes register definition headers files, and register definitions for debuggers. BSD open source license. New features and fixes - Fixed EIM test failure on sabre_ai board. - Added obds application. - Improved FAT filesystem cache. - Improved uSDHC API to allow access to entire 4GB card. - Added stream benchmark application. - Moved filesystem read/write performance test to be a new app. - New cpu_workpoint API in sdk/drivers/cpu_utility. - Improved menu API in sdk/utility/menu.h. - Fixed bug in D-cache invalidate and clean routines. - If an application returns from main(), _sys_exit() will now be called automatically. - Fixed a DDR region overflow linker error when using version 4.5.2 of the toolchain. - Removed smbus driver, as no i.MX6 boards have compatible devices and thus was untested. - Improved GIC driver by making it easier to init with new gic_init() API. - Implemented support for CSI test mode. - Converted SATA driver to use standard register definition macros. - Improvements to PWM driver. - Completely removed use of hw_module_t struct throughout SDK. Driver APIs that previously used this struct have been updated to take the relevant parameters, such as the peripheral instance, directly. Affected drivers: i2c, epit, uart, snvs, gpt, timer, flexcan. - The SDK build system now supports parallel builds. - Added jump_to_sdp() API in system_util.h to enter ROM Serial Download Protocol mode. - Static initialization of C++ objects now works as expected. - Fixed BCH ECC encoded reads and writes in GPMI driver. - Updated DCDs and debugger init scripts to the most recent versions. - Added GpioPin class in gpio driver. See sdk/drivers/gpio/gpio_pin.h. - Added classes for I2C and SPI devices. See sdk/drivers/i2c/i2c_device.h and sdk/drivers/spi/spi_device.h. - Added class to provide a software I2C port. See sdk/drivers/i2c/software_i2c_port.h. - Added gpio_set_gpio() API to gpio driver which configures the pin mux for a GPIO pin. - Added lwIP open source TCP/IP stack to the SDK. - Added two demo applications for lwIP: ping and httpd. - Implemented some minor improvements to ENET and FEC driver APIs. - Changed ENET driver so that it no longer puts the PHY into external loopback mode. A new API is added to enable loopback for the ENET unit test. - Added set_card_access_mode() API to uSDHC driver to replace some global variables that were used to configure DMA and interrupt mode. - Added read_input_string() and read_int() APIs to system_util.h. - Fixed ESAI driver so that it no longer always outputs each sample 3 times. - New arm_set_interrupt_state() API in cortex_a9.h. - Versions of all debugger init scripts are now provided for ARM DS-5. - Fixed a compiler warning generated by gcc 4.7.2 in the gpmi driver. - New version 3.4.0.4 of the IOMux Tool. - New driver for the MMA8451 accelerometer. - Added a full-featured USB Device stack under sdk/common/usb_stack. - Normalized line ending style to Unix (LF) for a few source files. - Created new APIs to manage starting up and shutting down secondary CPU cores. See cpu_start_secondary() and cpu_disable() in sdk/drivers/cpu_utility/cpu_utility.h. - Converted the multicore_demo application to a unit test under sdk/drivers/cpu_utility/test. - Added smp_primes multicore example application. - Improved spinlock API to work correctly in SMP situations. - Many small changes and improvements. - The startup code leaves interrupts disabled, and platform_init() now explicitly enables them. - Added readme files for all applications. - Changed how the makefiles archive objects in .a libraries. The timestamps of objects are compared with their copies in the archive, rather than being compared with the timestamps of the archive itself. This is to work around certain older Linux systems that do not save fractions of a second in file timestamps. One side effect of this is that the ar tool is invoked once per object that needs updating, where previously it was invoked to update a number of files at once. To reduce build log clutter, the archive messages are no longer shown.
記事全体を表示
      Minicom is a terminal emulation that can access a remote serial console enabling the configuration of RedBoot or the flash file system of the board.   Configuring       Reach the configuration by typing CTRL-A Z       Press key Z after releasing CTRL and A!       Configure Minicom to work with i.MX by following the procedures below.     Set the Serial Port       At the screen configuration, type O, choosing cOnfigure Minicom       In menu, choose Serial Port Setup       Below, the configuration option:   +-----------------------------------------------------------------------+   | A - Serial Device  : /dev/ttyS0                             |   | B - Lockfile Location  : /var/lock                          |   | C - Callin Program  :                                          |   | D - Callout Program  :                                        |   | E - Bps/Par/Bits  : 115200 8N1                           |   | F - Hardware Flow Control : No                           |   | G - Software Flow Control : No                           |   |                                                                        |   | Change which setting?                                      |   +-----------------------------------------------------------------------+   Type the letter of option to enable the modification.   Remember to choose the right Serial Device
記事全体を表示
INTRODUCTION REQUIREMENTS HARDWARE CONNECTIONS IMPLEMENTATION AND TESTING 1. INTRODUCTION This document explains how to generate and compile a custom Linux application on the UDOO NEO board  for using the GPIO headers to connect a 16x2 LCD. 2. REQUIREMENTS First of all, the Linux image used is UDOObuntu 2 RC1 (Ubuntu 14.04), available for download from the following link:      Downloads - UDOO​ For creating a bootable SD card and other basic setup please refer to the following guidelines:      Very First Start Then, it is required to install the proper drivers to ensure connectivity, including USB communication with Linux terminal of the target board. Please refer to the link below:      Usb Direct Connection The LCD driver of this document was already implemented on a previous application, and could be found on the following document: Customizing MQX applications on i.MX6SX. 3. HARDWARE CONNECTIONS Now, the hardware connection considers a 4-bit interface to the LCD plus the Register Select (RS) and Enable (E) pins, so, six GPIO are used. For this example, digital input/output pins are used as shown on the following figure (purple rectangle): Where: NEO GPIO GPIO148 GPIO105 GPIO149 GPIO140 GPIO141 GPIO142 LCD pin E RS DB7 DB6 DB5 DB4 4. IMPLEMENTATION AND TESTING After booting Linux, a text editor like nano should be used to generate the program. The three main configurations for GPIOS are the following (using the E pin as example): Export the GPIO. echo 148 > /sys/class/gpio/export Configure the direction of the GPIO (as output). echo out > /sys/class/gpio/gpio148/direction Set the GPIO value to Low or High: echo 0 > /sys/class/gpio/gpio148/value echo 1 > /sys/class/gpio/gpio148/value So, based on these configurations and the LCD driver already implemented on the document mentioned on Requirements section, the complete C application for Linux could be generated (find it attached). The GCC compiler already included on the UDOObuntu image could be used to generate the executable application. The picture below shows the terminal of the UDOO NEO board including the text editor, compilation and execution commands of the application. The used commands are the following: $ nano lcd16x2_imx6sx.c $ sudo gcc lcd16x2_imx6sx.c -o lcd $ sudo ./lcd Finally, the following image shows the LCD with the application working on the UDOO NEO board, connecting the LCD using a proto shield: NOTE: Ensure that M4 core is not running or using the same pins, in order to avoid unexpected behavior on GPIOs.
記事全体を表示