[Neeraj Dantu]

Based on the description of what is happening so far, USB1600 is producing an interrupt on the ALERT signal, but you do not see it detected on the kernel side. Is that correct?

If so I suggest:

Look at kernel messages for USB with “dmesg | grep usb” and make sure the IRQ is registered. The messages I see when I do this on OSD32MP1-RED:[    0.122420] usbcore: registered new interface driver usbfs1# dmesg | grep usb

[    0.122513] usbcore: registered new interface driver hub

[    0.122590] usbcore: registered new device driver usb

[    1.692445] usbcore: registered new interface driver pegasus

[    1.692533] usbcore: registered new interface driver asix

[    1.692617] usbcore: registered new interface driver ax88179_178a

[    1.692688] usbcore: registered new interface driver cdc_ether

[    1.692771] usbcore: registered new interface driver smsc75xx

[    1.692853] usbcore: registered new interface driver smsc95xx

[    1.692919] usbcore: registered new interface driver net1080

[    1.692984] usbcore: registered new interface driver cdc_subset

[    1.693058] usbcore: registered new interface driver zaurus

[    1.693154] usbcore: registered new interface driver cdc_ncm

[    1.696494] usbcore: registered new interface driver usb-storage

[    1.710775] usbcore: registered new interface driver usbhid

[    1.710792] usbhid: USB HID core driver

[    3.323124] vdd_usb: supplied by vin

[    3.550022] stm32-usbphyc 5a006000.usbphyc: registered rev:1.0

[    3.589060] dwc2 49000000.usb-otg: supply vusb_d not found, using dummy regulator

[    3.595971] dwc2 49000000.usb-otg: supply vusb_a not found, using dummy regulator

[    3.738244] dwc2 49000000.usb-otg: EPs: 9, dedicated fifos, 952 entries in SPRAM

[    3.746814] dwc2 49000000.usb-otg: DWC OTG Controller

[    3.750562] dwc2 49000000.usb-otg: new USB bus registered, assigned bus number 1

[    3.757906] dwc2 49000000.usb-otg: irq 98, io mem 0x49000000

[    3.773879] ehci-platform 5800d000.usbh-ehci: EHCI Host Controller

[    3.778756] ehci-platform 5800d000.usbh-ehci: new USB bus registered, assigned bus number 2

[    3.787902] ehci-platform 5800d000.usbh-ehci: irq 71, io mem 0x5800d000

[    3.817661] ehci-platform 5800d000.usbh-ehci: USB 2.0 started, EHCI 1.00

[    3.832919] ohci-platform 5800c000.usbh-ohci: Generic Platform OHCI controller

[    3.838833] ohci-platform 5800c000.usbh-ohci: new USB bus registered, assigned bus number 3

[    3.847510] ohci-platform 5800c000.usbh-ohci: irq 61, io mem 0x5800c000

[   27.274310] usb0: HOST MAC a0:39:f4:d0:0d:9a

[   27.284648] usb0: MAC ee:42:52:59:6b:25

[   27.287112] dwc2 49000000.usb-otg: bound driver configfs-gadget

[   34.397708] usb33: supplied by vdd_usb

IRQ 98 is what I see trigger when there is a device plugged in.

You can “cat /proc/interrupts” to get the interrupt details and # triggered. 98 should look like the following:

” 98:       3493          0  stm32-exti-h-direct  44 Level     49000000.usb-otg, 49000000.usb-otg, dwc2_hsotg:usb1″

 

If I am wrong and STUSB1600 is not generating the alert signal, you mentioned above that the mask register 0x0C does not look right. I am not sure what the reason for this would be, but you could modify this register by issuing a “i2cset” command from linux command line and see if that fixes the interrupt generation.

 

Best,

Neeraj

 

[Neeraj Dantu]

Gil,

