[Neeraj Dantu]

Prabhu,

The RED image you have should have the DDR configuration needed to boot OSD32MP1 device. The boot scheme for v3.0 images is TF-A –> u-boot –> kernel. There is not OPTEE stage.

Since we need more confidential information to continue debug. I will ask sales to setup a channel. Please lookout for an email.

Best,
Neeraj

[Neeraj Dantu]

Song,

I just updated the device tree repo: https://github.com/octavosystems/OSD32MP1-BRK-device-tree.

The README in the meta-octavo-osd32mp1 repository provides the procedure to build the images. You will need an Ubuntu VM or host machine to build it. We do plan to update the images on the BRK web page shortly.

Please let us know if you face any issues.

Best,
Neeraj

[Neeraj Dantu]

Prabhu,

Are you booting with BRK/RED images or is this a custom image?

If it is a custom image, can you check the device tree you are using? You will need to include the PMIC configuration in your TF-A device tree like here: https://github.com/octavosystems/OSD32MP1-BRK-device-tree/blob/kirkstone/tf-a-v2.6-stm32mp-r1/stm32mp157c-osd32mp1-brk.dts#L98. Note that BUCK2 output of the PMIC is rank 0, meaning it needs to be setup in device tree for it to turn ON after boot. Please probe VDD_DDR, VTT_DDR and VREF_DDR. The expected voltages are listed in table “OSD32MP15x Power Output Configuration” of this app note: https://octavosystems.com/app_notes/osd32mp1-power-system-overview/

In addition, make sure the correct .dtsi fiole defining DDR timing parameters are included. Here is the file: https://github.com/octavosystems/OSD32MP1-BRK-device-tree/blob/kirkstone/tf-a-v2.6-stm32mp-r1/osd32mp1_ddr_1x4Gb.dtsi.

Best,
Neeraj

[Neeraj Dantu]

ML,

I suspect what you are seeing is a result of delamination of OSD32MP1 substrate. This can happen due to moisture absorption of the device resulting in rapid expansion of the absorbed moisture during reflow.

Please review sections 9.2 and 9.3 of the datasheet for storage and reflow requirements for OSD32MP1. It is possible to rework the board to replace OSD32MP1. Please make sure the reflow and storage requirements are followed.

Best,
Neeraj

[Neeraj Dantu]

Guillaume,

I just pushed an update to the meta-octavo layer here: https://github.com/octavosystems/meta-octavo-osd32mp1/tree/scarthgap. This update only supports the BRK. I am working on adding the RED board. Please let me know if you have any issues.

Best,
Neeraj

[Neeraj Dantu]

ML,

You should be able to use 7F device as 3C by disabling the extra hardware as 7F is a super-set device that has all the features of 3C. Additionally, this patch: https://github.com/octavosystems/osd32mp1-build-tools/blob/master/patches/linux-5.10/0025-Fix-device-tree-for-800MHz-speedgrade-MP1-to-work-wi.patch allows you to run the 7F device at 3C speed(650MHz).

Best,
Neeraj

[Neeraj Dantu]

ML,

This is how I wrote and read back from EEPROM on OSD32MP1-BRK:

root@localhost:/sys/bus/i2c/devices/3-0050# echo “OSD32MP1” > eeprom
root@localhost:/sys/bus/i2c/devices/3-0050# cat eeprom
OSD32MP1
?????????????????????????????????????????????????????????

You are seeing “UU” in i2cdetect output because the driver for the EEPROM is in control of the I2C device. You can still force i2c tools to interact with the EEPROM using “-f” flag if you need to.

