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  

Question: What does it means by depending on load? Is there a value? This is  related with i.MX6D Answer: The comment about the "load" means the total system load on the 2.5V rail. We understand that people design systems, not just MX6 devices. The documentation confusion stems from the design team changing from allowing customers to use the LDOs to power system devices back to just using the LDOs to power the MX6. Reasons - thermals, and also concern for uncontrolled system noise injection into the MX6 and causing failures.

New i.mx6Q core board from OpenEmbed.comNew i.mx6Q core board from OpenEmbed.com

Patch for i.MX6 boards with LPDDR2 using single channel

Assemble wxWidgets version 2.8. TinyX used. Powered by touchscreens 4 "- 8".

Support SSI Master function based on 0001_SSI_ASRC_P2P.patch

Seeing a block diagram in IMX6SLRM 1.5.1, it looks like i.MXSL has Touch Panel Control. Is there interfaces for touch panel  in IMX6SL? Otherwise if I build HW using ADC or GPIO, can I be provided some SW drivers? Regards. The i.MX6 SL does not have embedded touch / ADC interface, sorry. Have a great day, Yuri ----------------------------------------------------------------------------------------------------------------------- Note: If this post answers your question, please click the Correct Answer button. Thank you! ----------------------------------------------------------------------------------------------------------------------- This document was generated from the following discussion: 

Fix cdc_ether connection over usb0 stalls and cannot recover after transmitting few MByte data The patch is modified from ENGR00278073.

Attached is a chunk of the filesystem for the Linux Image https://community.freescale.com/docs/DOC-93887

One chunk of the file system for the Linux Image i.MX 6Dual/6Quad Power Consumption Measurement Linux Image

Attached is a chunk of the filesystem for the Linux Image https://community.freescale.com/docs/DOC-93887