The attached circuit configuration should work correctly. A couple of changes I noticed in device tree from ST’s DK board: the GPIO pin used was declared as ANALOG until 5.10 and has changed to GPIO since 5.15 kernel. The IRQ_TYPE definition in the device tree has also changed since 5.10. I have not looked at the driver changes, can you check which version of the kernel you are using and try the configurations that match?

Best,
Neeraj

[Neeraj Dantu]

Pooja,

Which kernel version are you using?

I suggest looking at ethernet device tree for EVM-SK: https://github.com/RobertCNelson/dtb-rebuilder/blob/4.19-ti/src/arm/am335x-evmsk.dts corresponding to the kernel version you are using. Although the PHY is different, the device tree should not change much.

A couple of things you might need to change :The phy-mode depending on whether TX/RX delays are required. See https://www.kernel.org/doc/Documentation/devicetree/bindings/net/ethernet-controller.yaml for bindings.  phy_id address based on hardware configured phy address: https://github.com/RobertCNelson/dtb-rebuilder/blob/4.19-ti/src/arm/am335x-evmsk.dts#L663. Please note that these examples are kernel version specific. You will need to match the entries with the kernel version you are running on the device.

Best,

Neeraj

• This reply was modified 4 months, 2 weeks ago by Neeraj Dantu.

[Neeraj Dantu]

C spengler,

It seems like Yocto does stuff to binaries: https://docs.yoctoproject.org/dev/dev-manual/prebuilt-libraries.html. May be yocto is stripping the elf file when it is packaging?

There should be log files associated with each recipe as described here: https://docs.yoctoproject.org/dev-manual/new-recipe.html#running-a-build-on-the-recipe.

Best,

Neeraj

[Neeraj Dantu]

C Spengler,

It looks like PMIC_BSTOUT is experiencing an over current condition. I have seen this condition trigger when there is a large amount of capacitance on BSTOUT leading to an inrush current situation that exceeds the current limit on this rail. Please remove the large bypass capacitors and check if the issue persists.

Best,

Neeraj

[Neeraj Dantu]

Javas,

We do not re-ball parts, but we have worked with several rework outfits to re-ball parts successfully for debug. We recommend paying close attention to the storage and reflow requirements outlined in sections 9.2 and 9.3 of the datasheet: https://octavosystems.com/docs/osd335x-datasheet/. Baking is recommended before any reflow events as the devices will have been stored in uncontrolled environment.

 

Best,

Neeraj

[Neeraj Dantu]

Budimir,

Here is an example of how DK2(ST’s dev board) handles assignments to the M4 core via device tree: https://github.com/STMicroelectronics/linux/blob/v6.6-stm32mp/arch/arm/boot/dts/st/stm32mp157c-dk2-m4-examples.dts.

Here are some useful resources:

1. CubeMX based peripheral assignment to cores: https://wiki.st.com/stm32mpu/wiki/How_to_assign_an_internal_peripheral_to_an_execution_context

2. ETZPC peripheral: https://wiki.st.com/stm32mpu/wiki/ETZPC_device_tree_configuration

3. M4-A7 architecture overview: https://wiki.st.com/stm32mpu/wiki/Coprocessor_management_overview

Take a look at this introductory course that goes over a bunch of the above material closely: https://octavosystems.com/courses/getting-started-with-embedded-linux/

Best,

Neeraj

[Neeraj Dantu]

Gil,

Can you check the connection of VDD(pin 24) of USBC1600? For OTG functionality, this needs to be connected to mid way point of the USB-C sink power path. On the RED board, I needed to change the jumper position of JP21 in order for OTG function to work. I was able to verify both sink and source modes as well as see the interrupt on ALERT pin when something is connected.

I am still unsure why you are reading different value of GPIO. My suspicion is that there is an issue with U-Boot CLI handling this claimed pin. I will check further, but I don’t think anything is wrong based on the functionality all working.

Best,

Neeraj

• This reply was modified 4 months, 2 weeks ago by Neeraj Dantu.

