coloradocarlos

Forum Replies Created

Viewing 15 posts - 1 through 15 (of 41 total)
  • Author
    Posts
  • in reply to: USB only works for RNDIS #13739
    coloradocarlos
    Participant

      Julius,

      The BRK appears as a USB “peripheral” for RNDIS networking support. You confirmed that this works.

      Now you want to switch roles and have the OTG work as a “host”. In “host” mode, the OTG can be configured to provide power to the device such as a WIFI dongle. I assume that you are using an OTG cable since the Edimax is a USB Type-A peripheral and the BRK board is a USB Type-B micro. The cable has circuitry to inform the OTG that a peripheral is attached.

      It is not clear if the role switch is occurring and I don’t recall off the top of my head if the BRK has circuitry for VBUS and ID (and, of course, power supply pins other than USB). For testing your custom design, I would suggest you set in the device tree under the usbotg_hs node dr_mode = “peripheral”, usb-role-switch, and role-switch-default_mode = “peripheral”.

      ST has a page on configuring OTG: https://wiki.st.com/stm32mpu/wiki/OTG_device_tree_configuration.  Take a look at the example in section 3.3.5.

      Carlos

      in reply to: Waking up from sleep. #13729
      coloradocarlos
      Participant

        Carel,

        The other thing you should check is to make sure the pwr_regulator node in the TF-A device tree is what your want.

        system_off_soc_mode can be either <STM32_PM_SHUTDOWN> or <STM32_PM_CSTOP_ALLOW_STANDYBY_DDR_OFF>.

        Carlos

        in reply to: VDD (buck3) still on after “poweroff” cmd #13578
        coloradocarlos
        Participant

          Sylvain,

          This forum has been absorbing my replies. That is why you probably didn’t see it. I am surprised it showed up eventually.

          Carlos

          in reply to: Ethernet troubles in U-Boot #13545
          coloradocarlos
          Participant

            Austin,

            I have found several issues with the ST implementation of the DWC QOS drivers (dwc_eth_qos.c). I have not confirmed but it appears that the MAC clocks are stopped and the “mdio” and “mii” commands will get stuck and you will see a cryptic “not idle at entry” error. I found that the substitute is to run “ethtool eth0” in Linux instead and not use U-Boot’s equivalent.

            However, you can get dhcp to work. First, confirm your MAC address:

            > env print ethaddr

            If you don’t have one, make one up for now:

            > env set ethaddr 11:22:33:44:55:66

            The run:

            > dhcp

            You should get an IP address. Then “ping” your gateway and it should respond.

            Carlos

            in reply to: VDD (buck3) still on after “poweroff” cmd #13511
            coloradocarlos
            Participant

              Sylvain,

              You may want to check your device tree settings as they affect the behavior of Linux shutdown and the configuration of the PMIC regulators when the board transitions to another low-power state.

              The first is the “standby-ddr-off” node. The TF-A device tree in the BRK dunfell branch has this set to “regulator-on-in-suspend” for vdd (buck3).

              https://github.com/octavosystems/meta-octavo-osd32mp1/blob/35adfcaff2d3d27eed1a496181d52ab9b6c81e7b/recipes-bsp/trusted-firmware-a/files/0001-Add-OSD32MP1-BRK-Device-tree-support.patch#L339

              The second is the “system_off_soc_mode”. The dunfell device tree shows this to be “STM32_PM_CSTOP_ALLOW_STANDBY_DDR_OFF”.

              https://github.com/octavosystems/meta-octavo-osd32mp1/blob/35adfcaff2d3d27eed1a496181d52ab9b6c81e7b/recipes-bsp/trusted-firmware-a/files/0001-Add-OSD32MP1-BRK-Device-tree-support.patch#L512

              I believe what you are observing with “shutdown” is the SOC in standby/suspend with the DDR powered off but the VDD regulator on.

              If you want a complete PMIC shutdown, then you may want to consider “STM32_PM_SHUTDOWN” instead.

              Which mode to use depends on your requirements, for instance, you may want to use one of the special GPIO’s pins to wakeup from standby. In this case, leaving VDD powered up will facilitate this. The Octavo website has a good writeup on using the low-power states.

              Carlos

              in reply to: VDD (buck3) still on after “poweroff” cmd #13512
              coloradocarlos
              Participant

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

                in reply to: ADC and DAC not working #13384
                coloradocarlos
                Participant

                  (I tried to post this response last week, but it didn’t seem to go through.)

                  By default, regulators are disabled if there are no consumers. The idea is if a regulator is not supplying power to anything (consumers), it can be safely turned off.  This is what you are seeing in dmesg. Once a consumer is enabled, the regulator is also re-enabled.

                  If you have debugfs enabled, then you may be able to see where vdda is being used in the regulator tree:

                  # less /sys/kernel/debug/regulator/regulator_summary

                  I suspect that vdda is not configured as a supply or the device tree node is not status=okay. Can you post your adc and dac nodes in your device tree?

                  Carlos

                  in reply to: RNDIS Host not working #12999
                  coloradocarlos
                  Participant

                    The schematic is very helpful and a useful visual. This allows us to review chapters 60, 61, and 62 of RM0436.

                    BRK-A is not bringing up RNDIS because it doesn’t get that far in the initialization. Try “lsusb -v | grep -i gadget” and see if the “Linux Foundation Multifunction Composite Gadget” shows up as one of the devices that are detected. If the Gadget does not come up, then none of the supported “gadgets” like RNDIS will not work. You can also try “lsbusb -t” and see if the rndis_host driver is listed in the classes.

                    How is BRK-B powered? Is it receiving power from BRK-A USB Type-A or an external source on VIN?

                    in reply to: RNDIS Host not working #12994
                    coloradocarlos
                    Participant

                      Take a second look at the device trees for the modified BRK board with the Type-A female USB. Did you generate them using Cube MX? The default device tree from Octavo will probably not work because your “new” hardware differs than a stock BRK board. Check the USB nodes and pinmux assignments in the device tree for the kernel, uboot, and tf-a. The RED board has a USB host and it should serve as an example.

                      You mentioned that the host USB works with a flash drive or keyboard, but not a USB cable to the peripheral BRK. This suggests that HNP could be failing because both devices are supplying power at the same time and can’t “negotiate” who is the host for OTG. So take a look at the power rails too.

                      in reply to: RNDIS Host not working #12991
                      coloradocarlos
                      Participant

                        OK, so you modified the BRK hardware and the USB I assume is a USB Type-A. I would need to consult the STM documentation on the pins used for USB and specifically to support OTG mode detect.

                        This is what I have (I also have a CD-ROM gadget configured):

                        On the device board, restart the gadget service:

                        On the host board you should see messages in dmesg related to the device board bringing up rndis. This is where it gets a little tricky as I don’t know what to expect with OpenSTLinux. But you need to bring up an interface on the host and I highly recommend to set things up so packets are routed on different subnets (don’t rely on the default 192.168.7.x).

                        Where “12345…” is a MAC address of the USB network. Try using ifconfig to see what interfaces are configured. If none are configured, then rndis “host” is not detecting the “device”. lsusb -v might help.

                        The other key thing is you will likely need to modify /sbin/stm32_usbotg_eth_config.sh on the device to assign an IP address on a different subnet. In other words, the device in the middle is acting as a gateway router.

                        in reply to: RNDIS Host not working #12986
                        coloradocarlos
                        Participant

                          What would be helpful would be to describe your hardware and cabling configuration in more detail. The BRK board has a micro-USB port that is designed to work as a USB client. There are no other USB ports on the OSD32MP1-BRK board unless you added something to the board (or Octavo has something I am not aware of).

                          What is not clear either is if you trying to use the OTG role-switching “USB gadget” feature on the BRK board.

                          You may want to first test OTG host-mode using an OTG cable on another device, for example, HID keyboard or USB flash drive. OTG cable informs the hardware and OS that you want to place the USB in the host role.

                          Concerning loadable modules, it appears you compiled the module into the kernel and so it may not appear as a loadable module. If you are using OpenSTLinux, verify the module exists:

                          find /lib/modules/5.10.10/kernel/drivers/usb/gadget -name usb*

                          Carlos

                           

                          in reply to: Programming the FSBL to eMMC Flash #12973
                          coloradocarlos
                          Participant

                            Not clear why the flash layout TSV file used by STM32_Programmer_CLI  is not suitable. You can easily skip over partitions in the generated TSV by editing the file and putting a dash in field 1. Skip over everything except ID’s 0x04 and 0x05.

                            See: https://wiki.st.com/stm32mpu/wiki/STM32CubeProgrammer_flashlayout#Field1-_Options

                            in reply to: Kirkstone #12923
                            coloradocarlos
                            Participant

                              Probably frustrating for the Octavo team but ST updated their openstlinux layer a little more than a week ago. Latest layer is tagged openstlinux-5.15-yocto-kirkstone-mp1-v22.11.23. This tracks with Ecosystem / STLinux v4.1.0. Not sure about other customers, but I would be willing to wait for the Octavo layer to also track with v4.1.0 because ST has fixed bugs since v4.0.0.

                              in reply to: Kirkstone #12774
                              coloradocarlos
                              Participant

                                (Still having issues posting. Pass this on to Tomas, assuming it gets through.)

                                For custom boards using Dunfell, I found I needed to apply a board-specific patch in U-Boot 2020.10 to flash using DFU over USB. I suspect that the same is true for Kirkstone. Without the patch, DFU will be stuck in a loop booting TF-A / FIP. You can use the Octavo BRK board patch as a template:

                                 

                                https://github.com/octavosystems/meta-octavo-osd32mp1/blob/dunfell/recipes-bsp/u-boot/files/0007-Add-OSD32MP1-BRK-build-config.patch

                                 

                                This patch is based on the BRK U-Boot patch found here:

                                 

                                 

                                in reply to: Custom board and flashing the eMMC using USB/DFU #12773
                                coloradocarlos
                                Participant

                                  A bit more context. The flashing works for our custom board using the Debian SDK. It didn’t work for Dunfell.

                                  But it is working now. The solution is to apply the patch based on the BRK board. The patch adds the rule for the custom DTB to the Makefile. We are using the OTG pins but for a USB-C in peripheral mode. This is similar to Micro USB design in the BRK board.

                                  There is also a board.c that I included, but I don’t know if it was needed or not or if modification is required. We are not using the STUSB1600 since we don’t have a requirement to support USB-C OTG host mode.

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