Sometimes we need to use an SPI bus to communicate with sensors or another device. Unfortunately, by default on iMX8MN-EVK, we have the ECSPI2 disabled on our BSP.   We can use that peripheral on Linux enabling it in the device tree.   To enable the ECSPI2 on the device tree we have to add the next on imx8mn-evk.dtsi:     status = "okay"; }; +&ecspi2 { + #address-cells = <1>; + #size-cells = <0>; + fsl,spi-num-chipselects = <1>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_ecspi2 &pinctrl_ecspi2_cs>; + cs-gpios = <&gpio5 13 GPIO_ACTIVE_LOW>; + status = "okay"; + + spidev0: spi@0 { + reg = <0>; + compatible = "rohm,dh2228fv"; + spi-max-frequency = <500000>; + }; +}; + &fec1 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_fec1>;   On iomux node:   + pinctrl_ecspi2: ecspi2grp { + fsl,pins = < + MX8MN_IOMUXC_ECSPI2_SCLK_ECSPI2_SCLK 0x82 + MX8MN_IOMUXC_ECSPI2_MOSI_ECSPI2_MOSI 0x82 + MX8MN_IOMUXC_ECSPI2_MISO_ECSPI2_MISO 0x82 + >; + }; + + pinctrl_ecspi2_cs: ecspi2cs { + fsl,pins = < + MX8MN_IOMUXC_ECSPI2_SS0_GPIO5_IO13 0x40000 + >; + }; + pinctrl_ir_recv: ir-recv { fsl,pins = < MX8MN_IOMUXC_GPIO1_IO13_GPIO1_IO13 0x4f    after modifying and compiling the device tree you can see the device active like this:     Connection:   Test: spidev_test -D /dev/spidev1.0 -v       You can use the devsheell of yocto to make the changes:   https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/How-to-use-Devshell-to-compile-device-tree-files/ta-p/1727428

Attached is a chunk of the filesystem for the Linux Image https://community.freescale.com/docs/DOC-93887

HI, I want to build an Ubuntu Linux operating system with LTIB, but from the user guide the host system is Ubuntu 9.04, but we can't use 'apt-get install' any package due to there are no source lists. What should we do next? Thank you!

Attached is a chunk of the Filesystem needed to construct the Linux Image https://community.freescale.com/docs/DOC-93887

Symptoms   On i.MX8MP, when inputting a 80% duty, 0.4V-1.8V, 3KHz square wave, we observed that the system may hang. We also tested i.MX8MN and i.MX8MM and observed the same phenomenon. In i.MX8MN RM, there's a note in GPC chapter:     We believe that the issue described in this note exists not only in the iMX8MN, but also in the iMX8MP and iMX8MM. Meanwhile, there is not only a problem with power down in this issue, but also a problem with wait mode. Diagnosis   In debugging, we find that avoiding accessing LPCR_A53_AD register in imx_set_cluster_powerdown can fix the issue. So we think that due to frequently power up/down of cores, cores have chances failed to power up. When the IRQ behavior become more complex, because the IRQ is an async event, it will come in any time. if the wait mode is enabled, in some conner case, the GPC internal LPM mode state machine will run into problem, then lead to system failure. Solution   1. A workaround patch that bypass the wait mode setting during the cpuidle.. See the patch attached. 2. Will add the Note about "SCU power down should not be enabled in wait mode" to i.MX8MP and i.MX8MM RM. 3. Will try to identify this issue into errta document, ticket TKT0632147.

  Some customer need to config different I2C bus for their PMIC in DDR test period. There is a simple method can complete this, that is NXP DDR Config Tool. The tool download link is below: https://www.nxp.com/design/development-boards/i-mx-evaluation-and-development-boards/config-tools-for-i-mx-applications-processors:CONFIG-TOOLS-IMX I'm going to use the i.MX 93 EVK board here as a demonstration. On i.MX 93 EVK board, the default PMIC I2C Bus is I2C2, I will show you how to change I2C2 to I2C1, the other i2c bus is same.  Step 1 : Rework the board and make sure the PMIC is connected to I2C1. Remove R714 R715, connnect I2C1_SCL(C20) to U701 pin 41  and I2C1_SDA(C21) tp U701 pin 42. Step 2 : Setup I2C1 PinMux: Config Tool UI:   Advance -> IOMUX config   Command:           Address                Size               Value memory   set     0x443c0170            32                   0x10 memory   set     0x443c0174            32                   0x10 memory   set     0x443c0320            32                   0x40000b9e memory   set     0x443c0324            32                   0x40000b9e Step 3 : Set PMIC VDDQ as 1.1 V Config Tool UI:   Advance -> Custom PMIC initialization enabled   #  PMIC commands        Value 0         pmic_cfg             0x0025       /*I2C bus 1,  PMIC address 0x25 */ (0 for I2C1, 1 for I2C2, 2 for I2C3, 3 for I2c4 …) 1         pmic_set             0x0C29       /* BUCKxOUT_DVS0/1, preset_buck1=0.8V, preset_buck2=0.7V, preset_buck3=0.8V PCA9451_BUCK123_DVS, 0x29 */ 2         pmic_set             0x1118      /*  BUCK1OUT_DVS0=0.9V   PCA9451_BUCK1OUT_DVS0, 0x18 */ 3         pmic_set             0x1718      /*  BUCK3OUT_DVS0=0.9V   PCA9451_BUCK3OUT_DVS0, 0x18 */ 4         pmic_set             0x1428      /*  Set VDDQ to 1.1V  PCA9451_BUCK2OUT_DVS0, 0x28  */ PS : About pmic register, The first two bytes are the register address and the next two bytes are the register setting. Step 4 : Run the DDR "Firmware init test" and see the test result. The success log is as follows: DEBUG memtool.comm.serial_channel ==================hardware_init======================= DEBUG memtool.comm.serial_channel DEBUG memtool.comm.serial_channel Power up ddr... DEBUG memtool.comm.serial_channel DEBUG memtool.comm.serial_channel DDRMIX power on done... DEBUG memtool.comm.serial_channel DEBUG memtool.comm.serial_channel DDRPHY coldreset... DEBUG memtool.comm.serial_channel DEBUG memtool.comm.serial_channel DEBUG memtool.comm.serial_channel DEBUG memtool.comm.serial_channel ********Found PMIC PCA945X********** DEBUG memtool.comm.serial_channel DEBUG memtool.comm.serial_channel Set VDDQ to 1.1V for LPDDR4 DEBUG memtool.comm.serial_channel DEBUG memtool.comm.serial_channel ==================hardware_init exit==================    

Purpose: Introduce how to debug M4 using trace 32 and the difference with regular debug mode for imx6sx. If you are using other jtag debug tools, maybe you need to do the similar configuration. Debug tools: Trace32 – you can refer to http://www.lauterbach.cn/ for more information about this tool.

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.