[Neeraj Dantu]

Gil,

I am investigating and will report back.

Best,

Neeraj

[Neeraj Dantu]

mlarkin, Ronan,

Apologies for the delay. Please find a patch for OpenSTLinux version 6.1 OPTEE attached to this forum post. We are working on adding the support for OPTEE boot mode for latest OpenSTLinux under meta-octavo. I will push a new meta-octavo layer update in the next week.

Best,

Neeraj

Attachments:

1. 0001-Add-OSD32MP1-BRK-board-support.patch

[Neeraj Dantu]

Gil,

The device tree attached shows that GPIOE8 has the internal pull-up enabled. However, there should not be a measurement discrepancy between u-boot CLI and measurement.

Here is an interaction I just had on the CLI to show status of GPIOE8 on the RED board:

STM32MP> gpio input GPIOE8

gpio: pin GPIOE8 (gpio 72) value is 0

STM32MP> gpio status GPIOE8

Bank GPIOE:

GPIOE8: input: 0 [ ]

 

 

[Neeraj Dantu]

Budimir,

There are better ways for device tree modification:

1. Developer Package: https://wiki.st.com/stm32mpu/wiki/How_to_compile_the_device_tree_with_the_Developer_Package (Keep track of kernel version you are using and match the developer package kernel version)

2. Distribution Package: https://wiki.st.com/stm32mpu/wiki/How_to_compile_the_device_tree_with_the_Distribution_Package

3. Use the Debian SDK: https://github.com/octavosystems/osd32mp1-build-tools/blob/master/Makefile#L148

I am not sure whether this is happening on OSD32MP1-RED, but bootloader and kernel can modify the device tree at runtime.

Best,

Neeraj

[Neeraj Dantu]

spengler,

First thought is that you should check the card detect pin. It is different for OSD32MP1-RED and OSD32MP1-BRK. If you are using BRK device tree, the card detect pin is set to PG7(https://github.com/octavosystems/OSD32MP1-BRK-device-tree/blob/kirkstone/u-boot-v2021.10-stm32mp-r1/stm32mp157c-osd32mp1-brk.dts#L881).

Best,

Neeraj

[Neeraj Dantu]

Manish,

Initial look into the schematics does not reveal anything obviously incorrect. Although 1 thing I noticed was both pull-ups and pull-downs for Address setting of IC1 seem to be populated, which might mess withe EEPROM configuration as EEPROM inside OSD3358-SM is on address 0x50. May not be an issue, but recommend checking and making sure the external EEPROM is on a different address.

If you are getting outputs on power rails, that would mean that the PMIC is up. Can you double check all voltage rails are OK according to https://octavosystems.com/app_notes/osd335x-sm-power-application-note/?

When there is no SD card, do you get “CCCC” output on UART0? If so, this is an indication that the processor has booted correctly and searching for a boot media.

The other things to check is 24MHz and 32KHz clock signals.

One way you can completely bypass EEPROM is by using EEPROM Blank image as described in https://github.com/RobertCNelson/omap-image-builder/tree/master/octavo. You can build this image on your machine by selecting octavo-blank-eeprom.conf while running https://github.com/RobertCNelson/omap-image-builder/tree/master/octavo#generate-image-file.

When booting with the SD card, you should be able to see activity on SD CLK and CMD lines, if you have an oscilloscope, this would be a debug step to understand whether the processor is attempting to boot from the SD card.

Please let us know if you have an update on the debug,

Best,

Neeraj

[Neeraj Dantu]

David,

1. The parameters that are default for Beagleboards can be used for OSD3358. Because how close the DDR is to the SoC, a range of parameters work well. Please take a look at Section 6.2 of the datasheet(https://octavosystems.com/docs/osd335x-datasheet/) for the parameters that Octavo publishes and recommends.

2. Please contact sales@octavosystems.com for purchase information.

Best,

Neeraj

[Author]

Posts