coloradocarlos
Forum Replies Created
- AuthorPosts
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
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
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
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
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).
The second is the “system_off_soc_mode”. The dunfell device tree shows this to be “STM32_PM_CSTOP_ALLOW_STANDBY_DDR_OFF”.
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
Testing 1, 2, 3. Did this go through?
(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
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?
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.
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):
1234root@myboard:~# lsmod | grep rndisusb_f_rndis 24576 2u_ether 20480 1 usb_f_rndislibcomposite 49152 12 usb_f_mass_storage,usb_f_rndisOn the device board, restart the gadget service:
1systemctl restart usbotg-configOn 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).
1ifconfig enx123456789 192.168.8.2 upWhere “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.
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
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
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.
(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:
This patch is based on the BRK U-Boot patch found here:
Patches for BRK board support in U-Boot
https://github.com/neerajdantu/BRK_Uboot_patch
0 forks.
0 stars.
0 open issues.Recent commits:
- Update README.md, GitHub
- USB device support for OSD32MP1-BRK, GitHub
- Initial commit, GitHub
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.
- AuthorPosts