PROCESSOR-SDK-AM64X: Redundant u-boot environment in eMMC

Benjamin Postma

Tool/software:

Hi TI experts,

we develop a product with the AM64x EVM as reference design. For firmware updated we use swupdate (recovery image method).
On boot u-boot must decide which image to boot (recovery / normal image), and therefore the u-boot environment has to be modified when an update is initiated / finished.

For increased robustness, we want to use the redundant environment, both stored in the boot partition of the eMMC (mmcblk0 boot0). Therefore I modified the files configs/am64x_evm_a53_defconfig and configs/am64x_evm_r5_defconfig
As a reference I used the information provided by TI: software-dl.ti.com/.../UG-Memory.html

After build and flash the image (tisdk-default-image), the R5-SPL (contained in tiboot3.bin) hangs after producing the following output:

------
U-Boot SPL 2024.04-ti-g50481472c910 (Dec 04 2024 - 10:01:28 +0000)
Resetting on cold boot to workaround ErrataID:i2331
Please resend tiboot3.bin in case of UART/DFU boot
resetting ...

U-Boot SPL 2024.04-ti-g50481472c910 (Dec 04 2024 - 10:01:28 +0000)
SYSFW ABI: 4.0 (firmware rev 0x000a '10.0.8--v10.00.08 (Fiery Fox)')
SPL initial stack usage: 13392 bytes
Trying to boot from MMC2
Authentication passed
Authentication passed
Loading Environment from MMC...
-------

After some debugging I realized that there exist different variants of the function static int env_mmc_load(void) env/mmc.c,
where the selection criterium is the define CONFIG_SYS_REDUNDAND_ENVIRONMENT.

Within the variant for redundant environment, the function mmc_initialize (NULL) (line 405) is called, and it seems that the loader crashes there.
This function is not called when compiling for single environment, which leads to the following output:

--------
U-Boot SPL 2024.04-ti-g50481472c910 (Dec 04 2024 - 10:01:28 +0000)
Resetting on cold boot to workaround ErrataID:i2331
Please resend tiboot3.bin in case of UART/DFU boot
resetting ...

The environment could not be loaded either, but at least the boot process continues.

So my questions are:
1. Is my approach a valid one? Would you recommend using a second environment in my use case?

2. Can you tell why the mmc_initialize() function leads to a frozen system? I run a test with the line commented, and the system booted as if I had only a single environment.

Fullscreen config_patch.txt Download

diff --git a/configs/am64x_evm_a53_defconfig b/configs/am64x_evm_a53_defconfig
index 7312d3ae242..fe7c19b377e 100644
--- a/configs/am64x_evm_a53_defconfig
+++ b/configs/am64x_evm_a53_defconfig
@@ -12,7 +12,15 @@ CONFIG_K3_ATF_LOAD_ADDR=0x701c0000
 CONFIG_TARGET_AM642_A53_EVM=y
 CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
 CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x80480000
-CONFIG_ENV_SIZE=0x20000
+CONFIG_ENV_IS_IN_MMC=y
+# CONFIG_ENV_IS_NOWHERE is not set
+CONFIG_SYS_MMC_ENV_DEV=0
+CONFIG_SYS_MMC_ENV_PART=1
+CONFIG_SYS_REDUNDAND_ENVIRONMENT=y
+# CONFIG_USE_ENV_MMC_PARTITION is not set
+CONFIG_ENV_OFFSET=0x700000
+CONFIG_ENV_OFFSET_REDUND=0x704000
+CONFIG_ENV_SIZE=0x4000
 CONFIG_SYS_SPI_U_BOOT_OFFS=0x300000
 CONFIG_DM_GPIO=y
 CONFIG_SPL_DM_SPI=y
diff --git a/configs/am64x_evm_r5_defconfig b/configs/am64x_evm_r5_defconfig
index 7a20a0e67d9..b3293d4ef4c 100644
--- a/configs/am64x_evm_r5_defconfig
+++ b/configs/am64x_evm_r5_defconfig
@@ -10,8 +10,6 @@ CONFIG_SOC_K3_AM642=y
 CONFIG_TARGET_AM642_R5_EVM=y
 CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
 CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x7019b800
