[Neeraj Dantu]

Gil,

I believe the error you are seeing is because of the naming convention change of the main branch of libiio repository.

Can you edit: Work_Yocto/layers/meta-openembedded/meta-oe/recipes-support/libiio/libiio_git.bb file in your workspace to replace “branch=master” with “branch=main” and see if that fixes your issue?

I meant to test this before posting, but do not have Ubuntu 20.04 currently.

Please see https://stackoverflow.com/questions/68215012/how-do-i-fix-a-bitbake-failed-to-fetch-git-error for a similar kind of error that was fixed by changing the default branch name.

Best,
Neeraj

[Neeraj Dantu]

Antonio,

In addition to signal speed of 52MHz, trace length matching depends on other factors that have to do with the physical transmission medium and how it effects propagation delay.

Back of the napkin calculation for a 52MHz signal:

Period of signal is 1/52MHz = ~20ns. If you want to keep delay to ~5% of this period = ~1ns. Assuming that the transmission delay of the PCB is ~6 inches/ns(this can vary from PCB to PCB), the maximum difference in traces can be ~6 inches.

We never want to be this close. With 5mm difference you see on MP1-RED, there should be no issue.

However, there are other factors to consider:
– Do you plan to use high speed modes of the MMC controller running in DDR mode at 100MHz(~200MHz)? If so, the length matching rules will need to be tighter.
– Consider also that propagation delay is based on PCB parameters.
– We did not consider setup and hold times in the above calculation.
– eMMC being used might have special delays

My recommendation is to be as close as possible in matching as it would not hurt to make it tighter. The MP1-RED was designed keeping the use case(52MHz max) and PCB material in mind.

Best,
Neeraj

[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

[Author]

Posts