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

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

i.MX Processors Knowledge Base

ディスカッション

ソート順:
We will cross compile L5.4.3_1.0.0 on ubuntu18.04 LTS platform in three steps. 1. Installing Ubuntu 18.04 to vmplayer14 & Configuring Ubuntu 18.04 LTS 2. Compiling L5.4.3_1.0.0 BSP According to Steps in i.MX_Yocto_Project_User's_Guide.pdf 3. Handling tensorflow-lite compilation errors. --BEGIN No.1 Installing Ubuntu 18.04 to vmplayer14 & Configuring Ubuntu 18.04 LTS 1. Install 18.04 on vmplayer After installation is done, root user should be set at first. # sudo passwd root Then follow these steps to configuration ubuntu 18.04 for environment of compiliation --Changing sources of ubuntu 18.04 mirror If you are Chinese users, you can do the step, which can improve your system performance. # sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak # sudo geit /etc/apt/source.list Comment I.MX customers outside China do not need to modify Ubuntu source list, or can modify it to local mirror site of Ubuntu 18.04, which can improve the speed of software upgrade. Delet all sources and copy following lines here, Then save it and exit Update ubuntu source deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic main restricted universe multiverse # deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic main restricted universe multiverse deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-updates main restricted universe multiverse # deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-updates main restricted universe multiverse deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-backports main restricted universe multiverse # deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-backports main restricted universe multiverse deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-security main restricted universe multiverse # deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-security main restricted universe multiverse # deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-proposed main restricted universe multiverse # deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-proposed main restricted universe multiverse Then running these 2 commands to update sources and packages # sudo apt-get update # sudo apt-get upgrade 2. Installing packages for compiliation Packages For Compiling BSP # sudo apt-get install flex bison gperf build-essential zlib1g-dev lib32ncurses5-dev x11proto-core-dev libx11-dev lib32z1-dev libgl1-mesa-dev tofrodos python-markdown libxml2-utils xsltproc # sudo apt-get install uuid-dev:i386 liblzo2-dev:i386 gcc-multilib g++-multilib subversion openssh-server openssh-client uuid uuid-dev zlib1g-dev liblz-dev lzop  liblzo2-2 liblzo2-dev git-core curl # sudo apt-get install u-boot-tools mtd-utils android-tools-fsutils openjdk-8-jdk device-tree-compiler aptitude libcurl4-openssl-dev nss-updatedb # sudo apt-get install chrpath texinfo gawk cpio diffstat No.2 Compiling L5.4.3_1.0.0 BSP According to Steps in i.MX_Yocto_Project_User's_Guide.pdf          The detailed BSP compilation steps are given in i.MX_Yocto_Project_User's_Guide.pdf. Here are just some tips and simple steps. For Chinese customers, the system may not respond when the repo init or repo sync command is executed after obtaining the repo script. Detailed description is below: (1)Getting repo script # mkdir ~/bin (this step may not be needed if the bin folder already exists) # curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo # chmod a+x ~/bin/repo # export PATH=~/bin:$PATH (2)Getting Yocto source # mkdir imx-yocto-bsp # cd imx-yocto-bsp # repo init -u https://source.codeaurora.org/external/imx/imx-manifest -b imx-linux-zeus -m imx-5.4.3-1.0.0.xml # repo sync          After running repo init or repo sync, you may encounter a situation where there is no progress for a long time, and repo sync stops there without any prompt. This may be caused by googlesource site being inaccessible.          At this time, you can modify the googlesource URL to the URL of Tsinghua University. # gedit ./repo          Changing REPO_URL = 'https://gerrit.googlesource.com/git-repo'          To be:                    REPO_URL = 'https://mirrors.tuna.tsinghua.edu.cn/git/git-repo'          Save and exit. Then run “repo init -u https://source.codeaurora.org/external/imx/imx-manifest -b imx-linux-zeus -m imx-5.4.3-1.0.0.xml”. or repo sync No.3 Handling tensorflow-lite compilation errors       If you encounter a tensorflow-lite compilation error during the compilation process, the following processing methods may be helpful to you. Cause Analysis:          Compiling tensorflow-lite requires three steps: fetching packages, configuring environment, and compiling code.          During the configuring environment, the following 8 software packages need to be downloaded. If any of the 8 files are not successfully downloaded, an error will be reported and compilation will be terminated.          ①9f48e814419e.tar.gz          ②38ebac7b059e84692f53e5938f97a9943c120d98.zip          ③release-1.8.0.tar.gz          ④389ec3f906f018661a5308458d623d01f96d7b23.tar.gz          ⑤master.zip          ⑥816a4ae622e964763ca0862d9dbd19324a1eaf45.tar.gz          ⑦1f5eae5d6a135ff6811724f6c57f911d1f46bb15.tar.gz          ⑧fft.tgz          If you encounter this problem, you can refer to the following methods to solve it. Open the file with editor: ~/imx-yocto-bsp/build-xwayland/tmp/work/aarch64-poky-linux/tensorflow-lite/1.13.2-r0/git/tensorflow/lite/tools/make/download_dependencies.sh URLs EIGEN_URL="https://bitbucket.org/eigen/eigen/get/9f48e814419e.tar.gz" GEMMLOWP_URL="https://github.com/google/gemmlowp/archive/38ebac7b059e84692f53e5938f97a9943c120d98.zip" GOOGLETEST_URL="https://github.com/google/googletest/archive/release-1.8.0.tar.gz" ABSL_URL="https://github.com/abseil/abseil-cpp/archive/389ec3f906f018661a5308458d623d01f96d7b23.tar.gz" NEON_2_SSE_URL="https://github.com/intel/ARM_NEON_2_x86_SSE/archive/master.zip" FARMHASH_URL="https://github.com/google/farmhash/archive/816a4ae622e964763ca0862d9dbd19324a1eaf45.tar.gz" FLATBUFFERS_URL="https://github.com/google/flatbuffers/archive/1f5eae5d6a135ff6811724f6c57f911d1f46bb15.tar.gz" FFT2D_URL="http://www.kurims.kyoto-u.ac.jp/~ooura/fft.tgz" Save and exit. [comment]     Don’t run “bitbake tensorflow-lite -c cleanall before you modify it”, otherwise files will be deleted.  Then try to compile tensorflow-lite like below: # bitbake tensorflow-lite -c compile   At the same time, we can open this directory and check if the following directories are created. If these 8 directories are successfully created, it means that links we modified are no problem.          After tensorflow-lite is successfully built, we can continue to compile full images. # bitbake imx-image-full --END NXP TIC team Weidong Sun 2020/3/30
記事全体を表示
These questions and answers are about interrupt generation at a dedicated (configurable) video output port. The i.MX6D manual (Rev. 0) Image Processing Unit (IPU) chapter mentions: Every DI has 10 timing generator counters. The IPU Interrupt Generator has 10 DI0 counters (1...10) and just 2 DI1 counters (3 & 😎 as interrupt sources. The Interrupt Control Register lists 11 DI0 counters (0...10) Q1. Are the DI timing-generator counters linked to the counters in the interrupt controller, or are they different counters? A1. Yes, the DI timing generator counters are linked to the counters in the interrupt controller. Q2. Why are there 11 counters listed in the interrupt controller, but just 10 counters in the timing generator? A2. There is disp_clk_en_pre in the interrupt controller. Thus the 11 counters: 10 timing generator counters and 1 disp clock generator counter. Q3. Is configurable timing feasible for DI0 by using the timing generator counters? A3. Yes, using the 10 internal timing counters you can generate various timing relationships. In addition, you can detect any of the interrupt counters. For example, if you use counter 8, then you can detect the interrupt associated with counter 8. Q4. Explain the impact of the DI1 counter access of only channels 3 and 8. A4. DI1 also has 10 timing generator counters and 1 disp clock generator counter, which you can use to generate desired waveforms. This is similar to DI0. The difference is only 2 of the 10 counters (plus another disp_clk) are connected to the interrupt controller for DI1. Therefore, there is a restriction for detection. If you use counter 7, read out the counter 7 interrupt of DI1 is not possible. However, 2 channels should be sufficient. These interrupts are usually used to indicate a frame start or a frame end. We usually use counter 3 to represent Vsync. So normally we only use counter 3 interrupt. DI1 has only 3 accesses because this covers the anticipated use case and the desire was to restrict register size. The extra counters facilitate flexible DI1 timing generation.
記事全体を表示
SW: Linux 4.14.98_2.2.0 bsp release , gpu sdk 5.3.0 and patch in this doc HW: i.MX8QXP MEK board Inspired by the GIMP adjust color curve tool,  I write similar gui test code for i.MX8QXP gamma curve tuning. That is on display will show one linear curve first, use mouse to change any part of this curve, after that calculate value of point on changed curve , then pass related value to i.MX8QXP DPU gammcor unit , at last the display effect will be changed by DPU. When test code start up , will draw Y=X curve on display, that will from (0,0) to (500, 500) to (1023,1023). After you use mouse drag some part of the curve, will generated a new point (x_new, y_new) which is not on original Y=X curve. Then need draw a new curve that pass  through the (0,0) , (500, 500) , (x_new, y_new), (1023,1023).  That new curve , i choose to use Catmull-Rom Splines to get it. Use Catmull-Rom Splines for approximate a curve that pass through n point, then need n+2 control point. Extra 2 point could be selected as you want ,and they will affect the shape of the curve. Catmull-Rom Splines could pass through all control point, it is C1 continuity, no convex hull property. For example, there is four control point p0, p1 , p2 , p3,  to draw the curve pass through all of them, it could divide to segment p0 to p1 , segment p1 to p2 , segment p2 to p3. For segment p1 to p2 , select four control point as p0,p1, p2, p3, use Catmull-Rom Splines as below: For segment p0 to p1 , need use four control point as p0, p0, p1, p2: For segment p2 to p3, need use four control point as p1, p2, p3, p3: In this test code,  i will use gpu vertex shader to calculate each segment of curve, then use transform feedback to read back point value of each segment to cpu side, cpu side will pass related value to DPU gammcor unit for gamma tuning.   Test steps: Apply 8qxp_dpu_gammacor_4.14.98_2.2.0.diff on linux-imx for i.MX8QXP DPU device driver. Apply dpu_gamma_curve_gpusdk5.3.0.diff on imx-gpu-sdk for build this gui test code. Update the new kernel image, and copy test code to rootfs. Run any other application first to draw some thing on screen, for example  /usr/share/cinematicexperience-1.0/Qt5_CinematicExperience. Then run gui test code in this code, S01_SimpleTriangle_Wayland. Then there will show one linear curve on display , use mouse to change the curve as you like by put mouse cursor close to the curve, press the mouse button , drag it and release the mouse button, you will see the new curve on display , and also the display effect also be changed. Reference: 1>https://www.nxp.com/products/processors-and-microcontrollers/arm-processors/i-mx-applications-processors/i-mx-8-processors/i-mx-8x-family-arm-cortex-a35-3d-graphics-4k-video-dsp-error-correcting-code-on-ddr:i.MX8X  2>https://www.nxp.com/design/software/embedded-software/linux-software-and-development-tools/embedded-linux-for-i-mx-applications-processors:IMXLINUX?tab=Design_Tools_Tab  3>https://github.com/NXPmicro/gtec-demo-framework  4>https://en.wikipedia.org/wiki/Cubic_Hermite_spline  5>http://www.mvps.org/directx/articles/catmull
記事全体を表示
Fast GPU Image Processing in the i.MX 6x by Guillermo Hernandez, Freescale Introduction Color tracking is useful as a base for complex image processing use cases, like determining what parts of an image belong to skin is very important for face detection or hand gesture applications. In this example we will present a method that is robust enough to take some noise and blur, and different lighting conditions thanks to the use of OpenGL ES 2.0 shaders running in the i.MX 6X  multimedia processor. Prerequisites This how-to assumes that the reader is an experienced i.mx developer and is familiar with the tools and techniques around this technology, also this paper assumes the reader has intermediate graphics knowledge and experience such as the RGBA structure of pictures and video frames and programming OpenGL based applications, as we will not dig in the details of the basic setup. Scope Within this paper, we will see how to implement a very fast color tracking application that uses the GPU instead of the CPU using OpenGL ES 2.0 shaders. Step 1: Gather all the components For this example we will use: 1.      i.MX6q ARD platform 2.      Linux ER5 3.      Oneric rootfs with ER5 release packages 4.      Open CV 2.0.0 source Step 2: building everything you need Refer to ER5 User´s Guide and Release notes on how to build and boot the board with the Ubuntu Oneric rootfs. After you are done, you will need to build the Open CV 2.0.0 source in the board, or you could add it to the ltib and have it built for you. NOTE: We will be using open CV only for convenience purposes, we will not use any if its advanced math or image processing  features (because everything happens on the CPU and that is what we are trying to avoid), but rather to have an easy way of grabbing and managing  frames from the USB camera. Step 3: Application setup Make sure that at this point you have a basic OpenGL Es 2.0 application running, a simple plane with a texture mapped to it should be enough to start. (Please refer to Freescale GPU examples). Step 4: OpenCV auxiliary code The basic idea of the workflow is as follows: a)      Get the live feed from the USB camera using openCV function cvCapture() and store into IplImage structure. b)      Create an OpenGL  texture that reads the IplImage buffer every frame and map it to a plane in OpenGL ES 2.0. c)      Use the Fragment Shader to perform fast image processing calculations, in this example we will examine the Sobel Filter and Binary Images that are the foundations for many complex Image Processing algorithms. d)      If necessary, perform multi-pass rendering to chain several image processing shaders  and get an end result. First we must import our openCV relevant headers: #include "opencv/cv.h" #include "opencv/cxcore.h" #include "opencv/cvaux.h" #include "opencv/highgui.h" Then we should define a texture size, for this example we will be using 320x240, but this can be easily changed to 640 x 480 #define TEXTURE_W 320 #define TEXTURE_H 240 We need to create an OpenCV capture device to enable its V4L camera and get the live feed: CvCapture *capture; capture = cvCreateCameraCapture (0); cvSetCaptureProperty (capture, CV_CAP_PROP_FRAME_WIDTH,  TEXTURE_W); cvSetCaptureProperty (capture, CV_CAP_PROP_FRAME_HEIGHT, TEXTURE_H); Note: when we are done, remember to close the camera stream: cvReleaseCapture (&capture); OpenCV has a very convenient structure used for storing pixel arrays (a.k.a. images) called IplImage IplImage *bgr_img1; IplImage *frame1; bgr_img1 = cvCreateImage (cvSize (TEXTURE_W, TEXTURE_H), 8, 4); OpenCV has a very convenient function for capturing a frame from the camera and storing it into a IplImage frame2 = cvQueryFrame(capture2); Then we will want to separate the camera capture process from the pos-processing filters and final rendering; hence, we should create a thread to exclusively handle the camera: #include <pthread.h> pthread_t camera_thread1; pthread_create (&camera_thread1, NULL, UpdateTextureFromCamera1,(void *)&thread_id); Your UpdateTextureFromCamera() function should be something like this: void *UpdateTextureFromCamera2 (void *ptr) {       while(1)       {             frame2 = cvQueryFrame(capture);             //cvFlip (frame2, frame2, 1);  // mirrored image             cvCvtColor(frame2, bgr_img2, CV_BGR2BGRA);       }       return NULL;    } Finally, the rendering loop should be something like this: while (! window->Kbhit ())       {                         tt = (double)cvGetTickCount();             Render ();             tt = (double)cvGetTickCount() - tt;             value = tt/(cvGetTickFrequency()*1000.);             printf( "\ntime = %gms --- %.2lf FPS", value, 1000.0 / value);             //key = cvWaitKey (30);       }       Step 5: Map the camera image to a GL Texture As you can see, you need a Render function call every frame, this white paper will not cover in detail the basic OpenGL  or EGL setup of the application, but we would rather focus on the ES 2.0 shaders. GLuint _texture; GLeglImageOES g_imgHandle; IplImage *_texture_data; The function to map the texture from our stored pixels in IplImage is quite simple: we just need to get the image data, that is basically a pixel array void GLCVPlane::PlaneSetTex (IplImage *texture_data) {       cvCvtColor (texture_data, _texture_data, CV_BGR2RGB);       glBindTexture(GL_TEXTURE_2D, _texture);       glTexImage2D (GL_TEXTURE_2D, 0, GL_RGB, _texture_w, _texture_h, 0, GL_RGB, GL_UNSIGNED_BYTE, _texture_data->imageData); } This function should be called inside our render loop: void Render (void) {   glClearColor (0.0f, 0.0f, 0.0f, 0.0f);   glClear (GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);   PlaneSetTex(bgr_img1); } At this point the OpenGL texture is ready to be used as a sampler in our Fragment Shader  mapped to a 3D plane Lastly,  when you are ready to draw your plane with the texture in it: // Set the shader program glUseProgram (_shader_program); … // Binds this texture handle so we can load the data into it /* Select Our Texture */ glActiveTexture(GL_TEXTURE0); //Select eglImage glEGLImageTargetTexture2DOES(GL_TEXTURE_2D, g_imgHandle); glDrawArrays (GL_TRIANGLES, 0, 6); Step 6: Use the GPU to do Image Processing First we need to make sure we have the correct Vertex Shader and Fragment shader, we will  focus only in the Fragment Shader, this is where we will process our image from the camera. Below you will find the most simple fragment shader, this one only colors pixels from the sample texture const char *planefrag_shader_src =       "#ifdef GL_FRAGMENT_PRECISION_HIGH                    \n"       "  precision highp float;                            \n"       "#else                                          \n"       "  precision mediump float;                    \n"       "#endif                                        \n"       "                                              \n"       "uniform sampler2D s_texture;                  \n"       "varying  vec3      g_vVSColor;                      \n"       "varying  vec2 g_vVSTexCoord;                        \n"       "                                              \n"       "void main()                                    \n"       "{                                              \n"       "    gl_FragColor = texture2D(s_texture,g_vVSTexCoord);    \n"       "}                                              \n"; Binary Image The most Simple Image Filter is the Binary Image, this one converts a source image to a black/white output, to decide if a color should be black or white we need a threshold,  everything below that threshold will be black, and any color above should be white.               The shader code is as follows: const char* g_strRGBtoBlackWhiteShader =     #ifdef GL_FRAGMENT_PRECISION_HIGH                            precision highp float;                            #else                                            precision mediump float;                          #endif                                            varying  vec2 g_vVSTexCoord;                  uniform sampler2D s_texture;                    uniform float threshold;                                                                        void main() {                                    vec3 current_Color = texture2D(s_texture,g_vVSTexCoord).xyz;         float luminance = dot (vec3(0.299,0.587,0.114),current_Color);         if(luminance>threshold)                      \n"             gl_FragColor = vec4(1.0);                \n"           else                                  \n"                          gl_FragColor = vec4(0.0);                \n"       }                                        \n"; You can notice that the main operation is to get a luminance value of the pixel, in order to achieve that we have to multiply a known vector (obtained empirically) by the current pixel, then we simply compare that luminance value with a threshold. Anything below that threshold will be black, and anything above that threshold will be considered a white pixel. SOBEL Operator Sobel is a very common filter, since it is used as a foundation for many complex Image Processing processes, particularly in edge detection algorithms. The sobel operator is based in convolutions, the convolution is made of a particular mask, often called a kernel (on common therms, usually a 3x3 matrix). The sobel operator calculates the gradient of the image at each pixel, so it tells us how it changes from the pixels surrounding the current pixel , meaning how it increases or decreases (darker to brighter values).           The shader is a bit long, since several operations must be performed, we shall discuss each of its parts below: First we need to get the texture coordinates from the Vertex Shader: const char* plane_sobel_filter_shader_src = #ifdef GL_FRAGMENT_PRECISION_HIGH                    precision highp float;                          #else                                    precision mediump float;                        #endif                                          varying  vec2 g_vVSTexCoord;                  uniform sampler2D s_texture;                    Then we should define our kernel, as stated before, a 3x3 matrix should be enough, and the following values have been tested with good results: mat3 kernel1 = mat3 (-1.0, -2.0, -1.0,                                          0.0, 0.0, 0.0,                                              1.0, 2.0, 1.0);    We also need a convenient way to convert to grayscale, since we only need grayscale information for the Sobel operator, remember that to convert to grayscale you only need an average of the three colors: float toGrayscale(vec3 source) {                    float average = (source.x+source.y+source.z)/3.0;        return average;              } Now we go to the important part, to actually perform the convolutions. Remember that by the OpenGL ES 2.0 spec, nor recursion nor dynamic indexing is supported, so we need to do our operations the hard way: by defining vectors and multiplying them. See the following code:   float doConvolution(mat3 kernel) {                              float sum = 0.0;                                    float current_pixelColor = toGrayscale(texture2D(s_texture,g_vVSTexCoord).xyz); float xOffset = float(1)/1024.0;                    float yOffset = float(1)/768.0; float new_pixel00 = toGrayscale(texture2D(s_texture, vec2(g_vVSTexCoord.x-  xOffset,g_vVSTexCoord.y-yOffset)).xyz); float new_pixel01 = toGrayscale(texture2D(s_texture, vec2(g_vVSTexCoord.x,g_vVSTexCoord.y-yOffset)).xyz); float new_pixel02 = toGrayscale(texture2D(s_texture,  vec2(g_vVSTexCoord.x+xOffset,g_vVSTexCoord.y-yOffset)).xyz); vec3 pixelRow0 = vec3(new_pixel00,new_pixel01,new_pixel02); float new_pixel10 = toGrayscale(texture2D(s_texture, vec2(g_vVSTexCoord.x-xOffset,g_vVSTexCoord.y)).xyz);\n" float new_pixel11 = toGrayscale(texture2D(s_texture, vec2(g_vVSTexCoord.x,g_vVSTexCoord.y)).xyz); float new_pixel12 = toGrayscale(texture2D(s_texture, vec2(g_vVSTexCoord.x+xOffset,g_vVSTexCoord.y)).xyz); vec3 pixelRow1 = vec3(new_pixel10,new_pixel11,new_pixel12); float new_pixel20 = toGrayscale(texture2D(s_texture, vec2(g_vVSTexCoord.x-xOffset,g_vVSTexCoord.y+yOffset)).xyz); float new_pixel21 = toGrayscale(texture2D(s_texture, vec2(g_vVSTexCoord.x,g_vVSTexCoord.y+yOffset)).xyz); float new_pixel22 = toGrayscale(texture2D(s_texture, vec2(g_vVSTexCoord.x+xOffset,g_vVSTexCoord.y+yOffset)).xyz); vec3 pixelRow2 = vec3(new_pixel20,new_pixel21,new_pixel22); vec3 mult1 = (kernel[0]*pixelRow0);                  vec3 mult2 = (kernel[1]*pixelRow1);                  vec3 mult3 = (kernel[2]*pixelRow2);                  sum= mult1.x+mult1.y+mult1.z+mult2.x+mult2.y+mult2.z+mult3.x+     mult3.y+mult3.z;\n"     return sum;                                      } If you see the last part of our function, you can notice that we are adding the multiplication values to a sum, with this sum we will see the variation of each pixel regarding its neighbors. The last part of the shader is where we will use all our previous functions, it is worth to notice that the convolution needs to be applied horizontally and vertically for this technique to be complete: void main() {                                    float horizontalSum = 0.0;                            float verticalSum = 0.0;                        float averageSum = 0.0;                        horizontalSum = doConvolution(kernel1);        verticalSum = doConvolution(kernel2);            if( (verticalSum > 0.2)|| (horizontalSum >0.2)||(verticalSum < -0.2)|| (horizontalSum <-0.2))                        averageSum = 0.0;                      else                                                    averageSum = 1.0;                    gl_FragColor = vec4(averageSum,averageSum,averageSum,1.0);                }    Conclusions and future work At this point, if you have your application up and running, you can notice that Image Processing can be done quite fast, even with images larger than 640 480. This approach can be expanded to a variety of techniques like Tracking, Feature detection and Face detection. However, these techniques are out of scope for now, because this algorithms need multiple rendering passes (like face detection), where we need to perform an operation, then write the result to an offscreen buffer and use that buffer as an input for the next shader and so on.  But Freescale is planning to release an Application Note in Q4 2012 that will expand this white paper and cover these techniques in detail.
記事全体を表示
The following document contains a list of document, questions and discussions that are relevant in the community based on amount of views. If you are having a problem, doubt or getting started in i.MX processors, you should check the following links to see if your doubt is in there. Yocto Project Freescale Yocto Project main page‌ Yocto Training - HOME‌ i.MX Yocto Project: Frequently Asked Questions‌ Useful bitbake commands‌ Yocto Project Package Management - smart  How to add a new layer and a new recipe in Yocto  Setting up the Eclipse IDE for Yocto Application Development Guide to the .sdcard format  Yocto NFS &amp; TFTP boot  YOCTO project clean  Yocto with a package manager (ex: apt-get)  Yocto Setting the Default Ethernet address and disable DHCP on boot.  i.MX x Building QT for i.MX6  i.MX6/7 DDR Stress Test Tool V3.00  i.MX6DQSDL DDR3 Script Aid  Installing Ubuntu Rootfs on NXP i.MX6 boards  iMX6DQ MAX9286 MIPI CSI2 720P camera surround view solution for Linux BSP i.MX Design&amp;Tool Lists  Simple GPIO Example - quandry  i.MX6 GStreamer-imx Plugins - Tutorial &amp; Example Pipelines  Streaming USB Webcam over Network  Step-by-step: How to setup TI Wilink (WL18xx) with iMX6 Linux 3.10.53  Linux / Kernel Copying Files Between Windows and Linux using PuTTY  Building Linux Kernel  Patch to support uboot logo keep from uboot to kernel for NXP Linux and Android BSP (HDMI, LCD and LVDS)  load kernel from SD card in U-boot  Changing the Kernel configuration for i.MX6 SABRE  Android  The Android Booting process  What is inside the init.rc and what is it used for.  Others How to use qtmultimedia(QML) with Gstreamer 1.0
記事全体を表示
Overview i.MX6Dual/Quad and i.MX6DualLite supports 32-bit and 64-bit DDR3. Freescale i.MX6 SabreSD board deploys 64bit DDR3 and 64bit DDR3 script is delivered into Linux/Android Software release. This document introduces how to create i.MX6 32bit DDR script based on 64bit DDR script when deploying 32bit DDR on customized board. Changes Set the DSE field in the following iomux registers to 0 - disable unused IO pad to save power: IOMUXC_SW_PAD_CTL_PAD_DRAM_SDQS4 IOMUXC_SW_PAD_CTL_PAD_DRAM_SDQS5 IOMUXC_SW_PAD_CTL_PAD_DRAM_SDQS6 IOMUXC_SW_PAD_CTL_PAD_DRAM_SDQS7 IOMUXC_SW_PAD_CTL_GRP_B4DS IOMUXC_SW_PAD_CTL_GRP_B5DS IOMUXC_SW_PAD_CTL_GRP_B6DS IOMUXC_SW_PAD_CTL_GRP_B7DS IOMUXC_SW_PAD_CTL_PAD_DRAM_DQM4 IOMUXC_SW_PAD_CTL_PAD_DRAM_DQM5 IOMUXC_SW_PAD_CTL_PAD_DRAM_DQM6 IOMUXC_SW_PAD_CTL_PAD_DRAM_DQM7 Update MMDC registers to reflect 32bit DDR changes: MMDC0_MDASP: Update CS0_END if CS size is changed. MMDC0_MDCTL: set DSIZ to 32 bit MMDC1_MPODTCTRL: Set it as 0 and disable the odt of higher byte Follow "i.MX 6 Series DDR Calibration" Application note to calibrate DDR parameters. Reference One example about 32bit DDR script is located under uboot-imx git ( File: board/freescale/mx6q_sabresd/flash_header.S). Open it and you can see the following script: #if defined CONFIG_MX6DL_DDR3 #if defined CONFIG_DDR_32BIT ... #endif You can refer to it and create your 32bit DDR script.
記事全体を表示
iWave's i.MX6 UltraLite (i.MX6UL) based SODIMM CPU module integrates power efficient high performance ARM Cortex A7 CPU core operating up to 528MHz speed. iMX6 UL SOM is ultra-compact in size and integrated with on-board PMIC, Flash, DDR3 and dual Ethernet PHY. The SOM is ideally suitable for the cost & power optimized general embedded and industrial applications.                                                                                                                                                                                                                                                                                                    i.MX6UL SODIMM Development Kit    i.MX6UL SODIMM SOM                                                                                                                                                                                                                                                                                                 Benefits: Ultra-compact form factor module with size of 67.6mm x 29mm Long term support: 7+ years Technical & Quick customization support Compatible with ARM Cortex A9 i.MX6 Q/D/S SODIMM SOM Highlights: Power efficient ARM Cortex-A7 @ 528MHz Advanced hardware enabled security PMIC with DVFS support Industrial temperature support available  Features: CPU: Freescale’s i.MX6UL1/2/3 @ 528MHz ARM Cortex A7 PMIC: Freescale PF3000 Memory: 256MB DDR3 RAM(Expandable) 256MB NAND Flash (Expandable) MicroSD Slot (Optional) 1 eMMC Flash (Optional) 1 QSPI Flash (Optional) 1 Communication: 10/100 Ethernet PHY – 2 Ports SODIMM Edge Interfaces: Debug UART Data UART – 2 Ports CAN – 2 Ports SD(4-Bit) – 1 Port 10/100 Ethernet – Up to 2 Ports 2 USB OTG – 2 Ports 24bpp RGB display port 8-Bit Parallel Camera Port I2S Audio or JTAG I2C x 1 Port PWM GPIOs OS Support: Linux 3.14.28 Power Supply: 3.3V @ 1A through SODIMM edge Note 1: At a time either NAND Flash or eMMC & QSPI flash or uSD & QSPI flash can be used in the SOM. By default NAND Flash is supported. Note 2: If 2 nd Ethernet (ENET2) not used, it can be used as additional 3 UARTs or Key pad 4x4 or RMII interface. Target Applications: Industrial HMI & Access Control Energy management & IOT gateway Industrial control & automation White goods & Smart appliances Medical & Healthcare equipments Mobile POS & Secure e-commerces To send us an enquiry on this product, please click here Enquiry Form To get more details on this product, please write us on [email protected]
記事全体を表示
The instructions is based on building wayland-weston on Ubuntu prebuilt image. The same can be applied to other build systems as well. PREREQUISITIES The following is the software environment required: - Ubuntu Oneiric (11.10) distribution. (Download Pre-built Ubuntu demo image from www.freescale.com/imx6) - Wayland/Weston : Wayland dependencies are listed in http://wayland.freedesktop.org/building.html. - 0001-DRM-condition.patch and 0002-Enable-weston-for-Vivante-GPU.patches for Weston. WAYLAND VERSION This release is based on Wayland 1.1.0 version. BUILDING The steps are based on wayland building from http://wayland.freedesktop.org/building.html. Download wayland-1.1.0.tar.xz from http://wayland.freedesktop.org/releases.html    3. Setting up the environment. This need to be performed on the target $export WLD=/usr $export LD_LIBRARY_PATH=$WLD/lib $export PKG_CONFIG_PATH=$WLD/lib/pkgconfig/:$WLD/share/pkgconfig/ $export ACLOCAL="aclocal -I $WLD/share/aclocal"        Also, create the 'share/aclocal' directory.                $mkdir -p $WLD/share/aclocal       Let us consider, extracting the package to /opt $cd /opt $tar xvvf wayland-1.1.0.tar.xz $cd wayland-1.1.0 $ ./configure --prefix=$WLD --disable-documentation $ make $ make install   4. Setting up GPU-VIV graphics drivers The GPU-VIV graphics drivers are available as part of BSP release. Get the gpu-viv-wl-bin-mx6q-{VER}.tar.gz for 4.0.0 release gpu-viv-wl-bin-mx6q-3.0.35-4.0.0.tar.gz from the BSP-Source/pkgs Extract to the target $ROOTFS The prebuilt root file system (rootfs) may come with prebuilt GPU driver. By default, it may set to EGL framebuffer. To enable Wayland/Weston support, make EGL and GAL point to correct binaries as shown below: $ ls –l $(ROOTFS)/usr/lib/libEGL.so* libEGL.so -> libEGL-wl.so libEGL.so.1 -> libEGL-wl.so $ ls –l $(ROOTFS)/usr/lib/libGAL.so                            libGAL.so -> libGAL-wl.so   5. Build the libxkbcommon as in http://wayland.freedesktop.org/building.html 6. We will need Cairo stack as Weston clients depend on Cairo for rendering. Please build Cairo as described in http://wayland.freedesktop.org/building.html, but note that, for now, we do not enable gl backend for Cairo, so the '--enable-gl --enable-xcb' flags must not be used when building. 7. Building Weston     Now add the following environment settings in the terminal window. (Note the "`"- backtick - character). export WLD=/usr export LD_LIBRARY_PATH=$WLD/lib export PKG_CONFIG_PATH=$WLD/lib/pkgconfig/:$WLD/share/pkgconfig/ export ACLOCAL="aclocal -I $WLD/share/aclocal" export LD_LIBRARY_PATH="/usr/lib" export LDFLAGS="-lwayland-server -lwayland-client -lwayland-server -lwayland-cursor -lpixman-1" export COMPOSITOR_LIBS="-lGLESv2 -lEGL -lGAL -lwayland-server -lxkbcommon -lpixman-1" export COMPOSITOR_CFLAGS="-I $WLD/include -I $WLD/include/pixman-1 -L$SDK_DIR/drivers -DLINUX=1 -DEGL_API_FB -DEGL_API_WL" export CLIENT_CFLAGS="-I $WLD/include -I $WLD/include/cairo -I $WLD/include/pixman-1" export CLIENT_LIBS="-lGLESv2 -lEGL -lwayland-client -lwayland-cursor -lxkbcommon" export SIMPLE_EGL_CLIENT_CFLAGS="-DLINUX=1 -DEGL_API_FB -DEGL_API_WL -I $WLD/include" export SIMPLE_EGL_CLIENT_LIBS="-lGLESv2 -lEGL -lwayland-client -lwayland-cursor" export IMAGE_LIBS="-lwayland-cursor" export WESTON_INFO_LIBS="-lwayland-client" Apply the two patches 0001-DRM-condition.patch and 0002-Enable-weston-for-Vivante-GPU.patch. Build the Weston. $cd /opt $tar xvvf weston-1.1.1.tar.xz $ cd weston-1.1.1     $ ./configure --prefix=$WLD \         --disable-setuid-install \         --disable-x11-compositor --disable-drm-compositor \         --disable-rpi-compositor --disable-wayland-compositor \         --disable-weston-launch --disable-libunwind \         --disable-xwayland-test \ WESTON_NATIVE_BACKEND="fbdev-backend.so" $ make $ make install RUNNING Also, Weston must be run as root. copy weston.ini and weston-desktop-shell.ini to /root/.config/ . In terminal window, export LD_LIBRARY_PATH="/usr/lib" export XDG_RUNTIME_DIR=/tmp Execute 'src/weston'. You should see a blue screen fading in. In a different terminal, enter 'clients/simple-shm &'. You should see a scrolling color pattern. You can then enter 'clients/simple-egl &' to see a 3D client  action.
記事全体を表示
From iMX 3.1x kernel, all kernel debug messages will be print to debug serial port after UART driver loaded, so if the kernel hang up before tty console driver ready, there will be no kernel boot up messages.   The attached patch can be used to enable the iMX serial debug console in early time, then kernel will not buffer the debug messages.   Note: the default patch is for UART1 (tty0) as the debug port, if you need use other debug port, please modify the code "early_console_setup()" with correct UART port base address.   L3.10.53-Add-early-console-for-debug-message.patch This patch is based on L3.10.53_GA1.1.0 release, it can support iMX6S/DL/D/Q.   L3.14.52-Add-early-console-for-debug-message.patch This patch is based on L3.14.52_GA1.1.0 release, it can support iMX6S/DL/D/Q, iMX6SL, iMX6SX, iMX6UL and iMX7.  
記事全体を表示
The i.MX 6 D/Q/DL/S/SL Linux 3.10.17_1.0.1 patch release is now available in the Freescale git. The issue fixed is a GPU issue, for 2D GPU cores there is a potential need to manage the maximum number of outstanding return requests from the memory subsystem. The proper way to manage these for 2D cores with this configuration is to use a FLUSH. The patch does a FLUSH after every DRAW, the pipe will not overfill and the scenario which may lead to a stall will not occur. The instruction to get the patch are in the Readme on the git, under this link: http://git.freescale.com/git/cgit.cgi/imx/fsl-arm-yocto-bsp.git/tree/README?h=imx-3.10.17-1.0.1_ga
記事全体を表示
The document will introduce all steps for poring WM8960 audio codec to freescale android4.2.2 BSP. Attachments include : (1)Document for porting (2)Codec driver : wm8960.c (3)Machine driver: imx-wm8960.c (4)wm8960 schematic for reference (5)Android Audio HAL: config_wm8960.h (6)schematic: MX6QDL-PIANO-CNFV1.DSN (7)i.MX6DL BSP files mx6dl_piano.c mx6dl_piano.h mx6dl_piano_pmic_pfuse100.c (8)i.MX6Q BSP files mx6q_piano.c mx6q_piano.h mx6q_piano_pmic_pfuse100.c   Freescale TICS Team Weidong.sun
記事全体を表示
BSP version: 11.03 Multimedia Package version: 11.03 1. Install BSP and Multi Media package (11.03 release) 2. Avoid Display Timeout: append the following line to rootfs/etc/oprofile: echo -e -n '\033[9]' > /dev/tty0 3. Set VGA port as the primary display in the kernel command line: video=mxcdi1fb:GBR24,VGA-XGA di1_primary vga 4. Connect a VGA monitor and WVGA display to the MX53 Quick Start 5. Boot Linux on MX53 Quick Start board (NFS is used in this example) 6. Unblank WVGA display (fb1): $ echo 0 > /sys/class/graphics/fb1/blank 7. On the target enter into /dev/shm directory. If the following files are present: vss_lock vss_shmem ,delete them. 8. On your host, edit the ltib/rootfs/usr/share/vssconfig as following: vss device definition Master=VGA, Slave=WVGA master display [VGA] type = framebuffer format = RGBP fb_num = 2 main_fb_num = 0 vs_max = 4 slave display [WVGA] type = framebuffer format = RGBP fb_num = 1 vs_max = 4 9. Run the Gstreamer pipeline below: gst-launch filesrc location=file.mp4 ! qtdemux ! mfw_vpudecoder ! mfw_isink display=VGA display-1=WVGA Video is played on the VGA and WVGA panels. A 720p file can be played at the same time.
記事全体を表示
Print caller stack may help you to analyze the program and find out the caller stack more easily. You can write your code like this: Java:      Exception e = new Exception();      Log.e(TAG,"xxx",e); C++ file:       #include <utils/Callstack.h>      android::CallStack stack;      stack.update(1,30);      stacn.dump("xxx"); Then you can see the function's caller stack in Android main log file. C file: #include <corkscrew/backtrace.h> #define MAX_DEPTH 31 #define MAX_BACKTRACE_LINE_LENGTH 800 static backtrace_frame_t mStack[MAX_DEPTH]; static size_t mCount; void csupdate(int32_t ignoreDepth, int32_t maxDepth) {     if (maxDepth > MAX_DEPTH) {         maxDepth = MAX_DEPTH;     }     ssize_t count = unwind_backtrace(mStack, ignoreDepth + 1, maxDepth);     mCount = count > 0 ? count : 0; } void csdump(const char* prefix)\ { size_t i = 0;     backtrace_symbol_t symbols[MAX_DEPTH];     get_backtrace_symbols(mStack, mCount, symbols);     for (i = 0; i < mCount; i++) {         char line[MAX_BACKTRACE_LINE_LENGTH];         format_backtrace_line(i, &mStack[i], &symbols[i],                 line, MAX_BACKTRACE_LINE_LENGTH);         ALOGE("%s%s", prefix, line);     }     free_backtrace_symbols(symbols, mCount); } void myFunc() {      csupdate(1, 30);      csdump("myprefix"); } In Android.mk, add libcorkscrew, as below LOCAL_SHARED_LIBRARIES := libxxx libyyy libcorkscrew
記事全体を表示
       The document will introduce all steps for poring BCM4330/BCM43362 WIFI module to freescale android4.2.2 BSP, it includes these contents: --Hardware & Software Environment --Hardware Design Based on BCM43362 module --i.MX6 BSP configuration for WIFI module --BCM4330/BCM43362 dirver for linux 3.0.35 --Integrated to Android4.2.2    If customer has some questions with the porting, contact me , please ! my email address: [email protected] Freescale TICS team Weidong.sun 2015-08-20