-CONFIG_ENV_SIZE=0x20000
-CONFIG_ENV_OFFSET=0x680000
 CONFIG_DM_GPIO=y
 CONFIG_SPL_DM_SPI=y
 CONFIG_DEFAULT_DEVICE_TREE="k3-am642-r5-evm"
@@ -90,7 +88,12 @@ CONFIG_SPL_OF_LIST="k3-am642-r5-evm k3-am642-r5-sk"
 CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+CONFIG_SYS_MMC_ENV_DEV=0
 CONFIG_SYS_MMC_ENV_PART=1
+CONFIG_SYS_REDUNDAND_ENVIRONMENT=y
+CONFIG_ENV_SIZE=0x4000
+CONFIG_ENV_OFFSET=0x700000
+CONFIG_ENV_OFFSET_REDUND=0x704000
 CONFIG_SPL_DM=y
 CONFIG_SPL_DM_SEQ_ALIAS=y
 CONFIG_REGMAP=y

11 months ago

0 Prashant Shivhare 11 months ago

TI__Guru 73241 points

Hello,

As you might already know, the eMMC has two boot partitions: 1) Boot0, and 2) Boot1.

So, you could keep the normal U-Boot images to the Boot0 partition while the recovery U-Boot images to the Boot1 partition.

For the software update, you would modify the EXTCSD register to select the boot partition to Boot1 & hit reset. The ROM would then boot the R5 SPL from the Boot1 partition & the R5 SPL would boot the further images from the same partition as well.

At the end of the software update, you would again modify the EXTCSD register register to select the boot partition to Boot0 & hit reset to boot the normal U-Boot images.

Regards,

Prashant

0 Benjamin Postma 11 months ago in reply to Prashant Shivhare

Prodigy 70 points

Hi Prashant,

thanks for your response. I am aware of the two boot partitions, and of the EXTCSD register (reference: Working with eMMC (embeddedartists.com) ).
However, I think this is not related to my question, since I still need the u-boot environement to update some variables during software update (upgrade_available / bootcount).

So my question is:

How to enable redundant u-boot environment stored at e.MMC boot partition?

Further information: Currently I boot from SD Card. Is it a general problem, to boot from SD-Card (MMC port 1), and initialize (and later access) eMMC (MMC port 0) from R5 SPL?

Thanks in advance.

BR Benjamin

0 Benjamin Postma 10 months ago in reply to Benjamin Postma

Prodigy 70 points

Hi,
any updates so far? Any help is appreciated.

BR Benjamin

0 Prashant Shivhare 10 months ago in reply to Benjamin Postma

TI__Guru 73241 points

Hi,

Benjamin Postma said:
Currently I boot from SD Card.

This is the cause of the issue.

The U-Boot SPL is designed to probe only the required drivers for booting. If booting from the SD card, the eMMC is not required so it is not probed (driver not initialized) prior to the env load & hence the failure.

If booting from eMMC, the redundant env feature with switch between the original & redundant env should work as shown:

U-Boot SPL 2024.04-dirty (Dec 16 2024 - 19:51:14 +0530)
SYSFW ABI: 4.0 (firmware rev 0x000a '10.0.8--v10.00.08 (Fiery Fox)')
SPL initial stack usage: 13392 bytes
Trying to boot from MMC1
Authentication passed
Authentication passed
Loading Environment from MMC... [read_env:384] blk_start: 0x3400, blk_cnt: 0x100, buffer: 0x81fbfe00
[read_env:384] blk_start: 0x3500, blk_cnt: 0x100, buffer: 0x81fdfe40
[env_import:420] buf: 0x81fbfe00
OK
init_env from device 9 not supported!
Authentication passed
Authentication passed
Starting ATF on ARM64 core...

