Duplicate question. Replied Offline as well as https://octavosystems.com/forums/topic/usb-only-works-for-rndis/
Jack,
‘H’ and ‘L’ refer to reset release states. This is the state of the pin after reset is released, but the pin is not being controlled by firmware.
Please take a look at https://www.kernel.org/doc/Documentation/devicetree/bindings/gpio/gpio.txt for information on specifying gpio definitions in device tree. On newer kernels, it is possible to do definitions like this:https://github.com/STMicroelectronics/linux/blob/v6.1-stm32mp/arch/arm/boot/dts/stm32mp15xx-dkx.dtsi#L218C3-L218C45 for reset.
Best,
Neeraj
You are correct. USB1_OCN output of TPS2051 is used to indicate an over current on USB1 Host interface of the board With GPMC_A10 configured as GPIO input.
While this is implemented in hardware, by connecting the OC output of TPS2051 to GPMC_A10, this also needs software configuration to work. This is not currently implemented in dev board images, which is why you did not see pinmux setup for GPMC_A10.
In order to implement the feature, an interrupt must be captured on GPMC_A10 and handles by the USB host driver to turn of USB_DRVVBUS. It should be implemented in TI’s USB stack outlined here: https://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/Foundational_Components/Kernel/Kernel_Drivers/USB/MUSB.html. It does not look like this is implemented: https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/drivers/usb/musb/musb_am335x.c.
However, there the USB PHY controller in AM335x has undervoltage protection that monitors VBUS voltage and turns it OFF when VBUS goes below 4.4V. Please see https://e2e.ti.com/support/processors-group/processors/f/processors-forum/533061/am335x-usb-overcurrent-input for a discussion on TI forums.
Best,
Neeraj
Jeff,
Apologies for the late reply.
It looks like there is an issue with reset-gpio you defined in the mdio node. Please check whether the reset GPIO is working and is in the desired state when the Ethernet PHY is being probed.
Best,
Neeraj
Ryan,
Although VIN_BAT operating voltage range is lower(2.75V – https://www.ti.com/lit/ds/symlink/tps65217.pdf), note that the input should be able to support boot device voltage(3.3V), so actual required voltage on VIN_BAT is higher. Having said that, VBAT does offer wider voltage input than USB.
We recommend prototyping to understand what the implications are and how much capacitance you will need for your application to support safe shutdown.
Best,
Neeraj
mlarkin,
This is s new failure mode. Is firmware running on these boards? Is the behavior consistent or erratic on the boards that are shutting down?
Can you measure PMIC output voltages to check everything is OK? See https://octavosystems.com/app_notes/osd32mp1-power-system-overview/ for power rails and levels. Do you see activity on RSTn?
Please look for Turn-OFF conditions also described in Section 2.3 of the app note.
Best,
Neeraj
Ryan,
This should be possible as PMIC is able to switch from AC to USB input when VIN_AC goes below 4.1V(See 8.3.9.1 in PMIC datasheet: https://www.ti.com/lit/ds/symlink/tps65217.pdf).
However, note that valid voltage on VIN_USB is 4.3V or higher. So, you will have to make sure the voltage at the USB input stays above that range until shutdown occurs.
Please also check out https://octavosystems.com/app_notes/am335x-battery-applications-with-osd335x-sip/ and https://www.ti.com/lit/an/slva901/slva901.pdf.
Best,
Neeraj
Stephen,
This is unexpected behavior. We would expect to see similar performance to discrete MP1 implementation.
CPU load would depend on what applications are running. There are some differences between DK2 and RED board in terms of package configuration. Please take a look at “top” output to see what the difference is. Also review your clock tree(not just cpu)? See https://wiki.st.com/stm32mpu/wiki/Clock_overview to view clk_summary.
Best,
Neeraj
Stephen,
OSD32MP15x-512M uses x16 DDR. The DDR configuration file can be found here: https://github.com/octavosystems/OSD32MP1-RED-Device-tree/blob/main/tf-a-v2.4-r0/osd32mp1_ddr_1x4Gb.dtsi. This was generated using ST’s CubeMX tool and can be used with OpenSTLinux. Please take a look at https://github.com/octavosystems/meta-octavo-osd32mp1 for yocto compatible meta layer for OSD32MP1-RED.
Best,
Neeraj
Julius,
The device tree snippet you posted looks okay(- formatting). Here are a few things to check:
1. Check the regulator information with “cat /sys/kernel/debug/regulator/regulator_summary” to see if VREF is present and whether it is used by ADC. The summary should show you the voltage setting as well as where it is being used. See https://wiki.st.com/stm32mpu/wiki/Regulator_overview for additional information
2. Is vdda-supply(vdda) > 2.8V on your board? See https://www.st.com/resource/en/application_note/dm00389996-getting-started-with-stm32mp151-stm32mp153-and-stm32mp157-line-hardware-development-stmicroelectronics.pdf section 4.1.1 for reference. Note that VDDA is internally supplied by LDO5 in OSD32MP1. Please make sure that all voltage and ADC specific settings are good in the adc node. See example here: https://github.com/STMicroelectronics/linux/blob/v5.10-stm32mp/arch/arm/boot/dts/stm32mp15xx-dkx.dtsi#LL119C7-L119C7(Note the difference, on DK2, VDDA is supplied by VDD)
3. Make sure that the clock is OK. vref clock should be listed in /sys/kernel/debug/clk/clk_summary
4. Make sure you are not supplying external reference to VREF+ when you are activating VREFBUF internally. What does this pin voltage measure on your board?
Best,
Neeraj
Daniel,
For #1, https://community.st.com/s/question/0D53W00000cxRieSAE/wakeup-on-gpio-in-linux-on-stm32mp1 seems to have relevant information.
I have not tired this, but libgpiod can be of help for user space GPIO event detection: https://github.com/starnight/libgpiod-example/blob/master/libgpiod-event/main.c#L33
For #2, I believe you can enable/disable any wake up source via sysfs. For example, to disable a wake up source, “echo disabled > /sys/devices/platform/soc/<peripheral directory>/power/wakeup”
Best,
Neeraj
Damian,
Apologies for the late reply. Currently Octavo’s plan is to support major revisions of OpenSTLinux. Here is the latest meta-octavo layer that supports OpenSTLinux v4.0: https://github.com/octavosystems/meta-octavo-osd32mp1/tree/kirkstone. The device tree files are added in as patches(for example: https://github.com/octavosystems/meta-octavo-osd32mp1/tree/dunfell/recipes-kernel/linux/files for the kernel).
Best,
Neeraj
Rob,
Thank you for your thoughts and inputs.
I did notice that we have the 0.05″ TC2050-IDC-NL-050 linked in the “Getting started” post earlier. This should have been the TC2050 with 0.1″ pitch instead and was corrected. The MB1440 add on board for STLink V3 set converts all the 0.05″ connectors to 0.1″ pitch connectors.
The TC2050-ARM2010(https://www.tag-connect.com/product/tc2050-arm2010-arm-20-pin-to-tc2050-adapter) + TC2050-IDC-NL(https://www.tag-connect.com/product/tc2050-idc-nl-10-pin-no-legs-cable-with-ribbon-connector) connect to the 20 pin connector of MB1440, which is plugged in top of MB1441.
Hope that clears things up. Tag-connect is easy to work with, but with the right set of cables. Will pass on your inputs.
Best,
Neeraj
Rob,
Yes, TC2050-IDC-050-STDC14 should work. I verified the setup using items 2a + 2b + ST-Link V3 debugger from the original post.
Best,
Neeraj
Hey Sylvain,
Thank you for reporting this issue. It does appear that VDD stays on after issuing “poweroff” or “shutdown” command. This is likely from a bug in the secure monitor firmware that controls the PMIC. This behavior is consistent in OpenSTLinux V3, on ST dev boards(tested on DK2) as well.
ST’s is switching support to OPTEE for V4 and future releases. I verified that the DK2 does not fail to turn OFF VDD when OPTEE boot chain(https://wiki.st.com/stm32mpu/wiki/Boot_chain_overview) is used. We will update our support for OPTEE for OSD dev boards. We recommend you update your boot chain as well.
Best,
Neeraj
Octavo Systems LLC all rights reserved
OCTAVO is registered in the U.S. Patent and Trademark Office. OSD, C-SiP, and the Octavo Logo are trademarks of Octavo Systems LLC.
"*" indicates required fields
"*" indicates required fields
"*" indicates required fields
"*" indicates required fields