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

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

i.MX Processors Knowledge Base

ディスカッション

ソート順:
Board : i.MX93 EVK BSP: imx L6.1.1-1.0.0 Gui guider: 1.6.1   We have a GUI software tool called GUI Guider. It is a user-friendly graphical user interface development tool from NXP that enables the rapid development of high quality displays with the open-source LVGL graphics library. The GUI demo can run on the i.MX93EVK board. (https://www.nxp.com/design/software/development-software/gui-guider:GUI-GUIDER)   This document will show you an example how the buttons(gpio) on the EVK to interacting with the GUI. Basically, customer could use the same method to use the gpio pins to control everything.   On the i.MX93 EVK board, there are two buttons BTN1 and BTN2. They are connected to GPIO IO23 and GPIO IO24. Below is the schematic.    Buttons on the board.      SW1005 on the board   In the EVK's device tree file, need to change the pinmux for the two buttons like this: pinctrl_spdif: spdifgrp { fsl,pins = < // MX93_PAD_GPIO_IO22__SPDIF_IN 0x31e // MX93_PAD_GPIO_IO23__SPDIF_OUT 0x31e MX93_PAD_GPIO_IO23__GPIO2_IO23 0x31e MX93_PAD_GPIO_IO24__GPIO2_IO24 0x31e >; note: all the pins are defined in imx93-pinfunc.h.   For getting the input value of the buttons in user's space, I use the sysfs gpio. Build the imx-image-multimedia image first and then select the GPIO_SYSFS in kernel's menuconfig.   $ DISTRO=fsl-imx-xwayland MACHINE=imx93evk source imx-setup-release.sh -b build-xwayland $ bitbake imx-image-multimedia   After the build completed, go to the kernel's menuconfig to select the GPIO sysfs. $ bitbake linux-imx -c menuconfig [*] General setup-> Configure standard kernel features (expert users) [*] Device Drivers->GPIO Support-> /sys/class/gpio/... (sysfs interface)   Build the whole image again by "$ bitbake imx-image-multimedia".   Using the UUU to program the image to the EMMC on the EVK board. uuu -b emmc_all imx-image-multimedia-imx93evk.rootfs.wic.zst   Connect the LVDS to the board. Use the corresponding dtb to boot the board. In u-boot, set the dtb file. => setenv fdtfile imx93-11x11-evk-boe-wxga-lvds-panel.dtb => saveenv   Then restart the board. After the board boot up, it will look like below.     You need to calibrate the LVDS touch screen before it can normally use. Please use this command: $ weston-touch-calibrator LVDS-1     Now, build the GUI guider example. I use the Air Conditioner example. Download the GUI guider from the gui-guider web page: https://www.nxp.com/design/software/development-software/gui-guider:GUI-GUIDER   Follow the steps from the below web page to build the i.MX BSP and the gui example code. https://docs.nxp.com/bundle/GUIGUIDERUG-1.6.1/page/topics/yocto.html   After the gui-guider build completed, use the 'scp' command to transfer the gui_guider executable file to the board. Execute the command on your host PC like this: $ scp bld-imx93evk/tmp/work/armv8a-poky-linux/gui-guider/1.6.0-r0/image/usr/bin/gui_guider root@<Your Board IP address>:/ Note: You could use a router to connect your board and your host PC. They are on the same network so could use the 'scp' command to transfer the file to your board.   On your board, type the following commands to execute the gui. $ chmod 755 gui_guider $ ./gui_guider &   Then the GUI is running like this:   Now, let me explain how to find out the gpio number. Type the following command to show the mapping addresses of gpio. root@imx93evk:/# cat /sys/kernel/debug/gpio gpiochip3: GPIOs 0-31, parent: platform/47400080.gpio, 47400080.gpio: gpiochip0: GPIOs 32-63, parent: platform/43810080.gpio, 43810080.gpio: gpiochip1: GPIOs 64-95, parent: platform/43820080.gpio, 43820080.gpio: gpio-64 ( |cd ) in hi IRQ ACTIVE LOW gpio-71 ( |regulator-usdhc2 ) out lo gpiochip2: GPIOs 96-127, parent: platform/43830080.gpio, 43830080.gpio: gpiochip6: GPIOs 472-477, parent: i2c/0-001a, wm8962, can sleep: gpiochip5: GPIOs 478-487, parent: platform/adp5585-gpio.1.auto, adp5585-gpio, can sleep: gpio-479 ( |regulator-audio-pwr ) out hi gpio-483 ( |regulator-can2-stby ) out hi ACTIVE LOW gpio-486 ( |enable ) out hi gpiochip4: GPIOs 488-511, parent: i2c/1-0022, 1-0022, can sleep: gpio-492 ( |Headphone detection ) in lo IRQ gpio-501 ( |? ) out hi gpio-502 ( |regulator-vdd-12v ) out hi gpio-505 ( |reset ) out lo gpio-507 ( |? ) out hi gpio-508 ( |reset ) out lo ACTIVE LOW   The gpio pins of two buttons are GPIO2_IO23 and GPIO2_IO24. They are belongs to gpio2. In the imx93.dtsi, the gpio2's address is "gpio2: gpio@43810080". So, base on the information output from "/sys/kernel/debug/gpio", the gpio2 is mapping to "gpiochip0: GPIOs 32-63". So, the GPIO2_IO23 is 32+23=55, and the GPIO2_IO24 is 32+24=56.   To verify the gpio number is correct or not. We could do the following test. root@imx93evk:/# echo 55 > /sys/class/gpio/export root@imx93evk:/# echo in > /sys/class/gpio/gpio55/direction root@imx93evk:/# echo 56 > /sys/class/gpio/export root@imx93evk:/# echo in > /sys/class/gpio/gpio56/direction   Then, run these two commands to check the values. root@imx93evk:/# cat /sys/class/gpio/gpio55/value root@imx93evk:/# cat /sys/class/gpio/gpio55/value   When the button is not pressed, the value is 1. When press the button, the value is 0.  We could add the same in the GUI's custom.c. Open the GUI Guider software and add the code in the custom.c. /********************* * INCLUDES *********************/ #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <errno.h> #include <fcntl.h> #include "lvgl.h" #include "custom.h" #include "ui_Aircon.h" #include "guider_customer_fonts.h" /********************** * STATIC VARIABLES **********************/ int fdbtn1,fdbtn2,fdgpio; int btn1_pressed; int btn2_pressed; char btn1_value, btn2_value; void custom_func(void) { fdbtn1 = open("/sys/class/gpio/gpio55/value", O_RDWR); fdbtn2 = open("/sys/class/gpio/gpio56/value", O_RDWR); read(fdbtn1, &btn1_value, 1); read(fdbtn2, &btn2_value, 1); if(btn1_value=='0' && btn1_pressed) { btn1_pressed=0; ui_aircon_update_temp(0, kAIRCON_TempUp); } if(btn1_value=='1') btn1_pressed=1; if(btn2_value=='0' && btn2_pressed) { btn2_pressed=0; ui_aircon_update_temp(0, kAIRCON_TempDown); } if(btn2_value=='1') btn2_pressed=1; close(fdbtn1); close(fdbtn2); } void custom_init(lv_ui *ui) { fdbtn1 = open("/sys/class/gpio/gpio55/value", O_WRONLY); if (fdbtn1 == -1) { fdgpio = open("/sys/class/gpio/export", O_WRONLY); write(fdgpio,"55",3); write(fdgpio,"56",3); close(fdgpio); fdgpio = open("/sys/class/gpio/gpio55/direction", O_WRONLY); write(fdgpio,"in",3); close(fdgpio); fdgpio = open("/sys/class/gpio/gpio56/direction", O_WRONLY); write(fdgpio,"in",3); close(fdgpio); } else close(fdbtn1); ... ... ... ...   Add the custom_func() in the custom.h. #ifndef __CUSTOM_H_ #define __CUSTOM_H_ #ifdef __cplusplus extern "C" { #endif #include "gui_guider.h" void custom_init(lv_ui *ui); + void custom_func(void);   Also, need to add the custom function() into the dead loop in main.c.   To modify the code, bld-imx93evk$ vim tmp/work/armv8a-poky-linux/gui-guider/1.6.0-r0/gui-guider-1.6.0/ports/linux/main.c   while(1) { + custom_func(); // <--- Add the custom function here. /* Periodically call the lv_task handler. * It could be done in a timer interrupt or an OS task too.*/ time_till_next = lv_wayland_timer_handler(); #if LV_USE_VIDEO video_play(&guider_ui); #endif /* Run until the last window closes */ if (!lv_wayland_window_is_open(NULL)) { break; }   Re-build the code after modified. bld-imx93evk$ bitbake gui-guider -c compile -f   Build the whole image again. bld-imx93evk$ bitbake gui-guider Then use the 'scp' command to transfer the new gui-guider file to the board.   Finally, you can use the buttons on the EVK board to set the temperature up and down.                          
記事全体を表示
Hello everyone! In this quick example its focused on how to customize uboot code to generate an uboot image with a silent console so its speed up the flash and boot time, this may provide helpful for customers who have a bigger images or just want to have a silent console. Note: this should not be enabled if the image is still being under test, since this will disable all communication with the debug terminal and there won't be boot messages. Requirements: I.MX 8M Nano DDR4 EVK i.MX 8M Nano EVK Prebuilt image (6.1.1-1.0.0) UUU tool First clone the code from the uboot repository: $ git clone https://github.com/nxp-imx/uboot-imx -b lf-6.1.1-1.0.0 $ cd uboot-imx After we get the code, then proceed to enable the silent console in the uboot defconfig: $ nano configs/imx8mn_ddr4_evk_defconfig CONFIG_SILENT_CONSOLE=y CONFIG_SILENT_U_BOOT_ONLY=y For this to actually work we need to create the silent environmental variable and give it a value different from "0": $ nano include/configs/imx8mn_evk.h "silent=1\0"      \ As specified in our Linux porting guide: Generate an SDK from the Yocto Project build environment with the following command. To set up the Yocto Project build environment, follow the steps in the i.MX Yocto Project User's Guide (IMXLXYOCTOUG). In the following command, set Target-Machine to the machine you are building for. See Section "Build configurations" in the i.MX Yocto Project User's Guide (IMXLXYOCTOUG) Set up the host terminal window toolchain environment: $ source/opt/fsl-imx-xwayland/6.1.1/environment-setup-aarch64-poky-linux $ export ARCH=arm64 Build uboot binary: $ make distclean $ make imx8mn_ddr4_evk_defconfig $ make Build ARM Trusted Firmware (ATF) $ cd .. $ git clone https://github.com/nxp-imx/imx-atf -b lf-6.1.1-1.0.0 $ cd imx-atf/ $ make PLAT=imx8mn bl31 In case you get the error aarch64-poky-linux-ld.bfd: unrecognized option '-Wl,-O1' $ unset LDFLAGS Download the DDR training & HDMI binaries $ cd .. $ mkdir firmware-imx $ cd firmware-imx $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.19.bin $ chmod a+x firmware-imx-8.19.bin $ ./firmware-imx-8.19.bin Accept EULA and the firmware will be deployed. Download imx-mkimage and build the boot image $ cd .. $ git clone https://github.com/nxp-imx/imx-mkimage -b lf-6.1.1-1.0.0 $ cd imx-mkimage $ cp ../uboot-imx/spl/u-boot-spl.bin iMX8M/ $ cp ../uboot-imx/u-boot-nodtb.bin iMX8M/ $ cp ../uboot-imx/arch/arm/dts/imx8mn-ddr4-evk.dtb iMX8M/ $ cp ../imx-atf/build/imx8mn/release/bl31.bin iMX8M/ $ cp ../firmware-imx/firmware-imx-8.19/firmware/ddr/synopsys/ddr4_* iMX8M/ $ cp ../uboot-imx/tools/mkimage iMX8M/mkimage_uboot $ make SOC=iMX8MN flash_ddr4_evk After this we can download our uboot image to our board, we can either use the uboot image for boot or for flashing purpose only. We can compare the time it takes using UUU with a standard pre-built image uuu -V -b emmc_all imx-boot-imx8mn-ddr4-evk-sd.bin-flash_ddr4_evk imx-image-full-imx8mnevk.wic It takes 485.5 seconds using normal uboot with debug console enabled. uuu -V -b emmc_all flash.bin imx-image-full-imx8mnevk.wic It takes 477.5 seconds using silent uboot console. Even if the speed is not greatly improved (~8 seconds), in larger files it could help to speed up flashing, even if wants to have the console silent is a good option. Hope everyone finds this useful! For any question regarding this document, please create a community thread and tag me if needed. Saludos/Regards, Aldo.
記事全体を表示
On behalf of Gopise Yuan. A collection of several GST debugging tips and known-how. When you need to play onto a DRM layer/plane directly without going through compositor, kmssink should be a good choice: // kmssink, with scale and adjust alpha property (opaque) and zpos (this requires kmssink>=1.16): gst-launch-1.0 filesrc location=/media/AVC-AAC-720P-3M_Alan.mov ! decodebin ! imxvideoconvert_g2d ! kmssink plane-id=37 render-rectangle="<100,100,720,480>" can-scale=false plane-properties=s,alpha=65535,zpos=2 When using playbin, you can still customize the pipeline besides the sink plugin, e.g. add a converter plugin: // Playbin with additional customization on converter before sink: gst-launch-1.0 playbin uri=file:///mnt/MP4_H264_AAC_1920x1080.mp4 video-sink="imxvideoconvert_g2d ! video/x-raw,format=BGRA,width=1920,height=1080 ! kmssink plane-id=44" GST can generate a pipeline graph for analyzing the pipeline in a intuitive manner: // Generate pipeline graph: 1. Export GST_DEBUG_DUMP_DOT_DIR=<dump-folder>, GST_DEBUG=4 2. Run pipeline with gst-launch or others. 3. Copy all dump files (.dot) from <dump-folder>. Note: one dump file will be created for each state transaction. Normally, what we need will be PAUSE_READY or READY_PAUSE, after which pipeline has been setup. 4. Convert the .dot file to PDF with Graphviz: dot -Tpdf 0.00.03.685443250-gst-launch.PAUSED_READY.dot > pipeline_PAUSED_READY.pdf  
記事全体を表示
BSP: L5.15.5_1.0.0 Platform: i.MX8MPlus EVK Background   The function lpddr4_mr_read in BSP always return zero and this casue the customer can't use it to read MR registers in DRAM. This is a simple demo for reading MR registers. Patch Code   diff --git a/arch/arm/include/asm/arch-imx8m/ddr.h b/arch/arm/include/asm/arch-imx8m/ddr.h index 0f1e832c03..fd68996a23 100644 --- a/arch/arm/include/asm/arch-imx8m/ddr.h +++ b/arch/arm/include/asm/arch-imx8m/ddr.h @@ -721,6 +721,8 @@ int wait_ddrphy_training_complete(void); void ddrphy_init_set_dfi_clk(unsigned int drate); void ddrphy_init_read_msg_block(enum fw_type type); +unsigned int lpddr4_mr_read(unsigned int mr_rank, unsigned int mr_addr); + void update_umctl2_rank_space_setting(unsigned int pstat_num); void get_trained_CDD(unsigned int fsp); diff --git a/board/freescale/imx8mp_evk/spl.c b/board/freescale/imx8mp_evk/spl.c index 33bbbc09ac..85e40ffbbe 100644 --- a/board/freescale/imx8mp_evk/spl.c +++ b/board/freescale/imx8mp_evk/spl.c @@ -150,6 +150,40 @@ int board_fit_config_name_match(const char *name) return 0; } #endif +void lpddr4_get_info() +{ + int i = 0, attempts = 5; + + unsigned int ddr_info = 0; + unsigned int regs[] = { 5, 6, 7, 8 }; + + for(i = 0; i < ARRAY_SIZE(regs); i++){ + unsigned int data = 0; + data = lpddr4_mr_read(0xF,regs[i]); + ddr_info <<= 8; + ddr_info += (data & 0xFF); + switch (i) + { + case 0: + printf("DRAM INFO : Manufacturer ID = 0x%x",ddr_info); + if(ddr_info & 0Xff) + printf(", Micron\n"); + break; + case 1: + printf("DRAM INFO : Revision ID1 = 0x%x\n",ddr_info); + break; + case 2: + printf("DRAM INFO : Revision ID2 = 0x%x\n",ddr_info); + break; + case 3: + printf("DRAM INFO : I/O Width and Density = 0x%x\n",ddr_info); + break; + default: + break; + } + } + +} void board_init_f(ulong dummy) { @@ -187,6 +221,8 @@ void board_init_f(ulong dummy) /* DDR initialization */ spl_dram_init(); + + lpddr4_get_info(); board_init_r(NULL, 0); } diff --git a/drivers/ddr/imx/imx8m/ddrphy_utils.c b/drivers/ddr/imx/imx8m/ddrphy_utils.c index 326b92d784..f45eeaf552 100644 --- a/drivers/ddr/imx/imx8m/ddrphy_utils.c +++ b/drivers/ddr/imx/imx8m/ddrphy_utils.c @@ -194,8 +194,15 @@ unsigned int lpddr4_mr_read(unsigned int mr_rank, unsigned int mr_addr) tmp = reg32_read(DRC_PERF_MON_MRR0_DAT(0)); } while ((tmp & 0x8) == 0); tmp = reg32_read(DRC_PERF_MON_MRR1_DAT(0)); - tmp = tmp & 0xff; reg32_write(DRC_PERF_MON_MRR0_DAT(0), 0x4); + + while (tmp) { //try to find a significant byte in the word + if (tmp & 0xff) { + tmp &= 0xff; + break; + } + tmp >>= 8; + } return tmp; }     Test Result  
記事全体を表示
  1.overwrite the sources/meta-freescale/recipes-security/optee-imx with optee-imx.zip 2.add below code to conf/local.conf DISTRO_FEATURES_append += " systemd" DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit" VIRTUAL-RUNTIME_init_manager = "systemd" VIRTUAL-RUNTIME_initscripts = "systemd-compat-units" MACHINE_FEATURES_append += "optee" DISTRO_FEATURES_append += "optee" IMAGE_INSTALL_append += "optee-test optee-os optee-client optee-examples" 3.bitbake optee-examples or bitbake imx-image-xxx You can directly install optee-examples_3.11.0-r0_arm64.deb in your device.  
記事全体を表示
Software environment: L5.4.47_2.2.0 Hardware i.MX8QXPC0 EVK board In the uuu script we can see the bootloader imx-boot-imx8qxpc0mek-sd.bin-flash is necessary. The default BSP build generate in the yocto project is with the spl, some customers are confused about the how to build the imx-boot-imx8qxpc0mek-sd.bin-flash. Here I give the manually compile way and generate it in yocto. In the yocto generate it is more convenient than the manually compile way. Hope this can do help for you.
記事全体を表示
[中文翻译版] 见附件   原文链接: https://community.nxp.com/docs/DOC-342174 
記事全体を表示
You can but building times will take much longer (approximately 2 times longer for the core-image-minimal) compared to a build done on a native machine. In case you can not do the build on a native machine, make sure your virtual has enough hard-disk room (at least 50GB). For example, these are the build folders sizes after baking core-image-minimal: build$ du -h --max-depth=1 1.3G    ./sstate-cache 3.2M    ./cache 12K    ./.hob 32K    ./conf 22G    ./tmp 23G    . The tmp folder is by far the largest (containing building statistics, source code, deployed images, etc.) build/tmp$ tree -L 2 -d . ├── buildstats │   ├── cogl-imx6qsabresd │   ├── fsl-image-gui-imx6qsabresd │   ├── fsl-image-gui-sdk-imx6qsabresd │   ├── mesa-dri-imx6qsabresd │   ├── mesa-imx6qsabresd │   └── pseudo-native-imx6qsabresd ├── cache │   └── default-eglibc ├── deploy │   ├── images │   ├── licenses │   └── rpm ├── log │   ├── cleanlogs │   └── cooker ├── pkgdata │   ├── all-poky-linux │   ├── all-poky-linux-gnueabi │   ├── armv7a-vfp-neon-poky-linux-gnueabi │   ├── imx6qsabresd-poky-linux │   └── imx6qsabresd-poky-linux-gnueabi ├── sstate-control ├── stamps │   ├── all-poky-linux │   ├── all-poky-linux-gnueabi │   ├── armv7a-vfp-neon-poky-linux-gnueabi │   ├── imx6qsabresd-poky-linux │   ├── imx6qsabresd-poky-linux-gnueabi │   ├── work-shared │   └── x86_64-linux ├── sysroots │   ├── imx6qsabresd │   ├── imx6qsabresd-tcbootstrap │   └── x86_64-linux ├── work │   ├── all-poky-linux │   ├── all-poky-linux-gnueabi │   ├── armv7a-vfp-neon-poky-linux-gnueabi │   ├── imx6qsabresd-poky-linux │   ├── imx6qsabresd-poky-linux-gnueabi │   └── x86_64-linux └── work-shared     └── gcc-4.7.2-r13
記事全体を表示
[中文翻译版] 见附件   原文链接: https://community.nxp.com/docs/DOC-345148 
記事全体を表示
[中文翻译版] 见附件   原文链接: https://community.nxp.com/docs/DOC-343007 
記事全体を表示
This doc show: on i.MX6Q SabreSD board, configure ov5640 sensor(parallel or MIPI) output 5MP(2592x1944) RAW(Bayer) data at 15fps,and i.MX6Q IPU capture RAW RGB data, and i.MX6Q GPU debayer RAW data then display image. HW: i.MX6Q-SabreSD board, ov5640 sensor. SW: Linux 4.14.98_2.0.0 BSP, and patches in this doc. Configure at camera sensor side A Bayer filter is a color filter array (CFA) for arranging RGB color filters on a square grid of photosensors. The filter pattern is 50% green, 25% red and 25% blue, hence is also called BGGR, RGBG ,GRGB, or RGGB. The ov5640 has an image array capable of operating at up to 15 fps in 5 megapixel (2592x1944) resolution. OV5640 support output formats: RAW(Bayer), RGB565/555/444,CCIR656, YUV422/420, YCbCr422, and compression. To make ov5640 output 5MP RAW data at 15fps, check my patch imx6_ov5640_dvp_mipi_raw_capture_driver-4.14.98_2.0.0.diff which apply on i.MX Linux 4.14.98_2.0.0 BSP kernel code: Parallel interface ov5640, use ov5640_raw_setting[] array of drivers/media/platform/mxc/capture/ov5640.c. This register setting is come from ov5640 software application note and data sheet. MIPI interface ov5640, use ov5640_mipi_raw_setting[] array of drivers/media/platform/mxc/capture/ov5640_mipi.c. This register setting is combine setting of original code (remove ISP register setting), plus PLL register setting for MIPI interface, plus some data format register setting. Configure at i.MX6Q side The i.MX6Q IPU camera port(CSI-2 module) support data format include Raw(Bayer), RGB, YUV 4:4:4, YUV 4:2:2 and grayscale, up to 16 bits per value. Below is camera data routing for i.MX6Q:    Below is i.MX6Q IPU block daigram: The CSI-2 of IPU which is responsible for synchronizing and packing the video (or generic data) and sending it to other blocks. The video data received by CSI-2, could be sent to three other blocks: SMFC, VDI, IC. For RAW (Bayer) data capture, should go through path like this: CSI-2-->SMFC-->IDMAC-->DDR memory It means RAW data is received as generic data, see IPU_PIX_FMT_GENERIC in my patch, and IPU cannot process this kind data, it is just received to DDR memory. For MIPI interface camera, need note is i.MX6 side MIPI D-PHY clock must be calibrated to the actual clock range of the camera sensor’s D-PHY clock and the calibrated value must be equal to or greater than the camera sensor clock, detail see  AN5305. Take MIPI ov5640 as example: Pixel clock = 2592x1944x15fpsx(1/2 cycle/pixel)x1.35 blank interval = 51MHZ MIPI data rate = 51MHZ x 16 bit = 816Mb/s so 816/2/2*2 is 408MHZ is i.MX6 side D-PHY clock. Here due to one bayer pixel is 8bit, and i.MX6 MIPI data bus is 16 bit, so above use 1/2 cycle/pixel. And check ov5640_mipi_raw_setting[], you will got the sensor side D-PHY clock is about 672/2 = 336MHZ. And check AN5305, register MIPI_CSI2_PHY_TST_CTRL1 of i.MX6 need set as 0xC, but here i still keep it as default BSP value 0x14.   3.Capture test code I changed unit test mxc_v4l2_capture.c to capture the RAW data and save it to file. Check my patch imx6_ov5640_raw_captupre_test_4.14.98_2.0.0_ga.diff which apply on i.MX  Linux 4.14.98_2.0.0 BSP unit test code. Note the usage is: ./cap.out -c 1 -i 1 -fr 15 -m 6 -iw 2592 -ih 1944 -ow 2592 -oh 1944 -f BA81 -d /dev/video1 savefile.dmp parameter -i 1 means use CSI to MEM mode /dev/video1 is MIPI ov5640, /dev/video0 is parallel ov5640   4.Display RAW data The RAW data cannot be displayed directly, debayer process is needed to get complete red, green, blue color for each pixel. The debayer process if run on CPU, will cost much CPU time. To save CPU time, debayer could done by GPU. The method is, captured RAW data upload to GPU as texture , then GPU will do the debayer, then full color of each pixel will be got, then display it. To upload RAW camera data to GPU with zero memory copy, i will use i.MX6Q GPU extension GL_VIV_direct_texture. It create a texture with direct access support. API glTexDirectVIVMap,  which support mapping a user space memory or a physical address into the texture surface. The API glTexDirectVIVMap need logic and physical address of data buffer, so i will allocate data buffer from /dev/mxc_ipu, it is dma-buffer also get logic/physical address of buffer, then queue it as USERPTR to ipu v4l2 capture driver, after dequeue got RAW camera data, pass it to GPU for debayer. GPU side, I will use OpenGL shader code from "Efficient, High-Quality Bayer Demosaic Filtering on GPUs". Check my patch imx6-5640-debayer-testcode-gpusdk-5.2.0.diff which apply on i.MX GPU SDK 5.2.0 code. Note, here i only do is debayer, no extra process.   Known issue One thing is ov5640 output 5MP at 15fps, compare with output 5MP at 5fps, there are more noise of camera data at 15fps case. My debug found is , this noise seems come from ov5640 itself.   Reference: a>https://www.nxp.com/webapp/Download?colCode=IMX6DQRM b>https://www.nxp.com/webapp/Download?colCode=L4.14.98_2.0.0_MX6QDLSOLOX&appType=license c>https://github.com/NXPmicro/gtec-demo-framework d>https://www.nxp.com/docs/en/application-note/AN5305.pdf e>ov5640 data sheet f>ov5640 software application note g>Efficient, High-Quality Bayer Demosaic Filtering on GPUs https://www.semanticscholar.org/paper/Efficient%2C-High-Quality-Bayer-Demosaic-Filtering-on-McGuire/088a2f47b7ab99c78d41623bdfaf4acdb02358fb
記事全体を表示
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 "your_email@example.com" 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 meta-freescale@yoctoproject.org <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>
記事全体を表示
i.MX6UL/ULL extend uart port and integrate SIP I2C device. Contents 1 硬件设计说明 ............................................................. 2 硬件框图 ........................................................................ 2 硬件模块设计 ................................................................. 4 IOMUX 表 ....................................................................... 8 2 编译环境搭建 ............................................................. 8 编译环境文档及镜像下载。 ............................................ 8 编译环境搭建 ............................................................... 11 3 移植BSP 到扩展串口板 ........................................... 15 Uboot 中支持新的DTB ................................................ 15 Uboot 中调试串口改成UART6 ..................................... 16 去除掉无用的驱动及其IOMUX .................................... 18 增加i.MX6UL/ULL 本身串口支持 ................................. 18 增加GPIO 输出支持(GPIO_LED) ............................ 26 增加GPIO 输入支持(GPIO_KEY) ........................... 30 增加PWM支持 ............................................................ 34 增加i.MX6UL 本身ADC 支持 ....................................... 38 修改网口驱动仅支持一个网口 ...................................... 41 增加NXP PCF8591 I2C 转ADC 芯片支持 ................... 44 增加NXP PCA9555A I2C 转GPIO 芯片支持(rework 支持) 47 增加NXP PCT2075 I2C 温度传感器芯片支持(rework 支持) 55 增加NXP PCF8563 I2C RTC 支持(rework 支持) ......... 58 增加NXP PCA9632 I2C LED控制器芯片支持(rework 支持) 65 增加CH438 EIM 转串口芯片支持(delay) ..................... 70
記事全体を表示
platform: imx8qxp c0 mek OS: yocto 4.19.35_1.1.0 hardware connection: imx8qxp lvds0 => dummy panel ,  lvds1 => it6263 => display   On imx8qxp there are one DPU(display process unit) and one ISI(image subsystem interface), ISI supports input from dpu.   dpu block diagram: note that only dsi0 and lvds0 can be used for loopback. and this patch only test the lvds0, since lvds support dummy panel.   Please see the readme in the attchment for how to enale this feature.   Note: for ISI loopback,  it needs output of 2x GPIO (4x for HDMI-TX or combo PHY) to pixel_link_receiver_address: For iMX8QM: o LVDS: pixel_link_receiver_address[1:0] = do_gpio_dr[7:6]  o MIPI-DSI: pixel_link_receiver_address[1:0] = do_gpio_dr[7:6] o HDMI-TX: odd_pixel_link_receiver_address[1:0] = do_gpio_dr[7:6],even_pixel_link_receiver_address[1:0] = do_gpio_dr[5:4]   For iMX8QXP: o Combo MIPI-DSI / LVDS: pixel_link0_receiver_address[1:0] = do_gpio_dr[7:6], pixel_link1_receiver_address[1:0] = do_gpio_dr[5:4]   
記事全体を表示
On the build folder, type bitbake -g <image> && cat pn-depends.dot | grep -v -e '-native' | grep -v digraph | grep -v -e '-image' | awk '{print $1}' | sort | uniq where <image> is the image name (e.g. core-image-minimal). In case you want to know if a certain <package> is included on an image, just grep the output bitbake -g <image> && cat pn-depends.dot | grep -v -e '-native' | grep -v digraph | grep -v -e '-image' | awk '{print $1}' | sort | uniq | grep <package>
記事全体を表示
i.MX6UL OBDS test image
記事全体を表示