[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

[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

[Author]

Posts