Geoff,
2 things to note here:
1. You should be using the latest OpenSTLinux release from Octavo. You can generate the latest image by following instructions here: https://github.com/octavosystems/meta-octavo-osd32mp1
2. OSD32MP1-BRK has its own device tree. You will need to regenerate device tree binary after modifications that allow the demo to work on the BRK. Please see earlier post here: https://octavosystems.com/forums/topic/openamp-demo-failing-to-suspend-a7-on-osd32mp1-brk/#post-11610
Best,
Neeraj
Gil,
Since you are clearly seeing output in case of using the Raspberry Pi, I think the issue is the UART-USB adapter. Please try to independently verify the UART adapter or try a new one.
You can also verify boot of the board 1 or 2 additional ways to verify that the board has nothing wrong going on(Power the board without a UART connection):
1. LED D8 will turn ON as part of kernel initialization of the WiFi module. This indicates good kernel load and boot.
2. If you connect a USB-C Cable from the board’s USB-C port to a host computer, you should see it show up as an ethernet connection. You can use this connection to ssh into the board(see https://octavosystems.com/app_notes/osd32mp1-red-getting-started/#USB%20Connection). Can you try to do this?
Best,
Neeraj
Gil,
I just realized I am wrong. You are correct. SPI6 is closest to A7 cores for latency purposes. All the other SPIs would have similar latencies.
Note that there are 4 PLLs available for the whole SoC and generate all the frequencies required for all the peripherals. For example, SPI6 can have one or the following clock sources: PCLk5, PLL4Q, PLL3Q, HSI, CSI and HSE. These can also serve as clock sources for other peripherals.
Best,
Neeraj
Gil,
Can you double check from https://octavosystems.com/app_notes/osd32mp1-red-getting-started/#UART%20Connection:
1. hardware connections
2. UART speeds(115200 8N1)
Are you using the default image from OSD32MP1-RED page?
Best,
Neeraj
Gil,
Please see requested information below:
USB1
USB1_N 15379.511 559.346
USB1_P 14820.165
USB2
USB2_N 18453.704 572.107
USB2_P 17881.597
Note that all lengths are in microns.
Best,
Neeraj
Reply offline copied here::
Note that the maximum junction temperature for STM32MP157F is 105C(Datasheet: https://www.st.com/resource/en/datasheet/stm32mp157c.pdf Table 12). According to section 3.23 of the datasheet, the internal temperature sensor can be used, but it is recommended to use it to determine temperature changes only as it is by default uncalibrated.
Are there other temperature sensors on the board? Can you measure the maximum temperature of the case? Please note that the case temperature for OSD32MP1 is 85C and as long as you stay under this temperature, the device should be in spec. If you are seeing high temperatures on the case, we recommend looking into heat sinks or thermally conductive layout techniques to dissipate heat. Please also take a look at the thermal application note here: https://octavosystems.com/app_notes/osd32mp15x-thermal-guide/.
Neeraj
Fred,
Apologies for the late reply. The clock tree is setup in TF-A. This might be a change in the new version of OpenSTLinux as you could simply change the include and run with a different OPP in previous versions. OpenSTLinux supports opp-supported-hw property. OPPs can be set with hardware specific configuration with opp-supported-hardware property. As you can see, stm32mp15xf.dtsi includes stm32mp15xd.dtsi(https://github.com/STMicroelectronics/arm-trusted-firmware/blob/v2.4-stm32mp/fdts/stm32mp15xd.dtsi) which has the OPP settings corresponding to 800MHz clock setting. The opp-supported-hw property for this OPP is 0x2. For stm32mp15xc.dtsi which include stm32mp15xa.dtsi(https://github.com/STMicroelectronics/arm-trusted-firmware/blob/v2.4-stm32mp/fdts/stm32mp15xa.dtsi), the 650MHz OPP has opp-supported-hw set as 0x01.
So, if you want to run stm32mp15xc version on 800Mhz, you might have to make a change to this property in your build system. Thank you for pointing this out, we will review our app note and update it.
Best,
Neeraj
Gil,
From the shortest path point of view, according to the reference manual, SPI2/3 seem to be the closest as MPU connected to them via AHB-APB1. According to https://www.st.com/content/ccc/resource/training/technical/product_training/group0/6c/56/80/c9/e2/1b/40/db/STM32MP1-Peripheral-Serial_Peripheral_interface_SPI/files/STM32MP1-Peripheral-Serial_Peripheral_interface_SPI.pdf/_jcr_content/translations/en.STM32MP1-Peripheral-Serial_Peripheral_interface_SPI.pdf, SPI2/3 seem to be interfaces that can achieve maximum frequency. Please make sure you can set the clock speeds you need using CubeMX clock tree utility.
Best,
Neeraj
fsm,
Your device tree fragments indicate that you are changing the opp table as well as pll settings in your TF-A, u-boot and kernel device trees. The only thing you need to do is to change the device tree include file to “stm32mp15xf.dtsi”. Please take a look at example for F version of DK2:
TF-A: https://github.com/STMicroelectronics/arm-trusted-firmware/blob/v2.4-stm32mp/fdts/stm32mp157f-dk2.dts
Kernel/u-boot: https://github.com/STMicroelectronics/linux/blob/v5.10-stm32mp/arch/arm/boot/dts/stm32mp157f-dk2.dts
Make sure you also remove “stm32mp15xc.dtsi” from all your device trees.
Best,
Neeraj
bpiquette,
Both sequences show PGOOD coming up and staying up, which says that PMIC thinks all power rails are good. VDD1_3P3V sags slightly at the point of failure indicating there is a device on this power rail that is drawing excess current(possibly responsible for faulty power up?).
Is your boot media powered by VDD1_3P3V? If so, is it possible to use another boot source changing the SYSBOOT pins? For example, you can bypass the current boot media and let the board boot up in UART boot mode. You will be able to see “CC” on the UART terminal. Does the fault still occur in this different boot mode?
How much bypass capacitance do you have on SYS_VDD1_3P3V? Can you increase it and see if the board behaves differently?
Can you also check whether the 24MHz and 32KHz oscillators are working correctly normally as well as in failure mode?
Best,
Neeraj
Issue was resolved offline.
spi-max-frequency was set tp 30MHz causing an error in DFSDM interface setup. sps-max-frequency should be 3MHz.
Neeraj
Pratik,
Please check u-boot device tree to see if:
1. The right pins were used for the eMMC SD peripheral and the pinmux settings are accurate(https://github.com/octavosystems/OSD32MP1-RED-Device-tree/blob/main/linux-v5.10-r0/stm32mp157c-osd32mp1-red.dts#L438)
2. Whether the mmc node has all the right properties for emmc: https://github.com/octavosystems/OSD32MP1-RED-Device-tree/blob/main/linux-v5.10-r0/stm32mp157c-osd32mp1-red.dts#L1269.
3. Whether there is a pin usage conflict(pins you need for eMMC are being used by other peripheral)
The device tree linked above(for OSD32MP1-RED) is a good reference as it uses eMMC. Please see https://octavosystems.com/docs/osd32mp15x-red-schematic-pdf/ for the hardware schematic.
You can also probe the CLK and CMD pins of the mmc interface you are using to see if they are active during eMMC operations.
Best,
Neeraj
Gil,
The RTC(32KHz) oscillator is not included in the production parts. You will need to add an external oscillator. Please take a look at https://octavosystems.com/docs/osd32mp15x-red-schematic-pdf/ for the latest revision of our reference design for OSD32MP1.
Best,
Neeraj
mlarkin,
Please take a look at the Migration guide for OSD32MP1 family: https://octavosystems.com/app_notes/osd32mp1-variant-migration-guide/. https://github.com/STMicroelectronics/linux/blob/v5.10-stm32mp/arch/arm/boot/dts/stm32mp15xf.dtsi shows the entry for 800MHz setting. Note that this is ST’s kernel and not mainline.
Best,
Neeraj
bpiquette,
Yes, please scope shot the behavior of SYS_VOUT when this faulty power-up happens. Do you have power draw measurements when the device exhibits this fault? If SYS_VOUT comes up fine, can you map out the power up sequence as shown in Figure 2 of the power application note: https://octavosystems.com/app_notes/osd335x-sm-power-application-note/?
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