[Neeraj Dantu]

Gil,

Apologies for the confusion. When you are booting from UART, it is unfortunately not possible to change the default pinmuxing. Please take a look here: https://wiki.st.com/stm32mpu/wiki/STM32_MPU_ROM_code_overview#UART_Boot. While eMMC, SD, and QSPI boot modes allow you to change the default pins used in ROM code for booting, this is not possible for UART. However, the ROM code scans multiple UART interfaces as described in the ROM code overview. You can see if you have access to any of these interfaces on your board.

You can take a look at OTP mapping here: https://wiki.st.com/stm32mpu/wiki/STM32MP15_OTP_mapping. OTP_WORD3[0:4] can be set to configure non default pin mux for QSPI, eMMC and SD boot modes and the pinmux can be set in OTP_WORD5 – OTP_WORD7.

You could use USB boot if you have access to the USB OTG port. Booting with USB is described here: https://wiki.st.com/stm32mpu/wiki/STM32_MPU_ROM_code_overview#USB_Boot. You can use Cube Programmer to bring up FSBL and SSBL. From there as you can define pinmuxing as you like in the device tree, you can setup next boot steps according to your choice.

Best,
Neeraj

[Neeraj Dantu]

Carlos,

I think the warning is more about security rather than functionality. The features in the script can be used to inject malicious code such as a device tree overlay that should not be applied on a production level product. The suggestion is to use hard coded paths in u-boot bootcmd to setup boot.

Best,
Neeraj

[Neeraj Dantu]

Gil,

I think you can change the pin mux for UARt4 with device tree. For example, the pinmux in TF-A is defined here: https://github.com/octavosystems/osd32mp1-build-tools/blob/master/patches/arm-trusted-firmware-2.4/0001-Add-OSD32MP1-BRK-Device-tree-support.patch#L684. You should be able to change the pin setting there.

Best,
Neeraj

[Neeraj Dantu]

Carlos,

Yes, we will be adding support for OpenSTLinux v4.0 for both meta-octavo-osd32mp1 and Debian SDK. I will update here once I receive a timeline.

Best,
Neeraj

[Neeraj Dantu]

Anton,

OSD32MP1-BRK has been added to the Debian SDK. You will need to modify the Makefile in build-tools here: https://github.com/octavosystems/osd32mp1-build-tools/blob/master/Makefile#L26. You can change the board name to stm32mp157c-osd32mp1-brk. Please note that since BRK only has an SD card interface, you will need to set the BOOT_EMMC variable to 0 as well.

We will generate some collateral around the Debian SDK. The SDK was designed to be easy to understand and modify. Here are some pointers to get started:

1. The Makefile(https://github.com/octavosystems/osd32mp1-build-tools/blob/master/Makefile) defines the build process inside docker and this is where you will have to make changes to make changes to the kernel, device tree, u-boot and TF-A.

2. https://github.com/octavosystems/osd32mp1-build-tools/tree/master/patches contains all the patches that will be applied to the individual source codes. You can add custom patches here and they will automatically get added to the source code before build.

3. By adding commands under each Makefile target such as BOOTF(https://github.com/octavosystems/osd32mp1-build-tools/blob/master/Makefile#L113) to modify how each of the targets are built. For example, you can add custom splash image by modifying https://github.com/octavosystems/osd32mp1-build-tools/blob/master/Makefile#L119

4. You can add packages to the default image generated by modifying the multistrap config file here: https://github.com/octavosystems/osd32mp1-multistrap/blob/osd32mp1-v3.0/debian-config-bullseye

5. You can also add custom files to your root filesystem by adding them here: https://github.com/octavosystems/osd32mp1-multistrap/tree/osd32mp1-v3.0/files

Hope that helps. Please feel free to ask any specific question you have on the forums here.

Best,
Neeraj

[Neeraj Dantu]

jackthree,

The UART0 console is discussed here in the tutorial series: https://octavosystems.com/app_notes/osd335x-design-tutorial/bare-minimum-boot/peripheral-circuitry/. As you can see, there is no pull-down on RX. The pull-down on RX in the reference designs were added to make sure that the RX pin is not floating, which ensures that there is no halt during u-Boot execution, but this is not necessary to do in hardware. You can activate internal pull-up/pull-down in device tree as shown in https://github.com/octavosystems/OSD335x-Device-Tree/blob/master/OSD3358-SM-RED/osd3358-bsm-refdesign.dts#L219. Please check your device tree and try to add pull-up/pull-down configuration there. Note that internal configuration is a weak pull-up/pull-down. If you are still having issues after that, something might be interfering with UART0 comm lines.

Best,
Neeraj

[Neeraj Dantu]

Marco,

It looks like the boot mode setting are correct and AM335x initiates an SD card boot. The log file you posted, while it has errors in the beginning shows data transfer in the later half, which means the ROM code is able to read the SD card.

Have you looked at the EEPROM app note linked above to see if your board needs and EEPROM ID for boot check? Please see https://www.ti.com/lit/ug/spruh73q/spruh73q.pdf Section 26.1.8.5.3 for more information on boot procedure for SD card. By default, SPL debug print is disabled by u-boot config. You can turn it on for build using https://github.com/ARM-software/u-boot/blob/master/common/spl/Kconfig#L145.

You can also use https://github.com/RobertCNelson/omap-image-builder/tree/master/octavo to build images for blank EEPROM or enabling debug messages in SPL and U-Boot.

Best,
Neeraj

[Neeraj Dantu]

mlarkin,

Yes, OSD32MP153C, OSD32MP157C and OSD32MP157F projects will be available part of the app note update.

Best,
Neeraj

[Neeraj Dantu]

amolina,

As mentioned in https://octavosystems.com/forums/topic/kernel-modification-in-debian-image/, you can add configuration fragments to disable kernel signing in the same way you can disable via menuconfig.

See a related discussion here: https://stackoverflow.com/questions/24975377/kvm-module-verification-failed-signature-and-or-required-key-missing-taintin for more info on driver signing.

Best,
Neeraj

[Neeraj Dantu]

amolina,

You can do this by using configuration fragments. The kernel build for OpenSTLinux and OSD32MP1-Debian uses multi_v7_defconfig. You can see configuration fragments applied on top of the default config here: https://github.com/octavosystems/osd32mp1-build-tools/blob/master/Makefile#L106.

An example of the configuration fragment that gets applies as part of the Debian build process is here: https://github.com/octavosystems/osd32mp1-build-tools/blob/master/patches/linux-5.10/fragment-06-etnaviv.config.

Best,
Neeraj

[Neeraj Dantu]

Alciom,

Unfortunately, apart from preventing the input voltage from going out of the specified range of the PMIC, there is not a solution that will mitigate brownout in all scenarios. Adding capacitance can help. The new version of the OSD3358-SM-RED reference design does include this mitigation to prevent lockups dues to brownout.

Please take a look at this app note from TI: https://www.ti.com/lit/an/slva901/slva901.pdf that describes mitigation strategies for different use cases.

Best,
Neeraj

[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

[Author]

Posts