gil_he

Forum Replies Created

Viewing 15 posts - 16 through 30 (of 74 total)
  • Author
    Posts
  • 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 10 months, 3 weeks ago by Gil Hershmangil_he.
      • This reply was modified 10 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 1 year, 1 month 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 1 year, 2 months 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 1 year, 2 months 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

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

                            Hi Neeraj,

                            Behavior is the same in BRK, RED and in our board.

                            The UART in the SiP sends the correct baud rate. In addition, electrically, the signals are correct.

                            It seems the debugger is sending the ascii symbols properly, and the terminal shows them correctly.

                            When connecting the SiP directly to a serial to usb and to a pc, I see gibberish.

                            The only explanation I have is, something in the debugger (fw or hw) translates the SiP uart correctly to the terminal.

                            Gil

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

                              hi Neeraj,

                              An update:

                              I was able to receive readable uart4 output (not gibberish) ONLY when using the STLINK (as a uart to usb interface).

                              Direct connection of the SiP uart interface (via generic serial to usb), using numerous terminals, showed only gibberish.

                              thanks

                              Gil

                               

                               

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

                                Hi Neeraj,
                                1. We don’t use a chip like the STUSB1600. The SiP USB port is connected directly to the type c connector (as I described above).
                                The type C is just a connector. We work with it as if it’s USB2.
                                The CC pins are NC in the type C connector.
                                See attached picture. We also don’t use the OTG_HS_ID.
                                Setting on the CubeMX is OTG/Dual_Role_Device Type C and checked “Activate_VBUS”.
                                To your understanding, is that ok?

                                2. I tried many different setups using Putty. Always giberish.
                                I will further debug the uart4.

                                thanks

                                Gil

                                • This reply was modified 2 years, 4 months ago by Gil Hershmangil_he.
                                Attachments:
                                in reply to: Error: Start operation failed at partition 0x01 #13315
                                Gil Hershmangil_he
                                Participant

                                  hello Neeraj,

                                  (1)

                                  Regarding the USB configuration:

                                  We have the USB port in the SiP connected to a USB Type C connector.

                                  VBUS in the connector is connected to the SiP.

                                  Our device will act as a peripheral (device) and DRD. PA10 is not connected.

                                  The only pins connected to the type C are USBDP2/DM2 and OTG_VBUS.

                                  See enclosed picture from CubeMx: We defined OTG/Dual_Role_Device Type C and checked “Activate_VBUS”.

                                  Is the following setup correct?

                                  (2)

                                  We don’t have any other UART pins, in the SiP, that can be routed to the debug connector.

                                  The only pins are for UART4 but not the default ones, so, until we change it (in UBOOT), we cannot use it.

                                  (3)

                                  We connected the UART4 connector in the Octavo BRK and RED, and see giberish on the terminal.

                                  Trying all available settings (translations, com settings) did not help.

                                  Why can’t we see clearly the logs on uart4?

                                  thanks

                                  Gil

                                  • This reply was modified 2 years, 4 months ago by Gil Hershmangil_he.
                                  Attachments:
                                Viewing 15 posts - 16 through 30 (of 74 total)
                                chatsimple