NOTICE:  BL31: v2.10.0(release):v2.10.0-367-g00f1ec6b87-dirty
NOTICE:  BL31: Built : 16:09:05, Feb  9 2024
I/TC:
I/TC: OP-TEE version: 4.2.0-dev (gcc version 13.3.0 (GCC)) #1 Fri Apr 12 09:51:21 UTC 2024 aarch64
I/TC: WARNING: This OP-TEE configuration might be insecure!
I/TC: WARNING: Please check https://optee.readthedocs.io/en/latest/architecture/porting_guidelines.html
I/TC: Primary CPU initializing
I/TC: GIC redistributor base address not provided
I/TC: Assuming default GIC group status and modifier
I/TC: SYSFW ABI: 4.0 (firmware rev 0x000a '10.0.8--v10.00.08 (Fiery Fox)')
I/TC: HUK Initialized
I/TC: Activated SA2UL device
I/TC: Enabled firewalls for SA2UL TRNG device
I/TC: SA2UL TRNG initialized
I/TC: SA2UL Drivers initialized
I/TC: Primary CPU switching to normal world boot

U-Boot SPL 2024.04-dirty (Dec 16 2024 - 19:51:21 +0530)
SYSFW ABI: 4.0 (firmware rev 0x000a '10.0.8--v10.00.08 (Fiery Fox)')
Trying to boot from MMC1
Authentication passed
Authentication passed


U-Boot 2024.04-dirty (Dec 16 2024 - 19:51:21 +0530)

SoC:   AM64X SR2.0 HS-FS
Model: Texas Instruments AM642 EVM
Board: AM64-GPEVM rev C
DRAM:  2 GiB
Core:  98 devices, 31 uclasses, devicetree: separate
NAND:  0 MiB
MMC:   mmc@fa10000: 0, mmc@fa00000: 1
Loading Environment from MMC... [read_env:384] blk_start: 0x3400, blk_cnt: 0x100, buffer: 0xfde4cd80
[read_env:384] blk_start: 0x3500, blk_cnt: 0x100, buffer: 0xfde6cdc0
[env_import:420] buf: 0xfde4cd80
OK
In:    serial@2800000
Out:   serial@2800000
Err:   serial@2800000
Net:   eth0: ethernet@8000000port@1, eth2: icssg1-eth-port@0
Hit any key to stop autoboot:  0
=> saveenv
Saving Environment to MMC... Writing to redundant MMC(0)... [write_env:252] blk_start: 0x3500, blk_cnt: 0x100
OK
=> mw 0x43000030 0xcb 0x1;reset;
resetting ...

U-Boot SPL 2024.04-dirty (Dec 16 2024 - 19:51:14 +0530)
SYSFW ABI: 4.0 (firmware rev 0x000a '10.0.8--v10.00.08 (Fiery Fox)')
SPL initial stack usage: 13392 bytes
Trying to boot from MMC1
Authentication passed
Authentication passed
Loading Environment from MMC... [read_env:384] blk_start: 0x3400, blk_cnt: 0x100, buffer: 0x81fbfe00
[read_env:384] blk_start: 0x3500, blk_cnt: 0x100, buffer: 0x81fdfe40
[env_import:420] buf: 0x81fdfe40
OK
init_env from device 9 not supported!
Authentication passed
Authentication passed
Starting ATF on ARM64 core...

NOTICE:  BL31: v2.10.0(release):v2.10.0-367-g00f1ec6b87-dirty
NOTICE:  BL31: Built : 16:09:05, Feb  9 2024
I/TC:
I/TC: OP-TEE version: 4.2.0-dev (gcc version 13.3.0 (GCC)) #1 Fri Apr 12 09:51:21 UTC 2024 aarch64
I/TC: WARNING: This OP-TEE configuration might be insecure!
I/TC: WARNING: Please check https://optee.readthedocs.io/en/latest/architecture/porting_guidelines.html
I/TC: Primary CPU initializing
I/TC: GIC redistributor base address not provided
I/TC: Assuming default GIC group status and modifier
I/TC: SYSFW ABI: 4.0 (firmware rev 0x000a '10.0.8--v10.00.08 (Fiery Fox)')
I/TC: HUK Initialized
I/TC: Activated SA2UL device
I/TC: Enabled firewalls for SA2UL TRNG device
I/TC: SA2UL TRNG initialized
I/TC: SA2UL Drivers initialized
I/TC: Primary CPU switching to normal world boot

