[Neeraj Dantu]

Thanks for the update!

Best,

Neeraj

[Neeraj Dantu]

Carlos,

I am testing right now. Will update once I have anything here.

Best,

Neeraj

[Neeraj Dantu]

Gil,

CubeMX probably does not have that feature available. Please see https://wiki.st.com/stm32mpu/wiki/SPI_device_tree_configuration for example configuration of the SPI interface with a chip select pin. You can use any GPIO as a chip select.

Best,

Neeraj

[Neeraj Dantu]

Gil,

The alternate functions are for each pin and unrelated to each other in any port. You can set any alternate function on any pin as long as it makes sense in the peripheral defined. You do not need to set all pins of a port to a particular alternate function.

As far as booting interface goes, you can modify the default pins ROM code uses only for SD, eMMC and QSPI. You cannot change the default pins for UART interface, but you can select a different UART interface from which you can boot, unless disabled specifically in OTP.

Hope that clears things up.

Best,

Neeraj

[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

[Author]

Posts