[Eshtaartha Basu]

Hello bpiquette,

Yes, the enable pin of OSD335x-SM’s integrated TL5209 is driven by SYS_VDD3_3P3V. A minimum of 2V is sufficient to enable TL5209 (as indicated in its datasheet – https://www.ti.com/general/docs/suppproductinfo.tsp?distId=10&gotoUrl=https%3A%2F%2Fwww.ti.com%2Flit%2Fgpn%2Ftl5209).

[Eshtaartha Basu]

Hello paulfuchs,

The OSD32MP1-BRK has four groups of pins: PAxx, PBxx, PCxx and PDxx (xx = 01 to 30 i.e., 30pins in each group). On the top side of the OSD32MP1-BRK (the side where all the components are mounted), you can see the silk screen labels ‘A’, ‘B’, ‘C’ and ‘D’ that indicate the individual header groups. On the bottom side of OSD32MP1-BRK, the actual STM32MP15x’s pin names are labeled next to corresponding header pins.

PA10 (OSD32MP1-BRK header pin) is connected to PH9 (STM32MP15x pin) as indicated in OSD32MP1-BRK schematic (see picture attached) and also the “OSD32MP1-Pin-Muxing-Overview.xlsx”. Look for label “PH9” on the bottom side of OSD32MP1-BRK.

Attachments:

1. 

   Screen-Shot-2022-02-24-at-1.50.24-PM.png
   

[Eshtaartha Basu]

Hello Matthew,

Yes, please carefully investigate the differences between DK2 DT and RED DT. Suitably copy only those nodes that would be required by M4 examples from stm32mp157c-dk2-m4-examples.dts file to RED DT. Button and LED pinmux also needs to be updated to match RED hardware. Then, rebuild DT to use it.

You will have to copy/overwrite the following DT nodes from M4 examples DT to RED DT:

All nodes from line 28 (&dmamux1) of https://github.com/STMicroelectronics/linux/blob/v4.19-stm32mp/arch/arm/boot/dts/stm32mp157c-dk2-m4-examples.dts to line 129 (&timers1)

Line 116: PH7 is not connected to an LED on the RED versus DK2. Replace PH7 with PF3 and ensure JP12 is in pos 1-2.
Line 122: PE9 is available as pin20 of DSI connector X8 on the RED

You also may have to take care of any missing phandle references in device tree hierarchy. These app notes should help you take care of phandle references and also help you to better configure device trees and system resources:

OSD335x Lesson 2: Linux Device Tree

https://wiki.st.com/stm32mpu/wiki/How_to_configure_system_resources

[Eshtaartha Basu]

Hello jge14,

Sounds good. The connections seem correct.
We recommend this app note on battery usage with OSD335x – https://octavosystems.com/app_notes/am335x-battery-applications-with-osd335x-sip/.

[Eshtaartha Basu]

Hello JensOnOctavo,

DVFS is supported by OSD32MP15x SiPs.

DVFS is officially supported by OpenSTLinux v2.0.0 (kernel v5.4.x) and later versions.
See “Main NEW features of the STM32MP15-ecosystem-v2.0.0 release” of
https://wiki.st.com/stm32mpu-ecosystem-v2/wiki/STM32MP15_ecosystem_release_note_-_v2.0.0?action=view

As indicated here (https://github.com/octavosystems/osd32mp1-debian), Octavo’s SDK currently uses Linux Kernel v4.19
which does not support DVFS. Although scaling governors and related options are visible under sysfs, they
don’t function, as necessary. We’re working on updating our SDK. Please check back later for updates – https://octavosystems.com/octavo_products/osd32mp1-red/

Meanwhile, you can use DVFS on OpenSTLinux v2.0.0 (kernel v5.4.x):
https://wiki.st.com/stm32mpu-ecosystem-v2/wiki/STM32MP1_Developer_Package
You can select v2.0.0 from the drop-down menu of Linux, U-Boot and TF-A download pages.

Although DVFS is also supported by newer versions of OpenSTLinux, we have validated only v2.0.0 on our devices.

You can change the governor by writing to “scaling_governor” attribute under /sys/devices/system/cpu/cpufreq/policyX/

Example:

debian@localhost:/sys/devices/system/cpu/cpufreq/policy0$ cat scaling_governor
performance

debian@localhost: sudo su

root@localhost:/sys/devices/system/cpu/cpufreq/policy0# echo “” > scaling_governor
root@localhost:/sys/devices/system/cpu/cpufreq/policy0# cat scaling_governor
ondemand

You can read CPU’s real time speed by reading “scaling_cur_freq” attribute
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq

You can measure CPU’s core voltage by probing VDD_CORE pin using a multimeter.

For more detailed information on all CPU scaling parameters and how to modify them, read:
https://github.com/STMicroelectronics/linux/blob/v5.10-stm32mp/Documentation/admin-guide/pm/cpufreq.rst

• This reply was modified 3 years, 5 months ago by Eshtaartha Basu.

[Eshtaartha Basu]

Hello pratik.manvar,

=> Can you please point me to the patches for latest ST OpenLinux release?

[Octavo]: We’re working on updating the patches to the latest version. Please check back later for updates (https://github.com/octavosystems/BRK_Developer_Package_patches)

=> Do we have the patches for distribution-package compatible to Yocto instead of SDK?

[Octavo]: We’re currently working on this as well. Please check back later.

[Eshtaartha Basu]

Hello mlarkin,

No updates yet. We’re working on it. Please check our product pages for future updates.

BRK product page – https://octavosystems.com/octavo_products/osd32mp1-brk/
MP1-RED product page – https://octavosystems.com/octavo_products/osd32mp1-red/

[Eshtaartha Basu]

Hello hzhu,

Your device tree modification has minor issues.

As indicated in Table 8 (under section 4.1) of STPMIC1 datasheet (https://www.st.com/resource/en/datasheet/stpmic1.pdf), BOOST converter has a FIXED output voltage and hence has no programming step voltage or min/max voltage.

Remove the following lines from “bst_out” node and rebuild your device tree to fix the issue:

regulator-min-microvolt = <5200000>;
regulator-max-microvolt = <5200000>;

You can use OSD32MP1-RED device tree (which keeps BOOST converter ON) as good reference for device tree updates – https://github.com/octavosystems/OSD32MP1-RED-Device-tree/blob/main/linux-v4.19/osd32mp1-red.dts

Boost converter can also be turned ON once the device boosts (without modifying device tree) by talking to the PMIC over I2C and modifying PMIC registers (BST_SW_SR) as suggested by Neeraj in the above response (https://octavosystems.com/forums/topic/no-output-on-pmic_bstout/#post-11420)

• This reply was modified 3 years, 5 months ago by Eshtaartha Basu.
• This reply was modified 3 years, 5 months ago by Eshtaartha Basu.

[Eshtaartha Basu]

Hello jge14,

Since the question is posted under OSD335x-SM, I initially assumed you’re talking about OSD3358-SM-RED development board.

BeagleBone Black-Wireless uses OSD3358-BAS device.

On the OSD3358-BAS:

1. PMIC’s MUX_IN and MUX_OUT pins are not brought out of the SiP (not externally accessible for connections)
2. MUX_IN and MUX_OUT pins are not connected to anything (not connected to any ADC pins) within the SiP.

As seen on the BeagleBone Black-Wireless schematics, AIN7 is already being used to monitor output rail VDD_3V3B through resistor voltage divider (R21 and R22). This is why you’re seeing constant voltage. All other ADC pins including AIN6 are connected to BeagleBoard header P9.

Do you have anything on the P9 header(any BeagleBoard cape)? How are you charging the battery? Some external connection on P9 is probably making battery voltage appear on AIN6. Please check your connections.

[Eshtaartha Basu]

Hello coloradocarlos,

You can refer section 6.4.1 (EEPROM Contents) of OSD32MP1 datasheet – https://octavosystems.com/docs/osd32mp15x-datasheet/. The final 256 bytes of the EEPROM (0xF00 to 0xFFF) are reserved for device specific information.

The serial number will help us uniquely identify your BRK board and provide support (if needed) in the future. The software images provided by OctavoSystems with the BRK (at this time) do not read and use the board’s serial number for anything on the software side of things.

• This reply was modified 3 years, 5 months ago by Eshtaartha Basu.
• This reply was modified 3 years, 5 months ago by Eshtaartha Basu.

[Eshtaartha Basu]

Hello Manuel Malagon,

Thanks a lot for your kind words. We’re glad you love our products.

We’re currently putting together documentation on the same. Please check back later for an update (https://octavosystems.com/app_notes/).

For now, the documentation and links on our Git page can be used as a good starting point – https://github.com/octavosystems

• This reply was modified 3 years, 5 months ago by Eshtaartha Basu.

[Eshtaartha Basu]

Hello karlchansen,

OpenSTLinux image provided by ST for their own DK2 and EV1 boards detects the state of on-board user buttons B3 and B4 during boot up. These buttons are pulled up by default on the board. A button press will pull them down and assert DFU mode or Android FastBoot mode. These modes could get forced when the pins are left floating too.

See section 7.11.1 of https://www.st.com/resource/en/user_manual/dm00591354-discovery-kits-with-stm32mp157-mpus-stmicroelectronics.pdf for more info on these pins.

ST DK2’s schematic –
https://www.st.com/resource/en/schematic_pack/mb1272-dk2-c01_schematic.pdf

Octavo BRK’s schematic –

OSD32MP1-BRK Schematics

ST DK2’s user button B3 corresponds to MP1 pin PA14
ST DK2’s user button B4 corresponds to MP1 pin PA13

Both PA13 and PA14 are left floating on BRK so ST’s OpenSTLinux image will get forced into DFU or FastBoot modes unless these pins are externally pulled high.

The problem in your case is most likely one of the following:

1. OpenSTLinux image from ST is being used on BRK instead of Octavo’s BRK image from our website
2. The patches are not properly applied to Octavo’s BRK image

Please double check the image on your uSD card and see if problem persists.

[Eshtaartha Basu]

Hello jge14,

Thank you for bringing this to our notice. MUX_OUT is connected to AIN7 in hardware but there seems to be a pin muxing bug in software. Please see signal to ball mapping here for the bug – https://github.com/octavosystems/OSD335x-Device-Tree/blob/master/OSD335x_RED.pinmux

We will fix this bug soon and update OSD3358-SM-RED DT files to reflect the same. Thanks.

UPDATE: We verified the pinmux on the backend and IT IS CORRECT. The OSD335x-SM uses AM335x ZCZ package. Hence, the .pinmux file corresponds to pin mapping between signal names and balls numbers of AM335x ZCZ package.

By default MUX_OUT will be in High-Z. Make sure you’ve configured the PMIC registers properly to have the right input on AIN7. Which development board are you using?

• This reply was modified 3 years, 5 months ago by Eshtaartha Basu.

[Eshtaartha Basu]

Hello SylvainB,

This is a known bug. Two potential workarounds are given below. The examples below are for MCO1 through pin PA8. Please adopt them suitably for your use case:

Declare PA14 as gpio under the peripheral node that is supposed to use it (Note: If PA14 is declared under RCC node in your device tree, remove the declaration and declare it under peripheral node only).

Below is an example of pin PA8 (MCO1) being bound to camera module OV5640 (adopt it suitably for your use case):

&i2c5{

pinctrl-names = “default”, “sleep”;

pinctrl-0 = <&i2c5_pins_mx>;

pinctrl-1 = <&i2c5_sleep_pins_mx>;

status = “okay”;

/ USER CODE BEGIN i2c5 /

clock-frequency = <400000>;

i2c-scl-rising-time-ns = <185>;

i2c-scl-falling-time-ns = <20>;

/delete-property/ dmas;

/delete-property/ dma-names;

ov5640:camera@3c{

compatible = “ovti,ov5640”;

pinctrl-names = “default”, “sleep”;
pinctrl-0 = <&rcc_mco1_pin>;
pinctrl-1 = <&rcc_mco1_sleep_pin>;
reg = <0x3c>;
clocks = <&rcc CK_MCO1>;
clock-names = “xclk”;
….

}

};

Alternatively, you could also modify the following in clk-stm32mp1.c (search for this line, add CLK_IS_CRITICAL like below):

COMPOSITE(CK_MCO1, “ck_mco1”, mco1_src, CLK_IS_CRITICAL | CLK_OPS_PARENT_ENABLE |
CLK_SET_RATE_NO_REPARENT,
_GATE(RCC_MCO1CFGR, 12, 0),
_MUX(RCC_MCO1CFGR, 0, 3, 0),
_DIV(RCC_MCO1CFGR, 4, 4, 0, NULL)),

In the device tree, just the pinctrl entry should do to configure PA8 as alternate 0

[Eshtaartha Basu]

Hello @mlarkin,

We have not tested the patches for OSD32MP1-BRK on latest version of Developer Package from ST.

We will update the “Requirements” section of BRK patches Git page (https://github.com/octavosystems/BRK_Developer_Package_patches) once the BRK patches are updated to work on the latest Developer Package. No instructions are available at the moment.

Please follow our twitter handle @octavosystems to get quickly notified about any new updates.

[Author]

Posts