[Neeraj Dantu]

Majda,

Unfortunately, using LTDC as RGB will not be possible on OSD32MP1-RED board. However, there are options:

1. You can use the DSI display output with X8 or JP6(Sheet 9 of the schematics).
2. You can use ST’s EV1 dev board: https://www.st.com/en/evaluation-tools/stm32mp157f-ev1.html that has an RGB header. Any software developed on ST’s dev board can easily be ported to OSD32MP1 device with a DDR include file.

Best,
Neeraj

[Neeraj Dantu]

Majda,

The LTDC interface is used for HDMI on OSD32MP1-RED. Please take a look at Sheet 7 of rev 1.1 here: https://octavosystems.com/docs/osd32mp15x-red-schematic-pdf/ for LTDC connections to a HDMI Framer chip U3 as well as the Micro HDMI slot X6.

Best,
Neeraj

[Neeraj Dantu]

Manish,

The power rail measurements look OK. The sequence of RTC_1P8 vs VDD_1P8 also looks OK.

However, lack of 24MHz on OSC0 input is concerning. This is the main clock input for the SoC and it needs this clock input to function. The lack of activity on SD_CLK and CMD lines is consistent with the fact that the main clock input for the SoC is not functional.

Please review the values for C4, C6 and R33 in your schematic. Take a look at Section “Input Clock Requirements” in AM335x datasheet: https://www.ti.com/lit/ds/symlink/am3358.pdf to understand OSC0 Crystal Circuit Requirements. Can you see 32KHz signal?

Best,
Neeraj

[Neeraj Dantu]

Gil,

Glad you found the issue and appreciate the update!

Best,

Neeraj

[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 1 month 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 1 month 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 [ ]

1 2 3 4 5 6 7 8 9

STM32MP> gpio input GPIOE8   gpio: pin GPIOE8 (gpio 72) value is 0   STM32MP> gpio status GPIOE8   Bank GPIOE:   GPIOE8: input: 0 [ ]

 

 

[Author]

Posts