i.MX Processors Knowledge Base

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

i.MX Processors Knowledge Base

Discussions

Sort by:
Overview Measuring the power consumed an i.MX application processor can be a challenging undertaking. This document describes several boards designed to instrument i.MX application boards for current measurements. While this system does not offer many digits of accuracy, it can be used to quantify power consumed by application use cases as well as while in low power modes. The system can be used to instrument up to four power supply rails and measure current in two ranges. Range switching on the sensor boards is controlled via software running on the Kinetis K20 at the heard of the profiler board. Measured data is sent to a host computer over a virtual serial link over USB. Power for the profiler system is obtained from the USB connection although a external 5V supply may be used. Dual-Range Current Sensors INA250 + INA21x Sensor Circuit Description: The INA250 + INA21x Sensor board can measure two ranges using the INA250 and INA21x current sense amplifiers. The high range is measured with an INA250, which has an integrated 0.002 Ohm shunt, and is available in four output gains. The low range is measured with shunt R1 and the INA21x sense amp. The low range shunt is taken out of the circuit (by shorting it) with two paralleled, very low-Rds(on) FETs, Q1 and Q1. VCC_SENSE powers the two sense amplifiers. VCC_FET supplies the gate voltage on Q1 and Q2. The DMN1019 device has a Vgs max of 8V. The sources of both FETs are tied to the i.MX side of the current sense loop, so the gate voltage Q1 and Q2 see is VCC_FET-(rail voltage). The signal /LOW_EN controls the state of both Q1 and Q2. The sense amplifier outputs (HIGH_OUT1 and LOW_OUT1) and rail voltage (V_RAIL_MEASURE) are sent down the ribbon cable (X2) to the profiler board for measurement. When not used for a wire loop for a Hall-effect current probe, resistor R3 should be shorted with a solder bridge, a piece of wire, or a 0.001 Ohm resistor. Schematic: Board Layout: The two large vias by the current sense connection points are provided for use with a 0.1" header and jumper to short the low range shunt, allowing normal operation of the target board when the profiler is not powered. It should be noted a jumper will not be as effective for relatively large currents. BOM: Part   Device C1,C2  0.1uF 0805 Q1,Q2  DMN1019USN-13 SOT23 R1     2 1% 0805 (resize to change low range) R2     10k 0805 R3     Solder bridge/wire loop (see schematic) U1     INA250 TSSOP16 (choose gain, A3 [0.8V/A] or A4 [2.0V/A]) U2     INA21X SC70 (choose desired gain) X2     WM6769CT/0527460871 (bottom contacts) Dual INA21x Sensor Circuit Description: The Dual INA21x Sensor board can measure two ranges using two INA21x current sense amplifiers and two different shunts. The high range shunt (R1) is always in place. The low range shunt is taken out of the circuit (by shorting it) with two paralleled, very low-Rds(on) FETs, Q1 and Q1. VCC_SENSE powers the two sense amplifiers. VCC_FET supplies the gate voltage on Q1 and Q2. The DMN1019 device has a Vgs max of 8V. The sources of both FETs are tied to the i.MX side of the current sense loop, so the gate voltage Q1 and Q2 see is VCC_FET-(rail voltage). The signal /LOW_EN controls the state of both Q1 and Q2. The sense amplifier outputs (HIGH_OUT1 and LOW_OUT1) and rail voltage (V_RAIL_MEASURE) are sent down the ribbon cable (X2) to the profiler board for measurement. Schematic: Board Layout: The two large vias by the current sense connection points are provided for use with a 0.1" header and jumper to short the low range shunt, allowing normal operation of the target board when the profiler is not powered. It should be noted a jumper will not be as effective for relatively large currents. BOM: Part   Device C1,C2  0.1uF 0805 Q1,Q2  DMN1019USN-13 SOT23 R1     0.002 1% 0805 (resize to change high range) R2     0.05 1% 0805 (resize to change low range) R3     10k 0805 U1,U2  INA21X SC70 (choose desired gain) X2     WM6769CT/0527460871  (bottom contacts) Four-Channel Power Profiler Circuit Description: The Four-Channel Power Profiler board has at its heart a Kinetis K20 on a Teensy3.2 board. The ADCs of the K20 measure all the current sense amplifier's outputs, the voltage of each instrumented rail. There is provision for measuring temperature using up to three thermistors. GPIO provide control each sensor board's current range, and optionally, a hardware wake-up signal for the instrumented target board. Up to four dual-range sensor boards can be connected (either sensor board mentioned above). A micro-SD card socket is included for storing measured data (the SD card functionality has been tested but not implemented for use with measurements). Measured data is sent to the host computer over a virtual serial port using the Teensy's USB. Charge pump U1 boosts the 5V supply to 12V. The output is regulated down to 8V on VCC_FET via regulator U2. R2 and C5 provide filtering for the 3.3V supply from the Teensy that feeds the sensor boards through VCC_SENSE. FETs Q1 through Q4 provide voltage level translation which protect the Teensy's GPIO pins from the 8V that's placed on the gates of the shorting FETs on the sensor boards. Regulator IC2 provides power for the micro-SD socket, since the 3.3V regulator on the Teensy does not provide enough capacity. Since there are not "smarts" on the sensor boards, the Teensy has no way of knowing what kind of sensor board is connected or what shunt values and sense amplifier gains are in use. As currently implemented, current and voltage calculations are hard coded in the Teensy application code. Schematic: Board Layout: BOM: Part    Device C1,C2   0.22uF 0805 C3-C7   1uF 0805 C10,C12 1uF 0805 C11     0.1uF 0805 IC2     MCP1825ST-3302 SOT223 Q1-Q4   DMN1019USN SOT23 R2-R4   20k 1% 0805 R5-R8   10k 0805 R9      Ferrite bead 0805 S1-S4   WM6769CT/0527460871 (bottom contacts) U$1     101-00660-68-6-1-ND MICROSD U1      MAX662CPASO8 SO08 U2      78L08SMD SO08 Use mating Molex cables: 8in: 0150200087 or 10in: 0151660091 Using the Power Profiler Obtaining Sensor and Profiler Boards: Bare boards may be ordered directly from OSH Park using these links: INA250 + INA21x Sensor board (order with 2oz copper option selected) Dual INA21x Sensor board (order with 2oz copper option selected) Power Profiler board The sensor boards should be ordered with the 2oz copper option selected to reduce the trace resistance of the target board's current path. No special option is needed for the profiler board. Teensy3.2 boards may be ordered from OSH Park as well, and at a slightly lower price than the manufacturer (PJRC) sells them. Choosing Current Ranges: To choose the value of a shunt resistor, use the following equation: Rsh = Vfs / (Ifs * gain) where: Rsh is the shunt resistance Vfs is the full scale sense amplifier output voltage (3.3V here) Ifs is the full scale current to be measured gain is the gain of the sense amp to be used For example, to measure a 66mA full scale current with a sense amp of gain 1000, Rsh = 3.3V / (0.066A * 1000) = 0.050 Ohms. For sleep/leakage current, say 1mA full scale: Rsh = 3.3V / (0.001 * 1000) = 3.3 Ohms. The pads on both sensor boards for the shunt resistors have been laid out for 0805 SMT resistors. Precision resistors should be used, 1% or better. The highest power dissipation resistor available should be used to minimize resistance change from the shunt resistor heating up; 0805 resistors are typically available with 1/8, 1/4, 1/2 and 1 Watt dissipation. Building and Testing: These boards were designed to be assembled by hand in small quantities. The most difficult components to solder are the ribbon connectors and the SC70 packaged sense amplifiers. A fine tip soldering iron and a microscope are required. Solder wick is helpful for removing solder bridges from between pins (typically the ribbon connector and the sense amplifiers).  Early versions of the profiler board were assembled with header pins soldered to the Teensy and mating female recepticles soldered to the profiler board. Later versions (like in the example below) were assembled with male header pins between the Teensy and the profiler board.  To test the boards after assembly, check for the presence of 8V on the pull-up resistors R5-R8 when a USB cable is plugged into the Teensy. Program the Teensy with suitable application code. Connect the sensor boards to the profiler. Connect all the sensor boards together in series, positive of one to negative of the next and connect to a calibrated current source. (The image below shows an early prototype of the profiler with the sensor boards connected in series. Current is forced through them via the Kelvin contact clips.) Open a terminal window on the host computer. Force known currents and toggle the ranges of each sensor to verify that each sensor operates correctly in both ranges. To check that the profiler measures rail voltage correctly, disconnect the current source and apply the positive side of a voltage source to either side of the sensors still connected in series and connect the ground of the voltage source to a ground point on the profiler. The rail voltage measured by each sensor should match the supplied voltage (0 to 3.3V max). Accuracy/Calibration: After building in excess of 20 sensor boards and 6 profiler boards and checking their measurements against a Keysight B2902 SMU forcing known currents, the profiler system is fairly accurate. Measurements are good down to about 2% of any range's full scale; lower than that gets into the input offset range of the sense amplifier. Individual readings within 1% of that range's full scale when compared against forced current values. No calibration or tuning has been necessary. Measured values should only be considered good to at most 3 significant figures. Limitations: The maximum current through any sensor should be limited to a maximum of 4A. The current limit when using the low range needs to avoid exceeding the power dissipation of the low range shunt resistor. Particularly, the dissipation in the low range shunt resistor can cause resistance changes that would affect measurement accuracy. The voltage of any instrumented rail cannot be greater than 3.3V, the maximum input voltage of the K20's ADC inputs. Minimum resistance the sensor introduces is in high range is about 0.012 to 0.015 Ohms with a 0.002 Ohm shunt. At least 0.005 Ohms comes from the two shorting FETs on the sensor board. The rest comes from the traces on the board as well as the interconnect wires. The bottom line is: the sensor board has to be mounted as closely as possible to the current sense point on the target board. The maximum resistance the sensor introduces depends on the low range shunt. With a 0.020 Ohm low range shunt, the resistance is about 0.025 to 0.030 Ohms. With a 0.050 Ohm low range shunt, the resistance is about 0.065 to 0.075 Ohms. The sensor board needs to be rigidly mounted to prevent ripping up the current sense points on the target board. This can be a challenge when many rails are instrumented. Instrumenting Target Board: When instrumenting a target board, the on-board current sense resistor should be removed. The sensor board should be attached to the target board placed as close as possible to the sense resistor pads. Connection wires to the sensor board should be as short as possible to minimize series resistance. Great care should be taken to prevent movement of the sensor boards that could in turn lift the sense resistor pads off the target board. Foam double sticky tape should be used over clear areas of the target board to avoid dislodging components when the tape is removed. In the photos below, seven power supplies are instrumented on an interposer card. In this example, the sensor boards were affixed to perf board held in place by the headers. Because of the physical constraints of the target board and its power supply card, mounting the sensor boards directly to the interposer was not possible. Four sensors were mounted on one side and three on the other. Notches were cut in the perf board for the sensor's connection wires on the opposite side. Two profiler boards are required for simultaneous use. (Two were also required because the 0.1" headers and jumpers were not installed on the sensor boards to passively short the low-range shunts; all the sensor boards need to be powered to actively short the low-range shunts.)  The positive input of the sensor board (the center of the three connection points) goes to the regulator side of the current sense resistor. The negative input (either of the two outside connections) goes to the i.MX side of the sense resistor. [NOTE: In this example, the power profiler boards have not been fully populated: the thermistor-related components and the micro-SD card socket. The sensor boards were fully populated with the exception of the passive shorting jumper.] Here is another example of a board with six instrumented rails. The sensors in this case are mounted directly on the target board. In this example, the 12V rail is instrumented, which required modding to add a voltage divider to V_RAIL_LOWSIDE on that sensor board.  And here's yet another example of an instrumented i.MX6Q SDB (which still has wires on it from measuring it the old way...). Although it's difficult to see in this photo, all of the sensor boards have a jumper across the low range shunt which permits normal operation of the board without the profiler board attached to provide power to the shorting FETs. Profiler Application Code for Kinetis/Teensy: Below is sample application code for the Teensy for use with four INA250 + INA21x sensor boards populated with the INA250A3 (0.8V/A gain) for the high range and 0.05 Ohm shunts and INA212 (gain 1000). The current range of each channel can be independently changed. This code is also attached below as a file. Data is sent to the host computer over a USB virtual serial port. To reflash/update Teensy code, follow the instructions from PJRC. Download Windows virtual com port driver. /* MIT License (https://spdx.org/licenses/MIT.html) Copyright 2017 NXP Teensy Power Profiler v.2 (revised main board with individual Hi/Lo GPIO, fixed voltage levels, and on-board uSD card socket. Very basic code for the Teensy Power Profiler that sets up the ADCs and controls the GPIO with very basic, single-character serial commands... This version for all INA250A3 on high range, and 0.05Ohms+INA212 (1000 gain) on low range. */ // These constants won't change.  They're used to give names to the pins used: const int LoHiEn1 = 0; const int LoHiEn2 = 1; const int LoHiEn3 = 2; const int LoHiEn4 = 3; const int WakeUp = 5; const int Lo_1 = A0; const int Vrail_1 = A1; const int Hi_1 = A2; const int Lo_2 = A3; const int Vrail_2 = A4;  const int Hi_2 = A5; const int Lo_3 = A6; const int Vrail_3 = A7; const int Hi_3 = A8; const int Lo_4 = A9; const int Vrail_4 = A11; const int Hi_4 = A10; const int Therm1 = A14; #include <math.h> // thermistor temperature calculation stuff... int sensorValue = 0;        // value read from the pot float sensorValuef = 0.0; int B = 4334; // B25/100 value for thermistor NXRT15WF104FA1B040 // other stuff... int delayintvl = 20; int incomingByte; float vrefL = 3.3; float vrefH = 3.3; float vrefV = 3.3; bool one=true;   bool dispone=true; bool two=true;   bool disptwo=true; bool three=true; bool dispthree=true; bool four=true;  bool dispfour=true; int i,j; int num=100; float v1, v2, v3, v4, i1, i2, i3, i4; float il1, il2, il3, il4; void setup() {   // initialize serial communications at 115200 bps:   Serial.begin(115200);   // set analog resolution to 12 bits... (we want more than the 8 default bits...)   analogReadResolution(12);   // set up low/high range wakeup GPIO signals...   pinMode(LoHiEn1, OUTPUT); digitalWrite(LoHiEn1, HIGH);   pinMode(LoHiEn2, OUTPUT); digitalWrite(LoHiEn2, HIGH);   pinMode(LoHiEn3, OUTPUT); digitalWrite(LoHiEn3, HIGH);   pinMode(LoHiEn4, OUTPUT); digitalWrite(LoHiEn4, HIGH);   pinMode(WakeUp, OUTPUT); digitalWrite(WakeUp, HIGH); } void loop() {   // average voltages and currents...   v1=0; v2=0; v3=0; v4=0;   i1=0; i2=0; i3=0; i4=0;   il1=0; il2=0; il3=0; il4=0;   for (i=0; i<num; i++){     v1 = v1+ analogRead(Vrail_1)/4095.*vrefV;     i1 = i1+ analogRead(Hi_1)/4095.*vrefH/0.8*1000;     il1 = il1+ analogRead(Lo_1)/4095.*vrefH/0.05;     v2 = v2+ analogRead(Vrail_2)/4095.*vrefV;     i2 = i2+ analogRead(Hi_2)/4095.*vrefH/0.8*1000;     il2 = il2+ analogRead(Lo_2)/4095.*vrefH/0.05;     v3 = v3+ analogRead(Vrail_3)/4095.*vrefV;     i3 = i3+ analogRead(Hi_3)/4095.*vrefH/0.8*1000;     il3 = il3+ analogRead(Lo_3)/4095.*vrefH/0.05;     v4 = v4+ analogRead(Vrail_4)/4095.*vrefV;     i4 = i4+ analogRead(Hi_4)/4095.*vrefH/0.8*1000;     il4 = il4+ analogRead(Lo_4)/4095.*vrefH/0.05;   }   v1 = v1/num; v2 = v2/num; v3 = v3/num; v4 = v4/num;   i1 = i1/num; i2 = i2/num; i3 = i3/num; i4 = i4/num;   il1 = il1/num; il2 = il2/num; il3 = il3/num; il4 = il4/num;   // print the results to the serial monitor:   if (dispone) {   Serial.print(" RAIL1 (V)= ");  Serial.print(v1);  //Serial.print("\r\n");   if (!one) {Serial.print("    L1 (mA)= ");  Serial.print(il1, 1);}  //Serial.print("\r\n");   if (1==1) {Serial.print("    H1 (mA)= ");  Serial.print(i1, 1); }   Serial.print("\r\n");   }   if (disptwo) {   Serial.print(" RAIL2 (V)= ");  Serial.print(v2);  //Serial.print("\r\n");   if (!two) {Serial.print("    L2 (mA)= ");  Serial.print(il2, 1);}  //Serial.print("\r\n");   if (1==1) {Serial.print("    H2 (mA)= ");  Serial.print(i2, 1);}    Serial.print("\r\n");   }   if (dispthree) {   Serial.print(" RAIL3 (V)= ");  Serial.print(v3);  //Serial.print("\r\n");   if (!three) {Serial.print("    L3 (mA)= ");  Serial.print(il3, 1);}  //Serial.print("\r\n");   if (1==1) {Serial.print("    H3 (mA)= ");  Serial.print(i3, 1);}    Serial.print("\r\n");   }   if (dispfour) {   Serial.print(" RAIL4 (V)= ");  Serial.print(v4);  //Serial.print("\r\n");   if (!four) {Serial.print("    L4 (mA)= ");  Serial.print(il4, 1);}  //Serial.print("\r\n");   if (1==1) {Serial.print("    H4 (mA)= ");  Serial.print(i4, 1);}    Serial.print("\r\n");   }   Serial.print("\r\n");   Serial.print("\r\n");   while (Serial.available()) {  // while there are characters in the buffer, grab them all...     incomingByte = Serial.read();  // will not be -1     Serial.print("Incoming byte: "); Serial.print(incomingByte);     // Serial.print("    Delay interval:"); Serial.print(delayintvl);  Serial.print("\r\n");     if (incomingByte == 'h' || incomingByte == 'H'){       Serial.print("\r\n\r\nHelp:\r\n\r\n");       Serial.print("  +/= delay interval +/- 10mS\r\n");       Serial.print("  /- delay interval 20msec/1sec\r\n");       Serial.print("  l/L all rails low/high range in unison\r\n");       Serial.print("  q/w/e/r toggle display of rail 1/2/3/4\r\n");       Serial.print("  1/2/3/4 high range of rail 1/2/3/4\r\n");       Serial.print("  !/@/#/$ low range of rail 1/2/3/4\r\n");       Serial.print("  h print this help...\r\n");       Serial.print("\r\n");       delay(2000);       }     // change delay interval...     if (incomingByte == '+') delayintvl = delayintvl + 10;     if (incomingByte == '=') delayintvl = delayintvl - 10;     if (incomingByte == '_') delayintvl = 20;     if (incomingByte == '-') delayintvl = 1000;     if (delayintvl<1) delayintvl = 20;     // toggle low/high range of all rails in unison...     if (incomingByte == 'L') {       digitalWrite(LoHiEn1, LOW);       digitalWrite(LoHiEn2, LOW);       digitalWrite(LoHiEn3, LOW);       digitalWrite(LoHiEn4, LOW);       one = true; two = true; three = true; four = true;     }     if (incomingByte == 'l') {       digitalWrite(LoHiEn1, HIGH);       digitalWrite(LoHiEn2, HIGH);       digitalWrite(LoHiEn3, HIGH);       digitalWrite(LoHiEn4, HIGH);       one = false; two = false; three = false; four = false;     }     // still unimplemented, but for wakeup of target board...     if (incomingByte == 'w') digitalWrite(WakeUp, LOW);     if (incomingByte == 'W') digitalWrite(WakeUp, HIGH);     // toggle display of rail...     if (incomingByte == 'q') dispone = !dispone;     if (incomingByte == 'w') disptwo = !disptwo;     if (incomingByte == 'e') dispthree = !dispthree;     if (incomingByte == 'r') dispfour = !dispfour;     // change between high/low range..     if (incomingByte == '1') { digitalWrite(LoHiEn1, LOW);  one = true; }     if (incomingByte == '!') { digitalWrite(LoHiEn1, HIGH); one = false;}     if (incomingByte == '2') { digitalWrite(LoHiEn2, LOW);  two = true;}     if (incomingByte == '@') { digitalWrite(LoHiEn2, HIGH); two = false;}     if (incomingByte == '3') { digitalWrite(LoHiEn3, LOW);  three = true;}     if (incomingByte == '#') { digitalWrite(LoHiEn3, HIGH); three = false;}     if (incomingByte == '4') { digitalWrite(LoHiEn4, LOW);  four = true;}     if (incomingByte == '$') { digitalWrite(LoHiEn4, HIGH); four = false;}     }   // wait delayintvl mS after the last reading:   delay(delayintvl); }‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Future Work and Improvements Work on a "smart" sensor with a local Kinetis device (KL02Z or KL05Z) on the sensor board itself that has three separate sense amplifiers (one run/high current and two low) has begun. There are several advantages to having a microcontroller on each sensor board: All instrumented rails can be measured simultaneously The sampling rate can be increase over current generation's round robin Measured data is sent over I2C or UART, allowing arbitrary number of rails to be instrumented Each sensor board can provide all its shunt and gain info Sensor board can be used in isolation, i.e., without a master profiler board A GUI interface for the serial data output by the profiler would be really nice... Addditional Information For more information on current measurements in general, see this tutorial series: A Current Sensing Tutorial--Part 1: Fundamentals | EE Times  A Current Sensing Tutorial-Part II: Devices | EE Times  A Current Sensing Tutorial--Part III: Accuracy | EE Times  A Current Sensing Tutorial-Part IV: Layout and Troubleshooting Guidelines | EE Times 
View full article
FAQ Question: I receive the following error message when compiling GTK2 using LTIB" Making all in demos make[2]: Entering directory `/home/ltib/rpm/BUILD/gtk+-2.14.3/demos' no --raw --build-list \         apple_red  ./apple-red.png \                 gnome_foot ./gnome-foot.png \         > test-inline-pixbufs.h \ || (rm -f test-inline-pixbufs.h && false) /bin/sh: no: command not found make[2]: *** [test-inline-pixbufs.h] Error 1 make[2]: Leaving directory `/home/ltib/rpm/BUILD/gtk+-2.14.3/demos' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/ltib/rpm/BUILD/gtk+-2.14.3' make: *** [all] Error 2 error: Bad exit status from /home/ltib/tmp/rpm-tmp.69212 (%build) Answer: Some packages on your host are missing, install the following packages: For deb distributions: sudo apt-get install libgtk2.0-dev or For Fedora distributions: sudo yum install gtk2-devel IMPORTANT: After install the package above, be sure to remove the installed GTK package on your ltib: On your LTIB directory: rm -rf rpm/BUILD/gtk+-2.14.3/ Question: I receive the following error message when booting through NFS: "Root-NFS: Server returned error -13 while mounting /tftpboot/ltib" Answer: Probabilty you remake your rootfs and forgot to restart NFS server. To solve this issue the command: "service nfs restart" Question: I am receiving "error: cannot open Name index using db3" when installing LTIB on new Ubuntu 9.10 Answer: Edit the file "ltib" and modify line 2428 to: $cf->{rpm}           = "rpm --force-debian"; Question: I receive the error message "Cannot create lockfile. Sorry." when I try to open minicom. Answer: This error message is generated because your user doesn't have permission to create a lock file in /var/lock. Change /var/lock permission: # chmod 777 /var/lock Question: I receive the error message "cannot open /dev/ttyS0: Permission denied" when I try to open minicom. Answer: This error message is generated because your user doesn't have permission to open /dev/ttyUSB0. Change /dev/ttyUSB0 permission: # chmod 777 /dev/ttyS0 Question: Compilation of e2fsprogs package or others packages with dependencies like Qtopia using LTIB in Debian derived linux system like Ubuntu makes an error like: make[1]: Leaving directory `/home/daiane/LTIB/L2.6.24_1.2.1_SDK_042008/rpm/BUILD/e2fsprogs-1.34/tests/progs' making all in po make[1]: Entering directory `/home/daiane/LTIB/L2.6.24_1.2.1_SDK_042008/rpm/BUILD/e2fsprogs-1.34/po' : --update cs.po e2fsprogs.pot rm -f cs.gmo && : -c --statistics -o cs.gmo cs.po mv: cannot stat `t-cs.gmo': No such file or directory make[1]: *** [cs.gmo] Error 1 make[1]: Leaving directory `/home/daiane/LTIB/L2.6.24_1.2.1_SDK_042008/rpm/BUILD/e2fsprogs-1.34/po' make: *** [all-progs-recursive] Error 1 error: Bad exit status from /home/daiane/LTIB/L2.6.24_1.2.1_SDK_042008/tmp/rpm-tmp.66904 (%build) Answer: This error is caused by lack of the new version of package gettext. Install the gettext. For Ubuntu, the command line is: sudo apt-get install gettext But LTIB just recognize the existence of this package if it was installed before the LTIB installation. So, reinstall the LTIB. Question Compiling LTIB I got this error message: checking for glib-genmarshal... no configure: error: Could not find a glib-genmarshal in your PATH error: Bad exit status from /home/alan/ltib/tmp/rpm-tmp.48168 (%build) Answer: This error happen when you don't have glib2.0-dev in your system. To Ubuntu execute: sudo apt-get install libglib2.0-dev Question: How to convert an ELF binary to raw ARM binary? Answer: arm-none-linux-gnueabi-objcopy -O binary test.elf test.bin Question: How to inform to kernel to print all message on screen? Answer: echo 8 > /proc/sys/kernel/printk Question: How to disassembly an ARM binary? Answer: arm-none-linux-gnueabi-objdump -b binary -m arm -D test.bin Question: RedBoot returns invalid parameter: RedBoot> load -r -b 0x100000 zImage Using default protocol (TFTP) Can't load 'zImage': invalid parameter Answer: Verify if your tftp server is running correctly. If so, then verify if RedBoot network is configured correctly. You can use ping command to verify if communication with computer is working. Insert non-formatted text here Configure RedBoot to not use script and configure network: RedBoot> ^C RedBoot> fc Run script at boot: false Use BOOTP for network configuration: true. Update RedBoot non-volatile configuration - continue (y/n)? y ... Read from 0x07ee0000-0x07eff000 at 0xa1fe0000: . ... Erase from 0xa1fe0000-0xa2000000: . ... Program from 0x07ee0000-0x07f00000 at 0xa1fe0000: . RedBoot> Reset the board and then load the image Question: How can I test GPIO using a very simple test? Answer: You can find a very simple test here
View full article
This patch made the display no interrupt from uboot to kernel to Android. The IPU and related hardware display interface will only be initialized once in Uboot, the kernel code will skip the IPU initialization.   1. Description     1) Support HDMI, LVDS and LCD output in UBoot.     2) Support UBoot logo keep from uboot to kernel to Android.     3) For HDMI, both 720P and 1080P mode were supported.     4) For LVDS, 1024x768 and 1080P dual channel panels were supported.     5) The logo file is a 32 bpp bmp file. 2. File List -- kernel_imx\0001-Keep-uboot-logo-for-Android-boot-supports-HDMI-LCD-a.patch -- kernel_imx\0002-Bug-fix-for-uboot-logo-keep-patch.patch    Kernel patch to support the logo keep feature. -- uboot-imx\0001-Enable-uboot-logo-for-HDMI-LCD-and-LVDS.patch    Uboot patch to support the logo display. -- logo.bmp    Example 32bpp logo file. -- readme.txt    this file, please refer to it before use the patches 3. Requirement - iMX6 SabreSD board. - Android JB4.2.2_1.1.0-GA UBoot and kernel. 4. How to use -- Copy the two patch files to Android kernel_imx and uboot-imx folder and apply them.     $ cd ~/myandroid/kernel_imx/     $ git apply ./0001-Keep-uboot-logo-for-Android-boot-supports-HDMI-LCD-a.patch     $ cd ~/myandroid/bootable/bootloader/uboot-imx/     $ git apply ./0001-Enable-uboot-logo-for-HDMI-LCD-and-LVDS.patch     $ git apply ./0002-Bug-fix-for-uboot-logo-keep-patch.patch   -- Build the new uboot image:     $ cd ~/myandroid/bootable/bootloader/uboot-imx     $ export CROSS_COMPILE=~/myandroid/prebuilt/gcc/linux-x86/arm/arm-eabi-4.6/bin/arm-eabi-     $ export ARCH=arm     $ make mx6q_sabresd_android_config     $ make   -- Before build new UBoot image, the display type can be selected from file uboot-imx\include\configs\mx6q_sabresd.h // Select one of the output mode #define IPU_OUTPUT_MODE_HDMI //#define IPU_OUTPUT_MODE_LVDS //#define IPU_OUTPUT_MODE_LCD   -- Build the new kernel image:     $ cd ~/myandroid/kernel_imx     $ export CROSS_COMPILE=~/myandroid/prebuilt/gcc/linux-x86/arm/arm-eabi-4.6/bin/arm-eabi-     $ export ARCH=arm     $ make imx6_android_defconfig     $ make uImage   -- Before "make uImage", make menuconfig can be used to select the display type.                 System Type  --->                    Freescale MXC Implementations  --->                       MX6 clk setting for smooth UI transtion from bootloader to kernel  --->                           Select Display Interface                              ( )  Smooth UI transtion on LCD, IPU1, DI0                              ( )  Smooth UI transtion on LVDS, IPU1, DI1                              (X)  Smooth UI transtion on HDMI, IPU2, DI0   -- Uboot parameters for video mode    1080P HDMI:       "video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24,bpp=32 fb0base=0x27b00000 fbmem=28M hdmi_audio_clk=148500000"      720P HDMI:       "video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24,bpp=32 fb0base=0x27b00000 fbmem=28M hdmi_audio_clk=74250000"      1024x768 LVDS:       "video=mxcfb0:dev=ldb,LDB-XGA,if=RGB666,bpp=32 fb0base=0x27b00000 fbmem=28M"      800x480 LCD:       "video=mxcfb0:dev=lcd,CLAA-WVGA,if=RGB565,bpp=32 fb0base=0x27b00000 fbmem=28M" -- dd the logo.bmp to SD card address 0x100000 and skip the 54 bytes bmp file header.    sudo dd if=logo.bmp of=/dev/sdc bs=1 seek=1048576 skip=54 5. Note     1) The logo.bmp file should be 32bpp or 16bpp, and it should be synced with video mode parameters "bpp=xx",          and uboot config file mx6q_sabresd.h (#define DISPLAY_BPP  xx).       2) The IPU number and DI number are hard coded in kernel file "board-mx6q_sabresd.c". static struct fsl_mxc_hdmi_core_platform_data hdmi_core_data = {   .ipu_id = 1,   .disp_id = 0, }; static struct fsl_mxc_lcd_platform_data lcdif_data = {   .ipu_id = 0,   .disp_id = 0,   .default_ifmt = IPU_PIX_FMT_RGB565, }; static struct fsl_mxc_ldb_platform_data ldb_data = {   .ipu_id = 0,   .disp_id = 1,   .ext_ref = 1,   .mode = LDB_SEP1,   .sec_ipu_id = 0,   .sec_disp_id = 0, };       3) The IPU number and DI number are defined by Macro in Uboot file "include\configs\mx6q_sabresd.h" #define IPU_NUM   2  // 1 for IPU1, 2 for IPU2. #define DI_NUM   0  // 0 for DI0, 1 for DI1.       4) The display type used in uboot and kernel must be same, same type, same IPU number, same DI port and        same resolution.     [2015-06-29 Update]: JB4.2.2_1.1.0_uboot_logo_keep_patch_2015-06-29.zip Fix some LVDS issues for iMX6DL. Also given an example for LVDS0 with DI0. New Uboot patches:      0002-Updated-lvds-clock-source-to-pll2_pfd0.-Same-as-kern.patch      0003-Add-support-for-iMX6DL.patch   New kernel patches      0003-Skip-lvds-re-initialization-for-logo-keep.patch      0004-Add-examlpe-for-LVDS0-logo-keep.patch     [2015-08-07 Update]: JB4.2.2_1.1.0_uboot_logo_keep_patch_2015-08-07.zip Added the new Uboot patch 0004-Correct-the-sequence-to-set-LDB-clock.patch It can correct the LVDS clock set sequence whch is a known issue that caused no LVDS display sometimes.   [2015-09-18 Update]: JB4.3_1.1.1_uboot_logo_keep_patch_2015-09-18.zip Added the patch for Android JB4.3_GA1.1.1 release. Updated clock usecount, after blank the display, the related clock can be gated off correctly. Support LVDS clock from PLL5.   [2015-12-21 Update]: Added 3.10.53_GA1.1.0 patch: L3.10.53_GA1.1.0_uboot_logo_keep_patch_2015-12-21.zip. Verified on iMX6DL/Q SabreSD board. It supports LCD and LVDS panels, HDMI patch will be released later.   [2016-01-04 Update]: Added 3.10.53_GA1.1.0 patch: L3.10.53_GA1.1.0_uboot_logo_keep_patch_2016-01-04.zip. Added HDMI display support. Now it supports LCD, LVDS and HDMI displays. Fixed the video playback issue for boot up.   [2016-05-18 Update]: 0001-Fix-the-split-mode-LVDS-panel-no-TX3-signal-issue.patch An issue was founded, when dual channel 4 lanes LVDS panel was used, in uboot there will be no LVDS TX3 signa on one LVDS port, the attach "0001-Fix-the-split-mode-LVDS-panel-no-TX3-signal-issue.patch" was used to fix this issue, it is based on JB4.3_1.1.1_uboot_logo_keep_patch_2015-09-18.zip, for other BSP, please port it manually.   [2016-08-29 Update]: 0001-After-reset-IPU-in-SRC-Control-Register-wait-for-res.patch On some iMX6 chip, after reset the IPU in SRC Control Register, enable IPU at once will cause system hang up, to avoid such issue, software needs wait for IPU reset done by polling the SRC register. The attach "0001-After-reset-IPU-in-SRC-Control-Register-wait-for-res.patch" was used to fix this issue, it is based on JB4.3_1.1.1_uboot_logo_keep_patch_2015-09-18.zip + "0001-Fix-the-split-mode-LVDS-panel-no-TX3-signal-issue.patch", for other BSP, please port it manually.   [2017-01-06 Update] Added patch for L4.1.15_GA1.2.0 BSP and Android M6.0.1_GA2.1.0 BSP. Files: L4.1.15_GA1.2.0_uboot_logo_keep_patch_2017-01-06.zip; M6.0.1_2.1.0_uboot_logo_keep_patch_2017-01-06.zip
View full article
fw_env.config # Configuration file for fw_(printenv/saveenv) utility. # Up to two entries are valid, in this case the redundant # environment sector is assumed present. # Notice, that the "Number of sectors" is ignored on NOR.               # MTD device name Device offset Env. size Flash sector size Number of sectors #/dev/mtd1 0x0000 0x4000 0x4000 #/dev/mtd2 0x0000 0x4000 0x4000 # NAND example /dev/mtd0 0x80000 0x40000 0x20000 2
View full article
Uploading the i.MX 6 Linux Reference Manual here after being un-able to find it on Google or on i.MX6 product page.
View full article
In traditional file system, the WinCE image is a signal file “NK.NB0”/”NK.BIN”. And when using NAND flash for storage, since it can’t support XIP, the total “NK.NB0” need be copied into RAM before running. The EBOOT will do this copy. In this way, there are two main shortages: Long boot time and big size RAM requirement. If the WinCE image is big (Included more features), these issues will be critical. The BINFS can fix those two issues fine. It gave the chance to use 32MB RAM run 64MB WinCE image, this can cost down the final products. In BINFS file system, the final WinCE image will be divided into multi-BIN files, and only the XIPKERNEL BIN (Less than 7 MB) need be copied into RAM by EBOOT. The files in other BIN will work with demand paging mode. These files will be loaded into RAM only when they need run.
View full article
Trace the malloc and expose violate access to freed memory Introduction Libc has a malloc debug framework for difference debugger. Each debugger takes as a libraries, and override the default malloc/free/calloc/realloc/, hooked before calling the real functions. NOTE: This tip assume that you are working with an eng or userdebug build of the platform, not on a production device. Trace the low level malloc/free in bionic Bionic has a malloc debugger called leak debugger, which can record all the malloc/free in low level. And developers can use ddms on host to check each block of memory on heap by malloc. And ddms support convert caller function address to name conver. That makes easy for us to check which component, which function allocated for how many memories. You can turn on memory tracking with debug level 1: $ adb shell setprop libc.debug.malloc 1 $ adb shell stop $ adb shell start You need to restart the runtime so that zygote and all processes launched from it are restarted with the property set. Now all Dalvik processes have memory tracking turned on. You can look at these with DDMS, but first you need to turn on its native memory UI: Open ~/.android/ddms.cfg Add a line "native=true" Upon relaunching DDMS and selecting a process, you can switch to the new native allocation tab and populate it with a list of allocations. This is especially useful for debugging memory leaks. NOTE: to solve the module symbols, please export two env on HOST: $ export PATH=$PATH:<android src>/prebuilt/linux-x86/toolchain/arm-linux-androideabi-4.4.x/bin $ export ANDROID_PRODUCT_OUT=<android src>/out/target/product/<platform> Expose the memory access to freed area In this release he Electric Fence 2.2.0 has been ported to Android. it's also a memory debugger tool as above leak debugger. It helps you detect two common programming bugs: software that overruns the boundaries of a malloc() memory allocation, and software that touches a memory allocation that has been released by free(). It will dump the call stack and mmap of the process, if the malloc/free is not called with correct parameters. It will also make a segment fault, when applications want to access the address which is freed. The usage of efence is almost same as above, which we define it's debug level to 15: $ adb shell setprop libc.debug.malloc 15 After setting this property, you can run your applications, and if there's any memory leakage, logcat will show information. Example: Access the memory, which has been freed already: root@android:/data # setprop libc.debug.malloc 15 I/libc    ( 4136): setprop using MALLOC_DEBUG = 1 (leak checker) root@android:/data # ./memtest I/libc    ( 4138): ./memtest using MALLOC_DEBUG = 15 (efence) F/libc    ( 4138): Fatal signal 11 (SIGSEGV) at 0x4015bff4 (code=2) I/DEBUG  ( 3856): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** I/DEBUG  ( 3856): Build fingerprint: 'freescale/sabresd_6dq/sabresd_6dq:4.0.4/R13.5-rc1/eng.b03824.20120711.11133 8:eng/test-keys' I/DEBUG  ( 3856): pid: 4138, tid: 4138  >>> ./memtest <<< I/DEBUG  ( 3856): signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 4015bff4 I/DEBUG  ( 3856):  r0 00000000  r1 00000002  r2 40151c6c  r3 00000000 I/DEBUG  ( 3856):  r4 4015bff4  r5 bec75a54  r6 00000001  r7 bec75a5c I/DEBUG  ( 3856):  r8 00000000  r9 00000000  10 00000000  fp 00000000 I/DEBUG  ( 3856):  ip 00000000  sp bec75a20  lr 40133f8f  pc 0000a554  cpsr 60000010 I/DEBUG  ( 3856):  d0  203f810033915fe5  d1  0000000000000000 I/DEBUG  ( 3856):  d2  0000000000000000  d3  0000000000000000 I/DEBUG  ( 3856):  d4  0000000000000000  d5  0000000000000000 I/DEBUG  ( 3856):  d6  0000000000000000  d7  204cb48d00000000 I/DEBUG  ( 3856):  d8  0000000000000000  d9  0000000000000000 I/DEBUG  ( 3856):  d10 0000000000000000  d11 0000000000000000 I/DEBUG  ( 3856):  d12 0000000000000000  d13 0000000000000000 I/DEBUG  ( 3856):  d14 0000000000000000  d15 0000000000000000 I/DEBUG  ( 3856):  d16 41c0265a46a47ae1  d17 3f50624dd2f1a9fc I/DEBUG  ( 3856):  d18 41c9c8aff2800000  d19 0000000000000000 I/DEBUG  ( 3856):  d20 0000000000000000  d21 0000000000000000 I/DEBUG  ( 3856):  d22 0000000000000000  d23 0000000000000000 I/DEBUG  ( 3856):  d24 0000000000000000  d25 0000000000000000 I/DEBUG  ( 3856):  d26 0000000000000000  d27 0000000000000000 I/DEBUG  ( 3856):  d28 0000000000000000  d29 0000000000000000 I/DEBUG  ( 3856):  d30 0000000000000000  d31 0000000000000000 I/DEBUG  ( 3856):  scr 00000010 I/DEBUG  ( 3856): I/DEBUG  ( 3856):          #00  pc 0000a554  /data/memtest I/DEBUG  ( 3856):          #01  pc 00016834  /system/lib/libc.so (__libc_init) I/DEBUG  ( 3856): I/DEBUG  ( 3856): code around pc: I/DEBUG  ( 3856): 0000a534 e3a0000a ebfff8d1 e3a01001 e1a00004  ................ I/DEBUG  ( 3856): 0000a544 e5c4100a ebfff8d9 e3560001 e3a03000  ..........V..0.. I/DEBUG  ( 3856): 0000a554 e5c43000 0a000064 e59f21f0 e2857004  .0..d....!...p.. I/DEBUG  ( 3856): 0000a564 e5954004 e08f1002 e1a00004 ebfff8c0  .@.............. I/DEBUG  ( 3856): 0000a574 e3500000 0a00003f e59fc1d4 e1a00004  ..P.?........... I/DEBUG  ( 3856): I/DEBUG  ( 3856): code around lr: I/DEBUG  ( 3856): 40133f6c 68200701 0001f020 454e1046 2e00d018  .. h ...F.NE.... I/DEBUG  ( 3856): 40133f7c 2102da01 1c81e000 43394338 f7eb4622  ...!....8C9C"F.. I/DEBUG  ( 3856): 40133f8c 4605ed56 d1ec2800 da062e00 0101f008  V..F.(.......... I/DEBUG  ( 3856): 40133f9c f06f4620 f7ea4200 4628e8d4 87f0e8bd  Fo..B....(F.... I/DEBUG  ( 3856): 40133fac eff0f7e9 6003234b 30fff04f bf00e7f6  ....K#.`O..0.... I/DEBUG  ( 3856): I/DEBUG  ( 3856): memory map around addr 4015bff4: I/DEBUG  ( 3856): 40150000-4015a000 I/DEBUG  ( 3856): 4015a000-4015d000 I/DEBUG  ( 3856): 4015d000-4015e000 I/DEBUG  ( 3856): I/DEBUG  ( 3856): stack: I/DEBUG  ( 3856):    bec759e0  00000000 I/DEBUG  ( 3856):    bec759e4  00000000 I/DEBUG  ( 3856):    bec759e8  00000000 I/DEBUG  ( 3856):    bec759ec  4012090f  /system/lib/libefence.so I/DEBUG  ( 3856):    bec759f0  4015a014 I/DEBUG  ( 3856):    bec759f4  00002000 I/DEBUG  ( 3856):    bec759f8  00000004 I/DEBUG  ( 3856):    bec759fc  40120df1  /system/lib/libefence.so I/DEBUG  ( 3856):    bec75a00  4015bff4 I/DEBUG  ( 3856):    bec75a04  bec75a54  [stack] I/DEBUG  ( 3856):    bec75a08  00000001 I/DEBUG  ( 3856):    bec75a0c  bec75a5c  [stack] I/DEBUG  ( 3856):    bec75a10  00000000 I/DEBUG  ( 3856):    bec75a14  400d9167  /system/lib/libc.so I/DEBUG  ( 3856):    bec75a18  df0027ad I/DEBUG  ( 3856):    bec75a1c  00000000 I/DEBUG  ( 3856): #00 bec75a20  00008924  /data/memtest I/DEBUG  ( 3856):    bec75a24  bec75a54  [stack] I/DEBUG  ( 3856):    bec75a28  00000001 I/DEBUG  ( 3856):    bec75a2c  bec75a5c  [stack] I/DEBUG  ( 3856):    bec75a30  00000000 I/DEBUG  ( 3856):    bec75a34  400d9837  /system/lib/libc.so I/DEBUG  ( 3856): #01 bec75a38  00000000 I/DEBUG  ( 3856):    bec75a3c  00000000 I/DEBUG  ( 3856):    bec75a40  00000000 I/DEBUG  ( 3856):    bec75a44  00000000 I/DEBUG  ( 3856):    bec75a48  00000000 I/DEBUG  ( 3856):    bec75a4c  b00046ef  /system/bin/linker I/DEBUG  ( 3856):    bec75a50  00000001 I/DEBUG  ( 3856):    bec75a54  bec75b79  [stack] I/DEBUG  ( 3856):    bec75a58  00000000 I/DEBUG  ( 3856):    bec75a5c  bec75b83  [stack] I/DEBUG  ( 3856):    bec75a60  bec75b8f  [stack] I/DEBUG  ( 3856):    bec75a64  bec75ba2  [stack] I/DEBUG  ( 3856):    bec75a68  bec75bc5  [stack] I/DEBUG  ( 3856):    bec75a6c  bec75bde  [stack] I/DEBUG  ( 3856):    bec75a70  bec75c08  [stack] I/DEBUG  ( 3856):    bec75a74  bec75c20  [stack] I/DEBUG  ( 3856):    bec75a78  bec75c57  [stack] I/DEBUG  ( 3856):    bec75a7c  bec75c61  [stack] I/BootReceiver( 3551): Copying /data/tombstones/tombstone_00 to DropBox (SYSTEM_TOMBSTONE) D/dalvikvm( 3551): GC_CONCURRENT freed 398K, 10% free 8805K/9735K, paused 3ms+5ms [2] + Segmentation fault  ./memtest
View full article
[中文翻译版] 见附件   原文链接: https://community.nxp.com/docs/DOC-343007 
View full article
Please find attached preliminary errata on the two i.MX security vulnerabilities: ERR010872 – Secure Boot Vulnerability when using the Serial Downloader (CVE-2017-7936) ERR010873 – Secure Boot Vulnerability when Authenticating a Certificate (CVE-2017-7932) These are preliminary versions of the errata. Final versions will be incorporated into the Chip Errata (CE) document for each impacted device at a later date. Customer Notification A Customer Information Notification(CIN 201704026I) with the affected part numbers has been sent out to impacted users. Updated Silicon Sample Availability An Advanced Product Change Notification (A-PCN 201705010A), that provides updated silicon availability information has also been sent out to impacted users. Mitigations An Engineering Bulletin (EB00854) on possible mitigation strategies is available to impacted users and can be requested through your NXP field support team or distributor.  Further Questions or Support Please contact your NXP support representative or enter a support request for further questions on this topic indicating the part number and the mass production start date.
View full article
Q: What is quality level of IBIS file? In chapter 8.6 in IMX6DQ6SDLHDG (Rev.0). It says the following about quality assurance. ===== All models (GPIO, DDR, LVDS, MLB) have passed the following checks: • IBISCHK without errors or unexplained warnings • Data for basic simulation checked • Data for timing analysis checked • Data for power analysis checked • Correlated against Spice simulations Validation reports can be provided upon demand. ==== A: In addition, please see http://www.vhdl.org/pub/ibis/quality_wip/checklist/Using_IQ_2.0_checklist.pdf. This document says about quality level. According to these information, the IBIS quality level is IQ4 (IQ3 + data for power  analysis checked) + "Correlated against Spice simulations". This document was generated from the following discussion: IBIS QUALITIY LEVEL
View full article
Issue description: ZQ calibration issue with LPDDR2 memory with two chip selects    Micron has verified it on my customer's board with i.MX6Q. (ECT-SYT-1163 for FIC.pdf) The patch is made based on lp 5.1, see attachment.
View full article
To fix LCD problem: Download DirectFB patches (click here). Copy patches and kernel spec to LTIB: tar zxvf DirectFB-patches-specs.tar.gz cd specs cp kernel-imx31_3stack-2.6.24-DirectFB-LCD-fix.patch /opt/freescale/pkgs/ cp kernel.spec.in ~/ltib-imx31pdk-r14/config/platform/imx/ Remove old kernel: ~/ltib-imx31pdk-r14$ rm -rf rpm/BUILD/linux* Issue LTIB to decompress kernel and apply patches: ~/ltib-imx31pdk-r14$ ./ltib -p kernel -m prep You will see at end: + echo Patch #1 (kernel-imx31_3stack-2.6.24-DirectFB-LCD-fix.patch): Patch #1 (kernel-imx31_3stack-2.6.24-DirectFB-LCD-fix.patch): + patch -p1 -s + exit 0 Build time for kernel: 21 seconds It means which kernel-imx31_3stack-2.6.24-DirectFB-LCD-fix.patch was applied correctly! Now compile your kernel: ~/ltib-imx31pdk-r14$ ./ltib -p kernel -m scbuild Install it on your rootfs: ~/ltib-imx31pdk-r14$ ./ltib -p kernel -m scdeploy To fix Touch-Screen Copy specs to LTIB: cd specs cp tslib.spec ~/ltib-imx31pdk-r14/dist/lfs-5.1/tslib/ cp DirectFB.spec ~/ltib-imx31pdk-r14/dist/lfs-5.1/DirectFB/ Remove old directories: ~/ltib-imx31pdk-r14$ rm -rf rpm/BUILD/tslib-1.0/ ~/ltib-imx31pdk-r14$ rm -rf rpm/BUILD/DirectFB-1.1.0/ Edit your pkg_map and change tslib order. DirectFB needs tslib, then this lib needs be compiled first: [alan@localhost ltib-imx31pdk-r14]$ vi config/userspace/pkg_map ... PKG_TSLIB                                      = tslib PKG_DIRECTFB                               = DirectFB PKG_DIRECTFB_EXAMPLES            = DirectFB-examples ... Now run: alan@armagedon:~/ltib-imx31pdk-r14$ ./ltib -c Then select DirectFB and tslib packages. To test Touch-Screen mx31# mknod /dev/input/tslib0 c 13 65 mx31# export TSLIB_TSDEVICE=/dev/input/tslib0 mx31# rm -f /etc/pointercal mx31# ts_calibrate mx31# df_window
View full article
Android Jelly Bean(4.2) locks HDMI rotation by default. You can unlock by the instruction of this commit. -- Author: Jeff Brown <[email protected]> Date:   Wed Oct 17 18:32:34 2012 -0700     Add special mirroring modes for demonstration purposes.     Assume rotation of HDMI display is portait.     $ adb shell setprop persist.demo.hdmirotation portrait     Don't lock rotation while HDMI is plugged in.     $ adb shell setprop persist.demo.hdmirotationlock false     Hide secondary displays from apps but continue mirroring to them.     $ adb shell setprop persist.demo.singledisplay true     Bug: 7326281     Change-Id: I8f9a3b0bc19821a3a01043b0f516806dac82ce53
View full article
How To Understand JTAG BSDL File This example explains how to understand the BSDL file in order to create an OpenOCD configure file. IR Len That information can be retrieved directly: attribute INSTRUCTION_LENGTH of imx_device: entity is 5; This means that IR Len is 5, then in OpenOCD config it will be informed this way: -irlen 5 IR Capture The IR Capture also can be retrieved directly: attribute INSTRUCTION_CAPTURE of imx_device : entity is "XXX01"; This means that IR Capture is 1, then in OpenOCD config it will be informed this way: -ircapture 0x1 IR Mask The IR Mask is based on IR Len size. Just create a binary number with "IR Len" bits 1. If the IR Len is 4 then the IR Mask will be 0xF (1111). Case the IR Len is 5 the IR Mask will be 0x1F (11111). In this BSDL example (IR Len = 5) the OpenOCD config needs to inform the IR Mask this way: -irmask 0x1f TAP ID attribute IDCODE_REGISTER  of imx_device : entity is     "0010"            & -- Version     "000110"          & -- Design Center Number     "0100000001"      & -- Sequence Number     "00000001110"      & -- Manufacturer Identity     "1";                -- IEEE 1149.1 Requirement This code can be converted directly to TAP ID: Binary: 0010-0001-1001-0000-0001-0000-0001-1101 Hexadecimal: 2-1-9-0-1-0-1-D Then in OpenOCD configure you will create: if { [info exists SDMATAPID ] } {   set _SDMATAPID $SDMATAPID } else {   set _SDMATAPID 0x2190101d } The final configure line will be: jtag newtap $_CHIPNAME smda -irlen 5 -ircapture 0x1 -irmask 0x1f -expected-id $_SDMATAPID
View full article
1. HW Environment:     IMX8mm-evk board.     ITE6122 mipi dsi to lvds bridge board.     B101UAN02.1 1920x1200 LVDS panel   2. SW Environment:     IMX YOCTO 4.14.98-2.0.0ga release.   3. Patch operation:     a. git clone https://source.codeaurora.org/external/imx/linux-imx.git     b. git checkout -b  imx_4.14.98_2.0.0_ga remotes/origin/imx_4.14.98_2.0.0_ga     c. patch -p1 < ../ite6122_imx8mm_4.14.98ga_18c3fd8837fc3c6_0512.patch   4. Tested on imx8mm-evk board:   5. Attached doc list:      i.MX8MM(MN)_IT6122FN_ user guide_V0.20.pdf ------  ite6122 bridge board HW guide      i.MX8MM(MN)_IT6122FN_V11_20200513.pdf  ------  ite6122 bridge board SCH      ite6122_imx8mm_4.14.98ga_18c3fd8837fc3c6_0512.patch  ------  Linux kernel driver patch      B101UAN02.1_Ver1.0.pdf -------  panel spec              2020/10/30: 6122-hw-version-2010-10-30.zip ------ updated new HW design.        
View full article
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
View full article
Not all of imx6 boards can support SDR104, refer to imx6sx Reference Manual, BOOT_CFG1[2:3] = 11 is SDR104 normally hardware support 3.3v, but SDR104 only supports 1.8v. refer to the AI board schematic, you can find as below: For current yocto driver, which already supports sd3.0 standard, but kernel should change something to support this, for customer, one can refer to the source code in the yocto, the path:root/arch/arm/boot/dts/imx6sx-sdb.dts or path:root/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi For supporting SDR104, should change the dts file, because of 1.8v only, should remove no-1-8-v in the source code, then add vmmc-supply according to the dts file above. for example, based on the schematic, you can find: &usdhc1 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_usdhc1>; cd-gpios = <&gpio1 1 0>; no-1-8-v; keep-power-in-suspend; enable-sdio-wakeup; status = "okay"; }; &usdhc3 { pinctrl-names = "default", "state_100mhz", "state_200mhz"; pinctrl-0 = <&pinctrl_usdhc3>; pinctrl-1 = <&pinctrl_usdhc3_100mhz>; pinctrl-2 = <&pinctrl_usdhc3_200mhz>; cd-gpios = <&gpio6 15 0>; wp-gpios = <&gpio1 13 0>; /* * Due to board issue, we can not use external regulator for card slot * by default since the card power is shared with card detect pullup. * Disabling the vmmc regulator will cause unexpected card detect * interrupts. * HW rework is needed to fix this isssue. Remove R695 first, then you * can open below line to enable the using of external regulator. * Then you will be able to power off the card during suspend. This is * especially needed for a SD3.0 card re-enumeration working on UHS mode * Note: reg_sd3_vmmc is also need to be enabled */ /* vmmc-supply = <&reg_sd3_vmmc>; */ keep-power-in-suspend; enable-sdio-wakeup; status = "okay"; }; reg_sd3_vmmc: sd3_vmmc{ compatible = "regulator-fixed"; regulator-name = "P3V3_SDa_SWITCHED"; regulator-min-microvolt = <3300000>; regulator-max-microvolt = <3300000>; gpio = <&gpio7 8 GPIO_ACTIVE_HIGH>; enable-active-high; /* remove below line to enable this regulator */ status="disabled"; };
View full article
Application Note covering how to get the Silex SX-SDCAN working with the Sabre-SD i.MX6 Evaluation kit.
View full article
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.
View full article