U-Boot SPL 2024.04-dirty (Dec 16 2024 - 19:51:21 +0530)
SYSFW ABI: 4.0 (firmware rev 0x000a '10.0.8--v10.00.08 (Fiery Fox)')
Trying to boot from MMC1
Authentication passed
Authentication passed


U-Boot 2024.04-dirty (Dec 16 2024 - 19:51:21 +0530)

SoC:   AM64X SR2.0 HS-FS
Model: Texas Instruments AM642 EVM
Board: AM64-GPEVM rev C
DRAM:  2 GiB
Core:  98 devices, 31 uclasses, devicetree: separate
NAND:  0 MiB
MMC:   mmc@fa10000: 0, mmc@fa00000: 1
Loading Environment from MMC... [read_env:384] blk_start: 0x3400, blk_cnt: 0x100, buffer: 0xfde4cd80
[read_env:384] blk_start: 0x3500, blk_cnt: 0x100, buffer: 0xfde6cdc0
[env_import:420] buf: 0xfde6cdc0
OK
In:    serial@2800000
Out:   serial@2800000
Err:   serial@2800000
Net:   eth0: ethernet@8000000port@1, eth2: icssg1-eth-port@0
Hit any key to stop autoboot:  0
=> saveenv
Saving Environment to MMC... Writing to MMC(0)... [write_env:252] blk_start: 0x3400, blk_cnt: 0x100
OK
=> mw 0x43000030 0xcb 0x1;reset;
resetting ...

U-Boot SPL 2024.04-dirty (Dec 16 2024 - 19:51:14 +0530)
SYSFW ABI: 4.0 (firmware rev 0x000a '10.0.8--v10.00.08 (Fiery Fox)')
SPL initial stack usage: 13392 bytes
Trying to boot from MMC1
Authentication passed
Authentication passed
Loading Environment from MMC... [read_env:384] blk_start: 0x3400, blk_cnt: 0x100, buffer: 0x81fbfe00
[read_env:384] blk_start: 0x3500, blk_cnt: 0x100, buffer: 0x81fdfe40
[env_import:420] buf: 0x81fbfe00
OK
init_env from device 9 not supported!
Authentication passed
Authentication passed
Starting ATF on ARM64 core...

NOTICE:  BL31: v2.10.0(release):v2.10.0-367-g00f1ec6b87-dirty
NOTICE:  BL31: Built : 16:09:05, Feb  9 2024
I/TC:
I/TC: OP-TEE version: 4.2.0-dev (gcc version 13.3.0 (GCC)) #1 Fri Apr 12 09:51:21 UTC 2024 aarch64
I/TC: WARNING: This OP-TEE configuration might be insecure!
I/TC: WARNING: Please check https://optee.readthedocs.io/en/latest/architecture/porting_guidelines.html
I/TC: Primary CPU initializing
I/TC: GIC redistributor base address not provided
I/TC: Assuming default GIC group status and modifier
I/TC: SYSFW ABI: 4.0 (firmware rev 0x000a '10.0.8--v10.00.08 (Fiery Fox)')
I/TC: HUK Initialized
I/TC: Activated SA2UL device
I/TC: Enabled firewalls for SA2UL TRNG device
I/TC: SA2UL TRNG initialized
I/TC: SA2UL Drivers initialized
I/TC: Primary CPU switching to normal world boot

U-Boot SPL 2024.04-dirty (Dec 16 2024 - 19:51:21 +0530)
SYSFW ABI: 4.0 (firmware rev 0x000a '10.0.8--v10.00.08 (Fiery Fox)')
Trying to boot from MMC1
Authentication passed
Authentication passed


U-Boot 2024.04-dirty (Dec 16 2024 - 19:51:21 +0530)