記事全体を表示
Question: The following contradicting information regarding the UART clock tree has been seen in the Rev. 1.0  version of the reference manual: Page 813: PLL3_PFD1 -> divide by 6 -> adjustable post divider -> UART Page 839: PLL3 -> divide by 6 -> UART In the old Rev D I found: Page 803: PLL3 -> divide by 6  ... and something about 80MHz The assumption is that correct path would be: PLL3 -> divide by 6 -> post divider -> UART. Answer: The designer said that UART _CLK_ROOT comes from PLL3 (not PLL3:PFD1) and is divided by 6 to produce 80 MHz. I'm waiting for him to confirm that the divider he mentions is CSCDR1[UART_CLK_PODF].
記事全体を表示
After Nokia acquisition of Trolltech, QT has become an even more interesting framework/tool for UI and graphics development. The new release 4.6 can be obtained under LGPL license and comes with a new integrated IDE for software development (QT Creator) with many demos, some of them using OpenGL. In order to create an environment to create, simulate and cross-compile, it's needed to build three versions of QT: Qt/X11, qmake-x11. This is the Qt version that you will be using on your PC. It is also used for building the tools, such as Designer and Linguist. Qt/QVFb, qmake-qvfb. This is an embedded Qt configuration that runs on host, but works with the virtual framebuffer instead of the actual screen. It let’s you emulate the target system, but run your code on your host machine. Qt/target, qmake-target. This is the embedded Qt configuration that runs on your target platform. This is what you use to build an actual application running on your embedded device. On Host you need TO install following package (for Ubuntu distri) to install this QT toolsuit: [X] libx11-dev [X] libpng-dev [X] libjpeg-dev [X] libxext-dev [X] x11proto-xext-dev [X] qt3-dev-tools-embedded [X] libxtst-dev Building Qt/X11 Extract downloaded Qt package (from here) and install it by running: ./configure make sudo make install Qt will be installed on /usr/local/Trolltech/Qt-version directory. We also need to build qvfb tool that will provide virtual framebuffer for X11. To build and install it run: cd tools/qvfb make sudo make install qvfb will be installed on /usr/local/Trolltech/Qt-version/bin directory. Building Qt/QVFb To build Qt/QVFb, will be needed some parameters on configure file. Extract again Qt package on other folder and build as following: ./configure -embedded -qt-gfx-qvfb -qt-kbd-qvfb -qt-mouse-qvfb -prefix /usr/local/Trolltech/Qt-qvfb-version make sudo make install Used parameters: -qt-gfx-qvfb, the graphics driver will be for QVFb, i.e., the virtual framebuffer. -qt-kbd-qvfb, the keyboard input will come from the QVFb. -qt-mouse-qvfb, the mouse input will come from the QVFb. -prefix /usr/local/Trolltech/Qt-qvfb-version, the prefix is used to separate the QVFb version of embedded Qt from the target version. Testing QVFb So far you have two versions of Qt: 1. Qt/X11 built for PC host using X11 and located at /usr/local/Trolltech/Qt-version 2. Qt/QVFb built for PC host using Qt virtual framebuffer and located at /usr/local/Trolltech/Qt-qvfb-version Call qvfb from X11 version cd /usr/local/Trolltech/Qt-version/bin ./qvfb & A simple virtual framebuffer will open. To change screen configuration and add a skin, click in "file -> configure". The following window will open: i.e., choose ClamshellPhone and click ok. A cell phone skin will open. On QVFb version, there are a lot of example applications that can be run using Qt virtual framebuffer. Let's open fluidlauncher demo: cd /usr/local/Trolltech/Qt-qvfb-version/demos/embedded/fluidlauncher ./fluidlauncher -qws The argument -qws is used to inform that the application will run on Qt virtual framebuffer. Building Qt/Target To build Qt for target (i.MX), it's necessary to build Ltib with some required packages. In this example, a kernel and rootfs will be built for i.MX51 EVK with the following extra packages. [x] amd-gpu-bin-mx51 [x] freetype [x] glib2 [x] gstreamer [x] gstreamer-plugins-base [x] gstreamer-plugins-good [x] gstreamer-plugins-bad [x] gstreamer-plugins-ugly [x] libxml2 [x] tslib [x] zlib If you are building for any other i.MX processor, you don't need the "amd-gpu-bin-mx51" option. After build ltib, make a symbolic link /tftpboot/ltib pointing to your rootfs folder. It's needed to make the i.MX libs and incs available to qmake. ln -s <rootfs folder dir> /tftpboot/ltib Restart nfs server. If using Ubuntu, the command is: sudo /etc/init.d/nfs-kernel-server restart Extract downloaded Qt package on a new folder. Export the crosscompiler path. Usually it's located at /opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin: export PATH=$PATH:/opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin If you are building Qt for i.MX51 Download the mkspec package and extract the folder linux-mxc-g++ under <Qt source code folder>/mkspecs/qws Configure, build and install with the following commands: ./configure -embedded arm -xplatform qws/linux-mxc-g++ -release -prefix /usr/local/Trolltech/Qt-target-version -qt-gfx-linuxfb -qt-kbd-tty -qt-mouse-tslib -opengl es2 -little-endian -host-little-endian make sudo make install For targets without 3D engine support If you are building Qt for a target that doesn't support OpenGL, i.e., i.MX25, 233: Download the makespecs_no3D package and extract the folder linux-mxc-g++ under <Qt source code folder>/mkspecs/qws Configure, build and install with the following commands: ./configure -embedded arm -xplatform qws/linux-mxc-g++ -release -prefix /usr/local/Trolltech/Qt-target-version -qt-gfx-linuxfb -qt-kbd-tty -qt-mouse-tslib -little-endian -host-little-endian make sudo make install Copy Cross Qt to target's RFS The crosscompiled version of Qt will be located on your host machine as indicated on -prefix, in this case /usr/local/Trolltech/Qt-target-version Copy Qt-target-version folder to rootfs: cd /tftpboot/usr/local mkdir Trolltech cd Trolltech cp -a /usr/local/Trolltech/Qt-target-version . Now it's ready to use. On target, run: /usr/local/Trolltech/Qt-qvfb-version/demos/embedded/fluidlauncher/fluidlauncher -qws See some pictures of the same application running on host and on EVK: Tips 1. To clean all Qt configuration settings: make confclean 2. To check the current configuration: On Qt source code folder, you can open the file config.status to check the current configuration settings.
記事全体を表示
Debugging with JTAG JTAG was created to test populated circuit boards after manufacture. Nowadays, JTAG is primarilly used to access sub-blocks of integrated circuits and useful mechanism for debugging embedded systems. When used as a debugging tool, an in-circuit emulator - which in turn uses JTAG as the transport mechanism - enables a programmer to access an on-chip debug module which is integrated into the CPU, via the JTAG interface. The debug module enables the programmer to debug the software of an embedded system. Besides debugging, the second purpose of the JTAG interface is allowing device programmer hardware to transfer data into internal non-volatile device memory. Some device programmers serve a double purpose for programming as well as debugging the device. [Source: http://en.wikipedia.org] All Boards Hardware Software i.MX27 ADS Board Installing OpenOCD and GDB All Boards Debugging Android All Boards How To Understand JTAG BSDL
記事全体を表示
If you already followed the i.MX31ADS Compiling Uboot steps or got a compiled U-boot image, copy u-boot.bin to /tftpboot: $ cp u-boot.bin /tftpboot If you have RedBoot on your board follow the "Installing RedBoot using U-Boot", but if you already have been installed U-Boot and are just installing a new version jump to "Installing U-Boot using U-Boot". Installing U-Boot using RedBoot Load the U-boot image to board RAM: RedBoot> load -v -r -b 0x100000 /tftpboot/u-boot.bin -h 10.29.244.27 Where: 0x100000 is the memory position where the firmware image will be downloaded; 10.29.244.27 is your host IP which is running the TFTP server. Erase the Flash: RedBoot> fis erase -f 0xA0000000 -l 0x00040000 To make sure about what area you should erase, perform the fis list command and compare the areas Write the image to Flash: RedBoot> fis write -f 0xA0000000 -b 0x100000 -l 0x00040000 Reset the board: RedBoot> reset You should see something like this: U-Boot 1.3.3 (May 26 2008 - 11:19:43) CPU: Freescale i.MX31 at 531 MHz Board: MX31ADS DRAM: 128 MB Flash: 32 MB In: serial Out: serial Err: serial Hit any key to stop autoboot: 0 => Installing U-Boot using U-Boot First upload the U-Boot firmware using Network (Transferring file over network ) or Serial (Transferring File Over Serial) This is a common serial transfer output: => loady ## Ready for binary (ymodem) download to 0x80800000 at 115200 bps... CCmode, 1359(SOH)/0(STX)/0(CAN) packets, 9 retries ## Total Size = 0x0002a388 = 172936 Bytes Unprotect the bootloader flash area: protect off A0000000 A003FFFF Erase the flash blocks: erase A0000000 A003FFFF Copy from RAM to Flash: If firmware has been thansfered over serial: cp.b 80800000 A0000000 2a388 If firmware has been transfered over tftp: cp.b 100000 A0000000 2a388 Installing U-Boot using OpenOCD JTAG/GDB To do that you need to compile U-Boot with this define: #define CONFIG_SKIP_LOWLEVEL_INIT 1 Then enter in GDB and execute: (arm-gdb) restore u-boot.bin binary 0x87f00000 Restoring binary file u-boot.bin into memory (0x87f00000 to 0x87f2c790) (arm-gdb) set $pc = 0x87f00000 (arm-gdb) c You will see U-Boot starting in the serial console. Then compile a new U-Boot without the CONFIG_SKIP_LOWLEVEL_INIT and follow the Installing U-Boot using U-Boot to install U-Boot in the flash. Installing U-Boot using LogicLoader losh> ifconfig sm0 dhcp losh> load raw 0x81000000 115764 /tftp/10.29.244.27:u-boot.bin.lite losh> exec 0x81000000 -
記事全体を表示
Question: The code signing tool(CST) of i.MX6 with "CST -h" command just for viewing help message took about 22 minutes. On other system, it was shorter but still took about 2 minutes. CST version is BLN_CST_MAIN_02.00.00. More test results: 1. Print help message => 4 min. dnlk@bauer-mm2014:~/secureboot/bBLN_CST_MAIN_02.00.00/linux$ date && ./cst --help && date Fri Oct 18 14:10:52 KST 2013 Fri Oct 18 14:15:01 KST 2013 2. Signing 512MB file => 11 min. dnlk@bauer-mm2014:~/secureboot/bBLN_CST_MAIN_02.00.00/linux$ date && ./cst --output "out_system.csf" < "example_system.csf" && date Fri Oct 18 14:15:01 KST 2013 CSF Processed successfully and signed data available in out_system.csf Fri Oct 18 14:25:47 KST 2013 3. Signing 3MB file => 17 min. dnlk@bauer-mm2014:~/secureboot/bBLN_CST_MAIN_02.00.00/linux$ date && ./cst --output "out_kernel.csf" < "example_kernel.csf" && date Fri Oct 18 14:25:47 KST 2013 CSF Processed successfully and signed data available in out_kernel.csf Fri Oct 18 14:42:39 KST 2013 4. Signing 160KB file => 2 min. dnlk@bauer-mm2014:~/secureboot/bBLN_CST_MAIN_02.00.00/linux$ date && ./cst --output "out_uboot.csf" < "example_uboot.csf" && date Fri Oct 18 14:42:39 KST 2013 CSF Processed successfully and signed data available in out_uboot.csf Fri Oct 18 14:45:05 KST 2013 Answer: The slow performance is caused by lack of entropy source and it takes long time to initialize random number generator. Check amount of entropy  "cat /proc/sys/kernel/random/entropy_avail" Tried to install package rng-tools. 1. $sudo apt-get install rng-tools 2. add the following settings in /etc/default/rng-tools HRNGDEVICE=/dev/urandom RNGDOPTIONS=”-W 90% -t 1? 3. sudo /etc/init.d/rng-tools restart 4. cat /proc/sys/kernel/random/entropy_avail After rng-tools starts, entropy increases from less than 100 to more than 1000, then command ./cst -h can run very smoothly.
記事全体を表示
With Qt5  you will find the addition of new technologies that will make your development much easier. Qtquick2 SceneGraph Qml Qt5 is backwards compatible,  that means you can run your Qt 4.8 applications, But that doesn't mean they will have the best performance, sometimes it is better to do a porting to use the newest features. Qt5, has two options to paint components into the screen. Painting in Qt 5 is primarily done either with: The imperative QPainter API Qt’s declarative UI language, QML, and its scene graph back-end. QPainter As this document mentions  Qt5GraphicsOverview | Qt Wiki | Qt Project  The Qpainter engine uses software to paint, and is used when drawing Qimages or Qwidgets. Its  advantage over OpenGL is the high quality when antialiasing is enabled, and a complete feature set. The Qpainter can use an OpenGL engine, but as the document mentions it is more suceptible to state changes. And has to be used carefully. QML & Scene Graph. All visual QML items are rendered using the scene graph, a low-level, high-performance rendering stack, closely tied to OpenGL. Qt Quick 2 makes use of a dedicated scene graph based on OpenGL ES 2.0 or OpenGL 2.0 for its rendering. Using a scene graph for graphics rather than the traditional imperative painting systems (QPainter and similar), means the scene to be rendered can be retained between frames and the complete set of primitives to render is known before rendering starts. This opens up for a number of optimizations, such as batch rendering to minimize state changes and discarding obscured primitives. The QML scene graph is a new back-end for QML in Qt 5, and is based on OpenGL. It generally improves the performance of QML significantly over the QPainter-based back-end used in Qt 4. It achieves better performance in a number of ways: The scene graph uses OpenGL directly instead of going though a QPainter which could be using either the raster or OpenGL paint engine. This means that all the resources, like geometry, textures and shaders can be stored in a format suitable for OpenGL rather than using classes such as QPainterPath, QPixmap, QBrush, or QPen, which the QPainter would need to translate into OpenGL primitives and possibly cache. QML, being a declarative language, defines how the end result should look like, but it doesn’t define how and in which order each individual element is drawn. The drawing can therefore be reordered to reduce the number of state changes, or merged to reduce the number of draw calls. The scene graph uses a separate render thread, and synchronizes the animations with the vertical retrace on platforms where this can be supported. The render thread allows the preparation of the next frame to be done at the same time the current frame is being rendered. This has a positive effect also on single-core systems, since the render thread might block on OpenGL commands. The synchronization with the vertical retrace improves the perceived smoothness of the animations. We have tested on i.MX6 Both options, having the best results using QML Qtquick2 elements. When we tried using QtPainter via Widgets we face the problem that if not using a windowing system like X11 or Wayland the painter wont work well and will only show the QtGLWidget. With QML scene graph we are able to have an OpenGL element and a Qt element on the same environment, and there is an easy way to communicate one with the other and share variables.  Please look at the example results here: I.MX6 scene graph Qt5 - YouTube And the great advantage, the sceneGraph is all accelerated via OpenGL.
記事全体を表示