coloradocarlos

Forum Replies Created

Viewing 15 posts - 16 through 30 (of 41 total)
  • Author
    Posts
  • in reply to: Kirkstone #12682
    coloradocarlos
    Participant

      Yes, for the last 6 weeks I was getting messages to the effect that my posts were waiting to be moderated. Nothing was showing up.

      in reply to: Kirkstone #12680
      coloradocarlos
      Participant

        Testing 1, 2, 3. Did this post go through?

        in reply to: PA0 and PC13 wakeups #12583
        coloradocarlos
        Participant

          We reviewed using the line in PMIC_PONKEYn and decided that there is some risk in using it. The PONKEYn is not only used for power on but for shutdown too. A spurious signal could cause the board to shutdown unexpectedly.

          To be more specific, PC13 can be the RTCOUT1 output during VBAT mode (I found you need to set the right bits in RTC_CR). This could complicate using PC13 for external events to trigger a wakeup. Given this background, is PC13 a supported input or is it considered “for internal use only”?

          in reply to: Dunfell and PONKEY poweroff #12559
          coloradocarlos
          Participant

            Sorry, I found the solution, I should have updated this topic with the fix.

            Indeed systemd is controlling the power key event and needs to be changed to respond to poweroff.

            To troubleshoot, first determine if the root user session is ignoring the power key.

            If HandlePowerKey=ignore, then run systemd-analyze to find out where it is set.

            The key is ignored in /lib/systemd/logind.conf.d/01-openstlinux.conf. Apparently, ST didn’t think it was a good idea to respond to a PONKEYn to poweroff a board.  To override, create a file in /lib/systemd/login.conf.d/ named  02-osd32mp1-myboard.conf

            Then restart systemd-logind:

            I fixed this in my own Yocto layer with a custom bbappend. Should this be changed in the Octavo layer? I don’t know. Depends on what you think the PONKEYn should do or not while the system is running.

            One other gotcha. In the TF-A device tree, the STM32_PM_SHUTDOWN may not be honored. In other words, suspends but not a total poweroff and you encounter a watchdog timeout which reboots the board. The workaround is to emit a message to the console in stm32mp1_pm.c.  See this link for details: https://github.com/Seeed-Studio/meta-st-odyssey/issues/5. Happy patching!

            in reply to: Kirkstone #12472
            coloradocarlos
            Participant

              ST announced today (6/30/2022) STM32MPU ecosystem release v4.0.0 with kirkstone support: https://community.st.com/s/question/0D53W00001dwKXQSA2/stm32mpu-ecosystem-release-v400-release-is-online-

              in reply to: PMIC_VBUSOTG and OTG_VBUS hookup for USB Type-C #12377
              coloradocarlos
              Participant

                I reviewed the Getting Started documentation and it appears that the OTG_ID pin is used only for USB Micro-AB connectors. In other words, it is not used for USB Type-C connectors. Same for VBUS– it can’t be used directly unless there is an intermediate circuit such as the STUSB1600 that can detect role switches. Is this correct?

                in reply to: SPI Clock issue #12278
                coloradocarlos
                Participant

                  Ashvin,

                  I am having technical trouble viewing your recent correspondence.

                  You asked about SPI code running on the MCU. Try running one or more of these demos for the DK2. With slight modification, they run on the Octavo line of SIP’s:

                  https://github.com/STMicroelectronics/STM32CubeMP1/tree/master/Projects/STM32MP157C-DK2/Examples/SPI

                  Also the PZ0, etc. pins are secure pins defined in pinctrl_z. You may need to review the secure bootloader DTS configuration in TF-A or OP-TEE. I worry you may be having problems due to the security mechanism. Try the unsecure pins and see if you have the same problems.

                  Regards, Carlos

                  in reply to: Low power modes using Debian on OSD32MP1-BRK #12242
                  coloradocarlos
                  Participant

                    The suspend to “s2idle” is interesting. I would expect “deep” for the low power modes. Transitioning to low power is a bit more complicated because it includes coordination between the MPU and MCU. Are you running an app (firmware) on the M4 that happens to be using DMA? Try stopping the firmware and see if you can duplicate the behavior.

                    in reply to: SPI Clock issue #12212
                    coloradocarlos
                    Participant

                      Is the same behavior observed on the SPI CLK pin(s) for an unmodified version of the SD card image from Octavo? Which version of the kernel (SD card image) are you using? On the A7 side, is the “SPI communications” you are using the Linux spidev driver?

                      in reply to: Low power modes using Debian on OSD32MP1-BRK #12205
                      coloradocarlos
                      Participant

                        If you refer to the DMA driver in stm32-dma.c, the suspend code checks the EN bit (Stream Enable) in register DMA_SxCR. See page 1217 of the RM0436 which states:

                        Bit 0 EN: stream enable / flag stream ready when read low
                        This bit is set and cleared by software.
                        0: stream disabled
                        1: stream enabled
                        This bit may be cleared by hardware:
                        – on a DMA end of transfer (stream ready to be configured)
                        – if a transfer error occurs on the AHB master buses
                        – when the FIFO threshold on memory AHB port is not compatible with the size of the burst

                        So something related to the DMA controller. Of interest is the AHB. By any chance, do you have a ST-LINK debugger connected to BRK board?

                        Carlos

                        in reply to: How to change or add board name in OSD32MP1 Debian SDK #12019
                        coloradocarlos
                        Participant

                          Another thing to check for is the file arch/arm/dts/osd32mp1-xyz-u-boot.dtsi. I didn’t see it in your original list of files that you copied but is created by 0001-Add-OSD32MP1-RED-Device-Tree-support.patch. This is the “U-Boot DTSI options” file. The build will succeed even if this file does not exist. Even though it is an “include file”, it is not included anywhere and is build separately (if it exists). See line 165 of scripts/Makefile.lib to see what I mean.

                          in reply to: How to change or add board name in OSD32MP1 Debian SDK #12015
                          coloradocarlos
                          Participant

                            You are on the right track because I have done something similar to successfully rename the board.

                            Since U-Boot seems to be failing, I suggest first checking in ./deploy/bootfs. Make sure the directory layout and files are correct. In particular, make sure the extlinux.conf file points to the right DTB.

                            If all seems well, then rebuild the file system by running “make bootfs” in the docker container. This will make sure the *.stm32 file is up-to-date. Then try re-flashing.

                            Lastly, you should always be able to boot off a good SD card regardless of the state of the eMMC. Sometimes I forget to reset the boot switches after flashing.

                            in reply to: Debian 10 Header Files #12001
                            coloradocarlos
                            Participant

                              Are you using the Docker container provided by Octavo to build your binaries? It works great and the environment is set up to cross-compile for the arm:

                              in reply to: OSD32MP1-BRK Debian Build Steps #11984
                              coloradocarlos
                              Participant

                                Part of the Debian build process is setting the type of bootloader images to build. I am trying reproduce the Debian build steps for the BRK board and would like to know if we should be using “basic” build versus the “trusted” build. So rather than using the trusted image for the FSBL, we should use U-Boot SPL instead.

                                The reason I say this is the SD card image boots up with this message to the console:

                                U-Boot SPL 2018.11-stm32mp-r4 (May 07 2020 – 20:20:42 -0500)
                                Model: Octavo Systems OSD32MP1-BRK Board
                                RAM: DDR3-1066/888 bin G 1x4Gb 533MHz v1.45
                                Trying to boot from MMC1

                                Since I am using a custom board with the 800 MHz processor, U-Boot displays “basic mode” for the STM32MP157F:

                                U-Boot 2018.11-stm32mp-r4 (May 07 2020 – 20:20:42 -0500)

                                CPU: STM32MP157F?? Rev.Z
                                Model: Octavo Systems OSD32MP1-BRK Board
                                Board: stm32mp1 in basic mode (st,stm32mp157c-brk)
                                DRAM: 512 MiB

                                in reply to: How to read OSD32MP1-RED CPU/SiP Temperature in Debian Image #11900
                                coloradocarlos
                                Participant

                                  Here is a script that works on the BRK to display the ADC temperatures. I found that the temperature device driver is disabled on the RED so you will need to enable it in the device tree for this to work.

                                  EDIT: I am not sure why stray HTML tags are getting injected in the code block below. You will need to fix this before running the script.

                                   

                                  • This reply was modified 3 years ago by coloradocarlos. Reason: weird html chars in code block
                                  • This reply was modified 3 years ago by coloradocarlos. Reason: Note the odd HTML tags in the post
                                Viewing 15 posts - 16 through 30 (of 41 total)