[Neeraj Dantu]

Farid,

Bluetooth is implemented with USART interface connection to LBEE5KL1DX module. Take a look at USART2_XX signals on page 10 of the schematic: https://octavosystems.com/docs/osd32mp15x-red-schematic-pdf/. You can see the device tree entries for USART2 interface invoking the Bluetooth driver heer: https://github.com/octavosystems/osd32mp1-build-tools/blob/master/patches/linux-5.10/0024-Add-OSD32MP1-RED-Device-tree-support.patch#L1364.

Note that you don’t need the PCM interface for Bluetooth to work. PCM interface is needed to transfer audio over Bluetooth.

Best,
Neeraj

[Neeraj Dantu]

amolina,

The line of the Makefile(https://github.com/octavosystems/osd32mp1-build-tools/blob/master/Makefile#L139) I linked in my first response shows how you can sign the kernel module. You can integrate your custom driver into the Debian SDK by modifying the Makefile. Note the gcnano label that gives you a blueprint for out of tree kernel modules as the gcnano kernel module itself is an out of tree kernel module that gets compiled and added to the kernel(https://github.com/octavosystems/osd32mp1-build-tools/blob/master/Makefile#L147).

Best,
Neeraj

[Neeraj Dantu]

amolina,

This error could be related to signing of the kernel module. Module signing is enabled in the current version of the OpenSTLinux. You can sign the kernel module with the command shown here: https://github.com/octavosystems/osd32mp1-build-tools/blob/master/Makefile#L139.

You can also see the exact version of the kernel being cloned for the Debian SDK here: https://github.com/octavosystems/osd32mp1-debian/blob/main/default.xml#L7. It indicates that the kernel version is 5.10-stm32mp-r1.

That should be the same version used by meta-octavo: https://github.com/octavosystems/meta-octavo-osd32mp1.

Best,
Neeraj

[Neeraj Dantu]

amolina,

There is currently no CubeMX project for OSD32MP1 dev boards, but you should be able to achieve what you are trying to do using the following, fairly simple work around.

1. Generate device trees using the default minimal Cube MX project or an stm32mp157x project from CubeMX.

2. Save the device trees you generated.

3. Make specific changes you want to make to a peripheral by starting from either the minimal CubeMX project or an stm32mp157x project from Cube MX. Generate a new version of the device trees

4. Diff the device trees from step 1 and step 3 to reveal the specific changes related to the peripheral.

5. Add these changes to the RED board device tree.

Best,
Neeraj

[Neeraj Dantu]

Gregory & Tomas,

Thank you so much for the inputs on this issue. We are updating the CubeMX app note and will try to address migrating issues in the next revision.

Best,
Neeraj

[Neeraj Dantu]

amolina,

Unfortunately, the support for OSD32MP1 for Yocto compatible OpenSTLinux was added beginning with OpenSTLinux 3.0(Kernel 5.10). You can use the Debian SDK V1 to test the 4.19 kernel. You can find the procedure to build with 4.19 kernel on Debian SDK here: https://github.com/octavosystems/osd32mp1-debian/tree/9331557dc2870357f9f8701f3bc88bc5ee6f354f

Best,
Neeraj

[Neeraj Dantu]

amolina,

If you use Engineering boot mode,(100b: See Sheet 1 of OSD32MP1-RED schematics) you will not need to do anything to develop on M4 in terms of hardware configuration. The clock tree and pinmuxing can be setup in the M4 firmware code via ST-Link. This is the recommended way of developing code for the M4. This way, you can develop without the interference from the A7 core.

Once you are done developing code, you can setup the A7 device tree to give M4 access to the right pins and setup the clock tree. You can find more information on setting up the pinmuxing through the A7 core here:https://wiki.st.com/stm32mpu/wiki/How_to_assign_an_internal_peripheral_to_a_runtime_context

Best,
Neeraj

[Neeraj Dantu]

amolina,

You can use most of the pins of the motor control header or the RPi header defined in sheet 11 of the schematics(https://octavosystems.com/docs/osd32mp15x-red-schematic-pdf/) as they are not defined in the device tree in the default image. Note that some signals of the motor control header are used for other functions needed by the default image. These signals are on Sheet 3 of the schematic.

Best,
Neeraj

[Neeraj Dantu]

mlarkin,

The eMMC specification requires pull-ups on the interface signals. STM32MP1 I/Os have internal pull-ups that can be activated in bootloaders. For ROM code stage, only D0, CMD and CLK are used. So, EV1 includes pull-ups on these pins. The pull-ups on other data signals are activated in TF-A and the interface is switched from 1 bit to 8 bit interface according to specification in the device tree.

You can either populate the reduced number of pull-ups as in the EV1 schematics and activate the remaining pull-ups in device tree or populate all pull-ups and exclude pull-up configuration in device tree.

Best,
Neeraj

[Neeraj Dantu]

amolina,

We do not recommend using it to compile device trees for OSD32MP1, the main reason being it does not have all the include files and the kernel version is 4.14. ST’s latest release is 5.10 kernel: https://github.com/STMicroelectronics/linux. ST also has custom device tree organization that has not been pushed to mainline or exist anywhere else other than the linux kernel repository linked above.

Moreover, to effect change in peripheral setup, modifications to clock tree are also necessary that set and enable clocks for the peripherals being used. This can only be done in TF-A and U-Boot. This means, recompiling TF-A and U-Boot is necessary to make the clock tree changes needed to enable/disable a peripheral.

Here are some inputs on how to recompile device trees:

1. ST’s Developer Package: https://www.st.com/en/embedded-software/stm32mp1dev.html#get-software. For compatibility with the latest from Octavo. You will need to download version 3.0. This is essentially source code for TF-A, U-Boot and kernel and will allow you to compile them individually. You can then update your SD card/eMMC with the binaries you generated from the Developer Package. This procedure is described here: https://wiki.st.com/stm32mpu/wiki/STM32MP1_Developer_Package\

2. OSD32MP1 Debian SDK: The Debian SDK is Makefile based. So, you can edit the Makefile to do custom compilation. TF-A compilation happens here: https://github.com/octavosystems/osd32mp1-build-tools/blob/master/Makefile#L87. U-boot compilation happens https://github.com/octavosystems/osd32mp1-build-tools/blob/master/Makefile#L102. Kernel device tree compilation happens here: https://github.com/octavosystems/osd32mp1-build-tools/blob/master/Makefile#L108. You can edit the Makefile to trigger partial commands to just compile the TF-A, U-Boot FIP and kernel device tree.

3. Note on clock tree: You can set the clock tree settings here in TF-A(BRK device tree): https://github.com/octavosystems/osd32mp1-build-tools/blob/master/patches/arm-trusted-firmware-2.4/0001-Add-OSD32MP1-BRK-Device-tree-support.patch#L517. You can generate the rcc node bindings by using STM32CubeMX by making changes to the Clock tree page(see attached screenshot).

In addition, please take a look at https://octavosystems.com/app_notes/stm32mp1-cubemx-tutorial-for-osd32mp15x/

Best,
Neeraj

Attachments:

1. 

   cubemx_clock_tree.png
   

[Neeraj Dantu]

Carlos,

I apologize, I did not notice the USB-C aspect of your question. Yes, I believe you are correct. For a better understanding of what is required to use a USB-C port for dual role USB2, see https://www.ti.com/lit/wp/slly017/slly017.pdf. The controller performs switching role functions and monitors VBUS.

Best,
Neeraj

[Neeraj Dantu]

amolina,

We have not tried to use TI debuggers with ST device, initial thought is that it would not work.

I found ST Link V2 available here: https://www.amazon.com/Programmer-Debugger-Microcontroller-Interface-Simulation/dp/B09KV87CH3/ if you are in the US.

Best,
Neeraj

[Neeraj Dantu]

Marco,

Are you using an SD card which checks EEPROM ID when booting? Please see https://octavosystems.com/app_notes/osd335x-eeprom-during-boot/ for more details and procedure to boot with blank EEPROM.

As you are seeing “CC” in UART boot mode, you can assume that the board powers up just fine. You can probe(using an oscilloscope) the CLK and CMD lines of the SD card slot to see if the ROM code is selecting the boot mode for the SD card slot you selected.

Best,
Neeraj

[Neeraj Dantu]

Matringe,

This behavior is in general, an indication of a short present on one or more of the power rails of the PMIC. Please take a look at the start-up sequencing in Section 2 of the Power Application note here: https://octavosystems.com/app_notes/osd335x-c-sip-power-application-note/ to understand the start up sequence of the SiP. In addition to looking for shorts on all the power rails of the PMIC, you can scope the power up sequencing to determine which power rail is failing to come up.

Please also take a look at https://octavosystems.com/app_notes/osd335x-design-tutorial/bare-minimum-boot/boot-process/ as it goes through basic board bring up procedure.

Best,
Neeraj

• This reply was modified 2 years, 6 months ago by Neeraj Dantu.

[Neeraj Dantu]

Hey Carlos,

Please take a look at section 10.1.12 of the hardware getting started guide for MP1 for reference USB OTG circuit connections: https://www.st.com/resource/en/application_note/dm00389996-getting-started-with-stm32mp151-stm32mp153-and-stm32mp157-line-hardware-development-stmicroelectronics.pdf. Note the use of OTG_ID pin in addition to OTG_VBUS.

https://wiki.st.com/stm32mpu/wiki/OTG_device_tree_configuration shows the device tree configuration you will need for the OTG functionality.

Best,
Neeraj

[Author]

Posts