SoC:   AM64X SR2.0 HS-FS
Model: Texas Instruments AM642 EVM
Board: AM64-GPEVM rev C
DRAM:  2 GiB
Core:  98 devices, 31 uclasses, devicetree: separate
NAND:  0 MiB
MMC:   mmc@fa10000: 0, mmc@fa00000: 1
Loading Environment from MMC... [read_env:384] blk_start: 0x3400, blk_cnt: 0x100, buffer: 0xfde4cd80
[read_env:384] blk_start: 0x3500, blk_cnt: 0x100, buffer: 0xfde6cdc0
[env_import:420] buf: 0xfde4cd80
OK
In:    serial@2800000
Out:   serial@2800000
Err:   serial@2800000
Net:   eth0: ethernet@8000000port@1, eth2: icssg1-eth-port@0
Hit any key to stop autoboot:  0
=>

Regards,

Prashant

0 Benjamin Postma 10 months ago in reply to Prashant Shivhare

Prodigy 70 points

Hi Prashant,

thanks for your response, and sorry for my delayed answer.

During manufacturing, we want to boot a manufacturing image from SD-Card (connected via needlebed adapter), which contains manufacturing related apps as well as the final images (SPL / U-Boot / Rootfs, etc.), and program these images to the eMMC.

For simplification, it would help to reuse the final U-Boot components (SPL / U-Boot) for the manufacturing (SD-Card) use case. As explained earlier, this is not possible for now, since U-Boot crashes when running from SD-Card, but configured with redundant environment on eMMC.

Prashant Shivhare said:
The U-Boot SPL is designed to probe only the required drivers for booting. If booting from the SD card, the eMMC is not required so it is not probed (driver not initialized) prior to the env load & hence the failure.

Is there a way to initialize eMMC as well as SD-Card during R5 SPL? If environment shall be kept in e.MMC, it should be considered as required for booting, and therefore it should be probed.

Which part initializes the boot device? Internal ROM bootloader, or the R5-SPL? Since the R5-SPL must be loaded as well from the boot device, at least a basic initialization must be done by the ROM loader.
If the R5 SPL (re-)initializes the boot device, where does it get the information about which device to initialize? I would assume that it is somwhere in the device tree (a node with property bootph-all), but I have not found it yet.

Any help is appreciated.

Best regards, Benjamin

0 Benjamin Postma 9 months ago in reply to Benjamin Postma

Prodigy 70 points

Hi,
any update so far?

BR Benjamin

0 Prashant Shivhare 9 months ago in reply to Benjamin Postma

TI__Guru 73241 points

Hello,

Apologies for the delayed response.

The `mmc_initialize` at R5 SPL stage fails because the power domains for eMMC & SD card are disabled in its DTS file.

Could you please try the following patch & let us know if it works?

diff --git a/arch/arm/dts/k3-am64-main.dtsi b/arch/arm/dts/k3-am64-main.dtsi
index e17ea49e790..870bcdbced3 100644
--- a/arch/arm/dts/k3-am64-main.dtsi
+++ b/arch/arm/dts/k3-am64-main.dtsi
@@ -623,7 +623,7 @@
 		compatible = "ti,am64-sdhci-8bit";
 		reg = <0x00 0xfa10000 0x00 0x260>, <0x00 0xfa18000 0x00 0x134>;
 		interrupts = <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>;
-		power-domains = <&k3_pds 57 TI_SCI_PD_EXCLUSIVE>;
+		power-domains = <&k3_pds 57 TI_SCI_PD_SHARED>;
 		clocks = <&k3_clks 57 0>, <&k3_clks 57 1>;
 		clock-names = "clk_ahb", "clk_xin";
 		bus-width = <8>;
@@ -645,7 +645,7 @@
 		compatible = "ti,am64-sdhci-4bit";
 		reg = <0x00 0xfa00000 0x00 0x260>, <0x00 0xfa08000 0x00 0x134>;
 		interrupts = <GIC_SPI 134 IRQ_TYPE_LEVEL_HIGH>;
-		power-domains = <&k3_pds 58 TI_SCI_PD_EXCLUSIVE>;
+		power-domains = <&k3_pds 58 TI_SCI_PD_SHARED>;
 		clocks = <&k3_clks 58 3>, <&k3_clks 58 4>;
 		clock-names = "clk_ahb", "clk_xin";
 		bus-width = <4>;
