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
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
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
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/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
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
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
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
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
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
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
Sktz,
It seems like +5V input to OSD3358 experiences a glitch during power up. For the 5V power input(AC) there are 2 main requirements:
1. Rise time is < 50ms
2. Inrush is ~1500mA The scope shot indicates that the PMIC detects first power up and begins the internal power on sequence by switching SYS_VOUT ON. Then, +5V experiences a glitch resulting in a shutdown of the PMIC. It seems that +5V input does not go all the way down to 0V. In the scope shot, it only goes to ~2.7V. This is below the UVLO(default is set to 3.3V for the PMIC). So, PMIC is able to detect the next positive edge of the +5V signal for Auto turn-on. The suspicion is that in some cases, the +5V input does not go all the way down below UVLO voltage resulting in a lockup condition. Please take a look at https://www.ti.com/lit/an/slva901/slva901.pdf for more information on this type of brownout.
I think this glitch will need to be addressed in order to get reliable boot. Please also take a look at Sheet 1 of the SM-RED schematics: https://octavosystems.com/docs/osd3358-sm-red-schematics-pdf/ for a good power monitoring circuit that implements a solution to address brownout of the power input by adding a voltage monitor and switch.
Best,
Neeraj
Dinesh,
Seems like the kernel is unable to initialize the UART devices you are trying to setup. https://elixir.bootlin.com/linux/v6.11.11/source/include/uapi/asm-generic/errno-base.h#L26 shows the generic error codes for Linux kernel, here indicating an invalid argument somewhere in the driver probe function of the UART driver for STM32 inside OSD32.
Please review https://wiki.st.com/stm32mpu/wiki/Serial_TTY_device_tree_configuration and https://wiki.st.com/stm32mpu/wiki/Trace_and_debug_scenario_-_UART_issue for a reference to device tree and a good how-to on debugging the issue. May be there is an issue with DMA channel usage, in which case you can disable the use of DMA for the UARTs by following the device tree guide linked above.
Best,
Neeraj
Answered in the original thread:
Song,
The step-by-step build instructions are provided in the README for the repository. You will need an Ubuntu host to build the image.
I have also temporarily uploaded the latest built image here: https://octavosystems.com/flashlayout_sdcard_stm32mp157f-osd32mp1-brk-optee/
Best,
Neeraj
Dinesh,
Please take a look at the examples provided here(by ST):https://github.com/STMicroelectronics/STM32CubeMP1/tree/master/Projects/STM32MP157C-DK2/Examples.
Best,
Neeraj
Song,
The step-by-step build instructions are provided in the README for the repository. You will need an Ubuntu host to build the image.
I have also temporarily uploaded the latest built image here: https://octavosystems.com/flashlayout_sdcard_stm32mp157f-osd32mp1-brk-optee/
Best,
Neeraj
Octavo Systems LLC all rights reserved
OCTAVO is registered in the U.S. Patent and Trademark Office. OSD, C-SiP, and the Octavo Logo are trademarks of Octavo Systems LLC.
"*" indicates required fields
"*" indicates required fields
"*" indicates required fields
"*" indicates required fields