Eshtaartha Basu
Forum Replies Created
We carefully reviewed the remoteproc initialization log which was shared previously.
The line “[00000.000][INFO ]Cortex-M4 boot successful with STM32Cube FW version: v1.6.0” indicates that M4 firmware was built using STM32CubeMP1 Firmware v1.6.0. “OSD32MP1-BRK OpenSTLinux | Version: 3.0.1” official image is not compatible with “STM32CubeMP1 Firmware v1.6.0”
Please rebuild the M4 firmware using STM32CubeMP1 Firmware v1.4.0 and try again.
(STM32CubeMP1 FW v1.4.0 – https://github.com/STMicroelectronics/STM32CubeMP1/tree/1.4.0)We also re-validated the operation of RPMSG framework using “OpenAMP_TTY_echo” project:
STM32CubeMP1-1.4.0/Projects/STM32MP157C-DK2/Applications/OpenAMP/OpenAMP_TTY_echoValidation screenshot attached.
Arcady,
The device tree snippet posted doesn’t look correct. By referencing “uart0”, “uart1”, “uart2” without preceding “&”, you’re re-defining the UARTx peripheral definition instead of referencing and updating existing base definition.
The base UARTx device tree definitions are already present in the lower level DTS files (one of the many “include” files). For example:
uart1: serial@48022000 {compatible = “ti,am3352-uart”, “ti,omap3-uart”;ti,hwmods = “uart2”;clock–frequency = <48000000>;reg = <0x48022000 0x2000>;interrupts = <73>;status = “disabled”;dmas = <&edma 28 0>, <&edma 29 0>;dma–names = “tx”, “rx”;};To reference the above definition, enable the peripheral and update pinmux, you need to just refer the existing node’s name with “&” prefix as follows:
&uart1 {
pinctrl-names = “default”;
pinctrl-0 = <&uart1_pins>;
status = “okay”;};
After applying the above fixes and building your DTB, you can double check how the final UARTx node looks like (base definition + your custom updates) by “disassembling” your DTB blob as shown in the link below. This is the fastest way to figure out if your custom updates are actually being reflected in the final DTB.
https://stackoverflow.com/questions/21670967/how-to-compile-dts-linux-device-tree-source-files-to-dtbThere is a typo in the response you listed. As shown in the “Product Number Information” section of the OSDZU3 Datasheet (screenshot attached) and “VCCO_PSIO_500” section of the OSDZU3 datasheet (screenshot attached):
OSDZU3EG1-2G-xFA uses NOR QSPI with 3.3V IO. QSPI is connected to the XCZU3 through Bank 500 I/O and this requires Bank 500 to use 3.3V IO. eMMC interface is also on Bank 500. So, OSDZU3EG1-2G-xFA production parts support QSPI boot and does not support eMMC boot (eMMC boot is only supported with 1.8V IO).
OSDZU3EG1-2G-xFB uses NOR QSPI with 1.8V IO. This requires Bank 500 IO to be 1.8V as well. As a result, OSDZU3EG1-2G-xFB production parts support both QSPI and eMMC boot.Note: If you intend to use an external QSPI in addition to the QSPI integrated within the OSDZU3 SiP, please make sure to match the part number and IO voltage.
Hello FLeblanc OTI,
Once you create a project using the OSDZU3 Petalinux 2023.1 BSP, you can find an if/else statement in “weston.env” file under “meta-osdzu3” layer at:
<your_bsp_project_dir>/project-spec/meta-osdzu3/recipes-graphics/wayland/weston-init/weston.env. The function helps choose between LVDS and DP outputs. For debugging, you could modify this function to your liking and see how things change. Screenshots attached.However, the recommended approach for long term modifications to the behavior is to create your own custom meta-user layer, add the layer to the project and override the graphics settings of meta-osdzu3 from your layer. Your own custom user layer would help you modify several other settings of the project as well, all under one layer, without touching/modifying the official layers underneath.
Attachments:
Hello Carel,
Asserting nPONKEY and WAKEUP (PC13) do not work in your use case because your PMIC is in ALTERNATE (Low Power) mode and not in OFF state/NO_SUPPLY state since PWR_ON/PMIC_PWRCTRL pin is asserted by RTC.
As indicated by PMIC datasheet, the STPMIC1 offers 2 independent POWER_ON modes called MAIN and ALTERNATE.
Switching between these modes is driven by the application processor through PWRCTRL pin.See highlighted sentences of the attached screenshots from the official documentation for more information. If you have access to PWR_ON/PMIC_PWRCTRL pin on your board, you can probe it to see how its state changes between “sleep” and “wake-up”.