diff --git a/arch/arm/dts/k3-am642-r5-evm.dts b/arch/arm/dts/k3-am642-r5-evm.dts
index 548cfce8f99..dc23cb654f6 100644
--- a/arch/arm/dts/k3-am642-r5-evm.dts
+++ b/arch/arm/dts/k3-am642-r5-evm.dts
@@ -118,7 +118,7 @@
 };
 
 &sdhci0 {
-	/delete-property/ power-domains;
+	// /delete-property/ power-domains;
 	clocks = <&clk_200mhz>;
 	clock-names = "clk_xin";
 	ti,driver-strength-ohm = <50>;
@@ -127,7 +127,7 @@
 };
 
 &sdhci1 {
-	/delete-property/ power-domains;
+	// /delete-property/ power-domains;
 	clocks = <&clk_200mhz>;
 	clock-names = "clk_xin";
 	disable-wp;

Regards,

Prashant

0 Benjamin Postma 8 months ago in reply to Prashant Shivhare

Prodigy 70 points

Hi Prashant,

sorry for the delayed response, I had high-priority work to do, but will continue to work on remaining bringup topics starting next week.
I will let you know if your patch solves my problem.

BR Benjamin

0 Prashant Shivhare 8 months ago in reply to Benjamin Postma

TI__Guru 73241 points

Thanks for the update. I will wait for your further feedback.

0 Benjamin Postma 7 months ago in reply to Prashant Shivhare

Prodigy 70 points

Hi Prashant,

the changes suggested by you seem to work. I had problems, when I changed the power domains property only in u-boot device tree, and not in linux device tree. Then the kernel failed to access the rootfile system during boot (u-boot booted fine).

I'm also wondering about the following device tree nodes in device tree file k3-am642-r5-evm.dts. How are the single pins related to e.MMC? The e.MMC in our design is connected to the SoC similar compared to the EVM design.
I removed the node and referencing property, and it still works.

&main_pmx0 {
    ospi0_pins_default: ospi0-default-pins {
        pinctrl-single,pins = <
        AM64X_IOPAD(0x0000, PIN_OUTPUT, 0) /* (N20) OSPI0_CLK */
        AM64X_IOPAD(0x002c, PIN_OUTPUT, 0) /* (L19) OSPI0_CSn0 */
        AM64X_IOPAD(0x000c, PIN_INPUT, 0) /* (M19) OSPI0_D0 */
        AM64X_IOPAD(0x0010, PIN_INPUT, 0) /* (M18) OSPI0_D1 */
        AM64X_IOPAD(0x0014, PIN_INPUT, 0) /* (M20) OSPI0_D2 */
        AM64X_IOPAD(0x0018, PIN_INPUT, 0) /* (M21) OSPI0_D3 */
        AM64X_IOPAD(0x001c, PIN_INPUT, 0) /* (P21) OSPI0_D4 */
        AM64X_IOPAD(0x0020, PIN_INPUT, 0) /* (P20) OSPI0_D5 */
        AM64X_IOPAD(0x0024, PIN_INPUT, 0) /* (N18) OSPI0_D6 */
        AM64X_IOPAD(0x0028, PIN_INPUT, 0) /* (M17) OSPI0_D7 */
        AM64X_IOPAD(0x0008, PIN_INPUT, 0) /* (N19) OSPI0_DQS */
        >;
    };

    main_mmc0_pins_default: main-mmc0-pins-default {
        bootph-pre-ram;
        pinctrl-single,pins = <
            AM64X_IOPAD(0x01a8, PIN_INPUT_PULLDOWN, 0)  /* (B25) MMC0_CLK */
            AM64X_IOPAD(0x01aC, PIN_INPUT_PULLUP, 0)    /* (B27) MMC0_CMD */
            AM64X_IOPAD(0x01a4, PIN_INPUT_PULLUP, 0)    /* (A26) MMC0_DAT0 */
            AM64X_IOPAD(0x01a0, PIN_INPUT_PULLUP, 0)    /* (E25) MMC0_DAT1 */
            AM64X_IOPAD(0x019c, PIN_INPUT_PULLUP, 0)    /* (C26) MMC0_DAT2 */
            AM64X_IOPAD(0x0198, PIN_INPUT_PULLUP, 0)    /* (A25) MMC0_DAT3 */
            AM64X_IOPAD(0x0194, PIN_INPUT_PULLUP, 0)    /* (E24) MMC0_DAT4 */
            AM64X_IOPAD(0x0190, PIN_INPUT_PULLUP, 0)    /* (A24) MMC0_DAT5 */
            AM64X_IOPAD(0x018c, PIN_INPUT_PULLUP, 0)    /* (B26) MMC0_DAT6 */
            AM64X_IOPAD(0x0188, PIN_INPUT_PULLUP, 0)    /* (D25) MMC0_DAT7 */
            AM64X_IOPAD(0x01b0, PIN_INPUT, 0)       /* (C25) MMC0_DS */
        >;
    };
};

&sdhci0 {
	/delete-property/ power-domains;
	clocks = <&clk_200mhz>;
	clock-names = "clk_xin";
	ti,driver-strength-ohm = <50>;
	disable-wp;
	pinctrl-0 = <&main_mmc0_pins_default>; 
};

The nodes in my device tree (k3-am642-r5-vem.dts) look like this, and it works.

&sdhci0 {
	clocks = <&clk_200mhz>;
	clock-names = "clk_xin";
	ti,driver-strength-ohm = <50>;
	disable-wp;
};

&sdhci1 {
	clocks = <&clk_200mhz>;
	clock-names = "clk_xin";
	disable-wp;
	pinctrl-0 = <&main_mmc1_pins_default>;
};

Can you please give me a hint to the documentation which describes the power domain property? When do I have to use TI_SCI_PD_EXCLUSIVE, and when TI_SCI_PD_SHARED? Why is it a problem when u-boot and linux device trees have different values for this parameter?

Thank's a lot for your help!

BR Benjamin

0 Prashant Shivhare 7 months ago in reply to Benjamin Postma

TI__Guru 73241 points

Hello,

Benjamin Postma said:
I removed the node and referencing property, and it still works.

Those are pinmuxing configurations. Please do not remove those properties or nodes.

Benjamin Postma said:
Can you please give me a hint to the documentation which describes the power domain property?

Please see the following guide:

https://git.ti.com/cgit/ti-u-boot/ti-u-boot/tree/doc/device-tree-bindings/power/ti,sci-pm-domain.txt

Regards,

Prashant

0 Benjamin Postma 7 months ago in reply to Prashant Shivhare

Prodigy 70 points

Hi,

Prashant Shivhare said:
Those are pinmuxing configurations. Please do not remove those properties or nodes.

I understand that it is the pinmux configuration, but the content of main_mmc0_pins_default (from k3-am642-r5-vem.dts) is not clear to me. MMC0 interface is not connected to pins that are specified in main_mmc0_pins_default, see the following images.

The content of the OSPI interface node ospi0_pins_default matches with the design, see the following images.

I also compared the main_mmc0_pins_default (k3-am62x-sk-common.dtsi) node of the AM62-SK board with the schematic, and here the pins also match.

By the way, the device tree k3-am654-base-board.dts contains the same node main_mmc0_pins_default. Is it possible that the node is only valid for am654-based boards?

Prashant Shivhare said:
Please see the following guide:

https://git.ti.com/cgit/ti-u-boot/ti-u-boot/tree/doc/device-tree-bindings/power/ti,sci-pm-domain.txt

Thanks for the hint. Still not really clear to me, seems that I have to dive deeper in documentation.

BR Benjamin

0 Prashant Shivhare 7 months ago in reply to Benjamin Postma

TI__Guru 73241 points

Benjamin Postma said:
but the content of main_mmc0_pins_default (from k3-am642-r5-vem.dts) is not clear to me. MMC0 interface is not connected to pins that are specified in main_mmc0_pins_default, see the following images.

That's unexpected. I will once check internally & get back to you.

Thanks!

Processors

Processors forum

PROCESSOR-SDK-AM64X: Redundant u-boot environment in eMMC