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

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

i.MX Processors Knowledge Base

ディスカッション

ソート順:
The following steps allow to make use of device tree overlay files, a definition of device tree overlay provided by kernel.org is the next:  "A Devicetree’s overlay purpose is to modify the kernel’s live tree, and have the modification affecting the state of the kernel in a way that is reflecting the changes. Since the kernel mainly deals with devices, any new device node that result in an active device should have it created while if the device node is either disabled or removed all together, the affected device should be deregistered." Knowing that, in this post will be used as an example the baseboard "i.MX 93 EVK" and will be added with device tree overlay an LVDS panel, adding an automatic detection from u-boot, and will be used a host with linux version Ubuntu 20.04.2. Note: It only works for linux kernel version 6.6.3-nanbield onward. Linux device-tree overlay from linux-imx   This section explains all about device tree overlay compilation and building, to create a .dtso file, the equivalent of .dts for overlays, adding some difference between them, using as base the linux-imx repository. It can be downloaded from the following repository:   git clone https://github.com/nxp-imx/linux-imx.git -b <branch version>   Branch version used by this post "lf-6.6.3-1.0.0". Device tree source overlay (.dtso)    It can be similar to a device tree source (.dts) but it had little difference between them, there are some difference in the next list: There's another type of files to be included, if is used pinmux it's necessary adding it with "#include "imx93-pinfunc.h"" and libraries from dt-bindings, it depends on the type of device tree to implement "#include <dt-bindings/<library>>" At initialization it needs to add: "/dts-v1/;"  "/plugin/;" Addition of "fragment" nodes, it allow override parts of a device tree,  it can be a specific node or create a new node. following structure it's the structure of a fragment:   { /* ignored properties by the overlay */ fragment@0 { /* first child node */ target=<phandle>; /* phandle target of the overlay */ or target-path="/path"; /* target path of the overlay */ __overlay__ { property-a; /* add property-a to the target */ node-a { /* add to an existing, or create a node-a */ ... }; }; } fragment@1 { /* second child node */ ... }; /* more fragments follow */ }   kernel.org Overlays can't delete a property or a node when it's applied, so can't be used "/delete-node/" nor "/delete-prop/", but it can be added to the node "status = "disabled";" to disable it.  Using as an example the file imx93-11x11-evk-boe-wxga-lvds-panel.dts located in the previous repository file direction <linux-imx path>/arch/arm64/boot/dts/freescale/ using it as a base tree:   // SPDX-License-Identifier: (GPL-2.0+ OR MIT) /* * Copyright 2022 NXP */ #include "imx93-11x11-evk.dts" / { lvds_backlight: lvds_backlight { compatible = "pwm-backlight"; pwms = <&adp5585pwm 0 100000 0>; enable-gpios = <&adp5585gpio 8 GPIO_ACTIVE_HIGH>; power-supply = <&reg_vdd_12v>; status = "okay"; brightness-levels = < 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100>; default-brightness-level = <80>; }; ... }; ... &adv7535 { status = "disabled"; }; ...   imx93-11x11-evk-boe-wxga-lvds-panel.dts Using the previous points and making use of fragments, if we want adapt the node lvds_backlight as fragment, it will be  added in the section of overlay, and adding it to a target-path "/":   #include <dt-bindings/interrupt-controller/irq.h> #include "imx93-pinfunc.h" #include <dt-bindings/gpio/gpio.h> /dts-v1/; /plugin/; / { fragment@0 { target-path = "/"; __overlay__ { lvds_backlight: lvds_backlight { compatible = "pwm-backlight"; pwms = <&adp5585pwm 0 100000 0>; enable-gpios = <&adp5585gpio 8 GPIO_ACTIVE_HIGH>; power-supply = <&reg_vdd_12v>; status = "okay"; brightness-levels = < 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100>; default-brightness-level = <80>; }; }; }; ... };   imx93-11x11-evk-test-lvds-panel.dtso In the case of adding a property to an existing node, it will look in the following way using as example the node adv7535.   ... / { ... fragment@2 { target = <&adv7535>; __overlay__ { status = "disabled"; }; }; ... };   imx93-11x11-evk-boe-wxga-lvds-panel.dts At the end of this post, will be attach the complete file used for LVDS panel named as imx93-11x11-evk-test-lvds-panel.dtso Build device tree blob for overlay (dtbo)   To compile the previous .dtso it's necessary to include it to linux-imx repository, linux device tree overlay was included in BSP from version 6.6.3-nanbield onward in Makefile, so it's only necessary adding it as files to be compiled as .dtso, at the end of the post will be a patch file named as linux-imx-makefile.patch to add LVDS-panel to Makefile from branch lf-6.6.3-1.0.0 Add previously file imx93-11x11-evk-test-lvds-panel.dtso to path <linux-imx path>/arch/arm64/boot/dts/freescale/ Add imx93-11x11-evk-test-lvds-panel.dtso as file to be compiled in Makefile, it is located in the next path <linux-imx path>/arch/arm64/boot/dts/freescale/Makefile, it can be added with the next sentence format: <overlay without extension>-dtbs := <file to be overlayed>.dtb <overlay>.dtbo Example of how to add LVDS panel to makefile  imx93-11x11-evk-test-lvds-panel-dtbs := imx93-11x11-evk.dtb imx93-11x11-evk-test-lvds-panel.dtbo Makefile From main path, make the configuration to be compiled with the following bash command: $ cd <linux-imx path>/ $ make -j$(nproc --all) ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- imx_v8_defconfig​ Compile overlay to use $ make -j $(nproc --all) ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- freescale/<overlay>.dtbo​ as example for LVDS panel $ make -j $(nproc --all) ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- freescale/imx93-11x11-evk-test-lvds-panel.dtbo It will compile the device tree blob overlay to use. Copy .dtbo generated in memory used by i.MX 93, it can be sending it from scp. scp ./​<overlay>.dtbo​ root@<ip>:/run/media/<memory section used> u-boot   This section explain the procedure to load a device tree overlay, it will be from u-boot explaining commands used and using the LVDS panel as an example. Before applying overlay   Before applying, it's necessary had a device tree loaded so looking around in the process of booting in a i.MX 93 from u-boot, this process is defined by the enviroment variable "bsp_bootcmd" that calls the variable mmcboot, and looking what does these variables, it can be look in the following sentence:    bsp_bootcmd=echo Running BSP bootcmd ...; mmc dev ${mmcdev}; if mmc rescan; then if run loadbootscript; then run bootscript; else if test ${sec_boot} = yes; then if run loadcntr; then run mmcboot; else run netboot; fi; else if run loadimage; then run mmcboot; else run netboot; fi; fi; fi; fi; mmcboot=echo Booting from mmc ...; run mmcargs; if test ${sec_boot} = yes; then if run auth_os; then run boot_os; else echo ERR: failed to authenticate; fi; else if test ${boot_fit} = yes || test ${boot_fit} = try; then bootm ${loadaddr}; else if run loadfdt; then run boot_os; else echo WARN: Cannot load the DT; fi; fi;fi;   but reducing it in a normal situation, ignoring if else case and echoes, it can be simplify to:   mmc dev ${mmcdev}; run loadimage; run mmcargs; run loadfdt; run boot_os;   the device tree is load is in the section "run loadfdt" with fatload in his definition:   loadfdt=fatload mmc ${mmcdev}:${mmcpart} ${fdt_addr_r} ${fdtfile}   So, it's necessary to applying device tree overlay after "run loadfdt". How to apply an overlay   To load correctly an overlay it's necessary to following some steps: Load flattened device tree (fdt). (executed by loadfdt) Configure fdt address.  In some cases it's necessary to expand fdt memory size Load overlay Apply overlay The full sentence to apply it, it's the following u-boot command:   u-boot=> setexpr fdtovaddr ${fdt_addr} + 0xF0000; setexpr fdt_buffer 16384; fdt addr ${fdt_addr} && fdt resize ${fdt_buffer}; fatload mmc ${mmcdev}:${mmcpart} ${fdtovaddr} <overlay>.dtbo && fdt apply ${fdtovaddr};   First of all, setexpr it's just to create a new variable, in this case these variable is an integer. Spliting the previously command we can found the steps to applying it. "fdt addr ${fdt_addr};" used to configure fdt address, and point to the space of memory previously charged. "fdt resize ${fdt_buffer};" expand fdt memory size, is used as a value 16384 just to get the enough space to charge dtbo, this number was related with 2 14 "fatload mmc ${mmcdev}:${mmcpart} ${fdtovaddr} <overlay>.dtbo" Load device tree overlay using fdovaddr, that is fdt_addr adding an offset of memory space.  "fdt apply ${fdtovaddr};" apply device tree overlay Remembering about load overlay needs to be executed after loadfdt, it's possible to save the previous command to a variable and executing it after loadfdt with setexpr, in this case using as example lvds test.   u-boot=> setenv loadoverlay "setexpr fdtovaddr ${fdt_addr} + 0xF0000; setexpr fdt_buffer 16384; fdt addr $\{fdt_addr\} && fdt resize $\{fdt_buffer\}; fatload mmc $\{mmcdev\}:$\{mmcpart\} $\{fdtovaddr\} imx93-11x11-evk-test-lvds-panel.dtbo && fdt apply $\{fdtovaddr\};"   and modifying mmcboot with loadoverlay after loadfdt   u-boot=> setenv mmcboot "run mmcargs; run loadfdt; run loadoverlay; run boot_os;"   to save the environment variables created, it can be saved from u-boot wit the following command.   u-boot=> saveenv   At the end, boot imx93   u-boot=> boot   The LVDS panel should be working using the original dtb (imx93-11x11-evk.dtb) applied the overlay. Automatize u-boot LVDS Panel   This section explain how can be automatize the u-boot load overlay using an LVDS panel, it can vary depending the device to used for, the method used is detecting it in u-boot initialization and if found any device it will generate an environment variable. All the steps was using as a base uboot-imx repository, it can be downloaded from the following repository, at the end of this post will be a patch with the changes.   git clone https://github.com/nxp-imx/uboot-imx.git -b <branch version>   Branch version used "lf-6.6.3-1.0.0". Base   Knowing more about LVDS Panel used by imx93 it's really hard know more information about registers, so in this example will be limited to detect that is connected the address to a corresponding bus from touch controller.  To know i2c address and bus used by LVDS panel it was used searching it from the original device tree in the next section:   &lpi2c1 { exc80h60: touch@2a { compatible = "eeti,exc80h60"; reg = <0x2a>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_ctp_int>; /* * Need to do hardware rework here: * remove R131, short R181 */ interrupt-parent = <&gpio2>; interrupts = <21 IRQ_TYPE_LEVEL_LOW>; reset-gpios = <&pcal6524 17 GPIO_ACTIVE_HIGH>; status = "okay"; }; };   imx93-11x11-evk-boe-wxga-lvds-panel.dts Previous node is related with touch controller from LVDS using lpi2c1, the first channel of i2c corresponding to i2c bus 0, and the register used express the address used to be detected by device tree, in this case was the address 0x2A. u-boot generating a trigger   About how it can be detected touch controller from u-boot, this procedure use a function named as "board_late_init", it can be found by his definition from u-boot readme:   Board initialization settings: ------------------------------ During Initialization u-boot calls a number of board specific functions to allow the preparation of board specific prerequisites, e.g. pin setup before drivers are initialized. To enable these callbacks the following configuration macros have to be defined. Currently this is architecture specific, so please check arch/your_architecture/lib/board.c typically in board_init_f() and board_init_r(). - CONFIG_BOARD_EARLY_INIT_F: Call board_early_init_f() - CONFIG_BOARD_EARLY_INIT_R: Call board_early_init_r() - CONFIG_BOARD_LATE_INIT: Call board_late_init()   u-boot README In the case of i.MX 93 this function can be found in the next path <u-boot path>/board/freescale/imx93_evk/imx93_evk.c. Using the library included, "uclass.h", it will create a function that, if detect in the bus 0 (LVDS i2c bus) the address 0x2A (i2c LVDS address), it will create an environment variable with the overlay used, it can be set with the function env_set(<String with the name of the variable>, <String with the content of the variable>), the following function can detect and create the environment variable mentioned, creating it with the name "device-tree-overlay" with the content "lvds-panel".   #define LVDS_TOUCH_I2C_BUS 0 #define LVDS_TOUCH_I2C_ADDR 0x2A static void detect_display_connected(void) { struct udevice *bus = NULL; struct udevice *i2c_dev = NULL; int ret; ret = uclass_get_device_by_seq(UCLASS_I2C, LVDS_TOUCH_I2C_BUS, &bus); if (ret) { printf("%s: Can't find bus\n", __func__); } else { ret = dm_i2c_probe(bus, LVDS_TOUCH_I2C_ADDR, 0, &i2c_dev); if (ret) { printf("%s: Can't find device id=0x%x\n", __func__, LVDS_TOUCH_I2C_ADDR); } else { env_set("device-tree-overlay", "lvds-panel"); } } }   imx93_evk.c At the end, add this function to the previously mention, named as board_late_init, in the section CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG, like the following snipped from code:   int board_late_init(void) { #ifdef CONFIG_ENV_IS_IN_MMC board_late_mmc_env_init(); #endif env_set("sec_boot", "no"); #ifdef CONFIG_AHAB_BOOT env_set("sec_boot", "yes"); #endif #ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG env_set("board_name", "11X11_EVK"); env_set("board_rev", "iMX93"); detect_display_connected(); #endif return 0; }   imx93_evk.c Now, when it's starting u-boot after flashing, it will generate the environment variable as trigger if something it's connected with that i2c address, else it doesn't do anything. u-boot applying device tree overlay through event   As was explained in the section "How to apply device tree overlay", applying the device tree overlay automatically after configure the trigger it's easy, just adding an if/else case for this example, it can be more ways to applying it, even it's possible adding more of one device tree overlay, but in this example will load one.  Using u-boot command "test -e <environment variable>" it will detect if exist this environment variable, adding it to an if/else sentence it can create the event and applying the overlay if was detected or not, for this solution will be added this if/else as input if exists loadoverlay variable with the following structure:   u-boot=> if test -e ${device-tree-overlay}; then <case exists device-tree-overlay variable> else <case doesn't exists device-tree-overlay variable>; fi;   adding it to loadoverlay, it will be written like the following command:   u-boot=> setenv loadoverlay "if test -e ${device-tree-overlay}; then setexpr fdtovaddr ${fdt_addr} + 0xF0000; setexpr fdt_buffer 16384; fdt addr ${fdt_addr} && fdt resize $\{fdt_buffer\}; fatload mmc ${mmcdev}:${mmcpart} $\{fdtovaddr\} imx93-11x11-evk-test-lvds-panel.dtbo; fdt apply $\{fdtovaddr\} ; else echo no overlay; fi;"   A no recommended method it's that it can be saved the environment, and changing mmcboot variable with the following command:   u-boot=> setenv mmcboot "run mmcargs; run loadfdt; run loadoverlay; run boot_os;"; saveenv;   The problem about just saving it, it still necessary compile u-boot to load auto-detection of LVDS panel and flashing, another way to add the event trigger, it's adding it to u-boot as initial environment variable, it can be added in the header file of imx93, it is located in the next path <u-boot path>/include/configs/imx93_evk.h, line number 60, it can be added with the same string but it's recommended follow the same structure, like the following definition:   /* Initial environment variables */ #define CFG_EXTRA_ENV_SETTINGS \ ... "loadoverlay=echo loading overlays from mmc ...; " \ "if test -e ${device-tree-overlay}; then " \ "setexpr fdtovaddr ${fdt_addr} + 0xF0000; " \ "setexpr fdt_buffer 16384; " \ "fdt addr ${fdt_addr} && fdt resize ${fdt_buffer}; " \ "fatload mmc ${mmcdev}:${mmcpart} ${fdtovaddr} imx93-11x11-evk-test-lvds-panel.dtbo && fdt apply ${fdtovaddr}; " \ "else " \ "echo no overlay; " \ "fi;\0" \ ...   imx93_evk.h it also it's necessary to change mmcboot environment variable adding loadoverlay after executing loadfdt.    /* Initial environment variables */ #define CFG_EXTRA_ENV_SETTINGS \ .. "mmcboot=echo Booting from mmc ...; " \ "run mmcargs; " \ "if test ${sec_boot} = yes; then " \ "if run auth_os; then " \ "run run boot_os; " \ "else " \ "echo ERR: failed to authenticate; " \ "fi; " \ "else " \ "if test ${boot_fit} = yes || test ${boot_fit} = try; then " \ "bootm ${loadaddr}; " \ "else " \ "if run loadfdt; then " \ "run loadoverlay; " \ "run boot_os; " \ "else " \ "echo WARN: Cannot load the DT; " \ "fi; " \ "fi;" \ "fi;\0" \ ...   imx93_evk.h To build u-boot, copy the following commands in main path from u-boot   $ cd <u-boot path> $ make -j $(nproc --all) clean PLAT=imx93 CROSS_COMPILE=aarch64-linux-gnu- $ make -j $(nproc --all) ARCH=arm CROSS_COMPILE=aarch64-linux-gnu- imx93_11x11_evk_defconfig $ make -j $(nproc --all) PLAT=imx93 CROSS_COMPILE=aarch64-linux-gnu-   generating the files u-boot.bin and u-boot-spl.bin located in <uboot-imx path>/ and <uboot-imx path>/spl Build imx-boot image using imx-mkimage   To build the binary necessary to flash to iMX 93 EVK it's necessary build a file named as flash.bin, it can building using the next repository using the branch used for this example:    $ git clone https://github.com/nxp-imx/imx-mkimage.git -b lf-6.6.3_1.0.0   to build imx-boot image it's necessary adding some files to the path <imx-mkimage path>/iMX93, including 2 generated by u-boot, u-boot.bin and u-boot-spl.bin, move these files to iMX93 directory.   $ cp <uboot-imx path>/u-boot.bin <uboot-imx path>/spl/u-boot-spl.bin <imx-mkimage path>/iMX93/   follow the steps from imx linux users guide section 4.5.13 and imx linux release notes section 1.2 to build flash.bin, as an example of compile, there's the steps to compile for imx93. Get mx93a1-ahab-container.img $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-sentinel-0.11.bin $ chmod +x firmware-sentinel-0.11.bin $ ./firmware-sentinel-0.11.bin $ cp firmware-sentinel-0.11/mx93a1-ahab-container.img <imx-mkimage path>/iMX93/​ Get lpddr4_imem_1d_v202201.bin, lpddr4_dmem_2d_v202201.bin, lpddr4_imem_1d_v202201.bin and lpddr4_imem_2d_v202201.bin $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.23.bin $ chmod +x firmware-imx-8.23.bin $ ./firmware-imx-8.23.bin $ cp firmware-imx-8.23/firmware/ddr/synopsys/lpddr4_dmem_1d_v202201.bin firmware-imx-8.23/firmware/ddr/synopsys/lpddr4_dmem_2d_v202201.bin firmware-imx-8.23/firmware/ddr/synopsys/lpddr4_imem_1d_v202201.bin firmware-imx-8.23/firmware/ddr/synopsys/lpddr4_imem_2d_v202201.bin <imx-mkimage path>/iMX93/​ Get bl31.bin $ git clone https://github.com/nxp-imx/imx-atf.git -b lf-6.6.3-1.0.0 $ cd imx-atf $ make -j $(nproc --all) PLAT=imx93 CROSS_COMPILE=aarch64-linux-gnu- $ cp <imx-atf path>/build/imx93/release/bl31.bin <imx-mkimage path>/iMX93​ Compile flash.bin from imx-mkimage $ cd <imx-mkimage path>/ $ make SOC=iMX9 REV=A1 flash_singleboot​ it will generate the binary flash.bin located in the path <imx-mkimage path>/iMX93/flash.bin. Flashing u-boot   Flashing just u-boot image using flash.bin, will be used uuu.exe, it can be downloaded from the his repositroy, try using the most recent version taged as "Latest"    https://github.com/nxp-imx/mfgtools/releases   make sure is using i.MX 93 EVK in boot mode download and connect it to your host from download USB port, using uuu.exe run the next code:   .\uuu.exe -b emmc .\flash.bin   or it can be flashed the full image with flash.bin binary.   .\uuu.exe -b emmc_all .\flash.bin ..\uuu\imx-image-full-imx93evk.wic   after that, starting be will using the created u-boot environment. Result   Inside u-boot, when it's connected the LVDS panel, it will create the variable named "device-tree-overlay" and will be charged automatically LVDS panel overlay, enabling it, if not it will working normally using DSI as output. Note: Ensure to have imx93-11x11-evk-test-lvds-panel.dtbo in memory. Reference   Device tree overlay: https://docs.kernel.org/devicetree/overlay-notes.html  
記事全体を表示
On this tutorial we will review the implementation of Flutter on the i.MX8MP using the Linux Desktop Image. Please find more information about Flutter using the following link: Flutter: Option to create GUIs for Embedded System... - NXP Community Requirements: Evaluation Kit for the i.MX 8M Plus Applications Processor. (i.MX 8M Plus Evaluation Kit | NXP Semiconductors) NXP Desktop Image for i.MX 8M Plus (GitHub - nxp-imx/meta-nxp-desktop at lf-6.1.1-1.0.0-langdale) Note: This tutorial is based on the NXP Desktop Image with Yocto version 6.1.1 – Langdale. Steps: 1. First, run commands to update packages. $ sudo apt update $ sudo apt upgrade 2. Install Flutter for Linux using the following command. $ sudo snap install flutter --classic 3. Run the command to verify the correct installation. $ flutter doctor With this command you will find information about the installation. The important part for our purpose is the parameter "Linux toolchain - develop for Linux desktop". 4. Run the command “flutter create .” to create a flutter project, this framework will create different folders and files used to develop the application.  $ cd Documents $ mkdir flutter_hello $ cd flutter_hello $ flutter create .​ 5. Finally, you can run the “hello world” application using: $ flutter run Verify the program behavior incrementing the number displayed on the window.  
記事全体を表示
This article is now outdated - SCFW 1.16.0 fixes this issue and has now been released. All customers who are experiencing stability issues with the processors outlined below should update to SCFW >1.16.0. ------------------------------------------------------------------------------------------------------------------------------------- The i.MX 8QM and i.MX 8QP has been revised with lower clock speeds and higher core voltages to help improve instability issues found with the part. Old parts that have not been derated have an "FF" moniker in the part number, whereas new parts, releasing in June 2024, have an "FE" moniker. An example can be found below. SCFW (System Controller Firmware) 1.16.0, which will be released with the Q2 Linux Factory BSP (LF6.6.y_2.0.0), will make the necessary changes to increase core voltage for CPU and GPU cores in the 8QM/8QP, as well as reduce clock speeds. It may not be immediately apparent what changes must be made to derate these processors before the new parts and new SCFW version is released. To assist with these issues, we are providing the changes below as a workaround until SCFW 1.16.0 is released.     Recommended Changes until SCFW 1.16.0 is released 1. Increase voltages in pmic_init(). This function is found inside the respective board.c file within the SCFW porting kit. This is assuming that the customer has routed their VDD_A72 to PMIC_0 on SW3 and SW4, and routed their VDD_GPU0 and VDD_GPU1 to PMIC_1 on SW1 through SW4. +/* Set VDD_A72 to 1.1375V (1138mV) */ +BRD_ERR(PMIC_SET_VOLTAGE(PMIC_0_ADDR, PF8100_SW3, 1138, REG_RUN_MODE)) +BRD_ERR(PMIC_SET_VOLTAGE(PMIC_0_ADDR, PF8100_SW4, 1138, REG_RUN_MODE)) +/* Set VDD_GPU0 and VDD_GPU1 to 1.03125V (1032mV) */ +BRD_ERR(PMIC_SET_VOLTAGE(PMIC_1_ADDR, PF8100_SW1, 1032, REG_RUN_MODE)) +BRD_ERR(PMIC_SET_VOLTAGE(PMIC_1_ADDR, PF8100_SW2, 1032, REG_RUN_MODE)) +BRD_ERR(PMIC_SET_VOLTAGE(PMIC_1_ADDR, PF8100_SW3, 1032, REG_RUN_MODE)) +BRD_ERR(PMIC_SET_VOLTAGE(PMIC_1_ADDR, PF8100_SW4, 1032, REG_RUN_MODE))   2. Add +37.5mV offset for VDD_A72, +31.25mV offset for VDD_GPU0/VDD_GPU1. This is done in the function board_set_voltage, found in board.c of the respective processor in the SCFW porting kit. This ensures that voltages are set correctly if a frequency change occurs (like going from overdrive to nominal mode on GPU). /*--------------------------------------------------------------------------*/ /* Set the voltage for the given SS. */ /*--------------------------------------------------------------------------*/ sc_err_t board_set_voltage(sc_sub_t ss, uint32_t new_volt, uint32_t old_volt) { sc_err_t err = SC_ERR_NONE; pmic_id_t pmic_id[2] = {0U, 0U}; uint32_t pmic_reg[2] = {0U, 0U}; uint8_t num_regs = 0U; +// A72 cores are running on 1.1375V instead of 1.10V +if ((ss == SC_SUBSYS_A72) && (new_volt == 1100)) { +board_print(3, "Changing voltage from 1100 to 1138"); +new_volt = 1138; +} +// GPU is running on 1.03125V instead of 1.00V +if ((ss == SC_SUBSYS_GPU_0 || SC_SUBSYS_GPU_1) && (new_volt == 1000)) { +board_print(3, "Changing voltage from 1000 to 1032"); +new_volt = 1032; +} board_print(3, "board_set_voltage(%s, %u, %u)\n", snames[ss], new_volt, old_volt); board_get_pmic_info(ss, pmic_id, pmic_reg, &num_regs);   3. Remove 1.6GHz from Linux DTS OPP Table for A72 core. This is found in the device tree of the board. These are typically found in /arch/arm64/boot/dts/freescale/. /* opp-1596000000 { opp-hz = /bits/ 64 <1596000000>; opp-microvolt = <1100000>; clock-latency-ns = <150000>; opp-suspend; }; */ 4. Disable GPU overdrive mode - set to nominal mode using sysfs in Linux userland echo "nominal" > /sys/bus/platform/drivers/galcore/gpu_govern
記事全体を表示
The HSM Coding-Signing is new. When we follow the instructions in Code-Signing Tool User’s Guide , still has something to overcome, most of them are related to the OS. Actually, Code-Signing Tool User’s Guide  can not give detail every “obvious” step. The purpose of this document is to share the experiences on my system. Hope those experience can give you some clues on your system.     25JUL2024 - add pkcs11 proxy                         HSM Code-Signing Journey_25JUL2024.pdf                          HSM Code-Signing Journey_25JUL2024.txt  
記事全体を表示
  Just sharing some experiences during the development and studying.   Although, it appears some hardwares, it focuses on software to speed up your developing on your  hardware.     杂记共享一下在开发和学习过程中的经验。    虽然涉及一些硬件,但其本身关注软件,希望这些能加速您在自己硬件上的开发。 07/25/2024 iMX secondary boot collection https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/iMX-secondary-boot-collection/ta-p/1916915   07/25/2024 HSM Code-Signing Journey https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/HSM-Code-Signing-Journey/ta-p/1882244 25JUL2024 - add pkcs11 proxy                         HSM Code-Signing Journey_25JUL2024.pdf                          HSM Code-Signing Journey_25JUL2024.txt   06/06/2024 HSM Code-Signing Journey https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/HSM-Code-Signing-Journey/ta-p/1882244     02/07/2024 Device Tree Standalone Compile under Windows https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/Device-Tree-Standalone-Compile-under-Windows/ta-p/1855271   02/07/2024 i.MX8X security overview and AHAB deep dive i.MX8X security overview and AHAB deep dive - NXP Community   11/23/2023 “Standalone” Compile Device Tree https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/Standalone-Compile-Device-Tree/ta-p/1762373     10/26/2023 Linux Dynamic Debug https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/Linux-Dynamic-Debug/ta-p/1746611   08/10/2023 u-boot environment preset for sdcard mirror u-boot environment preset for sdcard mirror - NXP Community   06/06/2023 all(bootloader, device tree, Linux kernel, rootfs) in spi nor demo imx8qxpc0 mek all(bootloader, device tree, Linux kernel, rootfs)... - NXP Community     09/26/2022 parseIVT - a script to help i.MX6 Code Signing parseIVT - a script to help i.MX6 Code Signing - NXP Community   Provide  run under windows   09/16/2022   create sdcard mirror under windows create sdcard mirror under windows - NXP Community     08/03/2022   i.MX8MM SDCARD Secondary Boot Demo https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8MM-SDCARD-Secondary-Boot-Demo/ta-p/1500011     02/16/2022 mx8_ddr_stress_test without UI   https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/mx8-ddr-stress-test-without-UI/ta-p/1414090   12/23/2021 i.MX8 i.MX8X Board Reset https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8-i-MX8X-Board-Reset/ta-p/1391130       12/21/2021 regulator userspace-consumer https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/regulator-userspace-consumer/ta-p/1389948     11/24/2021 crypto af_alg blackkey demo crypto af_alg blackkey demo - NXP Community   09/28/2021 u-boot runtime modify Linux device tree(dtb) u-boot runtime modify Linux device tree(dtb) - NXP Community     08/17/2021 gpio-poweroff demo https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/gpio-poweroff-demo/ta-p/1324306         08/04/2021 How to use gpio-hog demo https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/How-to-use-gpio-hog-demo/ta-p/1317709       07/14/2021 SWUpdate OTA i.MX8MM EVK / i.MX8QXP MEK https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/SWUpdate-OTA-i-MX8MM-EVK-i-MX8QXP-MEK/ta-p/1307416     04/07/2021 i.MX8QXP eMMC Secondary Boot https://community.nxp.com/t5/i-MX-Community-Articles/i-MX8QXP-eMMC-Secondary-Boot/ba-p/1257704#M45       03/25/2021 sc_misc_board_ioctl to access the M4 partition from A core side sc_misc_board_ioctl to access the M4 partition fr... - NXP Community     03/17/2021 How to Changei.MX8X MEK+Base Board  Linux Debug UART https://community.nxp.com/t5/i-MX-Community-Articles/How-to-Change-i-MX8X-MEK-Base-Board-Linux-Debug-UART/ba-p/1246779#M43     03/16/2021 How to Change i.MX8MM evk Linux Debug UART https://community.nxp.com/t5/i-MX-Community-Articles/How-to-Change-i-MX8MM-evk-Linux-Debug-UART/ba-p/1243938#M40       05/06/2020 Linux fw_printenv fw_setenv to access U-Boot's environment variables Linux fw_printenv fw_setenv to access U-Boot's env... - NXP Community     03/30/2020 i.MX6 DDR calibration/stress for Mass Production https://community.nxp.com/docs/DOC-346065     03/25/2020 parseIVT - a script to help i.MX6 Code Signing https://community.nxp.com/docs/DOC-345998     02/17/2020 Start your machine learning journey from tensorflow playground Start your machine learning journey from tensorflow playground      01/15/2020 How to add  iMX8QXP PAD(GPIO) Wakeup How to add iMX8QXP PAD(GPIO) Wakeup    01/09/2020 Understand iMX8QX Hardware Partitioning By Making M4 Hello world Running Correctly https://community.nxp.com/docs/DOC-345359   09/29/2019 Docker On i.MX6UL With Ubuntu16.04 https://community.nxp.com/docs/DOC-344462   09/25/2019 Docker On i.MX8MM With Ubuntu https://community.nxp.com/docs/DOC-344473 Docker On i.MX8QXP With Ubuntu https://community.nxp.com/docs/DOC-344474     08/28/2019 eMMC5.0 vs eMMC5.1 https://community.nxp.com/docs/DOC-344265     05/24/2019 How to upgrade  Linux Kernel and dtb on eMMC without UUU How to upgrade Linux Kernel and dtb on eMMC without UUU     04/12/2019 eMMC RPMB Enhance and GP https://community.nxp.com/docs/DOC-343116   04/04/2019 How to Dump a GPT SDCard Mirror(Android O SDCard Mirror) https://community.nxp.com/docs/DOC-343079   04/04/2019 i.MX Create Android SDCard Mirror https://community.nxp.com/docs/DOC-343078   04/02/2019: i.MX Linux Binary_Demo Files Tips  https://community.nxp.com/docs/DOC-343075   04/02/2019:       Update Set fast boot        eMMC_RPMB_Enhance_and_GP.pdf   02/28/2019: imx_builder --- standalone build without Yocto https://community.nxp.com/docs/DOC-342702   08/10/2018: i.MX6SX M4 MPU Settings For RPMSG update    Update slide CMA Arrangement Consideration i.MX6SX_M4_MPU_Settings_For_RPMSG_08102018.pdf   07/26/2018 Understand ML With Simplest Code https://community.nxp.com/docs/DOC-341099     04/23/2018:     i.MX8M Standalone Build     i.MX8M Standalone Build.pdf     04/13/2018:      i.MX6SX M4 MPU Settings For RPMSG  update            Add slide CMA Arrangement  Consideration     i.MX6SX_M4_MPU_Settings_For_RPMSG_04132018.pdf   09/05/2017:       Update eMMC RPMB, Enhance  and GP       eMMC_RPMB_Enhance_and_GP.pdf 09/01/2017:       eMMC RPMB, Enhance  and GP       eMMC_RPMB_Enhance_and_GP.pdf 08/30/2017:     Dual LVDS for High Resolution Display(For i.MX6DQ/DLS)     Dual LVDS for High Resolution Display.pdf 08/27/2017:  L3.14.28 Ottbox Porting Notes:         L3.14.28_Ottbox_Porting_Notes-20150805-2.pdf MFGTool Uboot Share With the Normal Run One:        MFGTool_Uboot_share_with_NormalRun_sourceCode.pdf Mass Production with programmer        Mass_Production_with_NAND_programmer.pdf        Mass_Production_with_emmc_programmer.pdf AndroidSDCARDMirrorCreator https://community.nxp.com/docs/DOC-329596 L3.10.53 PianoPI Porting Note        L3.10.53_PianoPI_PortingNote_151102.pdf Audio Codec WM8960 Porting L3.10.53 PianoPI        AudioCodec_WM8960_Porting_L3.10.53_PianoPI_151012.pdf TouchScreen PianoPI Porting Note         TouchScreen_PianoPI_PortingNote_151103.pdf Accessing GPIO From UserSpace        Accessing_GPIO_From_UserSpace.pdf        https://community.nxp.com/docs/DOC-343344 FreeRTOS for i.MX6SX        FreeRTOS for i.MX6SX.pdf i.MX6SX M4 fastup        i.MX6SX M4 fastup.pdf i.MX6 SDCARD Secondary Boot Demo        i.MX6_SDCARD_Secondary_Boot_Demo.pdf i.MX6SX M4 MPU Settings For RPMSG        i.MX6SX_M4_MPU_Settings_For_RPMSG_10082016.pdf Security        Security03172017.pdf    NOT related to i.MX, only a short memo
記事全体を表示
i.MX93 eMMC Secondary Boot          i.MX93 eMMC Secondary Boot.zip   i.MX8MP eMMC Secondary Boot           i.MX8MP eMMC Secondary Boot.zip i.MX8MM SDCARD Secondary Boot Demo https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8MM-SDCARD-Secondary-Boot-Demo/ta-p/1500011   i.MX8QXP eMMC Secondary Boot https://community.nxp.com/t5/i-MX-Community-Articles/i-MX8QXP-eMMC-Secondary-Boot/ba-p/1257704#M45    i.MX6 SDCARD Secondary Boot Demo           i.MX6_SDCARD_Secondary_Boot_Demo.pdf      
記事全体を表示
  Test environment   i.MX8MP EVK LVDS0 LVDS-HDMI  bridge(it6263) Uboot2022, Uboot2023 Background   Some customers need show logo using LVDS panel. Current BSP doesn't support LVDS driver in Uboot. This patch provides i.MX8MPlus LVDS driver support in Uboot. If you want to connect it to LVDS panel , you need port your lvds panel driver like  simple-panel.c   Update [2022.9.19] Verify on L5.15.32_2.0.0  0001-L5.15.32-Add-i.MX8MP-LVDS-driver-in-uboot 'probe device is failed, ret -2, probe video device failed, ret -19' is caused by below code. It has been merged in attachment. // /* Only handle devices that have a valid ofnode */ // if (dev_has_ofnode(dev) && !(dev->driver->flags & DM_FLAG_IGNORE_DEFAULT_CLKS)) { // /* // * Process 'assigned-{clocks/clock-parents/clock-rates}' // * properties // */ // ret = clk_set_defaults(dev, CLK_DEFAULTS_PRE); // if (ret) // goto fail; // }   [2023.3.14] Verify on L5.15.71 0001-L5.15.71-Add-i.MX8MP-LVDS-support-in-uboot   [2023.9.12] For some panel with low DE, you need uncomment CTRL_INV_DE line and set this bit to 1. #include <linux/string.h> @@ -110,9 +111,8 @@ static void lcdifv3_set_mode(struct lcdifv3_priv *priv, writel(CTRL_INV_HS, (ulong)(priv->reg_base + LCDIFV3_CTRL_SET)); /* SEC MIPI DSI specific */ - writel(CTRL_INV_PXCK, (ulong)(priv->reg_base + LCDIFV3_CTRL_CLR)); - writel(CTRL_INV_DE, (ulong)(priv->reg_base + LCDIFV3_CTRL_CLR)); - + //writel(CTRL_INV_PXCK, (ulong)(priv->reg_base + LCDIFV3_CTRL_CLR)); + //writel(CTRL_INV_DE, (ulong)(priv->reg_base + LCDIFV3_CTRL_CLR)); }       [2024.5.15] If you are uing simple-panel.c, need use below patch to set display timing from panel to lcdif controller. diff --git a/drivers/video/simple_panel.c b/drivers/video/simple_panel.c index f9281d5e83..692c96dcaa 100644 --- a/drivers/video/simple_panel.c +++ b/drivers/video/simple_panel.c @@ -18,12 +18,27 @@ struct simple_panel_priv { struct gpio_desc enable; }; +/* define your panel timing here and + * copy it in simple_panel_get_display_timing */ +static const struct display_timing boe_ev121wxm_n10_1850_timing = { + .pixelclock.typ = 71143000, + .hactive.typ = 1280, + .hfront_porch.typ = 32, + .hback_porch.typ = 80, + .hsync_len.typ = 48, + .vactive.typ = 800, + .vfront_porch.typ = 6, + .vback_porch.typ = 14, + .vsync_len.typ = 3, +}; + @@ -100,10 +121,18 @@ static int simple_panel_probe(struct udevice *dev) return 0; } +static int simple_panel_get_display_timing(struct udevice *dev, + struct display_timing *timings) +{ + memcpy(timings, &boe_ev121wxm_n10_1850_timing, sizeof(*timings)); + + return 0; +} static const struct panel_ops simple_panel_ops = { .enable_backlight = simple_panel_enable_backlight, .set_backlight = simple_panel_set_backlight, + .get_display_timing = simple_panel_get_display_timing, }; static const struct udevice_id simple_panel_ids[] = { @@ -115,6 +144,7 @@ static const struct udevice_id simple_panel_ids[] = { { .compatible = "lg,lb070wv8" }, { .compatible = "sharp,lq123p1jx31" }, { .compatible = "boe,nv101wxmn51" }, + { .compatible = "boe,ev121wxm-n10-1850" }, { } };   [2024.7.23] Update patch for L6.6.23(Uboot2023)
記事全体を表示
The purpose of this document is to provide supportive information for selection of suitable LPDDR4, DDR4 and DDR3L devices that are supported by i.MX 8M family of processors to aid project feasibility assessment capabilities of customers that are evaluating the SoCs for usage in their products.  It is strongly recommended to consult with NXP and the memory vendor the final choice of the memory part number to ensure that the device meets all the compatibility, availability, longevity and pricing requirements. Please note that some of the LPDDR4 devices may not support operation at low speeds and in addition, DQ ODT may not be active, which can impact signal integrity at these speeds. If low speed operation is planned in the use case, please consult with the memory vendor the configuration aspects and possible customization of the memory device so correct functionality is ensured. In all cases, it is strongly recommended to follow the DRAM layout guidelines outlined in the NXP Hardware Developer's Guides for the specific SoCs available on NXP.com For any questions related to specific DRAM part numbers please contact the respective DRAM vendor. For any questions regarding the i.MX SoC please contact your support representative or enter a support ticket.  LPDDR4 - maximum supported densities Please note that the SoCs only support memory devices that support either the LPDDR4 mode or support both LPDDR4 and LPDDR4X modes. Memory devices that support only the LPDDR4X mode are not supported. SoC Max data bus width Maximum density Assumed memory organization Notes i.MX 8M Quad 32-bit 32Gb/4GB dual rank, dual-channel  device with 16-row addresses (R0-R15) 1, 2, 4 i.MX 8M Mini  32-bit 64Gb/8GB dual rank, dual-channel  device with 17-row addresses (R0-R16) 1, 2 i.MX 8M Nano  16-bit 32Gb/4GB dual rank, single-channel  device with 17-row addresses (R0-R16) 1, 2, 3, 12 i.MX 8M Plus  32-bit 64Gb/8GB dual rank, dual-channel  device with 17-row addresses (R0-R16)  1, 2   LPDDR4 - list of validated memories The validation process is an ongoing effort - regular updates of the table are expected. SoC Density Validated part number (vendor) Notes i.MX 8M Quad  24Gb/3GB MT53B768M32D4NQ-062 WT:B (Micron) 15 32Gb/4GB MT53D1024M32D4DT-046 AAT:D (Micron) 14 4Gb/512MB IS43LQ16256B-062BLI (ISSI) 5, 14 8Gb/1GB IS43LQ32256B-062BLI (ISSI) 5, 14 i.MX 8M Mini 16Gb/2GB MT53D512M32D2DS-053 WT:D (Micron) 15 16Gb/2GB M56Z16G32512A (ESMT) 5, 14 32Gb/4GB MT53E1G32D2FW-046 WT:A (Micron) 5, 14 64Gb/8GB MT53E2G32D4DT-046 AIT:A (Micron) 5, 14 i.MX 8M Nano  16Gb/2GB C1612PC2WDGTKR-U (Kingston) 15 32Gb/4GB MT53E2G32D4DT-046 AIT:A (Micron) 5, 13, 15 8Gb/1GB MT53D512M32D2DS-053 WT:D (Micron) 13, 15 i.MX 8M Plus 48Gb/6GB MT53E1536M32D4DT-046 WT:A (Micron) 15 64Gb/8GB MT53E2G32D4DE-046 AUT:C (Micron) 5, 14   LPDDR4 - list of incompatible devices Given the limitations mentioned in this document, the following memory devices were identified as incompatible with the particular SoCs as detailed in the following table:   Memory vendor Part Number Density Incompatible SoCs Incompatibility reason Samsung K4FHE3S4HA-KU(H/F)CL 24Gb/3Gb i.MX 8M Quad  The memory device requires 17th row address bit to function. Samsung K4UHE3S4AA-KU(H/F)CL 24Gb/3Gb i.MX 8M Quad i.MX 8M Mini i.MX 8M Nano i.MX 8M Plus The memory device only supports the LPDDR4X mode. Samsung K4UJE3D4AA-KU(H/F)CL 48Gb/6GB i.MX 8M Quad i.MX 8M Mini i.MX 8M Nano i.MX 8M Plus The memory device only supports the LPDDR4X mode. Samsung K4FCE3Q4HB-KU(H/F)CL 64Gb/8GB i.MX 8M Quad i.MX 8M Mini i.MX 8M Nano i.MX 8M Plus A byte mode memory device. Samsung K4UCE3Q4AB-KU(H/F)CL 64Gb/8GB i.MX 8M Quad i.MX 8M Mini i.MX 8M Nano i.MX 8M Plus A byte mode memory device. The memory device only supports the LPDDR4X mode.    DDR4 - maximum supported densities SoC Max data bus width Maximum density Assumed memory organization Notes i.MX 8M Quad  32-bit 32Gb/4GB x16, 16Gb device with 1 bank group address, 17-row addresses and 10 column addresses 1, 6 i.MX 8M Mini  32-bit 64Gb/8GB x16, 16Gb device with 1 bank group address, 17-row addresses and 10 column addresses 1, 7 i.MX 8M Nano  16-bit 64Gb/8GB x8, 16Gb device with 2 bank group addresses, 17-row addresses and 10 column addresses 1, 8 i.MX 8M Plus  32-bit 64Gb/8GB x16, 16Gb device with 1 bank group address, 17-row addresses and 10 column addresses 1, 7   DDR4 - list of validated memories The validation process is an ongoing effort - regular updates of the table are expected. SoC Density Validated part number (vendor) Notes i.MX 8M Quad 32Gb/4GB 4x MT40A512M16JY-083EAAT (Micron) 15 i.MX 8M Mini  16Gb/2GB 2x MT40A512M16LY-075:E (Micron) 15 i.MX 8M Nano 16Gb/2GB 1x MT40A1G16RC-062E:B (Micron) 15 i.MX 8M Plus 64Gb/8GB 4x MT40A1G16RC-062E:B (Micron) 15 16Gb/2GB NT5AD512M16C4-JRI (Nanya) 14   DDR3L - maximum supported densities SoC Max data bus width Maximum density Assumed memory organization Notes i.MX 8M Quad  32-bit 32Gb/4GB x16, 8Gb device with 16-row addresses and 10 column addresses 1, 9 i.MX 8M Mini  32-bit 64Gb/8GB x8, 8Gb device with 16-row addresses and 11 column addresses 1, 10 i.MX 8M Nano  16-bit 32Gb/4GB x8, 8Gb device with 16-row addresses and 11 column addresses 1, 11 i.MX 8M Plus  i.MX 8M Plus  does not support DDR3L   DDR3L - list of validated memories The validation process is an ongoing effort - regular updates of the table are expected. SoC Density Validated part number (vendor) Notes i.MX 8M Quad  16Gb/2GB 4x MT41K256M16TW-107 AAT (Micron) 14 i.MX 8M Mini  16Gb/2GB 4x MT41K256M16TW-107 AAT (Micron) 14   Note 1: The numbers are based purely on the IP vendor documentation for the DDR Controller and the DDR PHY, on the settings of the implementation parameters chosen for their integration into the SoC, and on the JEDEC standards JESD209-4/JESD209-4A (LPDDR4), JESD279-4/JESD279-4A (DDR4), and JESD79-3E/JESD79-3F/JESD79-3-1A (DDR3/DDR3L). Therefore, they are not backed by validation, unless said otherwise and there is no guarantee that an SoC with the specific density and/or desired internal organization is offered by the memory vendors. Should the customers choose to use the maximum density and assume it in the intended use case, they do it at their own risk. Note 2: Byte-mode LPDDR4 devices (x16 channel internally split between two dies, x8 each) of any density are not supported therefore, the numbers are applicable only to devices with x16 internal organization (referred to as "standard" in the JEDEC specification). Note 3: The memory vendors often do not offer so many variants of single-channel memory devices. As an alternative, a dual-channel device with only one channel connected may be used. For example: A dual-rank, single-channel device with 16-row address bits has a density of 16Gb. If such a device is not available at the chosen supplier, a dual-rank, dual-channel device with 16-row address bits can be used instead. This device has a density of 32 Gb however since only one channel can be connected to the SoC, only half of the density is available (16 Gb). Usage of more than one discrete memory chips to overcome market constraints is not supported since only point-to-point connections are assumed for LPDDR4. Note 4: Devices with 17-row addresses (R0-R16) are not supported by the DDR Controller Note 5: The memory part number did not undergo full JEDEC verification however, it passed all functional testing items. Note 6: The density can be achieved by connecting 2 single-rank discrete devices with one 16Gb die each. Since the SoC supports x8 devices and also has connectivity for a second rank, usage of more discrete devices is possible. However, this advantage cannot be used to get higher density since this SoC has only 32Gb/4GB of address space dedicated for the DDR. Two x16 16Gb devices giving 32Gb/4GB in total is, therefore, the optimal choice that balances the maximum density aspects, the signal integrity aspects (only two discrete devices used), and bandwidth aspects (full data bus width used). Note 7: The density can be achieved by connecting 4 single rank discrete devices with one 16Gb die each, 2 devices connected to each chip select. Since the SoC supports x8 devices, the usage of more discrete devices is possible. However, this advantage cannot be used to get higher density since this SoC has only 64Gb/8GB of address space dedicated for the DDR. Four x16 16Gb devices giving 64Gb/8GB in total is the optimal choice that balances the maximum density aspects, the signal integrity aspects (only four discrete devices used), and the bandwidth aspects (full data bus width used). Note 8: The density can be achieved by connecting 4 single rank discrete devices with one 16Gb die each, 2 devices connected to each chip select.  Note 9: The density can be achieved by connecting 4 single rank discrete devices with one 8Gb die each, 2 devices connected to each chip select, or by connecting 2 dual rank discrete devices with two 8Gb dies each. Since the SoC supports x8 devices, the usage of more discrete devices is possible. However, this advantage cannot be used to get higher density since this SoC has only 32Gb/4GB of address space dedicated for the DDR. Four x16 8Gb devices giving 32Gb/4GB in total is, therefore, the optimal choice that balances the maximum density aspects, the signal integrity aspects (four discrete devices used), and bandwidth aspects (full data bus width used). Note 10: The density can be achieved by connecting 8 single rank discrete devices with one 8Gb die each, 4 devices connected to each chip select or by connecting 4 dual rank discrete devices with two 8Gb dies each. Note that the first option significantly exceeds the number of devices used on the validation board (4 discrete devices) therefore, it is not guaranteed that the i.MX would be able to drive the signals with margin to the required voltage levels due to increased loading on the traces. A significant effort would be required in terms of PCB layout and signal integrity analysis. Practically, it is not recommended to use more than 4 discrete DDR3L devices. This corresponds to the maximum density of 32Gb/4GB in the case of the single rank devices containing one 8Gb die or 64Gb/8GB in case of the dual-rank devices, each containing two 8Gb dies. Note 11: The density can be achieved by connecting 4 single rank discrete devices with one 8Gb die each, 2 devices connected to each chip select or by connecting 2 dual rank discrete devices with two 8Gb dies each. Note 12: For single-channel (x16) memory devices, the current maximum available density in the market is 16Gb/2GB (Q1 2022). Note 13: Only one channel of the device (and hence, half of its density) was utilized due to the reduced data bus width (x16) of the SoC. Note 14: Part is active. Reviewed May 16th 2024 Note 15: Part is obsolete. Additional Links https://community.nxp.com/t5/iMX-and-Vybrid-Support/i-MX-8-8X-8XL-maximum-supported-LPDDR4-and-DDR3L-densities/ta-p/1152715          
記事全体を表示
1 - Introduction: The Ultra Secured Digital Host Controller (uSDHC) provides the interface between the host processor and the SD/SDIO/MMC cards. Most recent versions provides the ability to automatically select a quantized delay (in fractions of the clock period) regardless of on-chip variations such as process, voltage, and temperature (PVT). The auto tuning is performed during runtime at hardware level, no software enablement is needed to drive this feature. 2 - Failure description: SDIO cards can implement an optional feature that uses DATA[1] to signal the card's interrupt to the i.MX device, this feature can be enabled by the SDIO card device and does not depends on i.MX uSDHC driver configuration. NXP Linux BSP is enabling the auto tuning for high SDIO frequencies (SDR104 and SDR50). Out of reset uSDHC_VEND_SPEC2 register is configured to use DATA[3:0] for calibration, this setup can conflict with the SDIO interrupt as DATA[1] signal can be asserted asynchronously. SDIO failures can be observed when running SDIO applications that requires high usage of the SDIO interface (e.g Download of large files), SDIO controller cannot return an accurate DLL causing failures such as "CMD53 read error". Failure can be observed on i.MX8MM EVK and i.MX8MN EVK boards, both devices are running 88w8987 Wi-Fi chipset at 208Mhz (SDR104). Users can observe an SDIO crash followed by error message below at Linux Kernel level. [ 401.945627] cmd53 read error=-84 [ 401.974677] moal_read_data_sync: read registers failed 3 - Impacted devices: The following devices are impacted by this limitation. - i.MX6 Family:   i.MX6SL, i.MX6SLL, i.MX6SX, i.MX6UL, i.MX6ULZ and i.MX6ULL. - All i.MX7 and i.MX7ULP family:   i.MX7D, i.MX7S and i.MX7ULP. - All i.MX8M Family:   i.MX8MQuad, i.MX8M Mini, i.MX8M Nano, i.MX8M Nano UL and i.MX8M Plus. - All i.MX8/8X Family:   i.MX8DQXP, i.MX8DX and i.MX8QM. NXP Linux BSP is enabling the auto tuning for SDR104 and SDR50 modes. Other operation modes are not impacted by this limitation. Users can poll uSDHCx_CLK_TUNE_CTRL_STATUS register when running SDIO applications to confirm. TAP_SEL_PRE field is updated automatically during run time and constant variations can point to an incorrect delay cell calculated by the uSDHC controller.   All NXP Wi-Fi chipsets are enabling SDIO interrupt during firmware load, failures can be observed with any Wi-Fi vendor enabling SDIO asynchronous interrupt. 4 - Software changes: Recommendation is to enable auto tuning for DATA[0] and CMD signals only, DATA[1] should not be used for auto calibration to avoid a possible conflict with SDIO interrupt. This setup can only be used if SDIO interface length are well matched. Software patches can be found at codeaurora.org. Fix is already included in L5.10.52-2.1.0 BSP, users can add fsl,sdio-interrupt-enabled property to uSDHC device tree node to enable SW workaround. https://github.com/nxp-imx/linux-imx/commit/3b3d6dec05277f7786d813592a31ea4a1ce60a74 https://github.com/nxp-imx/linux-imx/commit/b9b5a43df1d709809b2b654ad8f8181b00a4ee55 https://github.com/nxp-imx/linux-imx/commit/95a846af9f82dc6ea60064d9d12d5d2378e23941      
記事全体を表示
We are pleased to announce that Config Tools for i.MX v16.0 are now available. Downloads & links To download the installer for all platforms, please login to our download site via:  https://www.nxp.com/design/designs/config-tools-for-i-mx-applications-processors:CONFIG-TOOLS-IMX Please refer to  Documentation  for installation and quick start guides. For further information about DDR config and validation, please go to this  blog post. Release Notes Full details on the release (features, known issues...) The product is based on Eclipse 2023-12 Framework – Enable the Peripherals tool in the Config Tools for i.MX – Enable the Clocks tool in the Config Tools for i.MX – A new command-line argument (- UpdateCode) has been added. It performs the same action as the Update Code button in the user interface. It must be used with -HeadlessTool. DDR tool – CA bus driver strength and ODT configuration for the mScale processors are added. – [MX 93/MX 91] The UART configuration from UI is added. – MX 91 DDR tool update for Config tools – MX 93 PF 09 DDR tool support is added. SerDes tool – MX 95 SerDes tool support is enabled. Pins tool – Simultaneous routing detection (routing of one signal may result in multiple signals being routed based on the same register settings) is added. In that case, such signals are offered to be added into the configuration. – Support of internal pins that are not available in the package is added.
記事全体を表示
Hello! In this time, we will look how the i.MX93 GPIOs IRQs works, also I will focus on Cortex M33 side with SDK 2_16_0 but also tested on 2_15.   We can see in this other post, how the i.MX8M family works, but for i.MX93 this is a little different because there are a Secure/Non-Secure options and Privilege/Non-Privilege.   According to reference Manual and SDK LED example, we must to set the PCNS and ICNS registers to 0x00 to set in Secure access.    Materials Used: i.MX93EVK Jumper cable to connect GPIO2_IO02 with GPIO2_IO03 SDK 2_16_0 from MCUXpresso SDK Builder Source power for i.MX93EVK USB C Cable for serial debug USB C Cable to transfer .bin ro EVK   The Cortex-M33 processor supports Secure and Non-secure security states, Thread and Handler operating modes, and can run in either Thumb or Debug operating states. In addition, the processor can limit or exclude access to some resources by executing code in privileged or unprivileged mode. Code can execute as privileged or unprivileged. Unprivileged execution limits or excludes access to some resources appropriate to the current security state. Privileged execution has access to all resources available to the security state. Handler mode is always privileged. Thread mode can be privileged or unprivileged. You can find this information in the ARM documentation.   To resume this post, we will focus just in the necessary registers to configure properly a GPIO as IRQ input.   On this example, we will take the i.MX93EVK board. The GPIO2_IO02 will be configured as an output and the GPIO2_IO03 will be configured as an input with Rising edge IRQ. On each GPIO2_IO02 Rising edge, the software will detect an IRQ.     At first, we need to configure our IOMUX: void BOARD_InitPins(void) { IOMUXC_SetPinMux(IOMUXC_PAD_GPIO_IO02__GPIO2_IO02, 0U); IOMUXC_SetPinMux(IOMUXC_PAD_GPIO_IO03__GPIO2_IO03, 0U); IOMUXC_SetPinMux(IOMUXC_PAD_UART2_RXD__LPUART2_RX, 0U); IOMUXC_SetPinMux(IOMUXC_PAD_UART2_TXD__LPUART2_TX, 0U); IOMUXC_SetPinConfig(IOMUXC_PAD_GPIO_IO02__GPIO2_IO02, IOMUXC_PAD_DSE(15U) | IOMUXC_PAD_FSEL1(2U) | IOMUXC_PAD_PD_MASK); IOMUXC_SetPinConfig(IOMUXC_PAD_GPIO_IO03__GPIO2_IO03, IOMUXC_PAD_PD_MASK); IOMUXC_SetPinConfig(IOMUXC_PAD_UART2_RXD__LPUART2_RX, IOMUXC_PAD_PD_MASK); IOMUXC_SetPinConfig(IOMUXC_PAD_UART2_TXD__LPUART2_TX, IOMUXC_PAD_DSE(15U)); }   Then, we can start to code. Using as an starting point we can use the SDK/boards/mcimx93evk/driver_examples/rgpio/led_output example. Our definitions (PIN_OUT_RGPIO and PIN_IN_RGPIO are the same GPIO2 but it is just for good practice):😞 /******************************************************************************* * Definitions ******************************************************************************/ #define PIN_OUT_RGPIO GPIO2 #define PIN_IN_RGPIO GPIO2 #define PIN_OUT_RGPIO_PIN 2U #define PIN_IN_RGPIO_PIN 3U   Then, our IRQ handler: void Reserved73_IRQHandler(void) { RGPIO_ClearPinsInterruptFlags(PIN_IN_RGPIO, kRGPIO_InterruptOutput0, 1U << PIN_IN_RGPIO_PIN); PRINTF("\r\n IRQ.........\r\n"); SDK_ISR_EXIT_BARRIER; }   Why Reserved73_IRQHandler? That is the correspondent for GPIO2, you can look this on SDK/devices/MIMX9352/gcc in the file called startup_MIMX9352_cm33.S:   Basically, the interruption will clear the IRQ flag and print a little message.   Now, here we have the complete main function, we will break down the most important points. int main(void) { /* Define the init structure for the output pin*/ rgpio_pin_config_t pin_out_config = { kRGPIO_DigitalOutput, 0, }; rgpio_pin_config_t pin_in_config = { kRGPIO_DigitalInput, 0, }; /* Board pin, clock, debug console init */ /* clang-format off */ const clock_root_config_t rgpioClkCfg = { .clockOff = false, .mux = 0, // 24Mhz Mcore root buswake clock .div = 1 }; /* clang-format on */ BOARD_InitBootPins(); BOARD_BootClockRUN(); BOARD_InitDebugConsole(); CLOCK_SetRootClock(EXAMPLE_RGPIO_CLOCK_ROOT, &rgpioClkCfg); CLOCK_EnableClock(EXAMPLE_RGPIO_CLOCK_GATE); CLOCK_EnableClock(kCLOCK_Gpio2); /* Set PCNS register value to 0x0 to prepare the RGPIO initialization */ PIN_OUT_RGPIO->PCNS = 0x0; PIN_IN_RGPIO->ICNS = 0x0; /* Print a note to terminal. */ PRINTF("\r\n RGPIO Driver example\r\n"); PRINTF("\r\n An IRQ will happen each GPIO2_IO02 Rising edge\r\n"); /* Init output PIN GPIO. */ RGPIO_PinInit(PIN_OUT_RGPIO, PIN_OUT_RGPIO_PIN, &pin_out_config); /* Init Input with IRQ Pin GPIO*/ RGPIO_SetPinInterruptConfig(PIN_IN_RGPIO, PIN_IN_RGPIO_PIN, kRGPIO_InterruptOutput0, kRGPIO_InterruptRisingEdge); EnableIRQ(GPIO2_0_IRQn); RGPIO_PinInit(PIN_IN_RGPIO, PIN_IN_RGPIO_PIN, &pin_in_config); while (1) { SDK_DelayAtLeastUs(1000000U, SystemCoreClock); RGPIO_PortToggle(PIN_OUT_RGPIO, 1u << PIN_OUT_RGPIO_PIN); } }   As we can see, we need set the GPIO2 PCNS register to 0x00:   Pin Control Nonsecure (PCNS) Configures secure or nonsecure access protection for each pin. You can write to this register only in the Secure-Privilege state if it is not locked (LOCK[PCNS] = 0).   Also the ICNS register to 0x00.   Interrupt Control Nonsecure (ICNS) Configures secure and nonsecure access protection for each interrupt, or DMA request. You can update this register only in the Secure-Privilege state if it is not locked (LOCK[ICNS] = 0).   Now, we can compile and run the example. On each GPIO2_IO02 Rising edge, the CM33 will detect an IRQ in GPIO2_IO03 (short those pads as showed in the image at first of the post).     I will attach the full .c file.   I hope this information can helps to everyone.   Best regards, --... ...-- Salas.
記事全体を表示
This document is about to build an image by Yocto , and it will disable a function that normal user can’t use command line of “ su ”.
記事全体を表示
The purpose of this document is to provide a guide on how to export new symbols using the Bazel Android server instead of the build_abi.sh script. For a better reference how to build Android i.MX image please look at the next chapter 3 Building the Android Platform for i.MX in the Android User's Guide 1. Compile full AOSP or only kernel Build full AOSP: $ source build/envsetup.sh $ lunch evk_8mp-eng $ ./imx-make.sh -j8  Only build the kernel: $ ./imx-make.sh kernel -j8 2. Generic Kernel Image GKI Development Download GKI outside of android_build (MY_ANDROID). # Make sure MY_ANDROID is set to the android_build folder. $ export MY_ANDROID=`pwd` # mkdir gki && cd gki (Make sure folder gki is not inside of ${MY_ANDROID}) $ repo init -u https://android.googlesource.com/kernel/manifest -b common-android14-6.1 $ repo sync $ cd common 3. Export New Symbols Switch the kernel in this common folder from AOSP to its device, and apply the patches required for your project. In this case Android $ cd common $ git remote add device https://github.com/nxp-imx/linux-imx.git $ git remote update $ git fetch device --tags $ git checkout android-14.0.0_1.2.0 $ cd .. $ ln -s ${MY_ANDROID}/vendor/nxp-opensource/verisilicon_sw_isp_vvcam verisilicon_sw_isp_vvcam $ ln -s ${MY_ANDROID}/vendor/nxp-opensource/nxp-mwifiex nxp-mwifiex $ BUILD_FOR_GKI=yes BUILD_CONFIG=common/build.config.imx $ EXT_MODULES_MAKEFILE="verisilicon_sw_isp_vvcam/vvcam/v4l2/Kbuild" $ EXT_MODULES="nxp-mwifiex/mxm_wifiex/wlan_src" Note: Be sure that your Symbolic Link is pointing to the correct folder Open the Makefile in the following path ../gki/nxp-mwifiex/mxm_wifiex/wlan_src/ and erase some ifreq lines that will generate a No such file or directory error. #Automatically determine Android version from build information to streamline diff --git a/mxm_wifiex/wlan_src/Makefile b/mxm_wifiex/wlan_src/Makefile index 3ec5308..7b6ca47 100644 --- a/mxm_wifiex/wlan_src/Makefile +++ b/mxm_wifiex/wlan_src/Makefile @@ -139,20 +139,7 @@ CONFIG_ANDROID_KERNEL=y ifeq ($(ANDROID_PRODUCT_OUT),1) ccflags-y += -DANDROID_SDK_VERSION=$(ANDROID_SDK_VERSION) else -include $(ANDROID_BUILD_TOP)/build/make/core/build_id.mk -ifeq ($(shell echo "$(BUILD_ID)" | cut -c1),R) - ccflags-y += -DANDROID_SDK_VERSION=30 -else ifeq ($(shell echo "$(BUILD_ID)" | cut -c1),S) - ccflags-y += -DANDROID_SDK_VERSION=31 -else ifeq ($(shell echo "$(BUILD_ID)" | cut -c1),T) - ccflags-y += -DANDROID_SDK_VERSION=33 -else ifeq ($(shell echo "$(BUILD_ID)" | cut -c1),U) - ccflags-y += -DANDROID_SDK_VERSION=34 -else - # Default optimization or actions - ANDROID_SDK_VERSION := 0 - ccflags-y += -DANDROID_SDK_VERSION -endif +ccflags-y += -DANDROID_SDK_VERSION=34 endif endif endif -- Then you could update the symbol list by typing the following command. $ tools/bazel run //common:imx_abi_update_symbol_list After the build process is successful, you should get an output like the image below. Build GKI locally. $ tools/bazel run //common:kernel_aarch64_dist  You could follow the next chapters to update the GKI image to your boot image.
記事全体を表示
Preface With i.MX android, it is often infeasible to directly build an OTA package with a newer android version and apply that OTA package to a device running old version of Android. For example, the OTA package buit with i.MX android-13.0.0_2.0.0 release for evk_8mm cannot be direclty applied on the evk_8mm board running the image built with i.MX android-11.0.0_1.0.0. In this article, the reason why directly cross-version OTA is infeasible in i.mx android is firstly explained. Then what should be takein into consideration and done before cross-version OTA are described.   The way Google update the system for its device Once Google first time releases a device, it is called a "launch device". it has: codename. Take pixel 3a xl as an example, the codename is bonito Android version. For pixel 3a xl, it's Android 9.0 kernel version. For pixel 3a xl, it's 4.9 PRODUCT_SHIPPING_API_LEVEL. For pixel 3a xl, it is set to be 28, the same as the SDK version of that Android version. FCM target level. For pixel 3a xl, it's 3 After the system code is updated to a new version, an OTA package can be built with the lunch target aosp_bonito-user or aosp_bonito-userdebug for pixel 3a xl, let's call the updated device "retrofit device" codename is not changed. its device configuration still can be found in "device/google/bonito/" Android version. it is the version the OTA updated to. Four android versions are supported, here they are android 9, 10, 11, 12, which means pixel 3a xl can at most upgraded to android12. "device/google/bonito/" is introduced in android9, and removed in android13. kernel version. not changed after OTA PRODUCT_SHIPPING_API_LEVEL. Not changed in OTA, so after the OTA, the value of property "ro.product.first_api_level" is different from the SDK version. FCM target level. not changed after OTA. The FCM target level is in the device manifest.xml, corresponds to a specific version of system compatibility.matrix.xml, so HALs provided by this device does not need to have much changes if the FCM target level is not changed. This is the way Google maintains the system for their devices. This is not the way i.MX Android devices are maintained. The way i.MX Android update the system to a new version for maintained device when the code is upaded to a new version for maintained imx devices, all the device are taken as "launch device", so compaired to the previous version, in the new system for the device: the kernel version is changed PRODUCT_SHIPPING_API_LEVEL is changed FCM target level is changed. Physical partitions may also be changed The FCM target level change means there may be some big changes in the HALs provided by this device. The PRODUCT_SHIPPING_API_LEVEL change means quite many code logic based on the property "ro.product.first_api_level" execute in different flow. Fro the partition changes, the OTA package directly build with this updated code often cannot be applied, for example, a new image for the new partition cannot be applied on the board running old system, as it does not have the partition for the image. Things cannot be changed during OTA To make things more clear that why direct cross-version OTA is infeasible, it is necessary to know that there are things cannot be changed during OTA. 1. physical partitions cannot be changed during OTA. related features are: * dynamic partition * gki * boot header version 2. user data on theuserdata partition should not be changed, or data loss may occur during OTA. the related features are: * encryption options encryption options should not be changed, to make new version of android can recognize the data encrypted by the old version of android. For some  fs_mgr encrypt options, the product_shipping_api_level impacts on the final encryption parameters passed to the kernel. take a look at the following code, even with the same fs_mgr encryption option, if the first_api_level is different, the final encryption parameter is different in different android version. android10 system/extras/libfscrypt/fscrypt.cpp if (filenames_encryption_mode == FS_ENCRYPTION_MODE_AES_256_CTS) { // Use legacy padding with our original filenames encryption mode. return FS_POLICY_FLAGS_PAD_4; } else if (filenames_encryption_mode == FS_ENCRYPTION_MODE_ADIANTUM) { // ...snip... return (FS_POLICY_FLAGS_PAD_16 | FS_POLICY_FLAG_DIRECT_KEY); } // ...snip... return FS_POLICY_FLAGS_PAD_16; android11 system/extras/libfscrypt/fscrypt.cpp if (!is_gki && options->version == 1 && options->filenames_mode == FSCRYPT_MODE_AES_256_CTS) { options->flags |= FSCRYPT_POLICY_FLAGS_PAD_4; } else { options->flags |= FSCRYPT_POLICY_FLAGS_PAD_16; } android12 system/extras/libfscrypt/fscrypt.cpp if (first_api_level <= __ANDROID_API_Q__ && options->version == 1 && options->filenames_mode == FSCRYPT_MODE_AES_256_CTS) { options->flags |= FSCRYPT_POLICY_FLAGS_PAD_4; } else { options->flags |= FSCRYPT_POLICY_FLAGS_PAD_16; }  The fscrypt version will also impact the result. If not sepcified, the default "version" would be "v1" if the "product_shipping_api_level <= 29" or the default "version" would be "v2". Some fscrypt functions like "casefold" and "project id" will depend on fscrypt "v2", these functions are enabled by including the "$(call inherit-product, $(SRC_TARGET_DIR)/product/emulated_storage.mk)" in "device/nxp". The "emulated_storage.mk" must not be included if fscrypt "v1" is used.  * the userdata partition filesystem type ext4 (used before i.mx android 13.0.0) f2fs (used from i.mx android 13.0.0) * The filesystem for the emulated storage on the userdata partition sdcardfs fuse 3. The boot control info in misc partition should be able to be recognized before and after OTA related feature is: * bootcontrol HAL 4. The bootargs passed by u-boot to kernel cannot be changed if the bootloader is not updated The related feature is: * bootconfig is used to pass boot args from android12.0.0_1.0.0. used with vendor boot header v4.   it should be known that if dual bootloader of postinstall is used, bootloader can be updated.   For these related features. Google does not implement or change them for a "retrofit device", just imlement for change the features for a "launch device", makes direct cross-version OTA feasible for them, because things cannot be changed during OTA are the same between different android versions. For i.mx android, to implement new features for all maintaied devices, things can be changed during OTA are often changed when update to a new version of android. which makes direct cross-version OTA infeasible.    For the ease of reference, list some feature change history here: * physical partition change history   P9.0.0_2.3.0 10.0.0_1.0.0 10.0.0_2.0.0 11.0.0_1.0.0 12.0.0_1.0.0 12.1.0_1.0.0 13.0.0_1.0.0 14.0.0_1.0.0 bootloader_a/b 4MB 4MB 4MB 4MB 4MB 16MB 16MB 16MB dtbo_a/b 4MB 4MB 4MB 4MB 4MB 4MB 4MB 4MB boot_a/b 48MB 48MB 64MB 64MB 64MB 64MB 64MB 64MB init_boot_a/b - -   -   - 8MB 8MB vendor_boot_a/b - -   64MB 64MB 64MB 64MB 64MB misc 4MB 4MB 4MB 4MB 4MB 4MB 4MB 4MB metadata 2MB 2MB 2MB 2MB 16MB 16MB 64MB 64MB presistdata 1MB 1MB 1MB 1MB 1MB 1MB 1MB 1MB super - - 7168MB 3584MB 4096MB 4096MB 4096MB 4096MB fbmisc 1MB 1MB 1MB 1MB 1MB 1MB 1MB 1MB vbmeta_a/b 1MB 1MB 1mb 1MB 1MB 1MB 1MB 1MB system_a/b 2560MB 1536MB - -   - - - vendor_a/b 256MB 512MB - -   - - - product_a/b - 1792MB - -   - - -   boot_a/b: 48MB → 64MB, Image becames bigger ater enabling some debug options vendor_boot_a/b: boot header v3. Vendor boot and boot header v3 are MUST to enable GKI feature.  init_boot_a/b: The init binary in ramdisk is moved from boot.img to init_boot.img. flash gki image from Google does not impact on the vendor modifications on init.   for the metadata partition: 2MB → 16MB, requirement of vts "-m vts_gsi_boot_test -t MetadataPartition#MinimumSize" 16MB → 64MB, to make the partition be formated as f2fs, 32MB is not enough, 64MB is used. metadata partition was firstly mounted in android11, when enable the user data checkpoint feature * gki feature history Firstly introduced in android11. Some codes are built into modules, put the modules in vendor_boot_a/b partition. vendor_boot_a/b partitions are also firstly introduced in android11 GKI prebuilt binary was integrated from android12   The way to handle cross-version OTA for i.mx android Here are the steps align the partitions within the OTA base code and the OTA target code if the product may be in the development stage, and the OTA base  code can be modified: reserve partitions in OTA base code. for example, OTA from 10 to 11, reserver the vendor_boot partition in android10 partitiont able although there is not vendor_boot.img. change the selinux rules to have update_engine to be able to update this partition. enlarge some partitions in the OTA base code as in the OTA target code. for examples, the bootloader partitions is 16MB in android13. if OTA from android12 to android13 and the android 12 code can be modified, enlarge the bootloader partition to 16MB. as data in userdata and metadata partition is not touched during OTA, modify the mount options of userdata and metadata partitions in OTA target code to be the same as the one in OTA base code. if the product partitions are already shipped, only the OTA target code can be modified:  as data in userdata and metadata partition is not touched during OTA, modify the mount options of userdata and metadata partitions in OTA target code to be the same as the one in the OTA base code. change the partition size to align with the OTA base code partitions like vendor_boot and/or init_boot may need to be removed. remove/change the features related to the removed or changed partitions if dual bootloader is not used: recently in android version update, vendor_boot and init_boot partitions are added, this is related to boot image header version, the images in these partitions are loaded and verified by uboot, so if dual bootloader is not used, uboot code related to these things need to be changed. check the code related to "struct boot_img_hdr" in uboot. the a/b slot metadata format may be changed between the OTA base code and the OTA target code , this a/b slot metadata is accessed by both Android bootctrl HAL and uboot, as dual bootloader is not used, uboot is not upaded, the updated Android bootctrl HAL should also use the same format to access the file. a postinstall mechanism can be used to update the uboot images, but as there is no fallback for the update failure, the risks need to be evaluated. check whether the OTA package can be applied and whether the updated system can boot up an failure example: OTA from android10 to android12, the system fail to boot up because of the PRODUCT_SHIPPING_API_LEVEL/"ro.product.first_api_level" value difference, different encryption options are used for userdata partitions. so the PRODUCT_SHIPPING_API_LEVEL value need to be changed to be the same as the one in the OTA base code. as PRODUCT_SHIPPING_API_LEVEL is changed, the FCM target version and related HALs may also need to be changed, including changes in device manifest.xml and compatibility_matrix.xml. need to check the commit history about what is changed together with the FCM target version change.   For dynamic partitions, there are something to be noticed: OTA from the image without dynamic partitions to use dynamic partitions: Refer to the code in android10.0.0_2.0.0, there is a demonstration to update 10.0.0_1.0.0 to 10.0.0_2.0.0. In 0.0.0_1.0.0, dynamic partition is not enabled. check the variable "TARGET_USE_RETROFIT_DYNAMIC_PARTITION" and related configurations. OTA from dynamic partitions to virtual A/B, for example, OTA from android10 to android11 inherit the file "build/make/target/product/virtual_ab_ota_retrofit.mk" the first time when update from android10 to android11 with OTA, inherit the "build/make/target/product/virtual_ab_ota_retrofit.mk", the BOARD_NXP_DYNAMIC_PARTITIONS_SIZE is set as dynamic paritition is used. the second time, the device is runing android11 with retrofit virtual A/B feature, this time OTA again, but not cross version, inherit "build/make/target/product/virtual_ab_ota.mk" instead, and the BOARD_NXP_DYNAMIC_PARTITIONS_SIZE  can be set as virtual A/B feature is used. Devices that were upgraded to dynamic partitions can’t retrofit virtual A/B. if there are new dynamic partitions in OTA target code, like vendor_dlkm, no additional changes need to be made for it. Then the customers need to do full xTS test to guarantee the quality.  
記事全体を表示
Overview The purpose of this document is to provide a guide on how to enable Dual Ethernet with the GKI Development. Reference: How to enable dual ethernet on Android 11 For a better reference how to build Android i.MX image please look at the next chapter 3 Building the Android Platform for i.MX in the Android User's Guide 1. Build the Android Image with the next modifications The 2nd ethernet port is DWMAC from synopsys and phy used is realtek RTL8211F. To add them into the SharedBoardConfig.mk and remove the camera drivers. diff --git a/imx8m/evk_8mp/SharedBoardConfig.mk b/imx8m/evk_8mp/SharedBoardConfig.mk index f68eb49e..3e95708e 100644 --- a/imx8m/evk_8mp/SharedBoardConfig.mk +++ b/imx8m/evk_8mp/SharedBoardConfig.mk @@ -82,7 +82,12 @@ BOARD_VENDOR_KERNEL_MODULES += \ $(KERNEL_OUT)/drivers/rtc/rtc-snvs.ko \ $(KERNEL_OUT)/drivers/pci/controller/dwc/pci-imx6.ko \ $(KERNEL_OUT)/drivers/net/phy/realtek.ko \ - $(KERNEL_OUT)/drivers/net/ethernet/freescale/fec.ko + $(KERNEL_OUT)/drivers/net/ethernet/freescale/fec.ko \ + $(KERNEL_OUT)/drivers/net/phy/micrel.ko \ + $(KERNEL_OUT)/drivers/net/pcs/pcs_xpcs.ko \ + $(KERNEL_OUT)/drivers/net/ethernet/stmicro/stmmac/dwmac-imx.ko \ + $(KERNEL_OUT)/drivers/net/ethernet/stmicro/stmmac/stmmac.ko \ + $(KERNEL_OUT)/drivers/net/ethernet/stmicro/stmmac/stmmac-platform.ko ifeq ($(POWERSAVE),true) BOARD_VENDOR_KERNEL_MODULES += \ $(KERNEL_OUT)/drivers/soc/imx/lpa_ctrl.ko \ @@ -219,15 +224,12 @@ BOARD_VENDOR_RAMDISK_KERNEL_MODULES += \ $(KERNEL_OUT)/drivers/perf/fsl_imx8_ddr_perf.ko \ $(KERNEL_OUT)/drivers/cpufreq/cpufreq-dt.ko \ $(KERNEL_OUT)/drivers/cpufreq/imx-cpufreq-dt.ko \ - $(KERNEL_OUT)/drivers/media/i2c/ov5640.ko \ $(KERNEL_OUT)/drivers/staging/media/imx/imx8-capture.ko \ $(KERNEL_OUT)/drivers/staging/media/imx/imx8-isi-capture.ko \ $(KERNEL_OUT)/drivers/staging/media/imx/imx8-isi-hw.ko \ $(KERNEL_OUT)/drivers/staging/media/imx/imx8-isi-mem2mem.ko \ $(KERNEL_OUT)/drivers/staging/media/imx/imx8-mipi-csi2-sam.ko \ $(KERNEL_OUT)/drivers/dma/imx-sdma.ko \ - $(TARGET_OUT_INTERMEDIATES)/VVCAM_OBJ/basler-camera-driver-vvcam.ko \ - $(TARGET_OUT_INTERMEDIATES)/VVCAM_OBJ/os08a20.ko \ $(KERNEL_OUT)/drivers/staging/media/imx/imx8-media-dev.ko \ $(TARGET_OUT_INTERMEDIATES)/VVCAM_OBJ/vvcam-dwe.ko \ $(TARGET_OUT_INTERMEDIATES)/VVCAM_OBJ/vvcam-isp.ko \​ To let the Android framework's EthernetTracker and EthernetNetworkFactory know which interfaces to manage, the framework level configure config_ethernet_iface_regex config_ethernet_interfaces must be overlay in device/nxp/imx8m/evk_8mp/overlay/frameworks/base/core/res/res/values/config.xml: diff --git a/imx8m/evk_8mp/overlay/frameworks/base/core/res/res/values/config.xml b/imx8m/evk_8mp/overlay/frameworks/base/core/res/res/values/config.xml index 298d50cc..63f6787e 100644 --- a/imx8m/evk_8mp/overlay/frameworks/base/core/res/res/values/config.xml +++ b/imx8m/evk_8mp/overlay/frameworks/base/core/res/res/values/config.xml @@ -22,7 +22,12 @@ <resources> <!--For Android we support eth0 now --> - <string translatable="false" name="config_ethernet_iface_regex">eth0</string> + <string translatable="false" name="config_ethernet_iface_regex">eth\\d</string> + + <string-array translatable="false" name="config_ethernet_interfaces"> + <item>eth0;12,13,14,15,16,18,19</item> + <item>eth1;12,13,14,15,16,18,19</item> + </string-array> <!-- List of regexpressions describing the interface (if any) that represent tetherable USB interfaces. If the device doesn't want to support tething over USB this should -- Apply the patch 0001-PATCH-Add-defines-for-ETH-support-drivers.patch Build the Android Image # Change to the MY_ANDROID Directory $ source build/envsetup.sh $ lunch evk_8mp-userdebug $ ./imx-make.sh -j4 2>&1 | tee build-log.txt​   GKI Development Follow and apply the next community post: Export new symbols of GKI development Android 14 Set the GKI repo $ repo init -u https://android.googlesource.com/kernel/manifest -b common-android14-6.1 $ repo sync $ git remote add device https://github.com/nxp-imx/linux-imx.git $ git remote update $ git fetch device --tags $ git checkout android-14.0.0_1.2.0 $ cd .. #Be sure that symbolic links are created correctly $ ln -s ${MY_ANDROID}/vendor/nxp-opensource/verisilicon_sw_isp_vvcam verisilicon_sw_isp_vvcam $ ln -s ${MY_ANDROID}/vendor/nxp-opensource/nxp-mwifiex nxp-mwifiex $ BUILD_FOR_GKI=yes $ BUILD_CONFIG=common/build.config.imx $ tools/bazel run //common:imx_abi_update_symbol_list Apply the following changes in the GKI Kernel tree: gki/common: Patch: 0001-PATCH-GKI-Kernel-tree-Drivers-for-the-ETH1-Interface.patch Build the GKI Image tools/bazel run //common:kernel_aarch64_dist​ Follow the build android boot.img and system_dlkm.img $ cp out/kernel_aarch64/dist/boot.img ${MY_ANDROID}/vendor/nxp/fsl-proprietary/ gki/boot.img $ cd ${MY_ANDROID} $ TARGET_IMX_KERNEL=true make bootimage # Change directory to the gki folder $ cp out/kernel_aarch64/dist/system_dlkm_staging_archive.tar.gz ${MY_ANDROID}/vendor/nxp/fsl-proprietary/gki/system_dlkm_staging_archive.tar.gz $ cd ${MY_ANDROID}/vendor/nxp/fsl-proprietary/gki $ tar -xzf system_dlkm_staging_archive.tar.gz -C system_dlkm_staging $ cd ${MY_ANDROID} $ make system_dlkmimag​e Create the tar.gz file for flash the android image (*.img, *.bat, *.sh, *.bin, *.imx) Boot the image and type lsmod to ensure the drivers are installed. Regards, Mario    
記事全体を表示
Debian is a free to use and redistribute Linux distribution that is widely used by the community for industrial and desktop applications.  This distribution started in 1993 as Debian Project with Ian Murdock inviting developers to contribute in one of the first Linux distributions.  Debian takes an important role in Linux world with a clear idea about be a full featured and free distribution with over than 59,000 packages provided as a free to use and distribute that supports a wide range of functionalities.  Currently, Debian 12 supports 9 architectures which makes it in a universal operating system that can be implemented in embedded systems, desktops or servers.  Finally, Debian has been an inspiration for well-known Linux distributions such as Kali and Ubuntu.  In this guide we will check the installation process of Debian 12 for NXP microprocessors i.MX family, specifically for i.MX8M Mini, i.MX8M Nano, i.MX8M Plus and i.MX93.  For this purpose, we divided the document in the following topics: Hardware Requirements Software Requirements Host Preparation SD Card Preparation Copying Bootloader  Copying Kernel and DTB files Debian Installation Configure Base System Boot your target References   Hardware Requirements Linux Host computer (Ubuntu 20.04 or later) USB Card reader or Micro SD to SD adapter SD Card Evaluation Kit Board for the i.MX8M Nano, i.MX8M Mini, i.MX8M Plus or i.MX93   Software Requirements Linux Ubuntu (20.04 and 24.04 tested) or Debian for host BSP version 6.1.55 for your specific target (Embedded Linux for i.MX Applications Processors | NXP Semiconductors)   Host Preparation For Debian installation we will require some specific packages for host.  You can download the packages using the following command: $ sudo apt install debian-archive-keyring debootstrap qemu-user-static We must validate the key to verify the archive using the command: $ sudo apt-key add /usr/share/keyrings/debian-archive-keyring.gpg If running an older release you need to get the unstable keyring package (because the version in your release is probably too old to have the current key) $ wget http://ftp.debian.org/debian/pool/main/d/debian-archive-keyring/debian-archive-keyring_2023.4_all.deb $ sudo dpkg -i debian-archive-keyring_2023.4_all.deb   SD Card Preparation The Linux kernel running on the Linux host assigns a device node to the SD/MMC card reader. The kernel might decide the device node name or udev rules might be used. In the following instructions, it is assumed that udev is not used. To identify the device node assigned to the SD/MMC card, carry out the following command: $ cat /proc/partitions   Partitioning the SD card On most Linux host operating systems, the SD card is mounted automatically upon insertion. Therefore, before running fdisk, make sure that the SD card is unmounted if it was previously mounted (through sudo umount /dev/sdx). Start by running fdisk with root permissions. Use the instructions above to determine the card ID. We are using sdx as an example. $ sudo fdisk /dev/sdx  Type the following parameters (each followed by <ENTER>): $fdisk: p # lists the current partitions $fdisk: d # to delete existing partitions. Repeat this until no unnecessary partitions $fdisk: n # create a new partition $fdisk: p # create a primary partition - use for both partitions $fdisk: 1 # the first partition $fdisk: 20480 # starting at offset sector $fdisk: 1024000 # ending position of the first partition to be used for the boot Images $fdisk: p # to check the partitions $fdisk: n # create a new partition $fdisk: p # create a primary partition $fdisk: 2 # the second partition $fdisk: 1228800 # starting at offset sector, which leaves enough space for the kernel, the bootloader and its configuration data $fdisk: <enter> # using the default value will create a partition that extends to the last sector of the media $fdisk: p # to check the partitions $fdisk: w # this writes the partition table to the media and fdisk exits   Copying Bootloader and Kernel In this section we will copy the bootloader and kernel image to SD card.  First, we can create a new directory to unzip the BSP downloaded from the NXP site.  $ mkdir debian-imx $ cd debian-imx $ unzip ~/Downloads/LF_v6.1.55-2.2.0_images_<board>.zip Where board is: IMX8MPEVK IMX8MNEVK IMX8MMEVK IMX93EVK Then, copy the U-Boot image. $ sudo dd if=<U-Boot_image> of=/dev/sdx bs=1k seek=<offset> conv=fsync Where offset is: 33 - for i.MX 8M Mini 32 - for i.MX 8M Nano, i.MX 8M Plus, and i.MX 9 The sectors of SD/eMMC before the “offset” KB are reserved. It may include the partition table.   Copying Kernel image and DTB files This section describes how to load the kernel image and DTB. The pre-built SD card image uses the VFAT partition for storing kernel image and DTB, which requires a VFAT partition that is mounted as a Linux drive, and the files are copied into it. This is the preferred method. Default: VFAT partition Format partition 1 on the card as VFAT with this command: $ sudo mkfs.vfat /dev/sdx1 Mount the formatted partition with this command: $ mkdir mountpoint $ sudo mount /dev/sdx1 mountpoint Copy the zImage and *.dtb files to the mountpoint by using cp. The device tree names should match $ sudo cp *.dtb mountpoint/ $sudo cp Image-<board_name>.bin mountpoint/Image Where board_name is: imx8mpevk imx8mnevk imx8mmevk imx93evk the one used by the variable specified by U-Boot. Unmount the partition with this command: $ sudo umount mountpoint   Debian Installation For Debian installation we will use the official tool debootstrap. This tool allows us to install Debian without a disk and run the system using qemu in a different architecture.  Before using debootstrap tool we need to format and mount the second partition of the SD card with the commands below: $ sudo mkfs.ext4 /dev/sdx2 $ sudo mount /dev/sdx2 mountpoint/ debootstrap can download the needed files directly from the archive when you run it. You can substitute any Debian archive mirror for http.us.debian.org/debian in the command below, preferably a mirror close to you network-wise. Mirrors are listed at http://www.debian.org/mirror/list $ sudo debootstrap --arch arm64 --foreign bookworm mountpoint/ http://ftp.debian.org/debian This step takes a while and depends on the resources of your host machine.   Configure Base System Now you’ve got a real Debian system, though rather lean, on disk. chroot into it: $ sudo cp /usr/bin/qemu-aarch64-static mountpoint/usr/bin $ sudo LANG=C.UTF-8 chroot mountpoint/ qemu-aarch64-static /bin/bash After chrooting you may need to set the terminal definition to be compatible with the Debian base system, for example: $ export TERM=xterm-color we need to finish the multi-stage boot strap $ /debootstrap/debootstrap --second-stage At this point /dev/ only contains very basic device files. For the next steps of the installation, additional device files may be needed. There are different ways to go about this and which method you should use depends on the host system you are using for the installation, whether you intend to use a modular kernel or not, and whether you want to use dynamic (e.g. using udev) or static device files for the new system. A few of the available options are: install the makedev package, and create a default set of static device files using (after chrooting) $ apt install makedev $ mount none /proc -t proc $ cd /dev $ MAKEDEV generic With these next steps we will be setting up the Debian system:   Setting fstab FSTAB is a configuration table designed to ease the burden of mounting and unmounting file systems to a machine. $ nano /etc/fstab # stock fstab - you probably want to override this with a machine specific one /dev/root / auto defaults 1 1 proc /proc proc defaults 0 0 devpts /dev/pts devpts mode=0620,ptmxmode=0666,gid=5 0 0 tmpfs /run tmpfs mode=0755,nodev,nosuid,strictatime 0 0 tmpfs /var/volatile tmpfs defaults 0 0 # uncomment this if your device has a SD/MMC/Transflash slot #/dev/mmcblk0p1 /media/card auto defaults,sync,noauto 0 0   Setting Timezone The following command allows you to choose your timezone. $ dpkg-reconfigure tzdata   Configure apt Debootstrap will have created a very basic /etc/apt/sources.list that will allow installing additional packages. However, you may want to add some additional sources, for example for source packages and security updates: $ nano /etc/apt/sources.list deb http://deb.debian.org/debian bookworm main non-free-firmware deb-src http://deb.debian.org/debian bookworm main non-free-firmware deb http://deb.debian.org/debian-security/ bookworm-security main non-free-firmware deb-src http://deb.debian.org/debian-security/ bookworm-security main non-free-firmware deb http://deb.debian.org/debian bookworm-updates main non-free-firmware deb-src http://deb.debian.org/debian bookworm-updates main non-free-firmware Make sure to run the apt update after you have made changes to the sources list   Configure locales and keyboard To configure your locale settings to use a language other than English, install the locales support package and configure it. Currently, the use of UTF-8 locales is recommended. $ apt install locales $ dpkg-reconfigure locales To configure your keyboard (if needed): $ apt install console-setup $ dpkg-reconfigure keyboard-configuration Note that the keyboard cannot be set while in the chroot, but will be configured for the next reboot   Adding Users $ apt install sudo $ adduser imx $ usermod -aG sudo imx $ nano /etc/sudoers imx ALL=(ALL:ALL) ALL   Tasksel Installation As mentioned earlier, the installed system will be very basic. If you would like to make the system a bit more mature, there is an easy method to install all packages with “standard” priority: $ tasksel install standard $ apt clean $ exit $ sudo umount mountpoint/ $sync   Boot your target Now, you can boot your target from your SD Card. (Review your specific target documentation)   Configure Networking (after booting target) Based on Debian official documentation for new systems the common names for network interfaces such as eth0 or wlan0 are not used. Therefore, we will need to list the interfaces using: $ ls /sys/class/net To have ethernet connection we will need to create a file in the path etc/network/. $ sudo nano etc/network/interfaces Type the following commands on the file: auto lo iface lo inet loopback auto end0 iface end0 inet dhcp   Install Neofetch (Optional) $ apt install neofetch   Outputs  Debian 12 running on i.MX8MP Debian 12 running on i.MX93   References Chapter 1. Definitions and overview. (2021, January). Retrieved May 30, 2024, from https://www.debian.org/doc/manuals/debian-faq/basic-defs.en.html Debian GNU/Linux Installation Guide. (2024). https://www.debian.org/releases/stable/i386/install.en.pdf Arm64Port. (n.d.). https://wiki.debian.org/Arm64Port i.MX Linux User's Guide (nxp.com)
記事全体を表示
The document will cover three parts, which include: A brief introduction to RSA algorithm How to compile boot image including OP-TEE-OS for Boot media - QSPI The steps to sign and verification The SoC for this experiment is based on i.MX8MP-EVK
記事全体を表示
Hello, on this post I will explain how to record separated audio channels using an 8MIC-RPI-MX8 Board. As background about how to setup the board to record and play audio using i.MX boards, I suggest you take a look on the next post: How to configure, record and play audio using an 8MIC-RPI-MX8 Board. Requirements: I.MX 8M Mini EVK. Linux Binary Demo Files - i.MX 8MMini EVK. 8MIC-RPI-MX8 Board. Serial console emulator (Tera Term, Putty, etc.). Headphones/speakers. Waveform Audio Format WAV, known for WAVE (Waveform Audio File Format), is a subset of Microsoft’s Resource Interchange File Format (RIFF) specification for storing digital audio files. This format does not apply compression to the information and stores the audio with different sampling rates and bitrates. WAV files are larger in size compared to other formats such as MP3 which uses compression to reduce the file size while maintaining a good audio quality but, there is always some lose on quality since audio information is too random to be compressed with conventional methods, the main advantage of this format is provide an audio file without losses that is also widely used on studio. This files starts with a file header with data chunks. A WAV file consists of two sub-chunks: fmt chunk: data format. data chunk: sample data. So, is structured by a metadata that is called WAV file header and the actual audio information. The header of a WAV (RIFF) file is 44 bytes long and has the following format: How to separate the channels? To separate each audio channel from the recording we need to use the next command that will record raw data of each channel. arecord -D plughw:<audio device> -c<number of chanels> -f <format> -r <sample rate> -d <duration of the recording> --separate-channels <output file name>.wav arecord -D plughw:2,0 -c8 -f s16_le -r 48000 -d 10 --separate-channels sample.wav This command will output raw data of recorded channels as is showed below. This raw data cannot be used as a “normal” .wav file because the header information is missing. It is possible to confirm it if import raw data to a DAW and play recorded samples: So, to use this information we need to create the header for each file using WAVE library on python. Here the script that I used: import wave import os name = input("Enter the name of the audio file: ") os.system("arecord -D plughw:2,0 -c8 -f s16_le -r 48000 -d 10 --separate-channels " + name + ".wav") for i in range (0,8): with open(name + ".wav." + str(i), "rb") as in_file: data = in_file.read() with wave.open(name + "_channel_" + str(i) +".wav", "wb") as out_file: out_file.setnchannels(1) out_file.setsampwidth(2) out_file.setframerate(48000) out_file.writeframesraw(data) os.system("mkdir output_files") os.system("mv " + name + "_channel_" + "* " + "output_files") os.system("rm " + name + ".wav.*") If we run the script, will generate a directory with the eight audio channels in .wav format. Now, we will be able to play each channel individually using an audio player. References IBM, Microsoft Corporation. (1991). Multimedia Programming Interface and Data Specifications 1.0. Microsoft Corporation. (1994). New Multimedia Data Types and Data Techniques. Standford University. (2024, January 30). Retrieved from WAVE PCM sound file format: http://hummer.stanford.edu/sig/doc/classes/SoundHeader/WaveFormat/
記事全体を表示
  Introduction   MATTER chip-tool android APK is a very useful tool for commission, control the MATTER network by smart phone. Vendor can add various features into the APK. It supports build by Android Studio and command line. The official build steps can be found here: https://github.com/project-chip/connectedhomeip/blob/master/docs/guides/android_building.md But the official guide does not cover how to build in a non-GUI linux distribution (without Android Studio installed). This article describes how to build under Ubuntu server. Install Android SDK  Install SDK command line from: https://developer.android.com/studio, And follow the steps: https://developer.android.com/tools/sdkmanager to install.  Install the Android-26 SDK and 23 NDK: $./sdkmanager "platforms;android-26" "ndk;23.2.8568313"  Export env  $export ANDROID_HOME=<SDK path>  $export ANDROID_NDK_HOME=<SDK path>/ndk/23.2.8568313/   Install kotlin (1.8.0)  $curl -s https://get.sdkman.io | bash  $sdk install kotlin 1.8.0  $whereis kotlin  $export PATH=$PATH:<patch of bin of kotlin>    Configure proxy for gradle  $ cat ~/.gradle/gradle.properties  # Set the socket timeout to 5 minutes (good for proxies)  org.gradle.internal.http.socketTimeout=300000  # the number of retries (initial included) (default 3)  org.gradle.internal.repository.max.retries=10  # the initial time before retrying, in milliseconds (default 125)  org.gradle.internal.repository.initial.backoff=500  systemProp.http.proxyHost=apac.nics.nxp.com  systemProp.http.proxyPort=8080  systemProp.http.nonProxyHosts=localhost|*.nxp.com  systemProp.https.proxyHost=apac.nics.nxp.com  systemProp.https.proxyPort=8080  systemProp.https.nonProxyHosts=localhost|*.nxp.com    Configure proxy  Configure proxy for download packages during build export FTP_PROXY="http://apac.nics.nxp.com:8080"  export HTTPS_PROXY="http://apac.nics.nxp.com:8080"  export HTTP_PROXY="http://apac.nics.nxp.com:8080"  export NO_PROXY="localhost,*.nxp.com"  export ftp_proxy="http://apac.nics.nxp.com:8080"  export http_proxy="http://apac.nics.nxp.com:8080"  export https_proxy="http://apac.nics.nxp.com:8080"  export no_proxy="localhost,*.nxp.com"    Patch for gradle java option  This step can be skipped if using OpenJDK16.  Otherwise if you're using OpenJDK 17 (Java 61), you have to upgrade the gradle from 7.1.1 to 7.3, and add java.io open to ALL-UNNAMED:  diff --git a/examples/android/CHIPTool/gradle.properties b/examples/android/CHIPTool/gradle.properties  index 71f72db8c8..5bce4b4528 100644  --- a/examples/android/CHIPTool/gradle.properties  +++ b/examples/android/CHIPTool/gradle.properties  @@ -6,7 +6,8 @@  # http://www.gradle.org/docs/current/userguide/build_environment.html  # Specifies the JVM arguments used for the daemon process.  # The setting is particularly useful for tweaking memory settings.  -org.gradle.jvmargs=-Xmx4096m -XX:MaxPermSize=2048m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8  +#org.gradle.jvmargs=-Xmx4096m -XX:MaxPermSize=2048m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8  +org.gradle.jvmargs=-Xmx4096m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8  --add-opens=java.base/java.io=ALL-UNNAMED  # When configured, Gradle will run in incubating parallel mode.  # This option should only be used with decoupled projects. More details, visit  # http://www.gradle.org/docs/current/userguide/multi_project_builds.html#sec:decoupled_projects  diff --git a/examples/android/CHIPTool/gradle/wrapper/gradle-wrapper.properties b/examples/android/CHIPTool/gradle/wrapper/gradle-wrapper.properties  index 05679dc3c1..e750102e09 100644  --- a/examples/android/CHIPTool/gradle/wrapper/gradle-wrapper.properties  +++ b/examples/android/CHIPTool/gradle/wrapper/gradle-wrapper.properties  @@ -1,5 +1,5 @@  distributionBase=GRADLE_USER_HOME  distributionPath=wrapper/dists  -distributionUrl=https\://services.gradle.org/distributions/gradle-7.1.1-bin.zip  +distributionUrl=https\://services.gradle.org/distributions/gradle-7.3-bin.zip  zipStoreBase=GRADLE_USER_HOME  zipStorePath=wrapper/dists    Build & Install Clone all the modules from github: $git clone --single-branch --recurse-submodules https://github.com/project-chip/connectedhomeip.git Enviroment setup: $source scripts/bootstrap.sh Build: ./scripts/build/build_examples.py --target android-arm64-chip-tool build Install built apk into phone: $adb install out/android-arm64-chip-tool/outputs/apk/debug/app-debug.apk  
記事全体を表示
Hello everyone! In this document you'll find an example on how to setup your own recipe for Yocto Project to add your own custom changes, such as custom device tree, patches, custom drivers, etc. Linux kernel used in this guide 6.1.36_2.1.0 At least 120(250)GB HDD in the host PC Ubuntu 20.04 or later host PC ##Host Setup $ sudo apt install gawk wget git diffstat unzip texinfo gcc build-essential chrpath socat cpio python3 python3-pip python3-pexpect xz-utils debianutils iputils-ping python3-git python3-jinja2 libegl1-mesa libsdl1.2-dev python3-subunit mesa-common-dev zstd liblz4-tool file locales -y $ sudo locale-gen en_US.UTF-8 ##Setup Repo utility $ mkdir ~/bin (this step may not be needed if the bin folder already exists) $ curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo $ chmod a+x ~/bin/repo $ export PATH=~/bin:$PATH ##Git Setup $ git config --global user.name "Your Name" $ git config --global user.email "Your Email" $ git config --list ##Yocto Setup $ mkdir imx-yocto-bsp $ cd imx-yocto-bsp $ repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-mickledore -m imx-6.1.36-2.1.0.xml $ repo sync $ DISTRO=fsl-imx-wayland MACHINE=imx8mp-lpddr4-evk source imx-setup-release.sh -b buildwayland ##Create the new layer $ cd ../sources $ bitbake-layers create-layer meta-newlayer ##Add the new layer to the bblayers.conf in the build directory $ bitbake-layers add-layer meta-newlayer ##Check that it has been added correctly $ tree -L 4 ./meta-newlayer ##Edit the new layer and delete the samples created by yocto $ cd meta-newlayer $ rm -r recipes-example $ rm conf/layer.conf ##Use any text editor to create the layer configuration $ nano conf/layer.conf ##Add the following to the layer configuration file BBPATH .= ":${LAYERDIR}" BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \             ${LAYERDIR}/recipes-*/*/*.bbappend" BBFILE_COLLECTIONS += "meta-newlayer" BBFILE_PATTERN_meta-newlayer := "^${LAYERDIR}/" BBFILE_PRIORITY_meta-newlayer = "8" LAYERSERIES_COMPAT_meta-newlayer = "mickledore" ##Prepare bbappend files so the patches get applied $ mkdir -p recipes-kernel/linux $ cd recipes-kernel/linux $ nano linux-imx_%.bbappend ##Add the following to the .bbappend file FILESEXTRAPATHS:prepend := "${THISDIR}/files:" SRC_URI += "file://001-add-imx8mp-dts-test.patch" PACKAGE_ARCH = "${MACHINE_ARCH}" KERNEL_DEVICETREE:append = " freescale/imx8mp-evk-test.dtb" ##Copy the patches to the layer file path, for this example I have created a simple patch to just rename the default device tree. $ mkdir files $ cp ~/patches/001-add-imx8mp-dts-test.patch files ##Make sure that the layers is created correctly $ bitbake-layers show-layers  ##Finally we bitbake our image $ cd ~/imx-yocto-bsp/buildwayland $ bitbake imx-image-multimedia #All the images built should appear at  <build directory>/tmp/deploy/images/<machine> Hope everyone finds this useful! For any question regarding this document, please create a community thread and tag me if needed. Saludos/Regards, Aldo.  
記事全体を表示