[Neeraj Kumar Reddy Dantu]

Farid,

The register read for SYBOOT pins “SYSCFG_BOOTR = 0” indicates that the SoC is seeing 000b boot setting instead of 010b for eMMC. This register read is the reading from the SoC of the physical pin setting for BOOT pins. There is something wrong with the way the boot mode is being set. Can you check for shorts?

The boot from eMMC at u-boot shows good eMMC boot. So, eMMC looks like it is programmed. So, once the SoC sees the correct boot settings, it should be able to boot from the eMMC

Best,
Neeraj

[Neeraj Kumar Reddy Dantu]

Farid,

Can you post the boot logs related to the flashing of the eMMC(UART output when flashing is initiated in DFU mode).

From the information you provided, it looks like the interface between OSD32MP1 and eMMC is functional.

As you are able to get to u-boot, the first thing to check is whether the boot mode is correct. If you execute “md.l 0x50020000 1” in u-boot command line, it should tell you what the device thinks the boot mode configuration is(See SYSCFG_BOOTR register description in the Technical Reference Manual – RM0436).

As you have access to u-boot command line, you can run the command “run distro_bootcmd” to see if the board can use the eMMC to boot the rest of the way. If eMMC is flashed correctly for boot and rootfs partitions, it should boot to Linux command line with eMMC rootfile system.

It eMMC is programmed and the board boots correctly after executing distro_bootcmd, there may be an issue is the boot0 and boot1 partitions of the eMMC. Booting from eMMC depends on FSBL being programmed into mmcblk2boot0 and mmcblk2boot1 partitions of eMMC that are apart from the main eMMC partitions. These are marked read only by default, but needed for eMMC boot.

Once you are are in Linux command line, you can program the boot0 and boot1 partitions like shown here: https://octavosystems.com/forums/topic/cloning-emmc-2/.

Best,
Neeraj

[Neeraj Kumar Reddy 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 Kumar Reddy 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 Kumar Reddy 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 Kumar Reddy 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 Kumar Reddy 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 Kumar Reddy 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 Kumar Reddy 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 Kumar Reddy 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 Kumar Reddy 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 Kumar Reddy 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 Kumar Reddy 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 Kumar Reddy 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 Kumar Reddy 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

[Author]

Posts