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:
The Yocto Project is open-source, so anyone can contribute. No matter what your contribution is (bug fixing or new metadata), contributions are sent through patches to a community list. Many eyes will look into your patch and at some point it is either rejected or accepted. Follow these steps to contribute: Make sure you have previously configured your personal info $ git config --global user.name "Your Name Here" $ git config --global user.email "[email protected]" Subscribed to the Freescale Yocto Project Mailing List Download `master` branches fsl-community-bsp $ repo init \   -u https://github.com/Freescale/fsl-community-bsp-platform \   -b master Update fsl-community-bsp $ repo sync Create local branches so your work is *not* done on master fsl-community-bsp $ repo start <branch name> --all Where `<branch name>` is any name you want to give to your local branch (e.g. `fix_uboot_recipe`, `new_gstreamer_recipe`, etc.) Make your changes in any Freescale related folder (e.g. sources/meta-fsl-arm). In case you modified a recipe (.bb) or include (.inc) file, do not forget to *bump* (increase the value by one) either the `PR` or `INC_PR` value Commit your changes using `git`. In this example we assume your change is on `meta-fsl-arm` folder sources/meta-fsl-arm $ git add <file 1> <file 2> sources/meta-fsl-arm $ git commit On the commit's log, the title must start with the filename change or introduced, then a brief description of the patch's goal, following with a long description. Make sure you follow the standards (type ` git log --pretty=oneline` to see previous commits) Create a patch sources/meta-fsl-arm $ git format-patch -s  --subject-prefix='<meta-fsl-arm][PATCH' -1 Where the last parameter (`-1`) indicate to patch last commit. In case you want to create patches for older commits, just indicate the correct index. If your patch is done in other folder, just make sure you change the `--subject-prefix` value. Send your patch or patches with git send-email --to [email protected] <patch> where `<patch>` is the file created by `git format-patch`. Keep track of patch's responses on the mailing list. In case you need to rework your patch, repeat the steps but this time the patch's subject changes to `--subject-prefix='<meta-fsl-*][PATCH v2'` Once your patch has been approved, you can delete your working branches fsl-community-bsp $ repo abandon <branch name>
View full article
This is an example to show how to connect two cameras (with same I2C address) on the i.MX6Q board. In this example, the I2C switch is PCA9543A. Two cameras are OV5640 & OV5645. OV5640 is connected to CSI0, and other one OV5645 is connected to MIPI. The Linux BSP is L3.0.35. In the your_board.c file, add the following for pca954x. static struct pca954x_platform_mode pca954x_modes[] = {      {            .adap_id = 4,            .deselect_on_exit = true,      },      {            .adap_id = 5,            .deselect_on_exit = true,      }, }; static struct pca954x_platform_data pca954x_data = {      .modes = pca954x_modes,      .num_modes = ARRAY_SIZE(pca954x_modes) }; In this example, the I2C switch is connected to i.MX6Q’s I2C0. The I2C address of the PCA9543A is 0x70. static struct i2c_board_info mxc_i2c0_board_info[] __initdata = {      {            I2C_BOARD_INFO("pca9543", 0x70),            .platform_data = (void *)&pca954x_data,      }, }; The channel 0 of PCA9543A is connected to the I2C of OV5645 MIPI. static struct i2c_board_info mux_i2c4_board_info[] __initdata = {      {            I2C_BOARD_INFO("ov5645_mipi", 0x3c),            .platform_data = (void *)&mipi_csi2_data,      }, }; The channel 1 of PCA9543A is connected to the I2C of OV5640 CSI0. static struct i2c_board_info mux_i2c5_board_info[] __initdata = {      {            I2C_BOARD_INFO("ov5640", 0x3c),            .platform_data = (void *)&csi0_camera_data,      }, }; In the board_init function, register the I2C4 and I2C5. i2c_register_board_info(4, mux_i2c4_board_info,                 ARRAY_SIZE(mux_i2c4_board_info)); i2c_register_board_info(5, mux_i2c5_board_info,                 ARRAY_SIZE(mux_i2c5_board_info)); Select the PCA954x driver In kernel configuration In Kernel Configuration, go to Device Drivers --> I2C support --> I2C bus multiplexing support --> Multiplexer I2C Chip support  --> Select <*> Philips PCA954x I2C Mux/switches
View full article
Booting from NAND    Some hardware configurations (switches) must be set for booting from NAND:    On the debug board:      Switch SW4 -> 10000001      Switch SW5 -> Off      Switch SW6 -> Off      Switch SW7 -> Off      Switch SW8 -> Off      Switch SW9 -> Off      Switch SW10 -> Off    On the personality board:      Switch SW21 -> 10011000      Switch SW22 -> 00100000 Booting from SD Card    Some hardware configurations (switches) must be set for booting from an SD card:       On the debug board:      Switch SW4 -> 10000001      Switch SW5 -> Off      Switch SW6 -> Off      Switch SW7 -> Off      Switch SW8 -> Off      Switch SW9 -> Off      Switch SW10 -> Off    On the personality board:      Switch SW21 -> 11000000      Switch SW22 -> 00000000   
View full article
Q: Does anyone have the Lauterbach script files for connecting to the mx53?  Also,  does anyone know of a converter to convert RealView scripts to Lauterbach? A: Please see below attach.cmm and load_simbols.cmm for i.MX53. attach.cmm ; ; Script to attach to a running system, halt the CPU, ; and display the ASM code ; screen.on ; Debugger Reset winpage.reset area.reset WINPOS 0. 26. 75. 8. 0. 0. W000 area print "resetting ICD..." System.Down Break.Delete MAP.RESet TASK.RESet sYmbol.RESet Data.PROLOG.RESet Data.EPILOG.RESet sYmbol.AutoLoad.CHECK OFF      ; disable dynamic autoloader sYmbol.AutoLoad.RESet          ; reset autoloader list MMU.RESet ; setup of ICD JTAG print "initializing JTAG..." SYStem.CPU CORTEXA8 SYStem.MultiCore IRPOST 0x0 SYStem.MultiCore IRPRE 0x0 SYStem.MultiCore DRPOST 0x0 SYStem.MultiCore DRPRE 0x0 SYStem.MultiCore DAPIRPOST 0x09 SYStem.MultiCore DAPIRPRE 0x0 SYStem.MultiCore DAPDRPOST 0x02 SYStem.MultiCore DAPDRPRE 0x0 SYStem.MultiCore MEMORYACCESSPORT 0 SYStem.MultiCore DEBUGACCESSPORT 1 SYStem.MultiCore COREBASE APB:0xC0008000 SYStem.Option DACR ON          ; give Debugger global write permissions TrOnchip.Set DABORT OFF        ; used by Linux OS for page miss! TrOnchip.Set PABORT OFF        ; used by Linux OS for page miss! TrOnchip.Set UNDEF OFF         ; let UNDEF be handled by Linux OS SYStem.Option MMU ON           ; enable space ids to virtual addresses SYStem.JtagClock 20.0MHz SETUP.IMASKASM ON              ; lock interrupts while single stepping ; Use on-chip breakpoints Break.SELect PROGRAM ONCHIP Break.SELect READ ONCHIP Break.SELect WRITE ONCHIP Break.SELect ALPHA ONCHIP Break.SELect BETA ONCHIP Break.SELect CHARLY ONCHIP Break.SELect DELTA ONCHIP Break.SELect ECHO ONCHIP SYStem.Option EnReset OFF SYS.m attach ; wait until reset is complete wait 2.s if run()     Break ; Open a Code Window -- we like to see something WINPOS 0. 0. 75. 20. Data.List enddo load.symbols.cmm ; ; Script to load the Linux kernel symbols into the debugger ; print "loading Linux kernel symbols..." &linuxpath="S:\git\kernel\linux-2.6-imx-0" &kbuildpath="build" sYmbol.SourcePATH.SET &linuxpath Data.LOAD.Elf &linuxpath\&kbuildpath\imx5\vmlinux /StripPART 3 /gnu /nocode ; Map the virtual kernel symbols to physical addresses ; to give the debugger access to it before CPU MMU is ; initialized print "setting system MMU..." MMU.FORMAT Linux swapper_pg_dir 0xc0000000--0xc1ffffff 0x70000000 MMU.Create 0xc0000000--0xc1ffffff 0x70000000 ; map kernel pages at RAM start MMU.COMMON 0xc0000000--0xffffffff            ; common area for kernel and processes ;MMU.TableWalk OFF   ; debugger uses a table walk to decode virtual addresses MMU.ON             ; switch on debugger(!) address translation ; Initialize Mutitasking Support print "initializing multitask support..." TASK.CONFIG ../linux       ; loads Linux awareness (linux.t32) MENU.ReProgram ../linux    ; loads Linux menu (linux.men) HELP.FILTER.Add rtoslinux  ; add linux awareness manual to help filter enddo This document was generated from the following discussion: Lauterbach CMM scripts for mx53
View full article
i.MX31 Lite Kit is a low cost development board developed by LogicPD OEM (an AMD company). Expanding on the Freescale offering of low-cost, high-performance application development kits, Freescale introduces the i.MX31 Lite Kit. Developed in collaboration with Logic Product Development, the Freescale i.MX31 Lite Kit provides a product-ready software and hardware platform for OEMs, ODMs, IDHs and independent developers. The i.MX31 Lite Kit enables rapid design of embedded products targeting the medical, industrial, wireless, consumer markets and general purpose markets. Leverage the power of our popular i.MX 31 multimedia processor in this cost-effective development solution. Features The Freescale i.MX31 SOM-LV is based on the i.MX31 multimedia applications processor running up to 532 MHz. LCD Display Connector Integrated LCD, touch, and backlight connector for Zoom Display Kits Audio Stereo input and output jacks Network Support One RJ45 Ethernet jack connector with magnetics (application/debug) PC Card Expansion CompactFlash® Type I card MMC/SD card ATA Support USB One USB 2.0 high-speed host interface One USB high-speed On-the-Go device interface Serial Ports 115.2kbps RS-232 debug serial port Software LogicLoader™ (bootloader/monitor) Windows® CE 5.0 BSP GNU cross development toolchain (compiler, linker, assembler, debugger) Cables Serial cable (null-modem) Ethernet crossover cable USB A to mini-B cable 5 volt power supply (with Europe, Japan, UK, & US adapters) Mechanical 146.1 mm wide x 158.8 mm long x 17.1 mm high RoHS Compliant More information [here.]
View full article
[中文翻译版] 见附件   原文链接: https://community.nxp.com/docs/DOC-343802 
View full article
[中文翻译版] 见附件   原文链接: https://community.nxp.com/docs/DOC-342420 
View full article
Freescale introduces the i.MXS Development Kit, a high performance development kit ideal for Microsoft's Windows Vista™ SideShow™ platform and .NET Micro Framework applications. The advanced i.MXS Development Kit leverages Freescale's i.MXS applications processor, based on the ARM920T™ core, a highly integrated IC that has been in production for nearly two years. The integrated development platform, featuring support of Microsoft's .NET Micro Framework for use with SideShow applications, is designed to enable hardware developers to more quickly and easily design applications targeting Microsoft's highly anticipated Windows Vista operating system. Typical SideShow applications include laptop external displays, remote controls and USB dongles, which can run certain applications without powering up the laptop. The i.MXS Development Kit features a small form-factor reference board that has a 2.5 inch color LCD panel with QVGA resolution. The card includes Freescale’s i.MXS applications processor that provides superb performance and extremely low power consumption, enabling hours of use off a single battery charge. The development kit also includes a USB interface and an expansion connector for add-on modules such as Bluetooth™ technology or the ZigBee™ wireless protocol, creating a comprehensive development platform for a variety of applications. Features i.MXS applications processor, based on the powerful ARM920T™ core Clock source crystal: 32 kilohertz Powered by USB bus voltage or external power adaptor Multi-ICE debug support connector I2C and SSI bus connector for connection to external audio CODEC SMbus interface 32-megabyte (MB) SDRAM device One 8-megabyte (MB) Burst Flash memory device One RS232 transceiver (configured for DCE) supporting on-chip UART1 port 1 UART port at CMOS level for expansion On-Chip USB 1.1 interface On-board 2.5 inch LCD with back-light and QVGA resolution 11 separated GPIO for key-button input LED indicator for power
View full article
Q: The i.MX 6Dual/6Quad Applications Processor Reference Manual Rev. D says that i.MX6 supports eMMC 4.5.  But does the current BSP(L3.0.35_12.08.00) support eMMC 4.5?  If not, does Freescale have it in their release plan? A: i.MX 6Dual/6Quad RM and Datasheet declare that the uSDHC module is "fully compliant with the MMC command/response sets and Physical Layer as defined in the Multimedia Card System Specification, v4.2/4.3/4.4/4.41, including high-capacity (> 2 GB) HC MMC cards."  Therefore, if your eMMC4.5 card is backward-compatible with eMMC4.4, you can use it in eMMC4.4 mode to enable eMMC4.4 functionality and performance on the i.MX6 platform. For example, the current i.MX6 Linux BSP (L3.0.35_4.1.0) has added code to interface with an eMMC4.5 card to operate as an eMMC4.4 card. See the following code in drivers/mmc/core/mmc.c:         card->ext_csd.rev = ext_csd[EXT_CSD_REV];         /* workaround: support emmc 4.5 cards to work at emmc 4.4 mode */         if (card->ext_csd.rev > 6) {                 printk(KERN_ERR "%s: unrecognised EXT_CSD revision %d\n",                         mmc_hostname(card->host), card->ext_csd.rev);                 err = -EINVAL;                 goto out;         }
View full article
Using Clock Out - i.MX31PDK i.MX31 has a clock out pin that can be used to output internal clock signals. On the i.MX31PDK the clock out pin is accessible on TP1. The clock out is controlled by register COSR (Clock Out Source Register) at address 0x53F8001C. There three fields on COSR: Field Description CLKOEN (bit 9) Clock output enable bit CLKOUTDIV (bits 8-6) Clock output divide factor CLKOSEL (bits 3-0) These bits select which clock is to be reflected on the clock output CKO. Here are the values each field may assume: CLKOEN Values CLKOUTDIV Values CLKOSEL Values 1 clock output IO pin is enabled 0 clock output IO pin disabled 000 => 1 001 => 2 010 => 4 011 => 8 100 => 16 0000 => mpl_dpdgck_clk 0001 => ipg_clk_ccm 0010 => upl_dpdgck_clk 0011 => pll_ref_clk 0100 => fpm_ckil512_clk 0101 => ipg_clk_ahb_arm 0110 => ipg_clk_arm 0111 => spl_dpdgck_clk 1000 => ckih 1001 => ipg_clk_ahb _emi_clk 1010 => ipg_clk_ipu_hsp 1011 => ipg_clk_nfc_20m 1100 => ipg_clk_perclk_uart1 1101 => ref_cir1 (ref_cir_gateload) 1110 => ref_cir2 (ref_cir_intrcload) 1111 => ref_cir3 (ref_cir_path) Based on the Clock Generation Scheme, we can play with COSR register using the Register Accessing application to test Clock out pin by checking some i.MX31 internal clocks. Testing First we can check the value of CKIH, it should be 26MHz as a 26MHz is connected to that pin. We can write 0x208 to COSR. [CLKOEN = 1| CLKOUTDIV = 1| CLKOSEL = ckih] root@freescale /home$ ./io2 0x53f8001c w 0x208 /dev/mem opened. Memory mapped on address 0x4001f000. Written: 0x208 Then we can check pll_ref_clock. We can write 0x203 to COSR. [CLKOEN = 1| CLKOUTDIV = 1| CLKOSEL = pll_ref_clk] root@freescale /home$ ./io2 0x53f8001c w 0x203 /dev/mem opened. Memory mapped on address 0x4001f000. Written: 0x203 As expected, pll_ref_clock is equals to CKIH because CCMR[PCRS]=10. Reading CCMR to confirm CCMR[PCRS]=10: root@freescale /home$ ./io2 0x53f80000 /dev/mem opened. Memory mapped on address 0x4001f000. Address value 0x53F80000 (0x4001f000): 0x174B0D7D The pll_ref_clock inputs to MCU PLL and Serial PLL. We can check MCU PLL and Serial PLL configurations on MPCTL (0x53F80010) and SPCTL (0x53F80010) registers respectively. Reading MPCTL and SPCTL: root@freescale /home$ ./io2 0x53f80010 /dev/mem opened. Memory mapped on address 0x4001f000. Address value 0x53F80010 (0x4001f010): 0x33280C root@freescale /home$ ./io2 0x53f80018 /dev/mem opened. Memory mapped on address 0x4001f000. Address value 0x53F80018 (0x4001f018): 0x2072356 Determine the PLL multiplication factor from MPCTL and SPCTL: - MPCTL: PD = 1 (0000) | MFD = 52 (0000110011) | MFI = 10 (1010) | MFN = 12 (0000001100) - MCPTL Multiplication Factor: 20,46153 - mpl-dpdgck-clk = 20,46153 * 26MHz = 532 MHz - SPCTL: PD = 1 (0000) | MFD = 520 (1000000111) | MFI = 8 (1000) | MFN = -170 (1101010110) - SCPTL Multiplication Factor: 15,3461538 - spl-dpdgck-clk = 15,3461538 * 26MHz = 399 MHz Finally we can output mpl-dpdgck-clk and spl_dpdgck_clk values to check the calculations above. We can write 0x300 to COSR for mpl-dpdgck-clk. [CLKOEN = 1| CLKOUTDIV = 16| CLKOSEL = mpl_dpdgck_clk] And 0x307 for spl-dpdgck-clk. [CLKOEN = 1| CLKOUTDIV = 16| CLKOSEL = spl_dpdgck_clk] root@freescale /home$ ./io2 0x53f8001c w 0x300 /dev/mem opened. Memory mapped on address 0x4001f000. Written: 0x300 root@freescale /home$ ./io2 0x53f8001c w 0x307 /dev/mem opened. Memory mapped on address 0x4001f000. Written: 0x307 By multiplying the results above by 16 to compensate for CLKOUTDIV we have the expected results.
View full article
This is a HW design checklist for customer's reference. Please read and fill it in carefully before requesting a schematic/design review.
View full article
Question: An alignement trap in Linux had been seen in an unaligned access of the WEIM (to an external FPGA) Alignment trap: testFPGA (1027) PC=0x000086dc Instr=0xe1d330b0 Address=0x08000001 FSR 0x011 The issue can be reproduced with the platform SDK EIM parallel Nor Test on the Sabre AI - When I access WEIM_BASE_ADDR +1 I get an exception. EIM test start: Flash size: 0x 2000000 Flash erase... . Oops, data abort occurred! Registers at point of exception: cpsr = nZCvqeAift Supervisor (0x60000113) r0 = 0x00000000    r8 =  0x00000000 r1 = 0x00000000    r9 =  0x00000000 r2 = 0x00000001    r10 = 0x00000000 r3 = 0x08000001    r11 = 0x10409770 r4 = 0xdeadfeed    r12 = 0x00000001 r5 = 0x10002458    sp =  0x10409734 r6 = 0x00000000    lr =  0x1000ef9c r7 = 0x00000094    pc =  0x1000bfd0 dfsr = 0x00000001 dfar = 0x08000001 Access type: read Fault status: 0x1 Is adress alligned access mandatory for EIM or AXI HW? or is it possible to support unaligned access? Answer: EIM should support unaligned access. Also ARM architecture supports unaligned access to data and address buses but only if the MMU co-processor is setup for that. Try checking cp15 sctlr[1]. Linux discourage the access to unaligned memory and some times that makes a bus error resulting in a kernel panic. So the drivers and the setup architecture files should support unaligned memory access. ARM Information Center /linux/Documentation/unaligned-memory-access.txt The EIM device is a AXI slave which should support unaligned access. Reference Manual and there's a sub-chapter in the EIM call AXI(Master) Bus cycles support. In that chapter there's a table AXI to Memory Burst Splits Number in that table states the increment burst access to a aligned or unaligned address. I expect those are for the EIM and not refer only to the AXI bus. At any case is not state clear if unaligned access should work only in burst mode (which doesn't make any sense to me) or if the RM information is incorrect. Also in the same chapter in signals not supported never list the alignment signals so unaligned access is supported. Link with some generic ARM information about that. http://forums.arm.com/index.php?/topic/8862-axi-narrowunaligned-read-transfers/ AXI4 - Aligned & unaligned address - ARM Community
View full article
Purpose: Introduce how to debug M4 using trace 32 and the difference with regular debug mode for imx6sx. If you are using other jtag debug tools, maybe you need to do the similar configuration. Debug tools: Trace32 – you can refer to http://www.lauterbach.cn/ for more information about this tool.
View full article
When you do long test (days or weeks) test on i.MX board and your test fails, you often wants to know what has happen with a JTAG probe. The problem is when you have 50 boards running in parallel, you don't have the budget to have 50 JTAG debug probe. If you do a "hot plug" of your JTAG probe, you have roughly one chance out 2 to reset your board... so you'll have to wait another couple of hour to resee the problem. Anyway to have a reliable JTAG plug with no reset, it is really simple... cut the RESET line on your cable! then you'll still be able to "attach" to your i.MX. On the MEK board, with a 10-pin JTAG connector, you have the cut the cable line 10 of the ribbon cable: On the cable, cut the reset line like this: With my Lauterbach JTAG  probe, when I do a "hot plug" I never have a reset of my i.MX. BR Vincent
View full article
1) Remove all "network" parameters from .../ltib-dir/rootfs/rc.d/rc.conf 2) Add the path of rootfs in the /etc/exports file eg : /home/user/ltib-dir/rootfs/rootfs *(rw,sync,no_root_squash) then execute :- #exportfs -ra 3) Execute NFS server /etc/init.d/nfs restart
View full article
Below is one implementation of i.MX as a USB Playback/Capture device on one OTG port. Design Block Diagram: Driver user space interface: As file /dev/gadget/g_audio file system : gadgetaudiofs_type usage: mount -t gadgetaudiofs path /dev/gadget /* if /dev/gadget is not exist, create it manually */ r/w interface open read write close ssize_t read(int fd, void *buf, size_t count); Notice: Attempts to read up to count bytes from file descriptor fd into the buffer starting at buf. On success, the number of bytes read is returned. This call may be blocked if device can't give enough data. Only if usb out pipe be broken(host stop audio player), return value is still positive and less than count. Error: Count must align with PCM audio frame size. If not -EFAULT as errorno. Notes: Audio frame size = audio sample size x audio channels. ssize_t write(int fd, void *buf, size_t count); Notice: Writes up to count bytes from the buffer pointed buf to the file referred to by the file descriptor fd. On success, the number of bytes written is returned. This call will never be blocked, even if the internal ring buffer dose not have enough space to write. A successful return from write() that return value equal to count does not make any guarantee that data all have been put to internal ring buffer. For example, if ring buffer is empty and has 1K bytes space, while write count is 3K bytes, only the last 1K bytes will be put to the ring buffer! Key attribute for g_audio driver USB out pipe parameter: Sample width hard code to 16bits. static int out_sample_rate = 48000; static int out_channel = 2; #define OUT_EP_ALIGN (2 * out_channel) // 2 mean 2 bytes, sample width 16bits OUT_EP_ALIGN mean “read ring buffer” write/read align, if read/write length not align this value, throw out error. Read mean user space read system call, write mean driver internal copy req->buf to “read ring buffer”. #define OUT_EP_MAX_PACKET_SIZE (192) // out pipe max packet size, it based on out_sample_rate and out_channel. 192 = (48KHZ / 1000) * out_channel * sample_width(as bytes) 192 = (48000 / 1000 ) * 2 * 2; Hear 1000 based on: as_out_ep_desc.bInterval = 4; /* 4 in hi speed as 2 exp (4 -1) = 8 uframe time, 8 uframe time is 8 * 125 us = 1ms 1000 = 1s / 1ms */ static int out_req_count = 256; /* out pipe queue count, this value dose not introduce extra audio latency ! */ #define AUDIO_READ_RINGBUF_LEN (23 * OUT_EP_MAX_PACKET_SIZE) /* 4416 bytes, max valid 23 * 192, about 23 ms at 48KHZ, this value determine out pipe max audio latency */ If “read ring buffer” full, how to handle continue write: discard the 1/3 oldest ring buffer. See function int f_audio_ringbuffer_write   if(ringbuf->len - ringbuf->actual < alignLen)   {   ringbuf->rp += (alignLen * (ringbuf->len /(alignLen * 3))); /* if cache up read pointer, discard 1/3 ring buf */   ...   } USB in pipe parameter: Sample width hard code to 16bits. static int in_sample_rate = 8000; static int in_channel = 2; #define IN_EP_ALIGN (2 * in_channel) // 2 mean 2 bytes, sample width 16bits IN_EP_ALIGN mean “write ring buffer” write/read align, if read/write length not align this value, throw out error. Write mean user space write system call, read mean driver internal copy “write ring buffer” to req->buf. #define IN_EP_MAX_PACKET_SIZE (32) // in pipe max packet size, it based on in_sample_rate and in_channel. 32 = (8KHZ / 1000) * in_channel * sample_width(as bytes) 32 = (8000 / 1000 ) * 2 * 2; Hear 1000 based on: as_in_ep_desc.bInterval = 4; /* 4 in hi speed as 2 exp (4 -1) = 8 uframe time, 8 uframe time is 8 * 125 us = 1ms 1000 = 1s / 1ms */ static int in_req_count = 32; /* in pipe queue count, this value dose introduce extra audio latency ! Latency = 32ms */ #define AUDIO_WRITE_RINGBUF_LEN (32 * OUT_EP_MAX_PACKET_SIZE) /* 1024 bytes, max valid 32 * 32, about 32 ms at 8KHZ, this value and in_req_count determine in pipe max audio latency 32 + 32 = 64 ms*/ If “write ring buffer” full, how to handle continue write: discard the 1/3 oldest ring buffer. See function int f_audio_ringbuffer_write   if(ringbuf->len - ringbuf->actual < alignLen)   {   ringbuf->rp += (alignLen * (ringbuf->len /(alignLen * 3))); /* if cache up read pointer, discard 1/3 ring buf */   ...   } Test Environment. Ubuntu 10.0.4 LTS Kernel 3.0.0-15 64bit. Ubuntu 10.0.4 LTS Kernel 2.6.32-42 64bit. Test application. Test user space application based on http://www.rosoo.net/a/201107/14725.html I will attach modified code. Test procedure. /* I.MX28 EVK board audio ADC default input is MIC, so, set it to LINE IN */ amixer sset 'ADC Mux' 'LINE_IN'  /* insmod g_audio driver and create directory for gadgetaudiofs */ modprobe g_audio && mkdir /dev/gadget /* mount gadgetaudiofs */ mount -t gadgetaudiofs path /dev/gadget /* start read g_audio device application.   It read PCM data from g_audio_device and put it to alsa playback device.   It read from g_audio_device per read system call per period_size (300 bytes).   See alsa PCM playback configuration   stream : PLAYBACK access : RW_INTERLEAVED   format : S16_LE   subformat : STD   channels : 2   rate : 48000   exact rate : 48000 (48000/1)   msbits : 16   buffer_size : 1200 (frames) (buffer time is 1200 / 48000 = 25ms)   period_size : 300 (frames)   period_time : 6250 (ns) */ ./lplay /dev/gadget/g_audio /* start write g_audio device application. It read PCM data from alsa capture device and put it to g_audio_device. It write to g_audio_device per write system call per period_size (50 bytes). See alsa PCM capture configuration   stream : CAPTURE   access : RW_INTERLEAVED   format : S16_LE   subformat : STD   channels : 2   rate : 8000   exact rate : 8000 (8000/1)   msbits : 16   buffer_size : 200 (frames) (buffer time is 200 / 8000 = 25ms)   period_size : 50 (frames)   period_time : 6250 (ns) */ ./lrecord /dev/gadget/g_audio The two processes CPU utilization on I.MX28 EVK board is about 5~15%, if you change per g_audio_device read/write system call size more larger, the more smaller CPU utilization you will get, but at the same time the more audio latency you will get. Per read/write system call size should has relation will “read/write ring buffer” size in g_audio driver. For example, if per write system call size is larger than “write ring buffer” size, then every write system call will discard some part of write buffer data. During 15 hours lplay and lrecord long test, driver and application both use default configuration as upper description, summarily 271 times driver internal buffer full appear. In another test, driver keep default configuration, new test set microphone ALSA capture buffer to 250ms, ALSA capture read as unblock mode, other configuration as lrecord application, block read USB gadget device 200 x 192 bytes (waiting 200ms), then unblock read whole ALSA capture buffer, found about every 1.5s, ALSA buffer will less then 16bytes (4 sample) compare to 200 x 32 bytes. Clock Sync issue of echo cancellation based on this implementation: Note: USB clock domain different with play back and microphone, some buffer will be discard by USB audio driver. See this diagram: 1: Echo cancellation application will try best to read “USB Output Buffer”, so no buffer will be discarded from output. ( Application input and output based on the same clock). 2: “Host playback buffer” maybe overrun because:   A: Playback source unstable and host playback buffer not enough larger.   B: Clock(playback) quick than Clock(USB). 3: Echo cancellation application will try best to read “ALSA Buffer”, so no buffer will be discarded from “ALSA buffer”. (Application discard some samples of “ALSA Buffer”) 3: Echo cancellation application handle “USB Output Buffer” and “ALSA Buffer” based on “USB Output Buffer” that same time mean based on Clock(USB). We assume Echo cancellation application will insert or discard some samples of “ALSA Buffer” based on “USB Output Buffer”. 4: Echo cancellation application will send processed buffer to USB audio driver based on Clock(USB), so no buffer will be discard from “USB Input Buffer”. If Echo cancellation application said “ I don't have the ability to insert or discard some samples of “ALSA Buffer”, we need adjust the Clock(MIC) based the internal buffer level of Echo cancellation application. But I think the “internal buffer level” will be influenced by difference of the clocks, the buffer input and output task runtime loading, so it may not be reality to implement this, need do more test on this! Add USB get output/input buffer length interface Add USB SAIF(only for i.mx 28) set clock interface For i.MX28 SAIF clock based on 480MHz. The fraction divider is 16bit, that mean the mini step is 0x 0.0001. 0x 0.0001 * 480MHz = 7324.21875Hz. If master clock as 512x frame rate, the mini step of frame rate is 14.3Hz USB get output/input buffer length interface: IOCTL CMD: #define USBAUDIO_BUFFER_STATUS_GET \ _IOR('g', 200, struct usbaudio_buffer_status) structure: struct usbaudio_buffer_status{   /* all as bytes */   __u32 playbackBufferTotalLen;   __u32 playbackBufferCurrentLen;   __u32 microphoneBufferTotalLen;   __u32 microphoneBufferCurrentLen; }; usage: struct usbaudio_buffer_status bufferStatus; ioctl(fd, USBAUDIO_BUFFER_STATUS_GET, &bufferStatus); USB SAIF(only for i.mx 28) set clock interface. IOCTL CMD: #define USBAUDIO_SAIF_CLOCK_CONTROL \ _IOWR('g', 201, struct usbaudio_saif_clock_control) structure: struct usbaudio_saif_clock_control{   /* all as HZ -1 as invalid */   __u32 saifCurrentClock; /* read */   __u32 saifNextClock; /* write */ }; usage: struct usbaudio_saif_clock_control saifClkCtl; saifClkCtl.saifNextClock = -1; ioctl(fd, USBAUDIO_SAIF_CLOCK_CONTROL, &saifClkCtl); saifClkCtl.saifNextClock = saifClkCtl.saifCurrentClock + step; ioctl(fd, USBAUDIO_SAIF_CLOCK_CONTROL, &saifClkCtl); Compile sample: /opt/freescale/usr/local/gcc-4.4.4-glibc-2.11.1-multilib-1.0/arm-fsl-linux-gnueabi/bin/arm-linux-gcc -I /home/haidong/Work/Mx28/L2.6.35_10.12.01_ER_source/LTIB/ltib/rootfs/usr/include/ -I /home/haidong/Work/Mx28/L2.6.35_10.12.01_ER_source/LTIB/Kernel/linux-2.6.35.3/include -L /home/haidong/Work/Mx28/L2.6.35_10.12.01_ER_source/LTIB/ltib/rootfs/usr/lib/ lrecord.c -o lrecord -lasound
View full article
This is done with the 11.09 BSP for imx53 specifically. Attached is an amrnb.spec file, I put it in ltib/dist/lfs-5.1/amrnb. Then I extracted opencore-amr-0.1.3.tar.gz and put it in ltib/rpm/BUILD. I built with ltib ( ALl this could be added to the ltib menus as well 😞 ./ltib –m scbuild –p amrnb ./ltib –m scdeploy –p amrnb Then I applied the patch to .ltib for gst-plugins-ugly and built that with ltib. It will play a .3gp file with this pipeline: gst-launch filesrc location=/media/sd/test.3gp ! qtdemux name=demux demux.audio_00 ! queue ! amrnbdec ! alsasink demux.video_00 ! multiqueue ! mfw_vpudecoder ! mfw_isink Regards, Randy Krakora
View full article
Hello Android users Otto has posted on the Element14 community some clear tutorial (accessible following the link below) to build Android from source. RIoTboard: Building Android from Source | element14 I recommend you to start following those steps to properly setup the Android tools. Happy Source Programming Greg
View full article
View the OSS Security and Maintenance Community
View full article