Mity CPU Platforms » MitySOM-AM62, MitySOM-AM62A, & MitySOM-AM62P

Hi Nathan,

Based on this from your comment:

So I took an image of first 9000 512 blocks of /dev/mmcblk0 ...

I am wondering if uBoot is booting from /dev/mmcblk0 and not /dev/mmblk0boot0 (which would explain your results). Or did you mean you dumped out /dev/mmblk0boot0 in your check?

I will look into this on Monday.

With regards,
Mike

How would I determine that?

In uboot, there is the mmc command and the existing script sets mmcdev to 0 and bootpart to 0 (once it failed to boot at mmcdev 1, bootpart 1:2).

I was under the impression that the mmcblk0boot0 was a linux construct. How does one target that from uboot?

Please forgive my ignorance!

Or did you mean you dumped out /dev/mmblk0boot0 in your check?

Can you confirm this part of Mike's question?

It sounds like you were writing to mmcblk0boot0 but u-boot is using mmblk0 instead for the environment location. If that's the case, try writing to mmcblk0 instead and let us know if that works.

Note according to our emmc boot instructions. https://support.criticallink.com/redmine/projects/mitysom_am62x/wiki/Boot_EMMC#EMMC-Layout

We do expect the environment to be in the boot0 block. My first guess is this was tested with the 2023 u-boot and might be misconfigured in the 2024 u-boot.

In my checks I tested both blocks. Reading back mmcblk0boot0 did show the environment. Reading back mmcblk0 did not have the environment. This is why I was speculating that Linux wasn't really writing to the actual device.

The probable source of my confusion is that I thought those we were same place.
I thought mmcblk0boot0 was like a read-only window to the front of the emmc.
So, I expected these two commands to technically write to the same location on the media...

dd if=uboot.env  of=/dev/mmcblk0boot0 bs=512 seek=7944
    dd if=uboot.env  of=/dev/mmcblk0 bs=512 seek=7944

This is apparently not the case?

Further confusing me is that we do boot from the emmc successfully.
So uboot is using mmcblk0boot0 to get the tiboot3.bin, tispl.bin, and u-boot.img, but it is using mmcblk0 for the environment.

Which I guess is fine since we have the workaround of initializing the environment with fw_setenv command.

I would like to understand it though.

It looks to me like this is misconfigured in both 2023 and 2024 u-boot.

Here is a trimmed-down version of the u-boot config.

$ ag ENV_ build-mitysom_am62x_devkit/a53/u-boot.cfg
#define CONFIG_ENV_OFFSET 0x3E1000
#define CONFIG_ENV_SIZE 0x1f000
#define CONFIG_SYS_MMC_ENV_DEV 0
#define CONFIG_ENV_IS_IN_MMC 1
#define CONFIG_SPL_ENV_IS_IN_MMC 1
#define CONFIG_SYS_MMC_ENV_PART 0

According to this, u-boot is going to look for the environment exactly where you found it. at address offset 0x3e1000 on mmcblk0. Unfortunately, that is inside the root partition so we need to fix that.

Pushed fix to u-boot 2023 and 2024
https://support.criticallink.com/gitweb/?p=u-boot-ti.git;a=commit;h=bb86b0aa5782cc2dcf2fe95c6009c93ae9394263

Test printing the environment after having saved it from u-boot

# dd if=/dev/mmcblk0boot0 bs=512 iseek=7944 | strings
7addr_fit=0x90000000
arch=arm
args_all=setenv optargs ${optargs} earlycon=ns16550a,mmio32,0x02800000 ${mtdparts}
args_mmc=run finduuid;setenv bootargs console=${console} ${optargs} root=PARTUUID=${uuid} rw rootfstype=${mmcrootfstype}
args_ospi_nand=setenv bootargs console=${console} ${optargs} ubi.mtd=${ospi_nand_bootpart} root=${ospi_nand_bootvolume} rootfstype=ubifs
...

The probable source of my confusion is that I thought those we were same place.
I thought mmcblk0boot0 was like a read-only window to the front of the emmc.

Correct. eMMC spec adds two unique boot sections and an rpmb? section. Which are distinct from the regular flash storage area seen on sdcards.