gil_he

Forum Replies Created

Viewing 15 posts - 1 through 15 (of 63 total)
  • Author
    Posts
  • in reply to: STPMIC1 DDR voltage rails #14897
    Gil Hershmangil_he
    Participant

      Hi Neeraj,

      Thank you.

      Can you please read what I enclosed below and comment on that? (from your knowledge).
      (1)
      My guess it that SDMMC initialization procedure in the TF-A powers the SDMMC device off/on (maybe to bring it to some initial state) and by removing this line, the TF-A code will not know which supply to toggle, so it will not perform it.
      So, the instability/oscillations in BUCK4 (due to the off/on) will not happen, thus will not affect the eMMC.

      (2)
      Then you wrote “In case of v3v3 supply of the sdmmc, you cannot do a power cycle of the sdmmc at tf-a level (because you will switch off almost all the platform). But this is not an issue because the romcode has already done it before.”
      I assume this is another justification to remove this line from the TF-A dts.

      (3)
      Can you describe what this patch does?
      (From you knowledge of the patch syntax, if you are familiar with it). I enclosed the patch.

      thank you

      Gil

      • This reply was modified 3 months ago by Gil Hershmangil_he.
      Attachments:
      in reply to: STPMIC1 DDR voltage rails #14886
      Gil Hershmangil_he
      Participant

        Hi Neeraj,

        I looked into the links you sent.

        I compiled and sent few questions to the person who submitted the patch in ST.

        That was five days ago and no reply from him.

        Please take a look and see if you can assist.

        ************************************************************************
        We encountered this issue just recently. Every few power-ons, the system is stuck and we get the messages as described at the beginning of the thread. Resetting the PMIC / STM32MP153C solves this.

        At first you suggested to remove the line for vmmc-supply from the TF-A dts.

        My guess it that SDMMC initialization procedure in the TF-A powers the SDMMC device off/on (maybe to bring it to some initial state) and by removing this line, the TF-A code will not know which supply to toggle, so it will not perform it.

        So, the instability/oscillations in BUCK4 (due to the off/on) will not happen, thus will not affect the eMMC.

        Then you wrote “In case of v3v3 supply of the sdmmc, you cannot do a power cycle of the sdmmc at tf-a level (because you will switch off almost all the platform). But this is not an issue because the romcode has already done it before.”

        I assume this is another justification to remove this line from the TF-A dts.

        In my case, our custom board connects v3v3 (BUCK4) to both vmmc and vqmmc supplies.

        So, should I remove both lines (vmmc-supply = <&v3v3>; vqmmc-supply = <&v3v3>) from the TF-A dts?

        Then, you wrote: “After internal discussions, we will deploy a correction that will have the same effect as the previous solution. So you can go on with it on your side.”

        And, suggested a fix: a patch, to be applied to “regulator_core.c” (a file in the TF-A package).

        Can you describe what this patch does?

        What do you suggest we do? Apply the patch or modify the TF-A dts file?

        *****************************************************************

        thank you

        Gil

        • This reply was modified 3 months, 1 week ago by Gil Hershmangil_he.
        in reply to: STPMIC1 DDR voltage rails #14869
        Gil Hershmangil_he
        Participant

          hello Neeraj,

          RANK 0 voltages, that we actively use, include BUCK2 (VDD_DDR) and the voltages that derive from it, LDO3/VTT_DDR and VREF_DDR.

          We don’t use the other power rails that are RANK 0: LDO1, LDO2, LDO6.

          However, I measure 0V on all of them.

          This “erratic” behavior was observed on at least 4-5 boards (out of the 18 we assembled).

          We use an eMMC Flash which has FSBL, SSBL, Linux, etc., on it.

          I managed to capture the boot log when the issue happens.

          Enclosed a text file with failing (problematic power-up) and successful boot logs.

          I can understand why RANK 0 voltages are not there. It didn’t reach the place where they are intialized and enabled.

          I am not able to accurately pin point where, during boot, the system fails.

          Is it during the SoC PROM execution?

          Was it able to load FSBL1 from the eMMC Flash?

          What is CMD13?

          Is everything we see in the boot log is a result of the SoC running its PROM code?

          Meaning initial access to eMMC fails?

          thanks,

          Gil

           

          • This reply was modified 3 months, 2 weeks ago by Gil Hershmangil_he.
          • This reply was modified 3 months, 2 weeks ago by Gil Hershmangil_he.
          • This reply was modified 3 months, 2 weeks ago by Gil Hershmangil_he.
          Attachments:
          in reply to: STPMIC1 DDR voltage rails #14834
          Gil Hershmangil_he
          Participant

            Hi Michal,

            I am thinking:

            The FSBL initializes the clock and DDR, then loads the SSBL into the DDR and executes it.

            Is there a known sequence that the FSBL follows when it initializes, before loading the SSBL?

            Maybe we fail in some early stage of the FSBL init (clock initialization for example) and do not reach the stage where the DDR and DDR power (BUCK2) are initialized, and that is why BUCK2 is not defined as 1.35V and/or is not turned on?

            thanks,

            Gil

             

            • This reply was modified 3 months, 3 weeks ago by Gil Hershmangil_he.
            in reply to: STPMIC1 DDR voltage rails #14828
            Gil Hershmangil_he
            Participant

              Hi Michal,

              Thank you for the prompt response.

              So, we have the ROM code in the STM32MP that loads the FSBL, from the eMMC flash, in the internal RAM and executes it.

              the FSBL initializes the clock and DDR, then loads the SSBL into the DDR and executes it.

              In our case, BUCK2=0V (VDD_DDR).

              FSBL should change the default voltage to 1.35V and enable it. I assume it does that via I2C4.

              The TF-A dts file you shared is very similar to what we use (I attached what we use).

              Is there any difference between the TF-a dts files that might cause this issue?

              It seems we have something marginal here since it only happens once every 5-10 power ups.

              In addition, NRST solves this.

              NRST resets the ST as well as the STPMIC1.

              thanks,

              Gil

               

              • This reply was modified 3 months, 3 weeks ago by Gil Hershmangil_he.
              • This reply was modified 3 months, 3 weeks ago by Gil Hershmangil_he.
              Attachments:
              in reply to: Linux Kirkstone 5.15 #14640
              Gil Hershmangil_he
              Participant

                Hi Neeraj,

                The log level is at its maximum.

                As soon as the kernel takes control, something goes wrong.

                It doesn’t even reach a point where it can send a message to the UART so we can see it.

                We saw a similar issue in some ST forum and it was suggested that there is a dependency between the kernel and UBOOT versions.

                We will follow what you suggested and see how it goes.

                thanks,

                Gil

                in reply to: Linux Kirkstone 5.15 #14631
                Gil Hershmangil_he
                Participant

                  hello Neeraj,

                  Another question:
                  The U-Boot version we use is the one that comes with Dunfell:  version: 2020.10

                  Should we use a more updated UBOOT version?

                  Are there any dependencies between the Linux kernel version and the UBOOT version?

                  thanks,

                  Gil

                  • This reply was modified 7 months ago by Gil Hershmangil_he.
                  in reply to: Linux Kirkstone 5.15 #14627
                  Gil Hershmangil_he
                  Participant

                    hello Neeraj,

                    Please see the attached files for details (“main” then “5_15_67_log”).

                    Do you have any suggestions for us?

                    thanks,

                    Gil

                    in reply to: Linux Kirkstone 5.15 #14558
                    Gil Hershmangil_he
                    Participant

                      hello Neeraj,

                      We see an issue with how the device tree is handled in 5.15.67 versus 5.10 and 5.15.24.

                      Please see the attached file for details.

                      How do we proceed from here?

                      thank you

                      Gil

                      Attachments:
                      in reply to: Linux Kirkstone 5.15 #14555
                      Gil Hershmangil_he
                      Participant

                        hello Neeraj,

                        Adding information to my above message:

                        We downloaded the kernel source from ST’s repository (where all the ST patches are already applied).

                        Some of the patches from the 5.15.24 do fail on the 5.15.67, but 14 patches fully pass.

                        So, some patches from the 5.15.24 are required for the 5.15.67. And some fail since they are already applied.

                        So, we can try and manually correct the failing patches.

                        Question is: Do we need also Octavo-created patches to be applied to the build of the 5.15.67 based Linux, so it can run on the Octavo SiP we use?

                        Will the 5.15.24 Octavo patches run successfully on the 5.15.67 sources? Are those enough, from Octavo, for the 5.15.67?

                        thank you

                        Gil

                        • This reply was modified 7 months, 1 week ago by Gil Hershmangil_he.
                        in reply to: Linux Kirkstone 5.15 #14554
                        Gil Hershmangil_he
                        Participant

                          hello Neeraj,

                          Well, totally eight of the patches fail.

                          We need kernel version 5.15.67 (or later) for the SPI slave support. Do you know if the kernel code from ST, you directed me to, is what we need?

                          Are all the required patches from ST only? Doesn’t we need also Octavo-created patches to be applied to the build of the 5.15.67 based Linux, so it can run on the SiP we use?

                          thanks,

                          Gil

                          in reply to: Linux Kirkstone 5.15 #14539
                          Gil Hershmangil_he
                          Participant

                            Hi Neeraj, Eshtaartha,

                            I input the information to three text files.

                            Please read them in this order: first.txt, second.txt, third.txt.

                            It is more updated and detailed than what I sent Martin.

                            Thank you

                            Gil

                            • This reply was modified 7 months, 1 week ago by Gil Hershmangil_he.
                            in reply to: Linux Kirkstone 5.15 #14536
                            Gil Hershmangil_he
                            Participant

                              Hi Neeraj, Eshtaartha,

                              Thank you.

                              I am unable to reply to you with the full information I need to enclose.

                              I just sent an email to Martin Burgos, asking him to forward it to you.

                              thank you

                              Gil

                              in reply to: Linux Kirkstone 5.15 #14526
                              Gil Hershmangil_he
                              Participant

                                Dear Eshtaartha,

                                Thank you for your reply.

                                We followed the guidelines.

                                The meta-layer Kirkstone support has Linux version 5.15.24.

                                It DOES NOT support SPI slave configurations.

                                Only from Linux version 5.15.67 SPI slave is supported.

                                Can we build the 5.15.67 Linux version and use the patches in your 5.15.24 version support?

                                thanks

                                Gil

                                 

                                in reply to: Error: Start operation failed at partition 0x01 #13348
                                Gil Hershmangil_he
                                Participant

                                  Hi Neeraj,

                                  The gibberish was shown using two different usb-serial adapters.

                                  I know these adapters connect successfully to a 3.3V serial bus.

                                  The only explanation I can find is that the stlink is specifically required to interpret correctly the SoC uart data.

                                  I assume this can be verified with ST.

                                  thanks

                                  Gil

                                Viewing 15 posts - 1 through 15 (of 63 total)