Please make sure you also set the EEPROM_WP(write protect) switch position located in the BOOT switches(switch #4) to the position towards the Micro-USB port. This disables the write protect on the EEPROM so you can write to it.

Best,
Neeraj

[Neeraj Dantu]

Hey ML,

I have re-verified that the image downloaded from the above post is OK. I also used Etcher(on Ubuntu OS) to program the SD card to make sure there is no problem with the image file. Can you try a different SD card/host machine/Etcher version?

Best,
Neeraj

[Neeraj Dantu]

ML,

My apologies, I did not realize a fix was not issued to the images on the website. The issue is that the EEPROM follows 16 bit addressing format and by default 8 bit addressing is used by the at24 driver.

To fix this, the device tree for the board needs “address-width = <16>;” definition in eeprom node.

Here is a Debian image that has this fix: https://octavosystems.com/wp-content/uploads/2025/02/FlashLayout_sdcard_stm32mp157c-osd32mp1-brk-trusted.zip. I am working on updating the images on the web and OpenSTLinux layers.

Please let me know how the new image works for you.

Best,
Neeraj

[Neeraj Dantu]

ML,

I would suggest trying a different USB cable(some cables only provide power).

Also, you should be able to use a USB to UART adapter to connect to the UART interface(marked TX, RX and GND) near the SD card slot. This will allow you to use a program like Putty to open a terminal on your computer and monitor the console log output of the BRK board when it is booting. After it boots, it will also provide a console for you to type in commands like “ifconfig” to see the Ethernet configuration from the board side. An example adapter can be found here: https://learn.sparkfun.com/tutorials/sparkfun-usb-to-serial-uart-boards-hookup-guide/all.

Best,
Neeraj

[Neeraj Dantu]

ML,

Please see https://www.kernel.org/doc/Documentation/i2c/i2c-sysfs.rst for an overview of I2C SYSFS. The EEPROM driver invoked by the device tree provides entries in /sys/bus/i2c/devices directory that you can interact with as files.

The default Linux image should come with EEPROM device driver enabled. Images for BRK are available here: https://octavosystems.com/octavo_products/osd32mp1-brk/#Software/. See also: https://octavosystems.com/app_notes/osd32mp1-brk-getting-started/.

Best,
Neeraj

[Neeraj Dantu]

ML,

The EEPROM is configured in the device tree here: https://github.com/octavosystems/OSD32MP1-BRK-device-tree/blob/kirkstone/linux-v5.15.24-stm32mp1-r1/stm32mp157c-osd32mp1-brk.dts#L837. You should be able to access it using the SYSFS via ‘/sys/bus/i2c/devices/3-0050/’. ‘3’ is the I2C interface number that the EEPROM is on and ‘0050’ is the address of the EEPROM. This directory contains file “eeprom”, which you can use to interact with the EEPROM. Please see https://stackoverflow.com/a/60781512.

There are a number of other ways including using Linux IOCTL/python libraries/[shell commands: i2ctools]. See https://wiki.st.com/stm32mpu/wiki/I2C_i2c-tools for useful info on using i2ctools.

Best,
Neeraj

[Neeraj Dantu]

Dinesh,

Have you checked whether the pinmux is correct? If there are pin conflicts in the device tree(same pin used by different peripherals), that could be an issue. An additional reference is the BRK, which implements UART5, UART7 and UART8: https://github.com/octavosystems/OSD32MP1-BRK-device-tree/tree/kirkstone.

If everything mentioned so far has been verified, please post the device tree you are using as well as the complete “dmesg” output so I can take a look.

Best,
Neeraj

[Neeraj Dantu]

Dinesh,

Unfortunately, the BRK does not bring out all the LTDC pins needed for RGB/HDMI display connections. We recommend using OSD32MP1-RED for GUI development. There is also STM32MP1-DK2(https://www.digikey.com/en/products/detail/stmicroelectronics/STM32MP157F-DK2/13536968) as well as EV1(https://www.mouser.com/ProductDetail/STMicroelectronics/STM32MP257F-EV1?qs=ZcfC38r4PosgjLnr0guC7A%3D%3D&mgh=1) which pins out RGB output to header for more custom display development. Please note that any development on ST’s dev boards can easily be ported to OSD32MP1 with a simple DDR header file change.

Best,
Neeraj

[Neeraj Dantu]

Song,

The build time depends on how powerful the machine is. More cores will definitely reduce the build time. It can take anywhere between ~20min to multiple hours to build the image from scratch depending on machine configuration, but modifications generally take much less time to do.

Best,
Neeraj

[Author]

Posts